From owner-ipsec@lists.tislabs.com Thu Apr 1 11:21:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02554; Thu, 1 Apr 1999 11:21:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02677 Thu, 1 Apr 1999 11:44:52 -0500 (EST) Date: Thu, 1 Apr 1999 12:06:13 -0500 Message-Id: <199904011706.MAA00212@brill.shiva.com> From: John Shriver To: ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, we could call it ECW for Ellis-Cocks-Williamson, for the three folks who originally invented these algorithms at the UK Government Communications Headquarters long before Rivest & co. See the April 1999 issue of Wired. Well, Cocks is the person who came up with the product of two large primes idea, in 1973. Williamson is the one who came up with what we now know as Diffie-Hellman. So, we could just call it Cocks. From owner-ipsec@lists.tislabs.com Thu Apr 1 12:37:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03183; Thu, 1 Apr 1999 12:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02937 Thu, 1 Apr 1999 12:47:11 -0500 (EST) From: "Jeff Carr" To: "Steven M. Bellovin" Cc: Subject: RE: IPSec for IP Telephony Date: Thu, 1 Apr 1999 10:11:05 -0800 Message-ID: <000f01be7c6b$028a1020$17b4a8c0@pc-jcarr.broadcom.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 Importance: Normal In-Reply-To: <19990330122732.93EAD41F16@SIGABA.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Granted the overhead is high wrt the small packet sizes, and ESP does interfere with the desire to compress headers (assuming no transport-friendly ESP) ------ but I am curious about your comparison of the threat models. Why are they very, very different? Jeff Carr Broadcom Corporation > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin > Sent: Tuesday, March 30, 1999 4:27 AM > To: Scott Cadzow > Cc: 'Stephen Kent'; Costantini, Frank ; ipsec@lists.tislabs.com > Subject: Re: IPSec for IP Telephony > > > > That said, it isn't clear to me that IPSEC is the right answer in any > event -- the overhead is high, relative to the very small packet size, > and its strong protection properties interfere with header compression. > Besides, the threat model is very, very different. We are dealing with > very limited bandwidth on the access lines; our general answer doesn't > seem to fit Internet telephony very well. > > > From owner-ipsec@lists.tislabs.com Thu Apr 1 12:43:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03229; Thu, 1 Apr 1999 12:43:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03107 Thu, 1 Apr 1999 13:17:17 -0500 (EST) To: "Jeff Carr" Cc: ipsec@lists.tislabs.com Subject: Re: IPSec for IP Telephony Date: Thu, 01 Apr 1999 13:40:30 -0500 From: "Steven M. Bellovin" Message-Id: <19990401184035.E555E41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <000f01be7c6b$028a1020$17b4a8c0@pc-jcarr.broadcom.com>, "Jeff Carr" writes: > Granted the overhead is high wrt the small packet sizes, and ESP does > interfere with the desire to compress headers (assuming no > transport-friendly ESP) ------ but I am curious about your comparison of the > threat models. Why are they very, very different? When you're dealing with general Internet hosts, you have to worry about all sorts of other services that might be able to use the same key pair. See http://www.research.att.com/~smb/papers/badesp.ps (or .pdf) -- even apart from the fixes to ipsec, most of the attacks described simply don't apply. To give just one example, here we want to protect the voice channel only; there are no other port numbers involved. From owner-ipsec@lists.tislabs.com Thu Apr 1 12:50:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03269; Thu, 1 Apr 1999 12:50:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03142 Thu, 1 Apr 1999 13:20:05 -0500 (EST) Date: Thu, 1 Apr 1999 13:42:46 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm In-Reply-To: <199904011706.MAA00212@brill.shiva.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmm, if Messrs. S and A are no longer involved with the company, we could show our opinion of this latest maneuver by calling the algorithm "rSA". (It's probably not a big enough change to get us into the clear. Pity.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Apr 1 14:26:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04108; Thu, 1 Apr 1999 14:26:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03467 Thu, 1 Apr 1999 14:40:09 -0500 (EST) Date: Thu, 1 Apr 1999 15:03:31 -0500 From: Raul Miller To: IP Security List Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Message-ID: <19990401150331.E24636@rdm.legislate.com> Mail-Followup-To: IP Security List References: <199904011706.MAA00212@brill.shiva.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Henry Spencer on Thu, Apr 01, 1999 at 01:42:46PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > Hmm, if Messrs. S and A are no longer involved with the company, we could > show our opinion of this latest maneuver by calling the algorithm "rSA". > > (It's probably not a big enough change to get us into the clear. Pity.) On the other hand, if Mr. Rivest objects to the use of his initial, perhaps it would be right to stop using it... -- Raul From owner-ipsec@lists.tislabs.com Thu Apr 1 14:50:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04311; Thu, 1 Apr 1999 14:50:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03698 Thu, 1 Apr 1999 15:32:50 -0500 (EST) Message-Id: <199904012049.PAA00657@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algor ithm In-reply-to: Your message of "Wed, 31 Mar 1999 07:45:30 PST." <4.2.0.32.19990331074444.0235a510@mail.imc.org> Date: Thu, 01 Apr 1999 15:49:50 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman writes: Paul> I suggest that we wait until RSA sends a letter to the IETF Paul> or to individual IPsec implementors about this. So, who has actually received the letter then? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Apr 1 15:23:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA04650; Thu, 1 Apr 1999 15:23:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03852 Thu, 1 Apr 1999 16:03:49 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 01 Apr 1999 14:17:17 -0700 From: "Hilarie Orman" To: Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA03849 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our essay is Arse-A Hilarie From owner-ipsec@lists.tislabs.com Thu Apr 1 16:03:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05059; Thu, 1 Apr 1999 16:03:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04040 Thu, 1 Apr 1999 16:52:28 -0500 (EST) Message-ID: <3703F00D.497ACE79@cs.umass.edu> Date: Thu, 01 Apr 1999 17:15:41 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IP Security WG List CC: Michael Richardson Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algor ithm References: <199904012049.PAA00657@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > So, who has actually received the letter then? IEEE P1363; see http://grouper.ieee.org/groups/1363/letters/SecurityDynamics.jpg From owner-ipsec@lists.tislabs.com Thu Apr 1 17:38:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA06279; Thu, 1 Apr 1999 17:38:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04312 Thu, 1 Apr 1999 18:20:14 -0500 (EST) Message-Id: <4.2.0.32.19990401153717.00ac8300@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Thu, 01 Apr 1999 15:43:32 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algor ithm In-Reply-To: <199904012049.PAA00657@pzero.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:49 PM 4/1/99 -0500, Michael Richardson wrote: > So, who has actually received the letter then? Burt Kaliski, who (humorously enough) works for RSA Labs. See for the actual copy of the letter. The letter is typically vague on what RSA (now Security Dynamics) might or might not do in the future with the trademark. It doesn't sound in the least bit threatening, and it all but admits that it is way too late to do anything about IEEE 1363. Again, I think we can let this one slide until they tell us the want to do something definite. At that point, we can decide whether they have any real legal argument, and can move forwards then. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 1 19:09:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA08597; Thu, 1 Apr 1999 19:09:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04520 Thu, 1 Apr 1999 19:46:36 -0500 (EST) From: fisher@hollywood.engr.sgi.com (William Fisher) Message-Id: <199904020107.RAA11794@hollywood.engr.sgi.com> Subject: Re: RSA claiming trademark on all uses of "RSA" to describe To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 1 Apr 1999 17:07:42 -0800 (PST) Cc: ipsec@lists.tislabs.com, fisher@hollywood.engr.sgi.com (William Fisher) In-Reply-To: <4.2.0.32.19990401153717.00ac8300@mail.imc.org> from "Paul Hoffman" at Apr 1, 99 03:43:32 pm Reply-To: fisher@sgi.com X-Mailer: ELM [version 2.4 PL3] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > At 03:49 PM 4/1/99 -0500, Michael Richardson wrote: > > So, who has actually received the letter then? > > Burt Kaliski, who (humorously enough) works for RSA Labs. See > for the > actual copy of the letter. > > The letter is typically vague on what RSA (now Security Dynamics) might or > might not do in the future with the trademark. It doesn't sound in the > least bit threatening, and it all but admits that it is way too late to do > anything about IEEE 1363. > > Again, I think we can let this one slide until they tell us the want to do > something definite. At that point, we can decide whether they have any real > legal argument, and can move forwards then. > > --Paul Hoffman, Director > --VPN Consortium > I just did a search of the trademarks for RSA via the government trademarks web site: http://trademarks.uspto.gov and there are the following ones registered: RSAREF RC2 RC4 RSASIGN RSACHECK RSA Data Security, Inc. The Keys to Privacy and Authentication The IEEE letter notes: "The terms "RSA public key", "RSA private key", and "RSA Key Pair" in section 8.1.3 of the draft standard and elsewhere may similarly be affectd by such protection". Hence it appears that either RSA hasn't filed trademarks on the above three "marks". Looking for all the trademarks owned by Security Dynamics pertaining to the RSA prefix we find: ACE/Sentry RSASecurPC SecurityDynamics, WEBID Thinking Ahead Put us Ahead SOFTID ACE/Server SecurID SecurityDynamics, ACE Access Control Encryption Hence I did not find any Registered trademarks by either RSA or Security Dynamics pertaining to the following three names: "RSA public key", "RSA private key", and "RSA Key Pair" Maybe this falls under some close or approximately similar clause. -- Bill (fisher@sgi.com) From owner-ipsec@lists.tislabs.com Fri Apr 2 06:02:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10971; Fri, 2 Apr 1999 06:02:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05797 Fri, 2 Apr 1999 06:09:55 -0500 (EST) Date: Fri, 2 Apr 1999 14:33:17 +0300 (EET DST) From: Tero Kivinen Message-Id: <199904021133.OAA27393@torni.ssh.fi> To: ipsec@lists.tislabs.com Subject: draft-kivinen-ike-ext-meth-00.txt Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is a draft I promised to send to the list about the extension mechanisms in the IKE. I would like to hear your comments about this. ---------------------------------------------------------------------- Network Working Group T. Kivinen INTERNET-DRAFT SSH Communications Security draft-kivinen-ike-ext-meth-00.txt 17 March 1999 Expires in six months IKE Extensions Methods Status of This memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in IKE [RFC-2409]. T. Kivinen [page 1] INTERNET-DRAFT 17 March 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Sending Error Notifications . . . . . . . . . . . . . . . . . . 3 5. Order of Checking . . . . . . . . . . . . . . . . . . . . . . . 3 6. ISAKMP Major and Minor Version Numbers . . . . . . . . . . . . . 3 6.1. ISAKMP Major Version Number . . . . . . . . . . . . . . . . 4 6.2. ISAKMP Minor Version number . . . . . . . . . . . . . . . . 4 7. Exchange type . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Flags Inside the Generic Packet Header . . . . . . . . . . . . . 5 9. Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . 7 11. Data Attribute Types and Values . . . . . . . . . . . . . . . . 7 11.1. Data Attributes, Protocol and Transform IDs . . . . . . . . 8 12. Reserved Fields . . . . . . . . . . . . . . . . . . . . . . . . 8 13. Identity Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. Certificate Encoding . . . . . . . . . . . . . . . . . . . . . 9 15. Notify Message Type . . . . . . . . . . . . . . . . . . . . . . 9 16. Domain of Interpretation . . . . . . . . . . . . . . . . . . . 10 17. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The ISAKMP [RFC-2408] and IKE [RFC-2409] protocols can be extended in various ways. It is not clearly defined in the current document set how to use the extension mechanisms. Also, the current document set does not clearly define what a conforming implementation should do if it receives an extension that it does not understand. This document describes how to provide backwards compatibility with the old versions. The reader is assumed to be familiar with most of the terms and concepts described in the ISAKMP [RFC-2408] and IKE [RFC-2409] documents. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC-2119] document. 3. Terminology This document uses the terms "new version" and "old version" to identify the two different protocol versions. The new version is the version that supports the new extension, and the old version is a version that does not support it. The terms should always be interpreted only in the T. Kivinen [page 2] INTERNET-DRAFT 17 March 1999 current context. 4. Sending Error Notifications If the other end does not send error notifications, it is very hard to create usable extensions to the protocol. In that case the only way to detect whether the other end supports the extension is to see if the negotiation times out. This may cause unnecessary delays in the negotiation process. Because of that, all implementations SHOULD send notifications back when they reject any extensions. Implementations MAY limit the number of notifications sent out. A suitable limit could be something like one notification per second per host. Implementations SHOULD still continue sending notifications back when the other end resends its own packet (in case the error notification was lost). 5. Order of Checking The order of checks performed for packet SHOULD be following: o Major version number o Minor version number o Exchange type o Flags in the generic header o Payload types o Reserved field in the generic payload header o Packet specific checks. 6. ISAKMP Major and Minor Version Numbers All IKE packets contain version numbers, which describe the major and minor version numbers of the sending party. In IKE version 1.0 these version numbers are not authenticated. Thus when they are later changed to be authenticated, there always exists the possibility of a version rollback attack where the attacker forces negotiating parties to fall back to the version 1.0. This can be prevented by disabling the version 1.0 protocol. Major version number changes when major changes are done to the protocol, i.e there are changes in the generic packet encoding routines. This means that the older versions cannot understand the newer packet format at all. Minor version number changes when new payloads are defined or other minor changes in the protocol take place. The older versions can still process the generic packet structure, but there might be small T. Kivinen [page 3] INTERNET-DRAFT 17 March 1999 variations in the fields inside the payloads. Each party MUST NOT change the version number it is sending during one negotiation, i.e if negotiation was started using version number 1.1, it MUST be used during the whole negotiation. Separate negotiations MAY have different version numbers, i.e newer version may restart negotiation with older version number. Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 negotiation that creates ISAKMP SA may use version X, and phase 2 negotiation done over that ISAKMP SA may use version Y. Because the minor version number is encoded into a 4-bit field (0-15), a minor version number rollover might occur. This means that the major version number must be incremented even if the packet structure is still actually same. Because of this phenomenon, incrementing the minor version number SHOULD be avoided if it is not absolutely necessary. Implementation supporting minor version X MUST support all features up to that level (it MUST at least be able to ignore the non-critical extensions, and detect critical extensions and abort the negotiation in that case). 6.1. ISAKMP Major Version Number If an old version receives a packet with a major version number larger than its own, it SHOULD send the INVALID-MAJOR-VERSION notification back. It MUST put its own version number inside the notification packet. This gives the other end the opportunity to obtain the version number supported by the sender of the notification. The received packet MUST then be discarded (the old version cannot parse anything else in the packet because the generic packet structure has changed). Note that in most cases this notification sent by the remote host is not authenticated, so it can also lead to the version rollback attack. A new version receiving the INVALID-MAJOR-VERSION notification MAY fall back to the older version. If falling back to the older version has security implications then the new version SHOULD NOT fall back to previous version but instead fail the negotiation with a clear error message). 6.2. ISAKMP Minor Version number If an old version receives a packet with a minor version newer than its own, it o SHOULD continue processing the packet, or it o MAY discard the packet. In that case it SHOULD send the INVALID- MINOR-VERSION notification back. In any case the old version MUST respond with a packet containing the T. Kivinen [page 4] INTERNET-DRAFT 17 March 1999 local minor version number so that a new version can get the older version number and fall back to same version if necessary. The new version MAY always start with the latest version number and fall back to the previous version every time separately, or it MAY cache this information for some time, or the version number used may be configured manually. 7. Exchange type An exchange type defines a generic packet exchange between two negotiating parties. It defines the number of packets in the exchange, the generic meaning of the packets (i.e. in main mode the first two packets exchange SA payloads, the next two packets are used for the key exchange, and the final two packets are used to exchange identities and to authenticate the exchange). If an implementor wants to add new packets to the existing exchanges, then the implementor MUST create a new exchange and allocate a new exchange type for it. If an implementation receives a packet that contains an exchange type it does not understand it SHOULD send back the INVALID-EXCHANGE-TYPE notification. Also it MUST ignore the packet. If an implementation receives the INVALID-EXCHANGE-TYPE notification it MAY fall back to a more standard exchange (for example, from the aggressive mode to the main mode). When new exchange types are added, the minor version number SHOULD NOT be updated. A new version MAY always start with the new exchange type and fall back to a previous, more standard exchange type every time separately, or it MAY cache this information for some time, or the exchange type used may be configured manually. 8. Flags Inside the Generic Packet Header Flags are a part of the generic ISAKMP packet structure. Currently, three flags are defined (encryption, commit bit, authentication only bit). When new flags are defined the minor version number MUST be updated. When a new flag is added, the specification MUST indicate if this flag has any security implications and whether a new version should fail the negotiation if the other end is using an old version. If the old version receives a packet with a newer minor version number, and some unknown flags are set it o SHOULD continue the exchange and ignore the new flags, or it T. Kivinen [page 5] INTERNET-DRAFT 17 March 1999 o MAY fail the negotiation. In that case it SHOULD send the INVALID- FLAGS notification back. If a new version notices that the other end is using an old version (from the version numbers) it MUST fail the negotiation if it tried to set a flag that has security implications. If the flag it set does not have security implications it MAY continue the exchange. 9. Payload Types Each payload inside a packet contains a type field in the generic payload header. The payload type describes the internal structure of the payload. Unknown payloads can be ignored because the generic payload header contains the length of the payload data. Payload types in the special private range are to be used for mutually consenting implementations only. Implementations SHOULD NOT send payloads of a private type unless the both parties have both sent and received a familiar vendor ID payload. After this exchange of the vendor ID payloads during the phase 1, implementations MAY immediately start sending private payloads. When new payload types are defined (other than private-use payloads), and a new version can detect from somewhere else than from version numbers that the other end understands or does not understand the new payload types, then the minor version number SHOULD NOT be updated. If there is no way to detect if the other end understands the newly defined payload types then the minor version number SHOULD be updated. For example if the newly defined payload type can only be used in a certain new exchange type (like the proposed attribute payload inside the transactional exchange) then an old version will fail the negotiation because of the new exchange type, and a new version can detect that. There is no need to update the version number in that case. This allows for creating optional features in the IKE protocol in such a manner that the implementors do not need to implement them all. Every time the minor version number is updated all the implementations MUST understand all the new mandatory payloads. Note that there is a risk of "mix of match" in this approach. In the case of a new generic payload that can be used in several exchanges etc, the minor version number MAY be updated. When a new payload type is added, the corresponding specification MUST indicate if the new payload has any security implications and whether a new version should fail the negotiation if the other end is using an old version. The specification MUST also indicate whether it is mandatory to implement the new feature or not. If the implementation receives an unknown private payload type it o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- T. Kivinen [page 6] INTERNET-DRAFT 17 March 1999 PAYLOAD-TYPE notification back. If the implementation receives an unknown payload type from the RESERVED range and the version numbers are same, it MUST fail the negotiation, and it SHOULD send INVALID-PAYLOAD-TYPE notification back. If the implementation receives unknown payload type from the RESERVED range, and the other ends minor version number is newer, it o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- PAYLOAD-TYPE notification back. If the new version has sent out a payload of a type that is defined first in a newer version of the protocol than an other end understands (this can be detected by checking the minor version number), and such that the payload has security implications then it MUST fail the negotiation. There may be a need to add a criticality flag in the generic payload header in the next version of IKE [RFC-2409]. This allows an old version to detect immediately whether it can safely ignore the payload or whether it MUST fail the negotiation (in that case it SHOULD send an error notification). This criticality flag could be added to the reserved field of the generic payload header (there are 8 reserved bits inside the generic payload header). 10. Vendor ID Payload The vendor ID payload is a payload that can be included anywhere in the phase 1 negotiation. It gives the other end a possibility to recognize the remote implementation. Vendor ID has two uses. The first one is that by sending a vendor ID payload the initiator specifies whose private-use values it is using (it SHOULD only send only one vendor ID, or at least all the vendor ID payloads MUST have same owner, i.e they MUST NOT have overlapping private numbers defining different things). The second use is to allow for vendor specific extensions, after both ends have sent and received familiar vendor IDs. Implementations MUST NOT fail a negotiation because of the presence of the vendor ID payload, i.e. they MUST be able to ignore it. If familiar vendor ID payloads have been exchanged (both sent and received) then implementations MAY do anything, including using private extensions, private payloads, new identity types, running nethack over the ISAKMP SA, etc. 11. Data Attribute Types and Values T. Kivinen [page 7] INTERNET-DRAFT 17 March 1999 SA payloads and some other payloads in the IKE contain data attributes. Data attribute consists of an attribute type and a value. The data attribute type and value number spaces are divided into two parts: The IANA range and the private-use range. The phase 1 data attribute types and values are defined in the IKE document. The Phase 2 data attributes are defined in the DOI [RFC-2407] document. The private-use data attribute TYPES can be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values the sender is using. When adding new IANA registered data attribute TYPES the minor number of the protocol MAY be updated. The private-use data attribute VALUES can also be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values sender is using. When adding new IANA registered data attribute VALUES the minor number of the protocol SHOULD NOT be updated. 11.1. Data Attributes, Protocol and Transform IDs The proposal or transform payload MUST NOT be selected by the responder if it contains unknown protocol IDs, transform IDs, data attribute types, or data attribute values. This means that an initiator SHOULD always include a proposal without any private-use types or values so that if the other end does not understand them then it may select the transform or proposal without private-use types or values. 12. Reserved Fields Lots of payloads in the IKE contain RESERVED fields that are defined to be zero and whose contents MUST be checked. This makes extension of the payloads very difficult to implement. Changing this so that their contents MUST be checked only if the version numbers are same makes it much easier to introduce backwards compatible extensions to the protocol in the future. When a new use of a RESERVED field is defined the minor version number MUST be updated. When a new use of a RESERVED field is defined, the corresponding specification MUST indicate if this new use of the RESERVED field has any security implications and whether a new version should fail the negotiation if the other end is using an old version. If an old implementation receives a packet that contains a non-zero RESERVED field, and the version number of the other end is newer than the local one then it o SHOULD ignore the contents of the RESERVED field and continue, or it T. Kivinen [page 8] INTERNET-DRAFT 17 March 1999 o MAY ignore the message. In that case it SHOULD send the INVALID- RESERVED-FIELD notification back. If the new version notices that the other end is using the old version it MUST fail the negotiation if it tried to use the RESERVED field in such a way that has security implications. If the new defined use of the RESERVED field does not have security implications it MAY continue the exchange. 13. Identity Type The identity type is used to specify the interpretation of the identity payload contents. When a new identity type is specified the minor version number MUST be incremented. If an old version receives an unknown identity type, it MUST fail the negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification back. A new version MAY always start with the new identity type and fall back to a previous more standard identity type every time separately, or it MAY cache this information for some time, or it MAY configure the identity type to be used manually. 14. Certificate Encoding Certificate encoding is used to specify the interpretation of the certificate payload contents. When a new certificate encoding type is added the minor version number SHOULD NOT be incremented. If an old version receives an unknown certificate encoding type, it o SHOULD just ignore the payload, and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- CERT-ENCODING notification back. 15. Notify Message Type Messages containing notify payload are sent to either notify an error situation or to give out status information. Each notify payload contain a notify message type, which describes the message type. If an unknown error (1 <= code <= 16383) notification type is received the receiver MUST treat it as a fatal error and abort the negotiation. If an unknown status (16384 <= code <= 32767) notification type is received the receiver MUST ignore the notification payload. T. Kivinen [page 9] INTERNET-DRAFT 17 March 1999 For example, a new keep-alive protocol for the ISAKMP SA may be defined by just defining that both ends must send a new STILL-CONNECTED notification every 60 seconds. If the other end never sees those notifications, it just assumes that the other end does not support this feature, and ceases to send any further keep-alive packets. If that new STILL-CONNECTED status code is selected from the status code range, then old implementations will just ignore them. When using notifications, implementations must take care of what to do with the notifications which are not authenticated (i.e those received before the ISAKMP SA is ready). If there is no ISAKMP SA established with the remote host, then most of the notifications may still be trusted in order to avoid lengthy timeouts in error situations. If there is a ISAKMP SA established, then unauthenticated notifications should propably be ignored. 16. Domain of Interpretation A domain of interpretation describes all the phase 2 numbers to be used in that domain of interpretation. If an unknown domain of interpretation is received the responder MUST discard the packet and it SHOULD send the DOI-NOT-SUPPORTED notification back. This usually also means that the negotiation is aborted. When a new domain of interpretation is defined the minor version number MUST NOT be incremented. 17. Security Considerations This document describes how to use the extension mechanisms to [RFC-2408] and IKE [RFC-2409]. Because some of those extensions might have security implications it is required that when those extensions are defined it is also explained what security implications they have and what the implementations supporting them should do if the other end does not support the extensions. One security problem comes from the [RFC-2408] and IKE [RFC-2409] protocol, because the version number, exchange type, and flags fields are not authenticated in the version 1.0 protocol. If a real security problem is later found from the 1.0 protocol the implementors MUST make sure that they never fall back to any previous version because the attacker can force falling back to previous version by changing the version numbers inside the packets. Another security problem comes from the fact that there is no way to send authenticated notifications before the phase 1 (ISAKMP) SA is finished. This means that most of the error notifications about the Phase 1 exchange are sent without any kind of protection. 18. References [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", November T. Kivinen [page 10] INTERNET-DRAFT 17 March 1999 1998. [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 19. Authors' Addresses Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi T. Kivinen [page 11] -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Apr 4 06:26:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26550; Sun, 4 Apr 1999 06:26:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10594 Sun, 4 Apr 1999 07:03:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 31 Mar 1999 14:12:33 -0700 From: "Tolga Acar" To: Subject: Algorithm OIDs in RFC 2104 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA10591 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wonder if there is an OID for predefined HMAC algorithms in RFC 2104. There is one specified for HMAC-SHA1 in PKCS#5, in the RSADSI arch: rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} I couldn't find one for SHA-1. Are they defined somewhere else ? - Tolga From owner-ipsec@lists.tislabs.com Mon Apr 5 12:20:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06748; Mon, 5 Apr 1999 12:20:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13694 Mon, 5 Apr 1999 12:14:32 -0400 (EDT) Message-ID: <6236E58EC451D1119E80006097040ED9EE9968@lobester.rsa.com> From: Bob Baldwin To: "'Tolga Acar'" , ipsec@lists.tislabs.com Subject: Algorithm OIDs for SHA1 & RSADSI OIDs Date: Mon, 5 Apr 1999 09:42:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE7F83.5B520DA0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE7F83.5B520DA0 Content-Type: text/plain; charset="iso-8859-1" Tolga, The OID for SHA1 comes from ISO. As bytes it is: unsigned char SHA1_OID[] = {43, 14, 3, 2, 26}; As ASN.1 it is: secsig OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) } id-sha1 OBJECT IDENTIFIER ::= { secsig 2 26 } The attached file has a list of the OIDs registered by RSA Data Security. --Bob Baldwin Technical Director, RSA Data Security -----Original Message----- From: Tolga Acar [mailto:TACAR@novell.com] Sent: Wednesday, March 31, 1999 1:13 PM To: ipsec@lists.tislabs.com Subject: Algorithm OIDs in RFC 2104 I wonder if there is an OID for predefined HMAC algorithms in RFC 2104. There is one specified for HMAC-SHA1 in PKCS#5, in the RSADSI arch: rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} I couldn't find one for SHA-1. Are they defined somewhere else ? - Tolga ------_=_NextPart_000_01BE7F83.5B520DA0 Content-Type: text/plain; name="oids.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="oids.txt" Content-Location: ATT-0-6F7CDFE66BEAD2119E9C006097040ED9-o ids.txt Object Identifiers Registered by RSA Data Security, Inc. An RSA Laboratories Technical Note RSA Data Security, Inc.'s OSI (Open Systems Interconnection) object identifier is 1.2.840.113549 (0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d in = hex),=20 as registered by the American National Standards Institute (ANSI).=20 In the following, the prefix "rsadsi" refers to that object identifier. = All object identifers registered by RSA Data Security begin with this = prefix.=20 NAME VALUE REFERENCE pkcs rsadsi.1 (none) pkcs-1 pkcs.1 PKCS #1 rsaEncryption pkcs-1.1 " " md2WithRSAEncryption pkcs-1.2 " " md4WithRSAEncryption pkcs-1.3 " " md5WithRSAEncryption pkcs-1.4 " " sha1WithRSAEncryption pkcs-1.5 BSAFE 3.0, = SET rsaOAEPEncryptionSET pkcs-1.6 SET id-RSAES-OAEP pkcs-1.7 PKCS#1 v2.0 id-mfg1 pkcs-1.8 PKCS#1 v2.0 id-pSpecified pkcs-1.9 PKCS#1 v2.0 pkcs-3 pkcs.3 PKCS #3 dhKeyAgreement pkcs-3.1 " " pkcs-5 pkcs.5 PKCS #5 pbeWithMD2AndDES-CBC pkcs-5.1 " " pbeWithMD5AndDES-CBC pkcs-5.3 " " pbeWithMD2AndRC2-CBC pkcs-5.4 BSAFE 2.0 pbeWithMD5AndRC2-CBC pkcs-5.6 BSAFE 2.0 pbeWithMD5AndXOR pkcs-5.9 = FASTCRYPT/BSAFE 3.0 pbeWithSHAAndDES-CBC pkcs-5.10 BSAFE 3.0 pkcs-7 pkcs.7 PKCS #7 data pkcs-7.1 " " signedData pkcs-7.2 " " envelopedData pkcs-7.3 " " signedAndEnvelopedData pkcs-7.4 " " digestedData pkcs-7.5 " " encryptedData pkcs-7.6 " " dataWithAttributes pkcs-7.7 FASTCRYPT encryptedPrivateKeyInfo pkcs-7.8 Netscape = SSLREF pkcs-9 pkcs.9 PKCS #9 emailAddress pkcs-9.1 " " unstructuredName pkcs-9.2 " " contentType pkcs-9.3 " " messageDigest pkcs-9.4 " " signingTime pkcs-9.5 " " countersignature pkcs-9.6 " " challengePassword pkcs-9.7 " " unstructuredAddress pkcs-9.8 " " extendedCertificateAttributes pkcs-9.9 " " issuerAndSerialNumber pkcs-9.10 (tentative) PKCS #9 = draft passwordCheck pkcs-9.11 (tentative) PKCS #9 = draft publicKey pkcs-9.12 (tentative) PKCS #9 = draft signingDescription pkcs-9.13 (tentative) S/MIME X.509 extension pkcs-9.14 (tentative) TIPEM 2.0 symmetricCapabilities pkcs-9.15 (tentative) S/MIME v2 friendlyName pkcs-9.20 PKCS #12 = v1.0 localKeyID pkcs-9.21 " " " certTypes pkcs-9.22 " " " x509Certificate certTypes.1 " " " sdsiCertificate certTypes.2 " " " crlTypes pkcs-9.23 " " " x509Crl crlTypes.1 " " " pkcs-12 pkcs.12 PKCS #12 = v1.0 pkcs-12PbeIds pkcs-12.1 " " " pbeWithSHA1And128BitRC4 pkcs-12PbeIds.1 " " " pbeWithSHA1And40BitRC4 pkcs-12PbeIds.2 " " " pbeWithSHA1And3-KeyTripleDES-CBC pkcs-12PbeIds.3 " " " pbeWithSHA1And2-KeyTripleDES-CBC pkcs-12PbeIds.4 " " " pbeWithSHA1And128BitRC2-CBC pkcs-12PbeIds.5 " " " pbeWithSHA1And40BitRC2-CBC pkcs-12PbeIds.6 " " " pkcs-12Version1 pkcs-12.10 " " " pkcs-12BagIds pkcs-12Version1.1 " " " keyBag pkcs-12BagIds.1 " " " pkcs-8ShroudedKeyBag pkcs-12BagIds.2 " " " certBag pkcs-12BagIds.3 " " " crlBag pkcs-12BagIds.4 " " " secretBag pkcs-12BagIds.5 " " " safeContentsBag pkcs-12BagIds.6 " " " digestAlgorithm rsadsi.2 (none) md2 digestAlgorithm.2 RFC 1319 md4 digestAlgorithm.4 RFC 1320 md5 digestAlgorithm.5 RFC 1321 id-hmacWithMD5 digestAlgorithm.6 RFC 2401 & = 2202 id-hmacWithSHA1 digestAlgorithm.7 RFC 2401 & = 2202 encryptionAlgorithm rsadsi.3 (none) rc2CBC encryptionAlgorithm.2 12/92 OIW rc2ECB encryptionAlgorithm.3 BSAFE2 rc4 encryptionAlgorithm.4 12/92 OIW rc4WithMAC encryptionAlgorithm.5 FASTCRYP DESX-CBC encryptionAlgorithm.6 BSAFE2 DES-EDE3-CBC encryptionAlgorithm.7 BSAFE2 RC5CBC encryptionAlgorithm.8 BSAFE3? RC5CBCPad encryptionAlgorithm.9 BSAFE4 CDMFCBCPad encryptionAlgorithm.10 S/PAY1 (see = cdmfdef.txt) applications rsadsi.4 (none) attributes applications.1 originalFilePath attributes.1 RSA FX OriginalOwner attributes.2 FASTCRYPT rsaApplications applications.2 RSA FX FX rsaApplications.1 RSA FX issuerSerialDigest FX.1 RSA FX Frog rsaApplications.2(tentative) = Frog MACFinderInfo Frog.1 (tentative) MACFrog AI_FrogMD5WithRC2_CBCPad Frog.2 (tentative) FASTCRYPT css rsaApplications.3 RSA CSS fieldIdentifier css.1 RSA CSS test applications.3 dsa-with-sha-test test.1 = dsatypes.doc datamedia test.2 datamedia ETA (Cyphercom) test.3 ETA securityDynamics rsadsi.5 (none) sdi-ce securityDynamics.1 certificate = extensions subjectSDIPrivilegeAttribute sdi-ce.1 PAC = extension sdi-algs securityDynamics.2 algorithms rsadsiLdap rsadsi.6 (none yet) ------_=_NextPart_000_01BE7F83.5B520DA0-- From owner-ipsec@lists.tislabs.com Mon Apr 5 14:55:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08586; Mon, 5 Apr 1999 14:55:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14314 Mon, 5 Apr 1999 15:35:16 -0400 (EDT) Message-Id: <199904051952.MAA07701@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 05 Apr 1999 12:50:33 -0700 To: ipsec@lists.tislabs.com From: Anita Freeman Subject: VPN Workshop Applications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We now have the application for the VPN Workshop up on our web site at http://www.ciug.org This workshop will be held May 23 to 28 in Santa Barbara and will include interoperability testing of PPP, L2TP, and IPSec protocols. Bob Larribeau Chairman CalBUG California Broadband Users' Group From owner-ipsec@lists.tislabs.com Mon Apr 5 15:46:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08995; Mon, 5 Apr 1999 15:46:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14431 Mon, 5 Apr 1999 16:27:27 -0400 (EDT) Message-ID: <3709220E.EAD499F9@siara.com> Date: Mon, 05 Apr 1999 13:50:22 -0700 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec/IKE MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Is there a RFC Standard or Draft on IPSec/IKE MIB ? Thx. Sunil. From owner-ipsec@lists.tislabs.com Mon Apr 5 17:37:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10855; Mon, 5 Apr 1999 17:37:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14768 Mon, 5 Apr 1999 18:12:35 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 05 Apr 1999 16:35:28 -0600 From: "Tolga Acar" To: , Subject: Re: IPSec/IKE MIB Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA14765 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sunil, You might be looking for RFC 2409: The Internet Key Exchange (IKE) It is available at www.ietf.org - Tolga >>> "Sunil.Vallamkonda" 4/5/99 14:50:22 >>> Hello, Is there a RFC Standard or Draft on IPSec/IKE MIB ? Thx. Sunil. From owner-ipsec@lists.tislabs.com Mon Apr 5 20:59:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23272; Mon, 5 Apr 1999 20:59:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15247 Mon, 5 Apr 1999 20:43:24 -0400 (EDT) Date: Mon, 5 Apr 1999 21:06:50 -0400 (EDT) Message-Id: <199904060106.VAA18750@dcl> From: "Theodore Y. Ts'o" To: "Tolga Acar" Cc: , In-Reply-To: Tolga Acar's message of Mon, 05 Apr 1999 16:35:28 -0600, Subject: Re: IPSec/IKE MIB Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Mon, 05 Apr 1999 16:35:28 -0600 From: "Tolga Acar" You might be looking for RFC 2409: The Internet Key Exchange (IKE) It is available at www.ietf.org >>> "Sunil.Vallamkonda" 4/5/99 14:50:22 >>> Is there a RFC Standard or Draft on IPSec/IKE MIB ? The original question was about the IPSec/IKE MIB; that's currently being worked on, and can be found as an Internet Draft; it's not an RFC yet. - Ted From owner-ipsec@lists.tislabs.com Tue Apr 6 05:15:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16014; Tue, 6 Apr 1999 05:15:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16749 Tue, 6 Apr 1999 05:24:04 -0400 (EDT) X-Envelope-Sender-Is: Michael.Bungert@mchp.siemens.de (at relayer david.siemens.de) Message-ID: <09625CEB7861D111AB1C00609731E8460F1CB5@MCHP952A> From: Bungert Michael To: "'Steven M. Bellovin'" Cc: ipsec@lists.tislabs.com Subject: AW: IPSec for IP Telephony Date: Tue, 6 Apr 1999 11:47:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > ---------- > Von: Steven M. Bellovin[SMTP:smb@research.att.com] > Gesendet: Donnerstag, 1. April 1999 20:40 > An: Jeff Carr > Cc: ipsec@lists.tislabs.com > Betreff: Re: IPSec for IP Telephony > > > When you're dealing with general Internet hosts, you have to worry > about all sorts of other services that might be able to use the same > key pair. See http://www.research.att.com/~smb/papers/badesp.ps (or .pdf) > -- even apart from the fixes to ipsec, most of the attacks described > simply don't apply. To give just one example, here we want to protect > the voice channel only; there are no other port numbers involved. > If you also want to protect signalling (e.g. in H.323) there are several ports involved. Nevertheless, I also doubt the appropriateness of IPSec for the protection of VoIP. I believe that for VoIP end-to-end security (esp. confidentiality) is crucial (even for communication in a local network). But, if I want to realize end-to-end security I have to deal with firewall traversals. How shall I do that using IPSec in a VoIP scenario ? Michael From owner-ipsec@lists.tislabs.com Tue Apr 6 09:32:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19191; Tue, 6 Apr 1999 09:32:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17489 Tue, 6 Apr 1999 09:07:42 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Bungert Michael Cc: ipsec@lists.tislabs.com Subject: Re: AW: IPSec for IP Telephony Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Apr 1999 09:30:59 -0400 From: "Steven M. Bellovin" Message-Id: <19990406133110.9D5D941F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > If you also want to protect signalling (e.g. in H.323) there are several port > s involved. Nevertheless, I also doubt the appropriateness of IPSec for the p > rotection of VoIP. I believe that for VoIP end-to-end security (esp. confiden > tiality) is crucial (even for communication in a local network). But, if I wa > nt to realize end-to-end security I have to deal with firewall traversals. Ho > w shall I do that using IPSec in a VoIP scenario ? > Firewalls are indeed another concern for IPsec, if your VoIP products are intended to run in that sort of environment. And signaling is a different matter entirely; its characteristics are very different. From owner-ipsec@lists.tislabs.com Tue Apr 6 12:57:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21449; Tue, 6 Apr 1999 12:57:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18372 Tue, 6 Apr 1999 12:40:16 -0400 (EDT) Message-ID: <01BE802D.DF2FFBA0.sakers@springtidenet.com> From: Steve Akers To: "'Anthony Walwyn'" , "ipsec@lists.tislabs.com" Cc: "'awallack@springtidenet.com'" , "'scollins@springtidenet.com'" Subject: RE: IPSec IP Telephony:End to End or Segment Date: Tue, 6 Apr 1999 13:03:30 -0400 Organization: springtide X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Anthony, I think that the model you suggest below will be a well known paradigm for IP telephony. Vendors such as Nortel and Qwest are terminating T1 lines at a device that is able to packetize voice. These voice gateways are then sending packetized voice over public IP networks. This is totally insecure traffic today. Our belief here at Spring Tide is that the ISP will need to provide an additional IP security service for the voice traffic. This will be done as you describe: two security gateways tunneling subscriber voice sessions. There are other aspects of this problem, such as providing a level of service that supports the delay-sensitive voice traffic, but that is another discussion. I hope that this helps you. Steve. -----Original Message----- From: Anthony Walwyn [SMTP:anthony.walwyn@telematics.com] Sent: Tuesday, March 30, 1999 5:32 AM To: ipsec@lists.tislabs.com Subject: IPSec IP Telephony:End to End or Segment Hi, I've a question which I hope the experts on this list can answer/give their opinion. With respect to IP Telephony, should security be end-to-end or does it make sense to have it on just one segment, eg between two IP Telephony Gateways. Phone--PSTN--IPGW--IP Network--IPGW--PSTN-Phone If security is only implemented between the Gateways is the security risk unacceptable ?? If the phones were Internet-Phones, security could be implemented end-to-end using IPSec, but what happens if one end is an Internet Phone and one end is a normal PSTN Phone ? -- Anthony Walwyn Title: Senior Systems Engineer ECI Telecom, UK DCME Development, Voice: +44(0)1256 388065 ISIS House, Reading Road, Chineham Fax : +44(0)1256 388142 Basingstoke, Hampshire UK RG24 8TW Email: anthony.walwyn@telematics.com From owner-ipsec@lists.tislabs.com Tue Apr 6 17:08:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA24202; Tue, 6 Apr 1999 17:08:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19698 Tue, 6 Apr 1999 17:22:44 -0400 (EDT) Message-ID: <89AA5A7CAE78D211A4E5009027177FF12AF933@hartman.aptis.com> From: Murtaza Chiba To: "IPSec (E-mail)" Subject: AH + ESP Interoperability Date: Tue, 6 Apr 1999 17:45:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello, I am new to this mailing list and have a couple of questions. First, is there a searchable archive for this list? The second question is wrt Interoperability and authentication. What is the accepted method of authentication calculation pertaining to crypto libraries? I have seen different implementations with different methods. One implementation does it as. Update(ipheader) Update(AH hdr + data) Final Another implementation does it as Update(ipheader) Update(AH hdr) Update(padding) Update(data) Final The RFC specifies Update(pdu) Final I apologize if this has been discussed before and would appreciate pointers to relevant information Thanks Murtaza From owner-ipsec@lists.tislabs.com Tue Apr 6 21:02:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA08310; Tue, 6 Apr 1999 21:02:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20297 Tue, 6 Apr 1999 21:12:10 -0400 (EDT) Message-Id: <4.2.0.32.19990406183328.00b80f00@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Tue, 06 Apr 1999 18:34:22 -0700 To: Murtaza Chiba , "IPSec (E-mail)" From: Paul Hoffman Subject: Re: AH + ESP Interoperability In-Reply-To: <89AA5A7CAE78D211A4E5009027177FF12AF933@hartman.aptis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:45 PM 4/6/99 -0400, Murtaza Chiba wrote: >First, is there a searchable archive for this list? There is an HTML archive at VPNC: . It will be searchable within a few weeks, maybe sooner. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Apr 6 23:24:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA15328; Tue, 6 Apr 1999 23:24:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20748 Tue, 6 Apr 1999 23:53:19 -0400 (EDT) Message-Id: <3.0.6.32.19990406211108.007d21d0@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 06 Apr 1999 21:11:08 -0700 To: "Tolga Acar" From: Rodney Thayer Subject: Re: Algorithm OIDs in RFC 2104 Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In this as with other things we should be weaning the IETF off of vendor OID's. In fact, we already defined this: SMI Security for Mechanism isakmpOakley Codes: Prefix: iso.org.dod.internet.security.ipsec.isakmpOakley (1.3.6.1.5.5.8.1) Decimal Name Description References ------- ---- ----------- ---------- 0 Reserved [IANA] 1 HMAC-MD5 HMAC-MD5 [Thayer] 2 HMAC-SHA HMAC-SHA [Thayer] 3 HMAC-TIGER HMAC-TIGER [Thayer] See smi-numbers, at http://www.isi.edu/in-notes/iana/assignments/smi-numbers off of www.iana.org Where were they missing from? At 02:12 PM 3/31/99 -0700, you wrote: > >I wonder if there is an OID for predefined HMAC algorithms in RFC 2104. >There is one specified for HMAC-SHA1 in PKCS#5, in the RSADSI arch: > >rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} >digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} >id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} > >I couldn't find one for SHA-1. >Are they defined somewhere else ? > >- Tolga > From owner-ipsec@lists.tislabs.com Wed Apr 7 06:33:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28280; Wed, 7 Apr 1999 06:33:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21725 Wed, 7 Apr 1999 06:50:45 -0400 (EDT) Message-Id: <199904071113.HAA03369@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-ipsec-ecn-00.txt Date: Wed, 07 Apr 1999 07:13:43 -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 Interactions with ECN Author(s) : S. Floyd, D. Black, K. Ramakrishnan Filename : draft-ipsec-ecn-00.txt Pages : 15 Date : 06-Apr-99 IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that provides indication of onset of congestion to delay- or loss- sensitive applications. ECN provides the congestion indication so as to enable adaptation to network conditions without the impact of dropped packets [RFC 2481]. Currently, the way ECN is specified does not conform to the manner in which IPsec tunnels are defined to be used. This document considers issues related to interactions between ECN and IPsec tunnel mode, and proposes two alternative solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ipsec-ecn-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-ipsec-ecn-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-ipsec-ecn-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: <19990406172726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ecn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ecn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990406172726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 7 07:03:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28567; Wed, 7 Apr 1999 07:03:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21881 Wed, 7 Apr 1999 07:38:41 -0400 (EDT) Message-Id: <3.0.32.19990407080204.00765b80@cpcug.org> X-Sender: jaubert@cpcug.org X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Apr 1999 08:02:05 -0400 To: ipsec@lists.tislabs.com From: Jack Aubert Subject: IPSec and IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have now heard for the second time somebody allege that IPSec is intimately connected with IPv6. I've been trying to follow developments in both areas to some degree, and have not run across anything in the RFCs from either group to support this contention. Did I miss something? From owner-ipsec@lists.tislabs.com Wed Apr 7 07:07:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28586; Wed, 7 Apr 1999 07:07:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21924 Wed, 7 Apr 1999 07:46:34 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Jack Aubert Cc: ipsec@lists.tislabs.com Subject: Re: IPSec and IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Apr 1999 08:09:58 -0400 From: "Steven M. Bellovin" Message-Id: <19990407121003.AF84F41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3.0.32.19990407080204.00765b80@cpcug.org>, Jack Aubert writes: > I have now heard for the second time somebody allege that IPSec is > intimately connected with IPv6. I've been trying to follow developments in > both areas to some degree, and have not run across anything in the RFCs > from either group to support this contention. Did I miss something? > > > No. IPv6 does mandate IPsec. But IPsec itself was carefully designed to work with IPv4 or IPv6. And there's plenty of interoperating, running code to prove the point. From owner-ipsec@lists.tislabs.com Wed Apr 7 09:05:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29584; Wed, 7 Apr 1999 09:05:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22055 Wed, 7 Apr 1999 08:57:55 -0400 (EDT) Date: Wed, 7 Apr 1999 16:21:24 +0300 (EET DST) From: Markku Savela Message-Id: <199904071321.QAA28946@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com cc: floyd@aciri.org In-reply-to: <199904071113.HAA03369@ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-ipsec-ecn-00.txt Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Title : IPsec Interactions with ECN > Author(s) : S. Floyd, D. Black, K. Ramakrishnan > Filename : draft-ipsec-ecn-00.txt I've one concern about this draft: it adds yet another unneeded binding between "tunnel" and SA, which is the wrong direction to go. In my implementation the tunnel wrapping is totally independent of the SA (SA really knows nothing about it), and I would prefer it to stay that way. I specify whether or not to use tunnel in the Security Policy definition, which applies first the tunnel and then the SA's that relate to tunnel end points (exactly as if it was a transport mode between SGs). If this ECN is a good thing, I would think the information has a more natural place in the policy database, added to the tunnel specification. (or the draft should not try to specify the implementation details in this way). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 7 12:57:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01787; Wed, 7 Apr 1999 12:57:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22672 Wed, 7 Apr 1999 12:23:24 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF969D1C@exchange> From: Tim Jenkins To: "'ipsec@lists.tislabs.com'" Subject: New re-keying document: draft-jenkins-ipsec-rekeying-01.txt Date: Wed, 7 Apr 1999 12:47:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, A new version of the IPSec re-keying information document is available at . Comments welcomed. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Thu Apr 8 16:07:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21293; Thu, 8 Apr 1999 16:07:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28107 Thu, 8 Apr 1999 14:46:59 -0400 (EDT) Message-ID: <370CFF90.7EE2B010@redcreek.com> Date: Thu, 08 Apr 1999 12:12:16 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ipsec error codes References: <319A1C5F94C8D11192DE00805FBBADDF969D1C@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the Minneapolis IETF, a few of us agreed to work on the ipsec error codes draft Bob Moskowitz has been calling for. Bob's initial suggestion was to take a look at the smtp response codes as an example. This is probably a good starting point for the discussion, and I'd like to solicit general input before producing a draft. I believe the smtp response codes are derived from the ftp response codes, and essentially consist of a 3 digit number followed by human readable text. Typically, the text is standardized, and in some cases contains fields which are inserted by the sender such as domain, path, etc. Each digit has a semantic meaning, i.e. the first digit indicates the status (complete, incomplete, or failed), the second digit encodes an error type, and the third digit further refines the second digit. I think an important point is that reply codes for ftp/smtp are just that: *reply* codes. That is, they are sent in response to commands, and are meant to facilitate state machine processing. From RFC 959, Replies to File Transfer Protocol commands are devised to ensure the synchronization of requests and actions in the process of file transfer, and to guarantee that the user process always knows the state of the Server. Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished. In addition, some commands occur in sequential groups, such as USER, PASS and ACCT, or RNFR and RNTO. The replies show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning. The important point here is that they are defined with particular semantic goals, which may or may not encompass the requirements of our situation. This brings us to a question: what, exactly, are our requirements? As a first cut, I'd say our requirements are these: 1) a standard message format, as opposed to simply numeric codes; this format would include the items listed below. o numeric codes which encode the following: - standard event codes; note that event codes are different than reply codes sometimes. - priority (perhaps like syslog) - originating element (e.g. isakmp, SPD, SAD, esp, ah, etc) o relative timestamp o standardized text portion containing variable fields which are filled in during message construction, e.g. ip address, spi,etc. I'd like some input on this before attempting to write up something more substantial. Are there additional requirements? Are the ones specified here correct? Scott From owner-ipsec@lists.tislabs.com Thu Apr 8 19:35:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24914; Thu, 8 Apr 1999 19:35:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28821 Thu, 8 Apr 1999 18:53:22 -0400 (EDT) From: Dan McDonald Message-Id: <199904082310.QAA29890@kebe.Eng.Sun.COM> Subject: Re: ipsec error codes To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 8 Apr 1999 16:10:36 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <370CFF90.7EE2B010@redcreek.com> from "Scott G. Kelly" at Apr 8, 99 12:12:16 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I think an important point is that reply codes for ftp/smtp are just > that: *reply* codes. That is, they are sent in response to commands, and > are meant to facilitate state machine processing. From RFC 959, > > Replies to File Transfer Protocol commands are devised to ensure > the synchronization of requests and actions in the process of file > transfer, and to guarantee that the user process always knows the > state of the Server. Every command must generate at least one > reply, although there may be more than one; in the latter case, > the multiple replies must be easily distinguished. In addition, > some commands occur in sequential groups, such as USER, PASS and > ACCT, or RNFR and RNTO. The replies show the existence of an > intermediate state if all preceding commands have been successful. > A failure at any point in the sequence necessitates the repetition > of the entire sequence from the beginning. > > The important point here is that they are defined with particular > semantic goals, which may or may not encompass the requirements of our > situation. This brings us to a question: what, exactly, are our > requirements? Good question. At first glance, I don't see what problem is being solved. What on-the-wire entity would issue these codes and messages? Dan From owner-ipsec@lists.tislabs.com Thu Apr 8 19:58:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA26566; Thu, 8 Apr 1999 19:58:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29009 Thu, 8 Apr 1999 19:56:23 -0400 (EDT) Message-ID: <370D47F3.223EC7@redcreek.com> Date: Thu, 08 Apr 1999 17:21:07 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904082310.QAA29890@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > The important point here is that they are defined with particular > > semantic goals, which may or may not encompass the requirements of our > > situation. This brings us to a question: what, exactly, are our > > requirements? > > Good question. > > At first glance, I don't see what problem is being solved. What on-the-wire > entity would issue these codes and messages? Also a good question, and maybe Bob will want to put on his ANX hat and give us some real world applications. I assume that the messages are issued by security gateways and ipsec host implementations. I also assume such messages would be useful in logfiles, and perhaps also in syslog-type output. Another consumer might be an intrusion detection event correlator, although a working group has been formed which is devoted to trying to settle on some format for those messages, and one of the possiblities I heard mentioned was (gak!) ASN.1. Scott From owner-ipsec@lists.tislabs.com Fri Apr 9 00:17:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA12427; Fri, 9 Apr 1999 00:17:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29542 Fri, 9 Apr 1999 00:37:18 -0400 (EDT) Message-ID: <926A591C08E3D211960600E029101CCC153243@mxclsa> From: "Black, David" To: "'msa@hemuli.tte.vtt.fi'" , ipsec@lists.tislabs.com Cc: floyd@aciri.org Subject: ECN: Tunnel/SA relationship Date: Fri, 9 Apr 1999 01:00:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela [SMTP:msa@anise.tte.vtt.fi] writes: > I've one concern about this draft: it adds yet another > unneeded binding between "tunnel" and SA, which is the > wrong direction to go. The basic reason for doing it that way is the desire to be able to negotiate ECN support between tunnel endpoints; this allows the tunnel ingress IPsec implementation to determine that the tunnel egress IPsec implementation won't discard congestion notifications before allowing the ECN Capable Transport bit to be set in the outer header, an important thing to know. In addition, there are security implications to allowing this bit to be set (it enables an adversary to erase congestion notifications), and hence negotiating ECN support as part of setting up a secured connection seems appropriate. Negotiating ECN support as an SA attribute appears to be the logical thing to do, especially as the encapsulation mode (tunnel vs. transport) is already negotiable as an SA attribute, and adding another attribute creates the least in the way of new protocol specification/mechanism. It is also the case that the IPsec protocol mode (tunnel/transport/wildcard) is a REQUIRED SAD field for implementations that cannot always determine the mode to be used from context. I would suggest that the decision to associate encapsulation mode (tunnel vs. transport) with security associations has been made, as reversing it would require revisions to at least RFC 2401 and RFC 2407. > In my implementation the tunnel wrapping is totally > independent of the SA (SA really knows nothing about it), > and I would prefer it to stay that way. In that case you could choose not to implement the OPTIONAL features in the IPsec/ECN draft -- the result is a minor change to header processing at tunnel ingress to turn off ECN support. > If this ECN is a good thing, I would think the information > has a more natural place in the policy database, added to > the tunnel specification. Moving the indication of whether ECN is supported to the SPD appears to remove the opportunity to negotiate ECN support between the tunnel endpoints, which would be wrong (IMHO). In addition, the header processing description in RFC 2401 makes it clear that the destination address for the outer header comes from the SA. I'm not sure what was meant by "tunnel specification", but I would think it includes the destination address, since that determines where the other end of the tunnel is. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Apr 9 10:56:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00317; Fri, 9 Apr 1999 10:56:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00897 Fri, 9 Apr 1999 08:45:43 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199904091308.GAA02231@kc.livingston.com> Subject: Re: ipsec error codes To: skelly@redcreek.com (Scott G. Kelly) Date: Fri, 9 Apr 1999 06:08:27 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <370CFF90.7EE2B010@redcreek.com> from "Scott G. Kelly" at Apr 8, 99 12:12:16 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk <... snip> > I'd like some input on this before attempting to write up something more > substantial. Are there additional requirements? Are the ones specified > here correct? > > Scott > Here is my thinking on this. When a packet is dropped at any node across the network due to enforcement of a certain policy, it would be beneficial for the end-node (that originated the packet) to know the policy that caused the packets to drop and why. Standardization of reject notification for such a purpose is desirable. Such a message should not only contain the packet that failed a policy, but also the policy and the ID of the policy enforcement device. It is important for the end-node to know if a packet is dropped due to enforcement of a policy or due to congestion and random drop. In the former case, it is fruitless to retry. If the application were to be aware of the policy that failed the session it could potentially pursue alternate approaches. cheers, suresh From owner-ipsec@lists.tislabs.com Fri Apr 9 12:16:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01094; Fri, 9 Apr 1999 12:16:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01044 Fri, 9 Apr 1999 09:52:52 -0400 (EDT) From: freedmanj@netscout.com X-Lotus-FromDomain: NETSCOUT To: skelly@redcreek.com cc: ipsec@lists.tislabs.com Message-ID: <8525674E.004EA858.00@nsismtp1.netscout.com> Date: Fri, 9 Apr 1999 10:14:22 -0400 Subject: Re: ipsec error codes Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Another consumer might be an intrusion detection >event correlator, although a working group has been formed which is >devoted to trying to settle on some format for those messages, and one >of the possiblities I heard mentioned was (gak!) ASN.1. ASN.1 is not a format, its a language. A format would be ASN1 and a set of encoding rules. There are several, BER, DER, PER. Depending upon what we are really talking about ( the consumer of these error codes/packets/messages?) such a format might be appropriate, then again it might not. From owner-ipsec@lists.tislabs.com Fri Apr 9 12:42:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01396; Fri, 9 Apr 1999 12:42:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01330 Fri, 9 Apr 1999 10:34:25 -0400 (EDT) To: "Black, David" cc: "'msa@hemuli.tte.vtt.fi'" , ipsec@lists.tislabs.com, floyd@aciri.org In-reply-to: Black_David's message of Fri, 09 Apr 1999 01:00:10 -0400. <926A591C08E3D211960600E029101CCC153243@mxclsa> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ECN: Tunnel/SA relationship From: Jun-ichiro itojun Hagino Date: Fri, 09 Apr 1999 14:38:43 +0900 Message-ID: <16626.923636323@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I've one concern about this draft: it adds yet another >> unneeded binding between "tunnel" and SA, which is the >> wrong direction to go. >The basic reason for doing it that way is the desire >to be able to negotiate ECN support between tunnel endpoints; >this allows the tunnel ingress IPsec implementation to >determine that the tunnel egress IPsec implementation won't >discard congestion notifications before allowing the ECN >Capable Transport bit to be set in the outer header, >an important thing to know. In addition, there are >security implications to allowing this bit to be set >(it enables an adversary to erase congestion notifications), >and hence negotiating ECN support as part of setting >up a secured connection seems appropriate. I did a "per-node" configuration for ECN friendliness, rather than per-SA, for our implementation (see below). Is it worth doing it or is it harmful? Adding an attribute to SA (and modifying IKE daemon) looks too much for me, and it seems to me that per-host configuration solves most of the cases. If it is harmful to ECN people, I'll be removing this code from ours. itojun@kame.net --- 4.5 ECN consideration on IPsec tunnels KAME IPsec implements ECN-friendly IPsec tunnel, described in draft-ipsec-ecn-00.txt. Normal IPsec tunnel is described in RFC2401. On encapsulation, IPv4 TOS field (or, IPv6 flowinfo field) will be copied from inner IP header to outer IP header. On decapsulation outer IP header will be simply dropped. The decapsulation rule is not compatible with ECN, since ECN bit on the outer IP TOS/flowinfo field will be lost. To make IPsec tunnel ECN-friendly, we should modify encapsulation and decapsulation procedure. This is described in http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, chapter 3. KAME IPsec tunnel implementation can give you three behaviors, by setting net.inet.ipsec.ecn (or net.inet6.ipsec6.ecn) to some value: - RFC2401: no consideration for ECN (sysctl value -1) - ECN forbidden (sysctl value 0) - ECN allowed (sysctl value 1) The behavior is summarized as follows (see source code for more detail): encapsulate decapsulate --- --- RFC2401 copy all TOS bits drop TOS bits on outer from inner to outer. (use inner TOS bits as is) ECN forbidden copy TOS bits except for ECN drop TOS bits on outer (masked with 0xfc) from inner (use inner TOS bits as is) to outer. set ECN bits to 0. ECN allowed copy TOS bits except for ECN use inner TOS bits with some CE (masked with 0xfe) from change. if outer ECN CE bit inner to outer. is 1, enable ECN CE bit on set ECN CE bit to 0. the inner. General strategy for configuration is as follows: - if both IPsec tunnel endpoint are capable of ECN-friendly behavior, you'd better configure both end to "ECN allowed" (sysctl value 1). - if the other end is very strict about TOS bit, use "RFC2401" (sysctl value -1). - in other cases, use "ECN forbidden" (sysctl value 0). The default behavior is "ECN forbidden" (sysctl value 0). For more information, please refer to: http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt RFC2481 (Explicit Congestion Notification) KAME sys/netinet6/{ah,esp}_input.c (Thanks goes to Kenjiro Cho for detailed analysis) From owner-ipsec@lists.tislabs.com Fri Apr 9 13:53:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02110; Fri, 9 Apr 1999 13:53:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01599 Fri, 9 Apr 1999 12:02:19 -0400 (EDT) Message-ID: <370E2A6B.CB7791D7@redcreek.com> Date: Fri, 09 Apr 1999 09:27:23 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904091308.GAA02231@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Suresh, Pyda Srisuresh wrote: > > <... snip> > > I'd like some input on this before attempting to write up something more > > substantial. Are there additional requirements? Are the ones specified > > here correct? > > > > Scott > > > Here is my thinking on this. > > When a packet is dropped at any node across the network due to > enforcement of a certain policy, it would be beneficial for the > end-node (that originated the packet) to know the policy that > caused the packets to drop and why. > One obvious concern with this would be denial of service attacks, i.e. now, you not only have to reject the packet, but you have to send out a meaningless notification as well. I suppose that if you could configure the device to only respond to known (that is, configured) endpoints, this would mitigate the risk, though not eliminate it entirely. Scott From owner-ipsec@lists.tislabs.com Fri Apr 9 13:58:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02155; Fri, 9 Apr 1999 13:58:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01730 Fri, 9 Apr 1999 12:24:27 -0400 (EDT) From: Dan McDonald Message-Id: <199904091647.JAA31177@kebe.Eng.Sun.COM> Subject: Re: ipsec error codes To: skelly@redcreek.com (Scott G. Kelly) Date: Fri, 9 Apr 1999 09:47:52 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <370E2C12.FCAD2FF@redcreek.com> from "Scott G. Kelly" at Apr 9, 99 09:34:26 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In this situation, standardized event codes would go a long way in terms of > diagnostics, accounting, etc. I understand that such diagnostics are useful. The other part of my question remains unanswered: > > At first glance, I don't see what problem is being solved. What > > on-the-wire entity would issue these codes and messages? Are these extensions to IKE? What entity issues such error codes? Are we inventing a new protocol that does nothing but report errors? Or is this merely a proposal of output from that can be read? Thanks, Dan From owner-ipsec@lists.tislabs.com Fri Apr 9 14:03:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02210; Fri, 9 Apr 1999 14:03:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01652 Fri, 9 Apr 1999 12:09:12 -0400 (EDT) Message-ID: <370E2C12.FCAD2FF@redcreek.com> Date: Fri, 09 Apr 1999 09:34:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904082310.QAA29890@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > > The important point here is that they are defined with particular > > semantic goals, which may or may not encompass the requirements of our > > situation. This brings us to a question: what, exactly, are our > > requirements? > > Good question. > > At first glance, I don't see what problem is being solved. What on-the-wire > entity would issue these codes and messages? > I'm replying again because, after reviewing my initial reply, I don't think I answered the implied portion of your message regarding the problem being solved. My understanding is that this would go a long way toward facilitating multi-vendor security implementation management. ANX is a good example, in that you (hopefully) have no way to guarantee what vendor's device you will be speaking to when connecting with a trading partner. Furthermore, a given installation may utilize several different vendors' devices for various applications. In this situation, standardized event codes would go a long way in terms of diagnostics, accounting, etc. Scott From owner-ipsec@lists.tislabs.com Fri Apr 9 14:18:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02375; Fri, 9 Apr 1999 14:18:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01767 Fri, 9 Apr 1999 12:36:16 -0400 (EDT) Message-ID: <370E3274.1EABD251@redcreek.com> Date: Fri, 09 Apr 1999 10:01:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904091647.JAA31177@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > > > In this situation, standardized event codes would go a long way in terms of > > diagnostics, accounting, etc. > > I understand that such diagnostics are useful. The other part of my question > remains unanswered: > > > > At first glance, I don't see what problem is being solved. What > > > on-the-wire entity would issue these codes and messages? > > Are these extensions to IKE? What entity issues such error codes? Are we > inventing a new protocol that does nothing but report errors? Or is this > merely a proposal of output from that can be read? Again, good question. I guess my assumption is that an ipsec implementation either contains or has an API into an audit subsystem of some type. In the case of a Unix kernel, this might be syslog, or it might simply be a logfile. The ipsec implementation must somehow signal the event to the audit subsystem. Depending upon the implementation, the formatting may be done by the ipsec component (as might be the case with syslog), or it might be done by the audit subsystem itself, as would be the case with a simple logfile. Scott From owner-ipsec@lists.tislabs.com Fri Apr 9 14:51:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02820; Fri, 9 Apr 1999 14:51:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01860 Fri, 9 Apr 1999 12:48:29 -0400 (EDT) Message-Id: <3.0.5.32.19990409201329.00b66320@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 09 Apr 1999 20:13:29 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: DESX 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 MAA01857 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there a way to negotiate draft-simpson-desx-02.txt with IKE? I'm missing an algorithm number as in 4.4.4 of RFC 2407. Are there any values in the 65001-65535 range that you agreed on? While we're at it, how about RC6, twofish, mars? Jörn Sierwald From owner-ipsec@lists.tislabs.com Fri Apr 9 17:13:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04173; Fri, 9 Apr 1999 17:13:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02695 Fri, 9 Apr 1999 16:04:16 -0400 (EDT) Message-ID: From: "Biggerstaff, Craig" To: ipsec@lists.tislabs.com, "'Scott G. Kelly'" Subject: RE: ipsec error codes Date: Fri, 9 Apr 1999 15:10:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Replies inline... > ---------- > From: Scott G. Kelly[SMTP:skelly@redcreek.com] > Sent: Thursday, April 08, 1999 2:12 PM > To: ipsec@lists.tislabs.com > Subject: ipsec error codes > [stuff deleted] > As a first cut, I'd say our requirements are these: > > 1) a standard message format, as opposed to simply numeric codes; > this format would include the items listed below. > > o numeric codes which encode the following: > - standard event codes; note that event codes are > different than reply codes sometimes. > - priority (perhaps like syslog) > - originating element (e.g. isakmp, SPD, SAD, esp, ah, etc) > > o relative timestamp > > o standardized text portion containing variable fields which are > filled in during message construction, e.g. ip address, > spi,etc. > > I'd like some input on this before attempting to write up something more > substantial. Are there additional requirements? Are the ones specified > here correct? > I would add a statement to the effect that: "Any event code or message sent to indicate failure to create an SA MUST NOT reveal information that would otherwise only be known to the initiator *after* the successful creation of an SA." -- Craig Biggerstaff From owner-ipsec@lists.tislabs.com Fri Apr 9 17:15:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04193; Fri, 9 Apr 1999 17:15:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02726 Fri, 9 Apr 1999 16:22:17 -0400 (EDT) Date: Fri, 9 Apr 1999 16:24:33 -0400 Message-Id: <199904092024.QAA06093@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904091308.GAA02231@kc.livingston.com> <370E2A6B.CB7791D7@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> Hi Suresh, Pyda Srisuresh wrote: >> <... snip> > I'd like some input on this before attempting to >> write up something more > substantial. Are there additional >> requirements? Are the ones specified > here correct? > > Scott > >> Here is my thinking on this. >> >> When a packet is dropped at any node across the network due to >> enforcement of a certain policy, it would be beneficial for the >> end-node (that originated the packet) to know the policy that >> caused the packets to drop and why. >> Scott> One obvious concern with this would be denial of service Scott> attacks, i.e. now, you not only have to reject the packet, Scott> but you have to send out a meaningless notification as well. I Scott> suppose that if you could configure the device to only respond Scott> to known (that is, configured) endpoints, this would mitigate Scott> the risk, though not eliminate it entirely. Not just that, but responding to strange input may be a security concern above and beyond denial of service. Clearly, any notion that you respond in ANY way to erroneous packets has to be at the option of the network manager. It probably should be implementation-optional. It may well be appropriate for the default to be not to respond. (My reasoning is that everyone should always default to the most secure option, while giving management the option to open things up. Of course I realize that many virus channels, er.., software products are built on the opposite notion.) paul From owner-ipsec@lists.tislabs.com Fri Apr 9 17:33:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04415; Fri, 9 Apr 1999 17:33:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02757 Fri, 9 Apr 1999 16:26:43 -0400 (EDT) Message-ID: <370E64C2.C11EC284@redcreek.com> Date: Fri, 09 Apr 1999 13:36:18 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ipsec@lists.tislabs.com Subject: Re: ipsec error codes References: <199904091308.GAA02231@kc.livingston.com> <370E2A6B.CB7791D7@redcreek.com> <199904092024.QAA06093@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Scott" == Scott G Kelly writes: > > Scott> Hi Suresh, Pyda Srisuresh wrote: > >> <... snip> > I'd like some input on this before attempting to > >> write up something more > substantial. Are there additional > >> requirements? Are the ones specified > here correct? > > Scott > > >> Here is my thinking on this. > >> > >> When a packet is dropped at any node across the network due to > >> enforcement of a certain policy, it would be beneficial for the > >> end-node (that originated the packet) to know the policy that > >> caused the packets to drop and why. > >> > > Scott> One obvious concern with this would be denial of service > Scott> attacks, i.e. now, you not only have to reject the packet, > Scott> but you have to send out a meaningless notification as well. I > Scott> suppose that if you could configure the device to only respond > Scott> to known (that is, configured) endpoints, this would mitigate > Scott> the risk, though not eliminate it entirely. > > Not just that, but responding to strange input may be a security > concern above and beyond denial of service. > > Clearly, any notion that you respond in ANY way to erroneous packets > has to be at the option of the network manager. It probably should be > implementation-optional. It may well be appropriate for the default > to be not to respond. (My reasoning is that everyone should always > default to the most secure option, while giving management the option > to open things up. Of course I realize that many virus channels, > er.., software products are built on the opposite notion.) > Agree fully - something that ocurred to me after replying to Suresh is that where the message is sent to is really out of scope for this effort. That is, the focus of this effort should be the content of the messages, not the destination(s). Scott From owner-ipsec@lists.tislabs.com Fri Apr 9 17:46:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04497; Fri, 9 Apr 1999 17:46:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03222 Fri, 9 Apr 1999 17:54:31 -0400 (EDT) Message-ID: <89AA5A7CAE78D211A4E5009027177FF12AF957@hartman.aptis.com> From: Murtaza Chiba Cc: ipsec@lists.tislabs.com Subject: Sequence Number Date: Fri, 9 Apr 1999 18:00:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Are there any implementations that dont send the Sequence Number field? Murtaza From owner-ipsec@lists.tislabs.com Fri Apr 9 20:48:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06042; Fri, 9 Apr 1999 20:48:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03855 Fri, 9 Apr 1999 21:41:14 -0400 (EDT) Message-ID: <926A591C08E3D211960600E029101CCC153249@mxclsa> From: "Black, David" To: "'Jun-ichiro itojun Hagino'" , "Black, David" Cc: ipsec@lists.tislabs.com, floyd@aciri.org Subject: RE: ECN: Tunnel/SA relationship Date: Fri, 9 Apr 1999 21:47:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I did a "per-node" configuration for ECN friendliness, rather than > per-SA, for our implementation (see below). > Is it worth doing it or is it harmful? Yes, it's worth doing. I definitely want to encourage this sort of experimentation. > Adding an attribute to SA (and modifying IKE daemon) looks too much > for me, and it seems to me that per-host configuration solves most > of the cases. > > If it is harmful to ECN people, I'll be removing this code from ours. I don't think it's harmful. The mechanisms in the draft are more general (and hence more complex) in two areas: (1) Putting the ECN support attribute in the SA allows one IPsec node to deal with a collection of other nodes that have different levels of ECN support and different opinions about whether to allow or forbid ECN. The intent of the draft is to allow one to add the SA attribute without also requiring the negotiation support (IKE daemon modifications); does this make things sufficiently simpler for you? (2) The negotiation mechanism was put in to allow an IPsec node to assure itself that ECN congestion notifications aren't being dropped by its counterpart before allowing ECN on the tunnel. If there's a strong opinion on this list that this assurance is not valuable and hence the negotiation is not worth implementing, I have no problem with taking it out of the next version of the draft. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Sat Apr 10 10:47:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12766; Sat, 10 Apr 1999 10:47:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05153 Sat, 10 Apr 1999 11:37:05 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <89AA5A7CAE78D211A4E5009027177FF12AF957@hartman.aptis.com> Date: Sat, 10 Apr 1999 11:31:13 -0400 To: Murtaza Chiba From: Stephen Kent Subject: Re: Sequence Number Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FYI, If you don't send the field or fail to include a monotonically increasing integer in it, you are non-compliant. Steve From owner-ipsec@lists.tislabs.com Sun Apr 11 15:53:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24176; Sun, 11 Apr 1999 15:53:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07598 Sun, 11 Apr 1999 15:32:43 -0400 (EDT) Message-Id: <4.2.0.32.19990411123054.00b0e7d0@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Sun, 11 Apr 1999 12:36:36 -0700 To: ipsec@lists.tislabs.com, ietf-ppp@merit.edu From: Paul Hoffman Subject: New mailing list for the May interop event Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. VPNC has started an open mailing list for folks going to or interested in the VPN Workshop being held May 23 to 28 in Santa Barbara, California. The purpose of the list is to discuss planning for the event, test scripts, things participants want to see, and so on. Although the list is open to participants and non-participants in the event, the focus is on the event. And, hey, we hope the non-participants change their minds and come and test! Please note that registering for the event does *not* sign you up for the mailing list; you have to do that yourself. To subscribe to the list, send a message to: workshop-may-99-request@vpnc.org with the single word subscribe in the body of the message. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 12 15:11:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21981; Mon, 12 Apr 1999 15:11:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10772 Mon, 12 Apr 1999 12:37:35 -0400 (EDT) Date: Mon, 12 Apr 1999 12:45:10 -0400 Message-Id: <199904121645.MAA09973@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Craig.Biggerstaff@csoconline.com Cc: ipsec@lists.tislabs.com, skelly@redcreek.com Subject: RE: ipsec error codes References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Biggerstaff," == Biggerstaff, Craig writes: Biggerstaff,> I would add a statement to the effect that: "Any event Biggerstaff,> code or message sent to indicate failure to create an Biggerstaff,> SA MUST NOT reveal information that would otherwise Biggerstaff,> only be known to the initiator *after* the successful Biggerstaff,> creation of an SA." That sounds sensible, but applied strictly it means canceling the product, because ANY message sent reveals some information. Minimally, it reveals that the other end is doing IPSEC and might be willing to talk if presented with suitable stimuli. paul From owner-ipsec@lists.tislabs.com Mon Apr 12 15:42:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22287; Mon, 12 Apr 1999 15:42:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11054 Mon, 12 Apr 1999 14:11:33 -0400 (EDT) Message-ID: From: "Biggerstaff, Craig" To: "Biggerstaff, Craig" , "'Paul Koning'" Cc: ipsec@lists.tislabs.com, skelly@redcreek.com Subject: RE: ipsec error codes Date: Mon, 12 Apr 1999 13:17:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Point taken. What I was trying to get across is that the reply channel should not become the next avenue for nmap-style attack scanning. If possible, the reply mechanism should be tied to the IKE "bootstrap" process such that the information it returns is proportional to the degree of authentication already received from the initiator. -- Craig > ---------- > From: Paul Koning[SMTP:pkoning@xedia.com] > Sent: Monday, April 12, 1999 11:45 AM > To: Craig.Biggerstaff@csoconline.com > Cc: ipsec@lists.tislabs.com; skelly@redcreek.com > Subject: RE: ipsec error codes > > >>>>> "Biggerstaff," == Biggerstaff, Craig > writes: > > Biggerstaff,> I would add a statement to the effect that: "Any event > Biggerstaff,> code or message sent to indicate failure to create an > Biggerstaff,> SA MUST NOT reveal information that would otherwise > Biggerstaff,> only be known to the initiator *after* the successful > Biggerstaff,> creation of an SA." > > That sounds sensible, but applied strictly it means canceling the > product, because ANY message sent reveals some information. > Minimally, it reveals that the other end is doing IPSEC and might be > willing to talk if presented with suitable stimuli. > > paul > From owner-ipsec@lists.tislabs.com Mon Apr 12 16:18:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22582; Mon, 12 Apr 1999 16:18:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10999 Mon, 12 Apr 1999 13:58:02 -0400 (EDT) Message-ID: <371230B5.279BA15F@nortelnetworks.com> Date: Mon, 12 Apr 1999 13:43:17 -0400 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipsec Subject: Mismatching PFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We are designing our IPSec implementation to allow PFS to be enabled/disabled on a per flow basis (i.e. SPD entry). Assume that an initiator is negotiating an IPSec SA without PFS (i.e. it will not send the optional [KE] payload). What happens if our responder wants PFS for this particular flow/SPD entry, should the SA negotiation be failed by the responder? If it is failed, where is this referenced in the literature? If it is not failed, is this not a serious concern that a responder is lowering its security standards to accommodate this request? Thanks, Kim Edwards Nortel Networks From owner-ipsec@lists.tislabs.com Mon Apr 12 16:30:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22655; Mon, 12 Apr 1999 16:30:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11249 Mon, 12 Apr 1999 14:46:14 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC032001@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: IPSEC monitor MIB Date: Mon, 12 Apr 1999 19:53:18 +0100 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 > I have a few thoughts having read draft 3 of the IPSEC Monitoring MIB: > > > 1) I feel there is room for an 'SPD' table entry to sit 'above' the IKE > Control Channel table. The IPSEC architecture describes interface-specific > SPD (I seem to remember) and in this case, the same IDs used to make the > IPSEC MIB entries unique could occur many time, for example, if I want to > define the security on a number of 'public' interfaces to 'protect > everything' in a LAN-LAN case, then I may have multiple occurrences of the > same simple selectors. The IPSEC MIB could then be used as an extension of > the Interface MIB. > > 2) As part of an attempt to recycle resources in a security gateway, would > it be possible to add an 'idle timer' that is used a bit like LifeTime, > but allow user inactivity to be identified and acted on in some way > (delete the SAs)? > > 3) While thinking about how to identify when a tunnel was broken, has > anyone proposed a way to actively monitor IP tunnels? I thinking of > something like an ICMP message poller to operate a bit like a PPP Echo > poll which can be used to declare the tunnel 'down'. > > 4) There is a lot of text in this draft that suggests that IKE can be used > to negotiate a 'protection suite' of just IPCOMP. Have I missed something? > Does anyone support this? This option would seem to be better placed as > an addition to IP-IP Tunnels/MIBs. > > 5) The IPSEC Tunnel table - given that it can contain TRANSPORT and TUNNEL > mode types, should we use a name other than tunnel in the table name? How > about IPSEC Connection - to go with the IKE Connection table? > > 6) Accounting. I guess I was going to use SA initiation/termination as a > handle to do IPSEC Accounting. If TRAPs are not intended for transient SA > initiation/termination, how could this be done? I suppose it could be > done on a timer basis that simple logs deltas on IPSEC Tunnel table > entries. > > 7) Under certain circumstances, I'd like to be able to use SETs to do some > rough management. I understand there are security worries with this, but > the SNMP flow could itself be protected with IPSEC... I'm looking to add > things such as turning IPSEC on/off, deleting IKE-SA or IPSEC-SA. > > 8) What counts the Phase-2 IKE traffic? It isn't clear to me what exactly > the IKE Control and IKE SA entries count as 'traffic'. > > Cheers, Steve. > > From owner-ipsec@lists.tislabs.com Mon Apr 12 16:54:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22845; Mon, 12 Apr 1999 16:54:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11433 Mon, 12 Apr 1999 15:29:17 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF998983@exchange> From: Tim Jenkins To: "Waters, Stephen" , ipsec@lists.tislabs.com Subject: RE: IPSEC monitor MIB Date: Mon, 12 Apr 1999 15:37:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] > Sent: April 12, 1999 2:53 PM > To: ipsec@lists.tislabs.com > Subject: IPSEC monitor MIB > > > I have a few thoughts having read draft 3 of the IPSEC > Monitoring MIB: That series has been abandoned; there is another that is draft 00 which is not representative either, but is closer; a new architecture was presented in Minneapolis. (I need to get the first series pulled off the WG page...) The current proposal (and we hope to release new documents very soon) consists of three separate MIBs. A rough description of them is: -a DOI-independent ISAKMP MIB -an IPSec SA MIB (raw SAs, independent of how created) -an IKE MIB, that links phase 1 and phase 2 Concepts like channels and tunnels as introduced in the original] series of MIBs are gone; they will have to added in as application specific MIBs on top of the above three MIBs. So, having said that... > > > > > > 1) I feel there is room for an 'SPD' table entry to sit > 'above' the IKE > > Control Channel table. The IPSEC architecture describes > interface-specific > > SPD (I seem to remember) and in this case, the same IDs > used to make the > > IPSEC MIB entries unique could occur many time, for > example, if I want to > > define the security on a number of 'public' interfaces to 'protect > > everything' in a LAN-LAN case, then I may have multiple > occurrences of the > > same simple selectors. The IPSEC MIB could then be used as > an extension of > > the Interface MIB. Control channels are gone; they were the logical phase 1 tunnel. I think you mean to associate the phase 2 tunnel with the Interface MIB. The relationships to the interface MIB of tunnel identifiers was discussed and I believe determined to be an implementation specific issue. This was then to be handled outside the scope of the IPSec MIBs. > > > > 2) As part of an attempt to recycle resources in a security > gateway, would > > it be possible to add an 'idle timer' that is used a bit > like LifeTime, > > but allow user inactivity to be identified and acted on in some way > > (delete the SAs)? This is a monitoring MIB only. While the addition of the idle timer might be a good idea, the ability to delete the SA via SNMP is not within the scope of this MIB. I'm really concerned that the addition of the ability to write will open up real problems in handling security issues; I've added writeable objects to control traps in the new MIBs, but I'm concerned about even those. > > > > 3) While thinking about how to identify when a tunnel was > broken, has > > anyone proposed a way to actively monitor IP tunnels? I thinking of > > something like an ICMP message poller to operate a bit like > a PPP Echo > > poll which can be used to declare the tunnel 'down'. There is talk of a 'keep-alive' notification; others will probably comment on that. > > > > 4) There is a lot of text in this draft that suggests that > IKE can be used > > to negotiate a 'protection suite' of just IPCOMP. Have I > missed something? > > Does anyone support this? This option would seem to be > better placed as > > an addition to IP-IP Tunnels/MIBs. There is nothing that precludes IKE negotiating just IPCOMP. Whether it is supported or not is an implementation issue. In any case, the new MIB proposal treats individual SAs completely separately; the IPCOMP SAs are in their own tables. > > > > 5) The IPSEC Tunnel table - given that it can contain > TRANSPORT and TUNNEL > > mode types, should we use a name other than tunnel in the > table name? How > > about IPSEC Connection - to go with the IKE Connection table? The words 'transport' and 'tunnel' are encapsulation modes. The 'tunnel' concept is just as valid since the original data (not including the IP header anymore) is still wrapped in another header and opaque to the rest of the world when wrapped. In any case, it's gone from the current proposals for the MIB. > > > > 6) Accounting. I guess I was going to use SA > initiation/termination as a > > handle to do IPSEC Accounting. If TRAPs are not intended > for transient SA > > initiation/termination, how could this be done? I suppose > it could be > > done on a timer basis that simple logs deltas on IPSEC Tunnel table > > entries. The concepts of transient and permanent tunnels are gone, since tunnels are gone. However, when the application specific overlay MIBs are added, your concerns should be applied to them. > > > > 7) Under certain circumstances, I'd like to be able to use > SETs to do some > > rough management. I understand there are security worries > with this, but > > the SNMP flow could itself be protected with IPSEC... I'm > looking to add > > things such as turning IPSEC on/off, deleting IKE-SA or IPSEC-SA. Again, this is a monitoring MIB only. I'd like to see how we can deal with the security issues before we add this kind of thing. > > > > 8) What counts the Phase-2 IKE traffic? It isn't clear to > me what exactly > > the IKE Control and IKE SA entries count as 'traffic'. The bytes that go across the wire. It's a measure of the 'overhead' used to manage the IPSec SAs themselves. At least, that's the intent; however this makes it different from the amount of traffic applied to the security transforms. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Mon Apr 12 17:06:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23035; Mon, 12 Apr 1999 17:06:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11521 Mon, 12 Apr 1999 16:24:33 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1062BBC@sothmxs06> From: Greg Carter To: "'Kim Edwards'" , ipsec Subject: RE: Mismatching PFS Date: Mon, 12 Apr 1999 16:24:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It fails, you know whether or not you are doing PFS at the time the SA is agreed to. If the transform attribute list sent by the initiator doesn't contain the DH group description parameter than that means they don't want to do PFS. If it does that means PFS was agreed to and they must send the KE payload. Bye. > -----Original Message----- > From: Kim Edwards [mailto:kimed@nortelnetworks.com] > Sent: Monday, April 12, 1999 1:43 PM > To: ipsec > Subject: Mismatching PFS > > > We are designing our IPSec implementation to allow PFS to be > enabled/disabled on a per flow basis (i.e. SPD entry). > > Assume that an initiator is negotiating an IPSec SA without > PFS (i.e. it > will not send the optional [KE] payload). What happens if > our responder > wants PFS for this particular flow/SPD entry, should the SA > negotiation > be failed by the responder? If it is failed, where is this referenced > in the literature? > > If it is not failed, is this not a serious concern that a responder is > lowering its security standards to accommodate this request? > > Thanks, > > Kim Edwards > Nortel Networks > > From owner-ipsec@lists.tislabs.com Mon Apr 12 20:03:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA05762; Mon, 12 Apr 1999 20:03:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12016 Mon, 12 Apr 1999 19:59:18 -0400 (EDT) Date: Tue, 13 Apr 1999 03:07:02 +0300 (EET DST) Message-Id: <199904130007.DAA24852@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: draft-kivinen-ike-ext-meth-00.txt In-Reply-To: <199904091727.NAA00514@pzero.sandelman.ottawa.on.ca> References: <199904090020.DAA11776@torni.ssh.fi> <199904091727.NAA00514@pzero.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under Emacs 19.34.2 X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > 6.1 has an extra ) > security implications then the new version SHOULD NOT fall back to > previous version but instead fail the negotiation with a clear error > message). > ^ Removed. > What about having the machine that gets the major version number > greater than its own initiating on its own... in order to send an > authenticated INVALID-MAJOR-VERSION, and then the original initiator > can use that phase 1 to do stuff? I tried to keep the initiator / responder roles same, just to avoid denial of service attacks (somebody starts flooding you with random source ip-address and major number 2, you start to initiating connection to all those machines), and avoid problems with the identities (you don't really know to whom the other end wanted to talk, and who the other end is == there is no enough data for original responder to initiate phase 2 anyways). > When you say "ignore the packet" --- you should say "datagram" > instead, and probably should say "ignore the ISAKMP datagram". > Packet could mean many things, but it could be misinterpreted to > mean ISAKMP *payload*. Changed. > I think that section 10 needs to be expanded to include an example > that you can use vendorID to protect private use DOI numbers in > proposals. Section 11 goes into this a bit more, but the connection > isn't clear. I added a paragraph about that. > Section 15, last paragraph: > > trusted in order to avoid lengthy timeouts in error situations. If there > is a ISAKMP SA established, then unauthenticated notifications should > propably be ignored. > s/should/SHOULD/? Fixed. I included the latest version of the draft to the end. I will also now submit it as IPSEC wg draft. Here is now the changes from the previous version: Section 6: Added comment about having only one version number, that defines both ISAKMP and IKE. Section 10: Added paragraph about how to use vendor id payloads and private-use values. Section 11: Added comment that ISAKMP/IKE DOI should be separated to its own document. Section 11: Changed text from MAY to SHOULD NOT about updating minor version number when adding new IANA registered data attribute types. (this is mostly doi issue, not a ISAKMP/IKE protocol version issue). Section 13: Added comment that identity type is DOI issue, not protocol issue. Section 13: Changed text from MUST to SHOULD NOT about updating minor version number when adding new identity types. Identity types are defined in the DOI, the do not have meaning in the ISAKMP/IKE protocol context. Also old implementations can find out generic identity type from the generic identity payload format, thus they can detect unknown identity types. Section 16: Added comments about not having version numbers for DOI. If incompatible changes are done new DOI number must be allocated. Section 16: Added comment that if ISAKMP/IKE DOI is updated there might be need to update minor version number. ---------------------------------------------------------------------- IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT SSH Communications Security draft-ietf-ipsec-ike-ext-meth-00.txt 13 April 1999 Expires: 13 October 1999 IKE Extensions Methods Status of This memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislab.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in IKE [RFC-2409]. T. Kivinen [page 1] INTERNET-DRAFT 13 April 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Sending Error Notifications . . . . . . . . . . . . . . . . . . 3 5. Order of Checking . . . . . . . . . . . . . . . . . . . . . . . 3 6. ISAKMP Major and Minor Version Numbers . . . . . . . . . . . . . 3 6.1. ISAKMP Major Version Number . . . . . . . . . . . . . . . . 4 6.2. ISAKMP Minor Version number . . . . . . . . . . . . . . . . 4 7. Exchange type . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Flags Inside the Generic Packet Header . . . . . . . . . . . . . 6 9. Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . 8 11. Data Attribute Types and Values . . . . . . . . . . . . . . . . 8 11.1. Data Attributes, Protocol and Transform IDs . . . . . . . . 9 12. Reserved Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 13. Identity Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 14. Certificate Encoding . . . . . . . . . . . . . . . . . . . . . 10 15. Notify Message Type . . . . . . . . . . . . . . . . . . . . . . 10 16. Domain of Interpretation . . . . . . . . . . . . . . . . . . . 11 17. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The ISAKMP [RFC-2408] and IKE [RFC-2409] protocols can be extended in various ways. It is not clearly defined in the current document set how to use the extension mechanisms. Also, the current document set does not clearly define what a conforming implementation should do if it receives an extension that it does not understand. This document describes how to provide backwards compatibility with the old versions. The reader is assumed to be familiar with most of the terms and concepts described in the ISAKMP [RFC-2408] and IKE [RFC-2409] documents. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC-2119] document. 3. Terminology This document uses the terms "new version" and "old version" to identify the two different protocol versions. The new version is the version that supports the new extension, and the old version is a version that does not support it. The terms should always be interpreted only in the T. Kivinen [page 2] INTERNET-DRAFT 13 April 1999 current context. 4. Sending Error Notifications If the other end does not send error notifications, it is very hard to create usable extensions to the protocol. In that case the only way to detect whether the other end supports the extension is to see if the negotiation times out. This may cause unnecessary delays in the negotiation process. Because of that, all implementations SHOULD send notifications back when they reject any extensions. Implementations MAY limit the number of notifications sent out. A suitable limit could be something like one notification per second per host. Implementations SHOULD still continue sending notifications back when the other end resends its own IKE datagram (in case the error notification was lost). 5. Order of Checking The order of checks performed for IKE datagram SHOULD be following: o Major version number o Minor version number o Exchange type o Flags in the generic header o Payload types o Reserved field in the generic payload header o Payload specific checks. 6. ISAKMP Major and Minor Version Numbers All IKE datagrams contain version numbers, which describe the major and minor version numbers of the sending party. In IKE version 1.0 these version numbers are not authenticated. Thus when they are later changed to be authenticated, there always exists the possibility of a version rollback attack where the attacker forces negotiating parties to fall back to the version 1.0. This can be prevented by disabling the version 1.0 protocol. Major version number changes when major changes are done to the protocol, i.e there are changes in the generic packet encoding routines. This means that the older versions cannot understand the newer packet format at all. Minor version number changes when new payloads are defined or other minor changes in the protocol take place. The older versions can still process the generic packet structure, but there might be small T. Kivinen [page 3] INTERNET-DRAFT 13 April 1999 variations in the fields inside the payloads. There are no separate version numbers for ISAKMP and IKE, so they both share one major/minor version number. Because the ISAKMP document describes the generic packet formats etc, changes in the ISAKMP part will propably cause major version number to be incremented. On the other hand changes in the IKE part propably will keep the generic packet formats intact, thus only minor version number needs to be incremented. Each party MUST NOT change the version number it is sending during one negotiation, i.e if negotiation was started using version number 1.1, it MUST be used during the whole negotiation. Separate negotiations MAY have different version numbers, i.e newer version may restart negotiation with older version number. Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 negotiation that creates ISAKMP SA may use version X, and phase 2 negotiation done over that ISAKMP SA may use version Y. Because the minor version number is encoded into a 4-bit field (0-15), a minor version number rollover might occur. This means that the major version number must be incremented even if the packet structure is still actually same. Because of this phenomenon, incrementing the minor version number SHOULD be avoided if it is not absolutely necessary. Implementation supporting minor version X MUST support all features up to that level (it MUST at least be able to ignore the non-critical extensions, and detect critical extensions and abort the negotiation in that case). 6.1. ISAKMP Major Version Number If an old version receives a datagram with a major version number larger than its own, it SHOULD send the INVALID-MAJOR-VERSION notification back. It MUST put its own version number inside the notification datagram. This gives the other end the opportunity to obtain the version number supported by the sender of the notification. The received IKE datagram MUST then be discarded (the old version cannot parse anything else in the datagram because the generic packet structure has changed). Note that in most cases this notification sent by the remote host is not authenticated, so it can also lead to the version rollback attack. A new version receiving the INVALID-MAJOR-VERSION notification MAY fall back to the older version. If falling back to the older version has security implications then the new version SHOULD NOT fall back to previous version but instead fail the negotiation with a clear error message. 6.2. ISAKMP Minor Version number If an old version receives a datagram with a minor version newer than its own, it T. Kivinen [page 4] INTERNET-DRAFT 13 April 1999 o SHOULD continue processing the datagram, or it o MAY discard the IKE datagram. In that case it SHOULD send the INVALID-MINOR-VERSION notification back. In any case the old version MUST respond with a datagram containing the local minor version number so that a new version can get the older version number and fall back to same version if necessary. The new version MAY always start with the latest version number and fall back to the previous version every time separately, or it MAY cache this information for some time, or the version number used may be configured manually. The minor number MUST be updated if o new flags are added (see section ``Flags Inside the Generic Packet Header'') o new use of a RESERVED field is defined (see section ``Reserved Fields'') The minor number MAY be updated if o new general purpose payload types are added (see section ``Payload Types'') The minor number SHOULD NOT be updated if o new exchange types are added (see section ``Exchange type'') o new payload types that can only be used in specific exchange etc are added (see section ``Payload Types'') o new IANA registered data attribute types are defined (see section ``Data Attribute Types and Values'') o new IANA registered data attribute values are defined (see section ``Data Attribute Types and Values'') o new certificate encoding type is added (see section ``Certificate Encoding'') o new identity type is defined (see section ``Identity Type'') The minor number MUST NOT be updated if o new domain of interpretation is defined (see section ``Domain of Interpretation'') 7. Exchange type An exchange type defines a generic packet exchange between two T. Kivinen [page 5] INTERNET-DRAFT 13 April 1999 negotiating parties. It defines the number of datagrams in the exchange, the generic meaning of the packets (i.e. in main mode the first two datagrams exchange SA payloads, the next two datagrams are used for the key exchange, and the final two datagrams are used to exchange identities and to authenticate the exchange). If an implementor wants to add new datagrams to the existing exchanges, then the implementor MUST create a new exchange and allocate a new exchange type for it. If an implementation receives a datagram that contains an exchange type it does not understand it SHOULD send back the INVALID-EXCHANGE-TYPE notification. Also it MUST ignore the IKE datagram. If an implementation receives the INVALID-EXCHANGE-TYPE notification it MAY fall back to a more standard exchange (for example, from the aggressive mode to the main mode). When new exchange types are added, the minor version number SHOULD NOT be updated. A new version MAY always start with the new exchange type and fall back to a previous, more standard exchange type every time separately, or it MAY cache this information for some time, or the exchange type used may be configured manually. 8. Flags Inside the Generic Packet Header Flags are a part of the generic ISAKMP packet structure. Currently, three flags are defined (encryption, commit bit, authentication only bit). When new flags are defined the minor version number MUST be updated. When a new flag is added, the specification MUST indicate if this flag has any security implications and whether a new version should fail the negotiation if the other end is using an old version. If the old version receives a datagram with a newer minor version number, and some unknown flags are set it o SHOULD continue the exchange and ignore the new flags, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- FLAGS notification back. If a new version notices that the other end is using an old version (from the version numbers) it MUST fail the negotiation if it tried to set a flag that has security implications. If the flag it set does not have security implications it MAY continue the exchange. 9. Payload Types T. Kivinen [page 6] INTERNET-DRAFT 13 April 1999 Each payload inside a datagram contains a type field in the generic payload header. The payload type describes the internal structure of the payload. Unknown payloads can be ignored because the generic payload header contains the length of the payload data. Payload types in the special private range are to be used for mutually consenting implementations only. Implementations MUST NOT send payloads of a private type unless the both parties have both sent and received a familiar vendor ID payload. After this exchange of the vendor ID payloads during the phase 1, implementations MAY immediately start sending private payloads. When new payload types are defined (other than private-use payloads), and a new version can detect from somewhere else than from version numbers that the other end understands or does not understand the new payload types, then the minor version number SHOULD NOT be updated. If there is no way to detect if the other end understands the newly defined payload types then the minor version number SHOULD be updated. For example if the newly defined payload type can only be used in a certain new exchange type (like the proposed attribute payload inside the transactional exchange) then an old version will fail the negotiation because of the new exchange type, and a new version can detect that. There is no need to update the version number in that case. This allows for creating optional features in the IKE protocol in such a manner that the implementors do not need to implement them all. Every time the minor version number is updated all the implementations MUST understand all the new mandatory payloads. Note that there is a risk of "mix and match" in this approach. In the case of a new generic payload that can be used in several exchanges etc, the minor version number MAY be updated. When a new payload type is added, the corresponding specification MUST indicate if the new payload has any security implications and whether a new version should fail the negotiation if the other end is using an old version. The specification MUST also indicate whether it is mandatory to implement the new feature or not. If the implementation receives an unknown private payload type it o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- PAYLOAD-TYPE notification back. If the implementation receives an unknown payload type from the RESERVED range and the version numbers are same, it MUST fail the negotiation, and it SHOULD send INVALID-PAYLOAD-TYPE notification back. If the implementation receives unknown payload type from the RESERVED range, and the other end's minor version number is newer, it T. Kivinen [page 7] INTERNET-DRAFT 13 April 1999 o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- PAYLOAD-TYPE notification back. If the new version has sent out a payload of a type that is defined first in a newer version of the protocol than an other end understands (this can be detected by checking the minor version number), and such that the payload has security implications then it MUST fail the negotiation. There may be a need to add a criticality flag in the generic payload header in the next version of IKE [RFC-2409]. This allows an old version to detect immediately whether it can safely ignore the payload or whether it MUST fail the negotiation (in that case it SHOULD send an error notification). This criticality flag could be added to the reserved field of the generic payload header (there are 8 reserved bits inside the generic payload header). See section ``Reserved Fields'' for more information what old version would handle that criticality flag. 10. Vendor ID Payload The vendor ID payload is a payload that can be included anywhere in the phase 1 negotiation. It gives the other end a possibility to recognize the remote implementation. Vendor ID has two uses. The first one is that by sending a vendor ID payload the initiator specifies whose private-use values it has ability to use (it SHOULD only send only one vendor ID, or at least all the vendor ID payloads MUST have same owner, i.e they MUST NOT have overlapping private numbers defining different things). When initiator wants to use some private-use values in the exchange, it just adds its own vendor ID payload. When the responder receives that vendor ID payload along with the for example the SA payload it can find out whose private-use values are inside the SA payload by checking the vendor ID payload. The second use is to allow for vendor specific extensions, after both ends have sent and received familiar vendor IDs. Implementations MUST NOT fail a negotiation because of the presence of the vendor ID payload, i.e. they MUST be able to ignore it. If familiar vendor ID payloads have been exchanged (both sent and received) then implementations MAY do anything, including using private extensions, private payloads, new identity types, running nethack over the ISAKMP SA, etc. 11. Data Attribute Types and Values SA payloads and some other payloads in the IKE contain data attributes. Data attribute consists of an attribute type and a value. The data T. Kivinen [page 8] INTERNET-DRAFT 13 April 1999 attribute type and value number spaces are divided into two parts: The IANA range and the private-use range. The phase 1 data attribute types and values are defined in the IKE document and ISAKMP documents. This part should propably be separated from those documents to separate IKE DOI. The Phase 2 data attributes are defined in the DOI [RFC-2407] document. The private-use data attribute TYPES can be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values the sender is using. When adding new IANA registered data attribute TYPES the minor version number of the protocol MAY be updated. The private-use data attribute VALUES can also be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values sender is using. When adding new IANA registered data attribute VALUES the minor version number of the protocol SHOULD NOT be updated. 11.1. Data Attributes, Protocol and Transform IDs The proposal or transform payload MUST NOT be selected by the responder if it contains unknown protocol IDs, transform IDs, data attribute types, or data attribute values. This means that an initiator SHOULD always include a proposal without any private-use types or values so that if the other end does not understand them then it may select the transform or proposal without private-use types or values. 12. Reserved Fields Lots of payloads in the IKE contain RESERVED fields that are defined to be zero and whose contents MUST be checked. This makes extension of the payloads very difficult to implement. Changing this so that their contents MUST be checked only if the version numbers are same makes it much easier to introduce backwards compatible extensions to the protocol in the future. When a new use of a RESERVED field is defined the minor version number MUST be updated. When a new use of a RESERVED field is defined, the corresponding specification MUST indicate if this new use of the RESERVED field has any security implications and whether a new version should fail the negotiation if the other end is using an old version. If an old implementation receives a packet that contains a non-zero RESERVED field, and the version number of the other end is newer than the local one then it o SHOULD ignore the contents of the RESERVED field and continue, or it T. Kivinen [page 9] INTERNET-DRAFT 13 April 1999 o MAY ignore the IKE datagram. In that case it SHOULD send the INVALID- RESERVED-FIELD notification back. If the new version notices that the other end is using the old version it MUST fail the negotiation if it tried to use the RESERVED field in such a way that has security implications. If the new defined use of the RESERVED field does not have security implications it MAY continue the exchange. 13. Identity Type The identity type is used to specify the interpretation of the identity payload contents. The identity type is specified in the DOI document, but the generic structure is defined in the ISAKMP document. This generic structure contains this identity type value. When a new identity type is specified the minor version number SHOULD NOT be incremented. If an old version receives an unknown identity type, it MUST fail the negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification back. A new version MAY always start with the new identity type and fall back to a previous more standard identity type every time separately, or it MAY cache this information for some time, or it MAY configure the identity type to be used manually. 14. Certificate Encoding Certificate encoding is used to specify the interpretation of the certificate payload contents. When a new certificate encoding type is added the minor version number SHOULD NOT be incremented. If an old version receives an unknown certificate encoding type, it o SHOULD just ignore the payload, and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- CERT-ENCODING notification back. 15. Notify Message Type Messages containing notify payload are sent to either notify an error situation or to give out status information. Each notify payload contain a notify message type, which describes the message type. The nofity message types are divided in the several separate ranges: 1 - 8191 ISAKMP error code range T. Kivinen [page 10] INTERNET-DRAFT 13 April 1999 8192 - 16383 Private use error code range 16384 - 24575 ISAKMP status code range 24576 - 32767 DOI status code range 32768 - 40959 Private use status code range If an unknown error (1 <= code <= 16383) notification type is received the receiver MUST treat it as a fatal error and abort the negotiation. If an unknown status (16384 <= code <= 40959) notification type is received the receiver MUST ignore the notification payload. For example, a new keep-alive protocol for the ISAKMP SA may be defined by just defining that both ends must send a new STILL-CONNECTED notification every 60 seconds. If the other end never sees those notifications, it just assumes that the other end does not support this feature, and ceases to send any further keep-alive packets. If that new STILL-CONNECTED status code is selected from the status code range, then old implementations will just ignore them. When using notifications, implementations must take care of what to do with the notifications which are not authenticated (i.e those received before the ISAKMP SA is ready). If there is no ISAKMP SA established with the remote host, then most of the notifications may still be trusted in order to avoid lengthy timeouts in error situations. If there is a ISAKMP SA established, then unauthenticated notifications SHOULD propably be ignored. 16. Domain of Interpretation Each SA payload (and some others like, notify, and delete payloads) specifies the domain of interpretation for the exchange. There is no version numbers in the DOI, so if new version of DOI is incompatible with the previous version a new DOI number MUST be allocated. In normal case there is no need to have version number in the DOI, and additions to it may be done without new DOI number. If an unknown domain of interpretation is received the responder MUST discard the IKE datagram and it SHOULD send the DOI-NOT-SUPPORTED notification back. This usually also means that the negotiation is aborted. When a new domain of interpretation is defined the minor version number MUST NOT be incremented. If ISAKMP DOI is modified there might be need to update the version numbers. T. Kivinen [page 11] INTERNET-DRAFT 13 April 1999 17. Security Considerations This document describes how to use the extension mechanisms to [RFC-2408] and IKE [RFC-2409]. Because some of those extensions might have security implications it is required that when those extensions are defined it is also explained what security implications they have and what the implementations supporting them should do if the other end does not support the extensions. One security problem comes from the [RFC-2408] and IKE [RFC-2409] protocol, because the version number, exchange type, and flags fields are not authenticated in the version 1.0 protocol. If a real security problem is later found from the 1.0 protocol the implementors MUST make sure that they never fall back to any previous version because the attacker can force falling back to previous version by changing the version numbers inside the datagrams. Another security problem comes from the fact that there is no way to send authenticated notifications before the phase 1 (ISAKMP) SA is finished. This means that most of the error notifications about the Phase 1 exchange are sent without any kind of protection. 18. References [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998. [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 19. Authors' Addresses Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi T. Kivinen [page 12] -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Apr 13 01:34:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA28209; Tue, 13 Apr 1999 01:34:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12728 Tue, 13 Apr 1999 02:13:47 -0400 (EDT) X-Internal-ID: 370E3C1B0000BD8A X-Internal-ID: 370B8845000035C1 Message-ID: <3712E207.D8AF67B@detexis.thomson-csf.com> Date: Tue, 13 Apr 1999 08:19:51 +0200 From: Yves Everaert X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: mode (tunnel/transport) in PF_Key Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How the mode (tunnel/transport) is specified by IKE to the IPSec Kernel, the PF_Key messages does not include directly this piece of information. If it's thanks to address-extension, what's the type of this extension ? Thanks Regards Yves From owner-ipsec@lists.tislabs.com Tue Apr 13 03:22:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA05985; Tue, 13 Apr 1999 03:22:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13141 Tue, 13 Apr 1999 04:17:06 -0400 (EDT) Date: Tue, 13 Apr 1999 11:24:38 +0300 (EET DST) From: Markku Savela Message-Id: <199904130824.LAA02050@anise.tte.vtt.fi> To: yves.everaert@detexis.thomson-csf.com CC: ipsec@lists.tislabs.com In-reply-to: <3712E207.D8AF67B@detexis.thomson-csf.com> (message from Yves Everaert on Tue, 13 Apr 1999 08:19:51 +0200) Subject: Re: mode (tunnel/transport) in PF_Key Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > How the mode (tunnel/transport) is specified by IKE to the IPSec Kernel, > the PF_Key messages does not include directly this piece of information. Whether or not to use tunnel is defined by the policy definition. IKE cannot change it. No PF_KEY interface is needed. Of course, this is an issue where views may differ: some want IKE to negotiate policy (and demand policy extensions to PF_KEY). I would prefer them separate. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Tue Apr 13 03:31:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA06127; Tue, 13 Apr 1999 03:31:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13129 Tue, 13 Apr 1999 04:15:46 -0400 (EDT) Date: Tue, 13 Apr 1999 11:23:31 +0300 (EET DST) Message-Id: <199904130823.LAA23719@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" CC: ipsec@lists.tislabs.com Subject: Re: draft-kivinen-ike-ext-meth-00.txt In-Reply-To: <002701be8558$8946fe20$6b323ac3@svan-pc-home.elvis.ru> References: <002701be8558$8946fe20$6b323ac3@svan-pc-home.elvis.ru> X-Mailer: VM 6.34 under Emacs 19.34.2 X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > >There are no separate version numbers for ISAKMP and IKE, so they both > >share one major/minor version number. Because the ISAKMP document > >describes the generic packet formats etc, changes in the ISAKMP part > >will propably cause major version number to be incremented. On the other > >hand changes in the IKE part propably will keep the generic packet > >formats intact, thus only minor version number needs to be incremented. > Well, what about situations when ISAKMP is used not with IKE, but with > some other KE protocol? When somebody starts using it that way, they have to define what do they mean. The current situation is that there is only one major and minor version number, and we are stuck with that, until we revise the protocol specification. > Or, even worse, when ISAKMP SA contains multiple transforms with > different KE protocols in each? To which of them will you apply > minor version number? Can you give me example how that can be done? The SA payload contains only one DOI, so I think you have to use it for only one KE protocol at a time. So if you want to support multiple KE protocols you propably have to allocate DOI numbers for each of them, thus you can only use one of the in one negotiation. > I think that new IKE versions should be encoded as a totally new transform > identifiers. Now we have only KEY_IKE; when new version appear we will > have, say, KEY_IKE and KEY_IKE_v2. The problem is that if we redefine some fields in the generic payload structure (like adding the criticality flag) for IKE, then we cannot parse the SA payload to find out that transform identifier. But you are right in any case that, I should add something about that KEY_IKE transform number also in the draft. I completely forgot it... > >Each party MUST NOT change the version number it is sending during one > >negotiation, i.e if negotiation was started using version number 1.1, it > >MUST be used during the whole negotiation. Separate negotiations MAY > >have different version numbers, i.e newer version may restart > >negotiation with older version number. > > > > > [...] > > >6.2. ISAKMP Minor Version number > > > >If an old version receives a datagram with a minor version newer than > >its own, it > > > >o SHOULD continue processing the datagram, or it > >o MAY discard the IKE datagram. In that case it SHOULD send the > > INVALID-MINOR-VERSION notification back. > > > >In any case the old version MUST respond with a datagram containing the > >local minor version number so that a new version can get the older > >version number and fall back to same version if necessary. > > Does it means (in conjunction with previously quoted paragraph, that > prohibits version number changing during negotiating), that it is > possible for ISAKMP headers of initiator and responder to contain > _different_ minor version numbers during negotiating (if responder > desides to continue negotiating)? Yes. There is nothing in the current RFC set to say against that. > In this case initiator must keep in mind two minor version numbers > during negotiating - one (highest), that it puts into outgoing > ISAKMP datagrams, and the other (lowest), that it process both > incoming and outgoing datagrams according with. Is it right? Yes. > Note, that if it is the case, initiator's datagrams will contain one > minor version number, but will be formatted according to other > (lower) minor version number. Not really. It sends packet out just as if the other end would be using same version number. It can disable itself to use of some extensions that it knows would cause problems in the other end, but it should still continue sending packets that conform its own version number. If it detects it cannot do that (because it would need to use extension that the other end will not understand), it should fall back to the previous version and start the negotiation from the start. All this really depends on what kind of extensions the next version of ISAKMP/IKE defines. Remember that this document is mainly for the current implementators. The basic idea is that if they follow the basic rules in the document and those who define next version of protocol or add new extension does the same, then the old versions can work with the newer versions. Those who define next version of protocol or add new extension MUST define in the document what new version should do if the other end doesn't support the feature. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Apr 13 12:01:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20726; Tue, 13 Apr 1999 12:01:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14309 Tue, 13 Apr 1999 09:38:11 -0400 (EDT) Date: Tue, 13 Apr 1999 09:45:08 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: mode (tunnel/transport) in PF_Key In-Reply-To: <199904130824.LAA02050@anise.tte.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 13 Apr 1999, Markku Savela wrote: > Whether or not to use tunnel is defined by the policy definition. IKE > cannot change it. No PF_KEY interface is needed. The crucial fact to understand is that PF_KEY as currently defined is meant to be a *key management* kernel interface, not a general IPSEC kernel interface. However, PF_KEY itself compromises somewhat on this, by dealing with other aspects of SA creation than just keying -- aspects which trespass into realms of (gasp!) policy -- so it is not surprising that many people want to extend it further in that direction. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Tue Apr 13 17:06:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA03532; Tue, 13 Apr 1999 17:06:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15927 Tue, 13 Apr 1999 16:50:56 -0400 (EDT) From: Steve Kent Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: Date: Tue, 13 Apr 1999 16:58:53 -0400 To: Jackie Wilson Subject: Re: Sequence Number Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jackie, >I thought using the transforms ESP_EDS_IV64 and ESP_DES_IV32 could be used to >provide backward compatibility to the old headers. Did I misunderstand this? I'll leave it to others to comment on what these IKE transforms may be intended for. Note, however, that the old versions of ESP and AH, with different formats and processing rules, have been replaced by the formats and processing specified in 2401, 2402, and 2405. Since the same protocol IDs are used for the old and new versions of AH and ESP, and since IPsec compliance does not require use of IKE, e.g.,to negotiate what version might be employed, it seems clear that a compliant IPsec implementation MUST follow the new, not old, AH and ESP specifications. Steve From owner-ipsec@lists.tislabs.com Wed Apr 14 02:17:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA25248; Wed, 14 Apr 1999 02:17:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17131 Wed, 14 Apr 1999 02:51:22 -0400 (EDT) Message-ID: <01BE865D.450E7B10@elksant1.mam.gov.tr> From: Devrim Unal To: "'ipsec@lists.tislabs.com'" Subject: Standard symbol for security gateway (IPSec) Date: Wed, 14 Apr 1999 09:57:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello to all, Does anybody know a standard symbol for a security gateway? I'll appreciate to receive one if there is one. Thanks in advance Best Regards Devrim Unal From owner-ipsec@lists.tislabs.com Wed Apr 14 04:25:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00557; Wed, 14 Apr 1999 04:25:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17409 Wed, 14 Apr 1999 04:36:57 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC032004@new-exc1.ctron.com> From: "Waters, Stephen" To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC monitor MIB Date: Wed, 14 Apr 1999 09:43:52 +0100 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 Thanks for the information Tim, I look forward to seeing the new offerings. I have a few responses: SPD - I would still like to push the point the IPSEC architecture does have the concept of SPDs and these SPDs can be applied to really interfaces if desired (I think this makes very good sense when a router/security gateway has a single/limited non-trusted interfaces). I would like to suggest that and SPD table be considered (just name and reference to an ifEntry) to live above the IKE Phase-1. The ifEntry may not actually point to an Interface entry, but it could. The interface that IKE packets are sent over could also be different from the interface referenced in the SPD table entry; the only implication is that a packet that is sent/received on a given interface may have an SPD associated with it in the same way that a set of packet filters are applied to an interface. This is similar to firewall events that reference an interface if it is appropriate. Allowing SA to be grouped under SPD allows for the possibility of having duplicate policy applied to multiple interfaces, or the same policies applied to all interfaces. Monitoring MIB - to me all MIBs are monitoring MIBs :) . Just because a MIB does not allow you to completely configure a feature does not mean it can't have a few SETs - in my book. Keep-Alive poll - I'm keen to see what this is. It would be a shame if this is IPSEC-specific since tunnels without IPSEC protection need similar help (IP-IP, GRE). IPCOMP-Only - this is not something that has been tested at bake-offs. Does anyone intend to implement this? Our approach currently would be to just use an IP-IP tunnel with LZS 'on' as a static configuration, rather than hijack IKE to become a generic tunnel negotiation protocol. Regards, Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Monday, April 12, 1999 8:38 PM To: Waters, Stephen; Subject: RE: IPSEC monitor MIB > -----Original Message----- > From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] > Sent: April 12, 1999 2:53 PM > To: ipsec@lists.tislabs.com > Subject: IPSEC monitor MIB > > > I have a few thoughts having read draft 3 of the IPSEC > Monitoring MIB: That series has been abandoned; there is another that is draft 00 which is not representative either, but is closer; a new architecture was presented in Minneapolis. (I need to get the first series pulled off the WG page...) The current proposal (and we hope to release new documents very soon) consists of three separate MIBs. A rough description of them is: -a DOI-independent ISAKMP MIB -an IPSec SA MIB (raw SAs, independent of how created) -an IKE MIB, that links phase 1 and phase 2 Concepts like channels and tunnels as introduced in the original] series of MIBs are gone; they will have to added in as application specific MIBs on top of the above three MIBs. So, having said that... > > > > > > 1) I feel there is room for an 'SPD' table entry to sit > 'above' the IKE > > Control Channel table. The IPSEC architecture describes > interface-specific > > SPD (I seem to remember) and in this case, the same IDs > used to make the > > IPSEC MIB entries unique could occur many time, for > example, if I want to > > define the security on a number of 'public' interfaces to 'protect > > everything' in a LAN-LAN case, then I may have multiple > occurrences of the > > same simple selectors. The IPSEC MIB could then be used as > an extension of > > the Interface MIB. Control channels are gone; they were the logical phase 1 tunnel. I think you mean to associate the phase 2 tunnel with the Interface MIB. The relationships to the interface MIB of tunnel identifiers was discussed and I believe determined to be an implementation specific issue. This was then to be handled outside the scope of the IPSec MIBs. > > > > 2) As part of an attempt to recycle resources in a security > gateway, would > > it be possible to add an 'idle timer' that is used a bit > like LifeTime, > > but allow user inactivity to be identified and acted on in some way > > (delete the SAs)? This is a monitoring MIB only. While the addition of the idle timer might be a good idea, the ability to delete the SA via SNMP is not within the scope of this MIB. I'm really concerned that the addition of the ability to write will open up real problems in handling security issues; I've added writeable objects to control traps in the new MIBs, but I'm concerned about even those. > > > > 3) While thinking about how to identify when a tunnel was > broken, has > > anyone proposed a way to actively monitor IP tunnels? I thinking of > > something like an ICMP message poller to operate a bit like > a PPP Echo > > poll which can be used to declare the tunnel 'down'. There is talk of a 'keep-alive' notification; others will probably comment on that. > > > > 4) There is a lot of text in this draft that suggests that > IKE can be used > > to negotiate a 'protection suite' of just IPCOMP. Have I > missed something? > > Does anyone support this? This option would seem to be > better placed as > > an addition to IP-IP Tunnels/MIBs. There is nothing that precludes IKE negotiating just IPCOMP. Whether it is supported or not is an implementation issue. In any case, the new MIB proposal treats individual SAs completely separately; the IPCOMP SAs are in their own tables. > > > > 5) The IPSEC Tunnel table - given that it can contain > TRANSPORT and TUNNEL > > mode types, should we use a name other than tunnel in the > table name? How > > about IPSEC Connection - to go with the IKE Connection table? The words 'transport' and 'tunnel' are encapsulation modes. The 'tunnel' concept is just as valid since the original data (not including the IP header anymore) is still wrapped in another header and opaque to the rest of the world when wrapped. In any case, it's gone from the current proposals for the MIB. > > > > 6) Accounting. I guess I was going to use SA > initiation/termination as a > > handle to do IPSEC Accounting. If TRAPs are not intended > for transient SA > > initiation/termination, how could this be done? I suppose > it could be > > done on a timer basis that simple logs deltas on IPSEC Tunnel table > > entries. The concepts of transient and permanent tunnels are gone, since tunnels are gone. However, when the application specific overlay MIBs are added, your concerns should be applied to them. > > > > 7) Under certain circumstances, I'd like to be able to use > SETs to do some > > rough management. I understand there are security worries > with this, but > > the SNMP flow could itself be protected with IPSEC... I'm > looking to add > > things such as turning IPSEC on/off, deleting IKE-SA or IPSEC-SA. Again, this is a monitoring MIB only. I'd like to see how we can deal with the security issues before we add this kind of thing. > > > > 8) What counts the Phase-2 IKE traffic? It isn't clear to > me what exactly > > the IKE Control and IKE SA entries count as 'traffic'. The bytes that go across the wire. It's a measure of the 'overhead' used to manage the IPSec SAs themselves. At least, that's the intent; however this makes it different from the amount of traffic applied to the security transforms. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Wed Apr 14 10:40:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07122; Wed, 14 Apr 1999 10:40:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17914 Wed, 14 Apr 1999 08:26:50 -0400 (EDT) Message-Id: <199904141233.IAA15311@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-ext-meth-00.txt Date: Wed, 14 Apr 1999 08:33:58 -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 Extensions Methods Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-ext-meth-00.txt Pages : 12 Date : 13-Apr-99 This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in IKE [RFC-2409]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ext-meth-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-ietf-ipsec-ike-ext-meth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-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: <19990413150123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ext-meth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990413150123.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Apr 14 12:21:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08416; Wed, 14 Apr 1999 12:21:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18255 Wed, 14 Apr 1999 08:53:40 -0400 (EDT) Message-ID: <009801be8650$a723cec0$03253ac3@svan-pc-home.elvis.ru> From: "Valery Smyslov" To: "Tero Kivinen" Cc: Subject: Re: draft-kivinen-ike-ext-meth-00.txt Date: Wed, 14 Apr 1999 12:27:29 +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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: >> Or, even worse, when ISAKMP SA contains multiple transforms with >> different KE protocols in each? To which of them will you apply >> minor version number? > >Can you give me example how that can be done? The SA payload contains >only one DOI, so I think you have to use it for only one KE protocol >at a time. So if you want to support multiple KE protocols you >propably have to allocate DOI numbers for each of them, thus you can >only use one of the in one negotiation. RFC2407explicitly states (section 4.4.2): Within the ISAKMP and IPSEC DOI framework it is possible to define key establishment protocols other than IKE (Oakley). Previous versions of this document defined types both for manual keying and for schemes based on use of a generic Key Distribution Center (KDC). These identifiers have been removed from the current document. The IPSEC DOI can still be extended later to include values for additional non-Oakley key establishment protocols for ISAKMP and IPSEC, such as Kerberos [RFC-1510] or the Group Key Management Protocol (GKMP) [RFC-2093]. So, I think, that while SA contains only one DOI, it's fully legal to include multiple transforms with different Transform Identifiers (e.g. KE protocols for this DOI) in it. Of course, there could be some restrictions on combinations of proposed KE protocols in one SA due to possible logical inconsistence of message, especially in Aggressive mode (the same thing as we have with different Auth methods in IKE, where negotiation is limited in Aggressive mode), but, in general, nothing prevents from putting multiple KE protocols in one SA. At least, I couldn't find any explicit prohibition in the RFCs. >> I think that new IKE versions should be encoded as a totally new transform >> identifiers. Now we have only KEY_IKE; when new version appear we will >> have, say, KEY_IKE and KEY_IKE_v2. > >The problem is that if we redefine some fields in the generic payload >structure (like adding the criticality flag) for IKE, then we cannot >parse the SA payload to find out that transform identifier. But you I think that redefining general payload structure is more of an ISAKMP's issue, not IKE's. In my opinion ISAKMP defines a "syntax", while IKE defines a "semantics" of KE process. In other words, nothing prevents from using IKE with some other "syntax" (providing the same functionality as ISAKMP), or from using ISAKMP with different "semantics" (another KE protocol). Adding criticality flag, I think, belongs to a "syntax", it doesn't change payload designation. >are right in any case that, I should add something about that KEY_IKE >transform number also in the draft. I completely forgot it... > >-- >kivinen@iki.fi Work : +358-9-4354 3218 >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Wed Apr 14 22:57:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA00823; Wed, 14 Apr 1999 22:57:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20935 Wed, 14 Apr 1999 23:43:16 -0400 (EDT) Date: Thu, 15 Apr 1999 12:31:06 +0530 (IST) From: Unmesh Kulkarni X-Sender: unmesh@pc096.cse.iitk.ernet.in To: ipsec@lists.tislabs.com Subject: SAD and SPD... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, The role of SPD for inbound packets, explained in the The IPSec Architcture document, is not very clear to me. Since the address, SPI and the protocol already specify an SA, do we seperately use SPD in this case? Thanx in advance, -Unmesh. From owner-ipsec@lists.tislabs.com Wed Apr 14 23:10:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA00963; Wed, 14 Apr 1999 23:10:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20987 Thu, 15 Apr 1999 00:15:40 -0400 (EDT) Message-Id: <3.0.6.32.19990415094742.012af100@hydmail> X-Sender: rohit@hydmail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 15 Apr 1999 09:47:42 To: Unmesh Kulkarni , ipsec@lists.tislabs.com From: Rohit Subject: Re: SAD and SPD... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:31 PM 4/15/99 +0530, Unmesh Kulkarni wrote: > >Hi All, > The role of SPD for inbound packets, explained in the The IPSec >Architcture document, is not very clear to me. Since the address, SPI and >the protocol already specify an SA, do we seperately use SPD in this case? The role of spd in case of inbound processing comes when you have to crosscheck whether the order and types of SAs which you have applied are the same as that of specifed in the inbound policy. Inbound SPD is also looked up to check for the presence of any bypass policy, if the SAlookup fails for the incoming packet. -Rohit >Thanx in advance, >-Unmesh. > > ################################################################## Rohit Aradhya Software Engineer Motorola (I) Electronics Ltd TSR Towers, Rajbhavan Road Somajiguda, HYDERABAD INDIA Ph # (040)3308095/96/97 Ext 3060 ################################################################## From owner-ipsec@lists.tislabs.com Thu Apr 15 11:44:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25067; Thu, 15 Apr 1999 11:44:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22277 Thu, 15 Apr 1999 09:31:30 -0400 (EDT) Date: Thu, 15 Apr 1999 09:38:40 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SAD and SPD... 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, 15 Apr 1999, Unmesh Kulkarni wrote: > The role of SPD for inbound packets, explained in the The IPSec > Architcture document, is not very clear to me. Since the address, SPI and > the protocol already specify an SA, do we seperately use SPD in this case? Yes, but in reverse: not to determine what action to take, but to check whether the action specified by address/SPI/protocol was correct for the packet that finally emerges. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Apr 15 15:04:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26977; Thu, 15 Apr 1999 15:04:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22610 Thu, 15 Apr 1999 11:23:45 -0400 (EDT) Message-Id: <9904151530.AA00088@giove.polito.it> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@lists.tislabs.com Subject: IKE implementation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Apr 99 17:30:20 BST From: Madalina Baltatu Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello. I'm new in IPsec, and I would like to know if there is any (if possible) free, functional (more or less) IKE implementation (for BSD systems) around... something that can be distributed for universities for study/test purposes? I'd appreciate any info. Thanks a lot. Madalina Baltatu. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Madalina Baltatu engineer, Ph.D. Student Politecnico di Torino phone: +39-11-5647090 Dip. Automatica e Informatica fax: +39-11-5647099 corso Duca degli Abruzzi 24 e-mail: baltatu@athena.polito.it 10129 Torino (TO), Italy From owner-ipsec@lists.tislabs.com Thu Apr 15 17:39:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28335; Thu, 15 Apr 1999 17:39:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23591 Thu, 15 Apr 1999 16:36:46 -0400 (EDT) Date: Thu, 15 Apr 1999 16:43:17 -0400 (EDT) From: Henry Spencer To: Madalina Baltatu cc: ipsec@lists.tislabs.com Subject: Re: IKE implementation In-Reply-To: <9904151530.AA00088@giove.polito.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Apr 1999, Madalina Baltatu wrote: > I'm new in IPsec, and I would like to know if there is any (if possible) > free, functional (more or less) IKE implementation (for BSD systems) around... > something that can be distributed for universities for study/test purposes? If you're willing to use Linux rather than BSD, the one in FreeS/WAN (see http://www.xs4all.nl/~freeswan/) might be suitable. It doesn't implement all of IKE yet, but it's getting there. The OpenBSD distribution includes, I believe, a cousin of the Linux one. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Apr 15 18:07:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28546; Thu, 15 Apr 1999 18:07:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23812 Thu, 15 Apr 1999 18:00:43 -0400 (EDT) Date: Fri, 16 Apr 1999 00:08:14 +0200 From: Markus Friedl To: Madalina Baltatu Cc: ipsec@lists.tislabs.com Subject: Re: IKE implementation Message-ID: <19990416000814.A20546@faui01.informatik.uni-erlangen.de> References: <9904151530.AA00088@giove.polito.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <9904151530.AA00088@giove.polito.it>; from Madalina Baltatu on Thu, Apr 15, 1999 at 05:30:20PM +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Apr 15, 1999 at 05:30:20PM +0100, Madalina Baltatu wrote: > I'm new in IPsec, and I would like to know if there is any (if possible) > free, functional (more or less) IKE implementation (for BSD systems) around... OpenBSD includes an IKE implementation. You can browser the source on the web http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/ -markus From owner-ipsec@lists.tislabs.com Fri Apr 16 02:08:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27355; Fri, 16 Apr 1999 02:08:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24761 Fri, 16 Apr 1999 02:34:09 -0400 (EDT) Message-ID: <3716DB7F.ECDDF38A@utimaco.co.at> Date: Fri, 16 Apr 1999 08:41:03 +0200 From: Michael Schmidt Organization: Utimaco Safe Concept GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,de-DE, de-AU MIME-Version: 1.0 To: Madalina Baltatu CC: ipsec@lists.tislabs.com Subject: Re: IKE implementation References: <9904151530.AA00088@giove.polito.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm new in IPsec, and I would like to know if there is any (if possible) > free, functional (more or less) IKE implementation (for BSD systems) around... > something that can be distributed for universities for study/test purposes? > I'd appreciate any info. There is an implementation for OpenBSD. It's available in the source code tree of OpenBSD (well - it's part of OpenBSD). Check out www.openbsd.org and pick up a (non-US) FTP server for download. For FreeBSD, there's a Japanese initiative, called KAME. Check out www.kame.net for details. Also, NetBSD has IPSEC extensions. I have no pointers available, though. Michael -- Michael Schmidt | Utimaco Safe Concept GmbH | Tel: ++43 732 655 755 - 35 Europaplatz 6 | Fax: ++43 732 655 755 - 5 A-4020 Linz, Austria | E-Mail: Michael.Schmidt@utimaco.co.at From owner-ipsec@lists.tislabs.com Fri Apr 16 08:00:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05529; Fri, 16 Apr 1999 08:00:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25299 Fri, 16 Apr 1999 06:52:55 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199904141233.IAA15311@ietf.org> MIME-Version: 1.0 To: IETF-Announce:;;;;@era.co.uk@era.co.uk;;; Cc: ipsec@lists.tislabs.com Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ext-meth-00.txt Date: Wed, 14 Apr 1999 08:33:58 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" 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 Extensions Methods Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-ext-meth-00.txt Pages : 12 Date : 13-Apr-99 This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in IKE [RFC-2409]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ext-meth-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-ietf-ipsec-ike-ext-meth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-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: <19990413150123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ext-meth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990413150123.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Apr 16 11:21:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA26225; Fri, 16 Apr 1999 11:21:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25898 Fri, 16 Apr 1999 09:38:13 -0400 (EDT) To: Markus Friedl cc: Madalina Baltatu , ipsec@lists.tislabs.com In-reply-to: Markus.Friedl's message of Fri, 16 Apr 1999 00:08:14 +0200. <19990416000814.A20546@faui01.informatik.uni-erlangen.de> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IKE implementation From: Jun-ichiro itojun Hagino Date: Fri, 16 Apr 1999 10:09:05 +0900 Message-ID: <10935.924224945@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I'm new in IPsec, and I would like to know if there is any (if possible) >> free, functional (more or less) IKE implementation (for BSD systems) around... >OpenBSD includes an IKE implementation. >You can browser the source on the web > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/ KAME IPv6/IPsec kit includes IKE implmentation too (www.kame.net, look for "SNAP" kit and a program "racoon" in the kit). itojun From owner-ipsec@lists.tislabs.com Fri Apr 16 11:23:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA26366; Fri, 16 Apr 1999 11:23:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25783 Fri, 16 Apr 1999 09:23:13 -0400 (EDT) Message-Id: <199904152115.XAA03589@waldorf.appli.se> To: Madalina Baltatu cc: ipsec@lists.tislabs.com Subject: Re: IKE implementation In-reply-to: Your message of "Thu, 15 Apr 1999 17:30:20 -0000." <9904151530.AA00088@giove.polito.it> Date: Thu, 15 Apr 1999 23:15:12 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Thu, 15 Apr 99 17:30:20 BST > From: Madalina Baltatu > I'm new in IPsec, and I would like to know if there is any (if > possible) free, functional (more or less) IKE implementation (for > BSD systems) around... something that can be distributed for > universities for study/test purposes? I'd appreciate any info. I and Niels Provos have written an implementation called isakmpd, sponsored by Ericsson Radio Systems, but released under BSD license. The code is available either as part of OpenBSD (www.openbsd.org, there are links on how to get the source on the web) in src/sbin/isakmpd, or from ftp.appli.se or ftp.gsnig.net in /pub/isakmpd. The former variant is crippled in two ways, no RSA functionality due to patent reasons and no foreign OS support. However, the latter variant has not been updated in a long time. Let's see if I can put up a snapshot tomorrow or so... If you are really interested in participating in the development there is of course a third way, getting an account to our CVS repository, but for setting up that I require to see some initial bug-hunting with fixes or feature additions. This implementation is still under development, but it is possible to use if you do not care to much of easy configuration and such. It has been shown to interoperate with a dozen or so of other IKE implementations. Niklas From owner-ipsec@lists.tislabs.com Fri Apr 16 11:53:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28027; Fri, 16 Apr 1999 11:53:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25920 Fri, 16 Apr 1999 09:40:14 -0400 (EDT) Date: Fri, 16 Apr 1999 14:48:33 +0900 (JST) From: Shoichi Sakane Message-Id: <199904160548.OAA25177@ta.nu.rant.yokogawa.co.jp> To: baltatu@athena.polito.it Cc: ipsec@lists.tislabs.com Subject: Re: IKE implementation In-Reply-To: Your message of "Thu, 15 Apr 99 17:30:20 BST" <9904151530.AA00088@giove.polito.it> References: <9904151530.AA00088@giove.polito.it> X-Mailer: Cue version 0.5 (990316-1755/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm new in IPsec, and I would like to know if there is any (if possible) > free, functional (more or less) IKE implementation (for BSD systems) around... There is Racoon in KAME IPv6/IPsec stack which is able to run on FreeBSD, BSD/OS and NetBSD. Racoon is in kit/src/racoon. You can find all information in http://www.kame.net/. /Shoichi `NE' Sakane/ From owner-ipsec@lists.tislabs.com Fri Apr 16 12:14:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29092; Fri, 16 Apr 1999 12:14:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25923 Fri, 16 Apr 1999 09:40:15 -0400 (EDT) Message-Id: <199904160511.HAA12736@waldorf.appli.se> To: Henry Spencer cc: Madalina Baltatu , ipsec@lists.tislabs.com Subject: Re: IKE implementation In-reply-to: Your message of "Thu, 15 Apr 1999 16:43:17 EDT." Date: Fri, 16 Apr 1999 07:11:54 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Thu, 15 Apr 1999 16:43:17 -0400 (EDT) > From: Henry Spencer > The OpenBSD distribution includes, I believe, a cousin of the Linux one. Actually it has no heritage from Pluto (The Linux IKE implementation). Pluto was considered as a basis at The start of the project but licensing, design goal differences and advice from the original author led to the decision of writing another one from scratch. Besides, competetition is good for all products. Niklas From owner-ipsec@lists.tislabs.com Fri Apr 16 12:17:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29270; Fri, 16 Apr 1999 12:17:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26132 Fri, 16 Apr 1999 10:35:33 -0400 (EDT) Message-Id: <9904161443.AA08886@giove.polito.it> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@lists.tislabs.com Subject: IKE implementation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Apr 99 16:43:01 BST From: Madalina Baltatu Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you very much for the information you've sent. Madalina. From owner-ipsec@lists.tislabs.com Fri Apr 16 17:00:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04484; Fri, 16 Apr 1999 17:00:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26934 Fri, 16 Apr 1999 15:15:47 -0400 (EDT) Message-ID: <027d01be883f$addcd2c0$634cf526@east.isi.edu> From: "Aaron Griggs" To: Cc: Subject: IPSec interop question Date: Fri, 16 Apr 1999 15:31:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am implementing IPSec in IPv6. We are ready to do some interoperability testing of our IPSec and ran across this issue. The AH document (RFC 2402) states the following: 3.3 Outbound Packet Processing ... For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. ... The SHOULD means one vendor may not interoperate with another. Why isn't this SHOULD a MUST? That would mean that any combination would work, right? I know this doesn't affect the required combos since AH is after ESP (IP_AH_ESP_DATA). "After" means it occurs closer to the IP header. However for IP_ESP_AH_DATA, why SHOULD I ignore the ESP header? You have to predict everything anyway for AH. And the ESP header is quite simple (as is AH) compared to the other IPv6 extension headers. And why say, "For simplicity of processing?" It is not necessarily simpler to ignore them if you want to authenticate the entire packet without having to worry that other security extension headers may exist after the AH header (at least on the send side). The issue here should be interoperating not simplicity. On the receive side, you can't throw away the extension headers because you many need them to do the AH authentication. Which means you may want to save the IPSec extension headers if you are not ignoring them. So since this is a SHOULD I want to try and get a consensus of what implementations do, be they IPv4 or IPv6. Are there any implementations that do not ignore IPSec headers that come after an AH header? Do most implementations just do the required IPSec combos and not worry about this? Thanks, Aaron From owner-ipsec@lists.tislabs.com Mon Apr 19 05:32:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27163; Mon, 19 Apr 1999 05:32:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA02801 Mon, 19 Apr 1999 05:10:21 -0400 (EDT) Message-ID: <371AF487.691D@loria.fr> Date: Mon, 19 Apr 1999 11:16:56 +0200 From: "khadija.boumahdi" Organization: LORIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: problem with ping6 and setkey References: <9904161443.AA08886@giove.polito.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk i try to run ping6 -A after adding 2 sa betwenn two machines but it semm that there is a problem, no packet was sent between these machines and when i consult the SAD, i found another sa with spi 0x00 added by the kernel after the ping6 -A . what is the problem? thinks From owner-ipsec@lists.tislabs.com Mon Apr 19 09:34:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29705; Mon, 19 Apr 1999 09:34:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03249 Mon, 19 Apr 1999 07:59:27 -0400 (EDT) Message-ID: <371B1CB9.9CE688E7@checkpoint.com> Date: Mon, 19 Apr 1999 15:08:25 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: DoS on QM and how to solve it. References: <027d01be883f$addcd2c0$634cf526@east.isi.edu> Content-Type: multipart/mixed; boundary="------------7F908349469A984BB40E1898" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------7F908349469A984BB40E1898 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a possible DoS attack on IKE: Alice and Bob do a Quick Mode exchange using PFS. Mallory records the first QM packets and replays them after a while. Result: The receiver needs to do unnecessary DH computations. Solution: Alice and Bob should keep a hash table whose keys are the peer, the IKE SA SPI (Cookie I and CookieR) and the QM MsgId. Before processing a first QM packet they should consult the hash table to check that they didn't already have a QM exchange with the same MsgId and Cookies. The hash table can be cleared from these entries after the IKE SA is expired. Note that even though this solution consumes memory (the storage needed for hash table entries), the amount of memory needed depends only on the number of QM exchanges negotiated under the IKE SA which is not controlled by Mallory. --------------7F908349469A984BB40E1898 Content-Type: text/x-vcard; charset=us-ascii; name="zegman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tamir Zegman Content-Disposition: attachment; filename="zegman.vcf" begin:vcard n:Zegman;Tamir tel;fax:+972-3-5759256 tel;work:+972-3-7534606 x-mozilla-html:TRUE url:www.checkpoint.com org:Check Point Software Technologies Ltd.;Encryption group adr:;;3A Jabotinsky St., Diamond Tower;Ramat-Gan;;52520;ISRAEL version:2.1 email;internet:zegman@checkpoint.com title:Software engineer fn:Tamir Zegman end:vcard --------------7F908349469A984BB40E1898-- From owner-ipsec@lists.tislabs.com Wed Apr 21 01:35:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA23729; Wed, 21 Apr 1999 01:35:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA10187 Wed, 21 Apr 1999 01:48:00 -0400 (EDT) Date: Wed, 21 Apr 1999 01:54:47 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: ipsec@lists.tislabs.com cc: "FreeS/WAN Team -- D. Hugh Redelmeier" , Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: representation of IKE DH shared secret Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2409 (IKE) uses g^xy, the DH shared secret, in several places. This is a pure number, but it needs to be an octet sequence to be used. I don't see any place that specifies how to convert from the number to the numeral. Note that although the numeral never appears on the wire, it is used in ways that require both parties to use the same numeral (eg. generating keying info). It is easy to infer that the numeral would be big endian -- that's the way we do things. But what length should the numeral have? Pluto (the FreeS/WAN IKE daemon) has always used as many octets as were needed. I suspect that a better choice would be to use the number of octets needed to represent the number of bits in the group description. These two numbers are probably different roughly one time in 256 (i.e. there would be a leading 0 octet in the second representation this often). For a similar case, that of the KE payload, RFC 2409 does specify the more about the representation in section 5: The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros. [This doesn't actually say "padded up to be an integral number of octets", but I assume that this is meant. Should it be stated?] [This seems to contradict 3.2: KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g. a TLV) used for the data of a KE payload. I think we do have a particular encoding.] => I think that RFC 2409 should have specified the representation to be used for the DH shared secret. If it is agreed that this is a problem, what is the appropriate way to deal with it? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Wed Apr 21 14:40:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13054; Wed, 21 Apr 1999 14:40:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12147 Wed, 21 Apr 1999 12:29:53 -0400 (EDT) Message-Id: <3.0.32.19990421115207.00a87c80@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 Apr 1999 11:52:25 -0400 To: hugh@mimosa.com From: Shawn Mamros Subject: Re: representation of IKE DH shared secret Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >=> I think that RFC 2409 should have specified the representation to > be used for the DH shared secret. > >If it is agreed that this is a problem, what is the appropriate way to >deal with it? RFC 2409 will have to be revised at least once as it goes from Proposed to Draft Standard. That would be a good time to put clarifying text in there. If the long-talked-about clarifications document gets written, that would be a good place for it too. For the record, all the interoperable implementations I've seen use the same representation, which is the same as that mentioned for the KE payload contents in RFC 2409, section 5 - just the number itself, big-endian representation, pre-pended with zeroes to be the same number of bits as the group description, rounded up to the nearest integral number of octets. I think that's been the assumption all along, but assumptions aren't always codified in text as well as they can be. But that's what the whole Proposed Standard->Draft Standard->Standard process is all about, right? -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Wed Apr 21 16:58:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15365; Wed, 21 Apr 1999 16:58:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13014 Wed, 21 Apr 1999 16:55:11 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 21 Apr 1999 15:02:25 -0600 From: "Hilarie Orman" To: Subject: Re: representation of IKE DH shared secret Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA13011 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the spirit of "less is more", I wonder what interest is served by specifying the representation of internal values? You can represent g^xy as a decimal string if it is convenient for your hardware. If it gives all implementors an important reference point for clarification of their implementations, I can understand wanting to have a specification of the internal format, but in this case I'd worry that some implementors, perfectly well understanding the arithmetic, might become confused by a requirement to use a particular internal format. Hilarie From owner-ipsec@lists.tislabs.com Wed Apr 21 17:40:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16601; Wed, 21 Apr 1999 17:40:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13211 Wed, 21 Apr 1999 18:38:15 -0400 (EDT) Message-Id: <199904212246.WAA02202@orchard.arlington.ma.us> To: "Hilarie Orman" cc: ipsec@lists.tislabs.com Subject: Re: representation of IKE DH shared secret In-Reply-To: Message from "Hilarie Orman" of "Wed, 21 Apr 1999 15:02:25 MDT." Date: Wed, 21 Apr 1999 18:46:08 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In the spirit of "less is more", I wonder what interest is served > by specifying the representation of internal values? You can > represent g^xy as a decimal string if it is convenient for your > hardware. The shared secret g^xy is used in several places as input to a pseudo-random function. The prf's I'm familiar with (HMAC-SHA1, HMAC-MD5) want a byte string as input. For interoperability you need to agree on the exact sequence of bytes fed into the prf; it's not a matter of what internal representation is in use.. - Bill From owner-ipsec@lists.tislabs.com Wed Apr 21 20:52:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29495; Wed, 21 Apr 1999 20:52:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13575 Wed, 21 Apr 1999 21:46:19 -0400 (EDT) Message-Id: <199904220153.SAA13986@potassium.network-alchemy.com> To: hugh@mimosa.com cc: ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-reply-to: Your message of "Wed, 21 Apr 1999 01:54:47 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13983.924746017.1@network-alchemy.com> Date: Wed, 21 Apr 1999 18:53:37 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Apr 1999 01:54:47 EDT you wrote > > For a similar case, that of the KE payload, RFC 2409 does specify the > more about the representation in section 5: > > The Diffie-Hellman public value passed in a KE payload, in either a > phase 1 or phase 2 exchange, MUST be the length of the negotiated > Diffie-Hellman group enforced, if necessary, by pre-pending the value > with zeros. > > [This doesn't actually say "padded up to be an integral number of > octets", but I assume that this is meant. Should it be stated?] > > [This seems to contradict 3.2: > KE is the key exchange payload which contains the public > information exchanged in a Diffie-Hellman exchange. There is no > particular encoding (e.g. a TLV) used for the data of a KE payload. > I think we do have a particular encoding.] I'm obviously not enough of a pedant so let me try to be one. Webster says: "encode: to convert (as a body of information) from one system of communication into another." So if the KE payload was, say, MIME then we would have an encoding. The information is not converted into another system. It's not an encoding. It's no contradiction. > => I think that RFC 2409 should have specified the representation to > be used for the DH shared secret. > > If it is agreed that this is a problem, what is the appropriate way to > deal with it? Is this a problem? We seem to have gotten a score (or so) interoperable implementations as its written but maybe that's just because a D-H secret hasn't been produced yet that began with 8 bits of zero. But somehow I doubt it. The way to proceed is to write up some suggested text and send it to the list. If no one complains I'll add it to the next rev which will be out Real Soon Now. Dan. From owner-ipsec@lists.tislabs.com Thu Apr 22 11:09:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29336; Thu, 22 Apr 1999 11:09:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15155 Thu, 22 Apr 1999 08:40:56 -0400 (EDT) Message-Id: <3.0.32.19990421173618.00a59790@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 Apr 1999 17:36:18 -0400 To: "Hilarie Orman" From: Shawn Mamros Subject: Re: representation of IKE DH shared secret Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In the spirit of "less is more", I wonder what interest is served >by specifying the representation of internal values? You can >represent g^xy as a decimal string if it is convenient for your >hardware. Under "normal" circumstances, you're right, it wouldn't matter how g^xy is represented internally. The problem is that g^xy is used as input to the HMAC function that generates the key material. If both sides don't use the same set of octets in the same order as input to the hash function, they won't generate the same keys. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Thu Apr 22 15:35:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03088; Thu, 22 Apr 1999 15:35:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16229 Thu, 22 Apr 1999 13:24:15 -0400 (EDT) Date: Thu, 22 Apr 1999 20:32:05 +0300 (EET DST) Message-Id: <199904221732.UAA18528@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Dan Harkins Cc: hugh@mimosa.com, ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-Reply-To: <199904220153.SAA13986@potassium.network-alchemy.com> References: <199904220153.SAA13986@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > Is this a problem? We seem to have gotten a score (or so) interoperable > implementations as its written but maybe that's just because a D-H > secret hasn't been produced yet that began with 8 bits of zero. But > somehow I doubt it. It is mainly because of the interop meetings. I remember seeing different non-interoperable version because of this in one interop meeting. After we didn't interoperate the other ends code was changed to do what everybody else is doing, and then we had interoperable versions. There is some of this kind of things that you can only learn by coming to the interop meeting and checking out how others are doing things. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Apr 22 17:26:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04605; Thu, 22 Apr 1999 17:26:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16700 Thu, 22 Apr 1999 15:49:59 -0400 (EDT) Message-Id: <3.0.32.19990422130154.009d7910@cymail.cylink.com> X-Sender: jburke@cymail.cylink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 Apr 1999 13:01:55 -0700 To: ipsec@lists.tislabs.com From: jburke@cylink.com (John Burke) Subject: Re: representation of IKE DH shared secret Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:53 PM 4/21/99 -0700, somebody wrote: >On Wed, 21 Apr 1999 01:54:47 EDT you wrote >> >> For a similar case, that of the KE payload, RFC 2409 does specify the >> more about the representation in section 5: >> >> The Diffie-Hellman public value passed in a KE payload, in either a >> phase 1 or phase 2 exchange, MUST be the length of the negotiated >> Diffie-Hellman group enforced, if necessary, by pre-pending the value >> with zeros. [ ... ] >I'm obviously not enough of a pedant so let me try to be one. Webster says: >"encode: to convert (as a body of information) from one system of >communication into another." So if the KE payload was, say, MIME then we >would have an encoding. The information is not converted into another >system. It's not an encoding. It's no contradiction. > [ ... ] >Is this a problem? We seem to have gotten a score (or so) interoperable >implementations as its written but maybe that's just because a D-H >secret hasn't been produced yet that began with 8 bits of zero. But >somehow I doubt it. I would suggest the attitude showing through in the above does not contribute to the clearest specs. As another responder (Tero Kivinen ) pointed out, some implementors had to go to an interoperation workshop to discover such things. The fact that x percent of twenty people guess right - when not entirely isolated - doesn't make the spec clear. On the other hand there is this in the conclusion: >The way to proceed is to write up some suggested text and send it to >the list. If no one complains I'll add it to the next rev which will be [ ... ] - John Burke Cylink, Sunnyvale, CA From owner-ipsec@lists.tislabs.com Thu Apr 22 18:20:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05172; Thu, 22 Apr 1999 18:20:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16994 Thu, 22 Apr 1999 18:12:47 -0400 (EDT) Date: Thu, 22 Apr 1999 15:20:22 -0700 (PDT) From: Sunil Vallamkonda X-Sender: sunil@seltzer.mtv.siara.com To: ipsec@lists.tislabs.com Subject: info request... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I am looking for Glossary for IKE/IPSec. (want to know what ARL, HMAC RIPEMD-160, etc,) Any ideas/pointers where I can find ? Thx. Sunil. From owner-ipsec@lists.tislabs.com Thu Apr 22 18:33:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05208; Thu, 22 Apr 1999 18:33:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17098 Thu, 22 Apr 1999 18:32:45 -0400 (EDT) Message-Id: <199904222240.WAA17502@orchard.arlington.ma.us> To: Dan Harkins cc: hugh@mimosa.com, ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-Reply-To: Message from Dan Harkins of "Wed, 21 Apr 1999 18:53:37 PDT." <199904220153.SAA13986@potassium.network-alchemy.com> Date: Thu, 22 Apr 1999 18:40:40 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (oops, last one got away from me too soon). > > [This doesn't actually say "padded up to be an integral number of > > octets", but I assume that this is meant. Should it be stated?] Yes. MD5, (and, by extension, HMAC-MD5) counts bits rather than bytes (though, perhaps fortunately, the published C API to MD5 doesn't let you feed a non-integral number of octets through it), so it's *conceivable* that someone could interpret the spec to indicate an unpadded shared secret. - Bill From owner-ipsec@lists.tislabs.com Thu Apr 22 18:36:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05237; Thu, 22 Apr 1999 18:36:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17060 Thu, 22 Apr 1999 18:28:57 -0400 (EDT) Message-Id: <199904222236.WAA17485@orchard.arlington.ma.us> To: Dan Harkins cc: hugh@mimosa.com, ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-Reply-To: Message from Dan Harkins of "Wed, 21 Apr 1999 18:53:37 PDT." <199904220153.SAA13986@potassium.network-alchemy.com> Date: Thu, 22 Apr 1999 18:36:39 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From owner-ipsec@lists.tislabs.com Thu Apr 22 18:47:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05290; Thu, 22 Apr 1999 18:47:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17146 Thu, 22 Apr 1999 18:41:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 22 Apr 1999 16:48:48 -0600 From: "Tolga Acar" To: , Subject: Re: representation of IKE DH shared secret Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA17143 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is my concerns and two pennies worth of a write up: Security Concerns: After the Diffie-Hellman key exchange phases are complete, the shared secret is an integer in the DH group as pointer out earlier, and that number may or may not be padded with zero, depending on the most significant bit of the exchanged "integer" and the group (namely, the prime p). This puts a restriction on the most significant octet of the exchanged shared integer, since the exchanged integer must be less than the prime. Note that the zero padding comes as an addition to this. 1. The shared integer is in big endian representation. This is DH as identified in PKCS#3. 2. the restriction on the first octet regardless of the zero padding may reveal some of the bits of the shared integer (some of the bits are zero). And yes, this should be a concern when an attack that reduces the exhaustive search space of a DES key from 2^56 to 2^47 is of a concern. 3. Zero padding problem only makes things worse. It adds an entirely known 8 bits in front of the shared integer. 4. For other key exchange (agreement) algorithms (such as MQV or EC version of DH), restrictions may be different. Those should be addressed after such additional algorithms are added. Suggestion: (the write up) Discard octets upto and including the first non-zero octet, and use the remaining octets in the shared integer as the shared secret. regards, - Tolga >>> John Burke 4/22/99 14:01:55 >>> At 06:53 PM 4/21/99 -0700, somebody wrote: >On Wed, 21 Apr 1999 01:54:47 EDT you wrote >> >> For a similar case, that of the KE payload, RFC 2409 does specify the >> more about the representation in section 5: >> >> The Diffie-Hellman public value passed in a KE payload, in either a >> phase 1 or phase 2 exchange, MUST be the length of the negotiated >> Diffie-Hellman group enforced, if necessary, by pre-pending the value >> with zeros. [ ... ] >I'm obviously not enough of a pedant so let me try to be one. Webster says: >"encode: to convert (as a body of information) from one system of >communication into another." So if the KE payload was, say, MIME then we >would have an encoding. The information is not converted into another >system. It's not an encoding. It's no contradiction. > [ ... ] >Is this a problem? We seem to have gotten a score (or so) interoperable >implementations as its written but maybe that's just because a D-H >secret hasn't been produced yet that began with 8 bits of zero. But >somehow I doubt it. I would suggest the attitude showing through in the above does not contribute to the clearest specs. As another responder (Tero Kivinen ) pointed out, some implementors had to go to an interoperation workshop to discover such things. The fact that x percent of twenty people guess right - when not entirely isolated - doesn't make the spec clear. On the other hand there is this in the conclusion: >The way to proceed is to write up some suggested text and send it to >the list. If no one complains I'll add it to the next rev which will be [ ... ] - John Burke Cylink, Sunnyvale, CA From owner-ipsec@lists.tislabs.com Thu Apr 22 20:08:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA16381; Thu, 22 Apr 1999 20:08:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17392 Thu, 22 Apr 1999 20:49:20 -0400 (EDT) Message-Id: <3.0.32.19990422180116.009dd8e0@cymail.cylink.com> X-Sender: jburke@cymail.cylink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 Apr 1999 18:01:17 -0700 To: ipsec@lists.tislabs.com From: jburke@cylink.com (John Burke) Subject: Re: Re: representation of IKE DH shared secret Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just for the interest of all contributors: At 03:34 PM 4/22/99 -0700, you wrote: >On Thu, 22 Apr 1999 13:01:55 PDT you wrote >> At 06:53 PM 4/21/99 -0700, somebody wrote: >> >On Wed, 21 Apr 1999 01:54:47 EDT you wrote >> >> >> >> For a similar case, that of the KE payload, RFC 2409 does specify the >> >> more about the representation in section 5: >> >> >> >> The Diffie-Hellman public value passed in a KE payload, in either a >> >> phase 1 or phase 2 exchange, MUST be the length of the negotiated >> >> Diffie-Hellman group enforced, if necessary, by pre-pending the value >> >> with zeros. >> [ ... ] >> >I'm obviously not enough of a pedant so let me try to be one. Webster says: >> >"encode: to convert (as a body of information) from one system of >> >communication into another." So if the KE payload was, say, MIME then we >> >would have an encoding. The information is not converted into another >> >system. It's not an encoding. It's no contradiction. >> > >> [ ... ] >> >Is this a problem? We seem to have gotten a score (or so) interoperable >> >implementations as its written but maybe that's just because a D-H >> >secret hasn't been produced yet that began with 8 bits of zero. But >> >somehow I doubt it. >> >> I would suggest the attitude showing through in the above does not >> contribute to the clearest specs. As another responder (Tero Kivinen >> ) pointed out, some implementors had to go to an >> interoperation workshop to discover such things. The fact that x percent >> of twenty people guess right - when not entirely isolated - doesn't make >> the spec clear. > >Nice suggestion John. But it's true. I'm not anal-retentive enough to >write "clear". I seriously wonder how some people tie their shoes in the >morning and walk across a street. > >> On the other hand there is this in the conclusion: > >> >The way to proceed is to write up some suggested text and send it to >> >the list. If no one complains I'll add it to the next rev which will be >> [ ... ] > >What a completely content-free post. A "suggestion", which is no such thing >at all, followed by an observation of something that was obvious to all. >Way to contribute! > > Dan, > > From owner-ipsec@lists.tislabs.com Thu Apr 22 20:45:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA19055; Thu, 22 Apr 1999 20:45:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17529 Thu, 22 Apr 1999 21:42:56 -0400 (EDT) Date: Thu, 22 Apr 1999 21:49:47 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Tolga Acar cc: jburke@cylink.com, ipsec@lists.tislabs.com Subject: Re: representation of IKE DH shared secret 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: Tolga Acar | Here is my concerns and two pennies worth of a write up: This isn't a problem because the g^xy is used as input to a function that mixes up the entropy. It is pushed through a prf, sometimes more than once. Look at the SKEYID_* stuff in RFC2409 (IKE) section 5 and KEYMAT in section 5.5. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 | Security Concerns: | After the Diffie-Hellman key exchange phases are complete, the shared secret is an integer in the DH group as pointer out earlier, and that number may or may not be padded with zero, depending on the most significant bit of the exchanged "integer" and the group (namely, the prime p). This puts a restriction on the most significant octet of the exchanged shared integer, since the exchanged integer must be less than the prime. Note that the zero padding comes as an addition to this. | | 1. The shared integer is in big endian representation. This is DH as identified in PKCS#3. | | 2. the restriction on the first octet regardless of the zero padding may reveal some of the bits of the shared integer (some of the bits are zero). And yes, this should be a concern when an attack that reduces the exhaustive search space of a DES key from 2^56 to 2^47 is of a concern. | | 3. Zero padding problem only makes things worse. It adds an entirely known 8 bits in front of the shared integer. | | 4. For other key exchange (agreement) algorithms (such as MQV or EC version of DH), restrictions may be different. Those should be addressed after such additional algorithms are added. | | Suggestion: (the write up) | Discard octets upto and including the first non-zero octet, and use the remaining octets in the shared integer as the shared secret. From owner-ipsec@lists.tislabs.com Thu Apr 22 20:50:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA19695; Thu, 22 Apr 1999 20:50:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17575 Thu, 22 Apr 1999 21:57:54 -0400 (EDT) Date: Fri, 23 Apr 1999 05:05:50 +0300 (EET DST) Message-Id: <199904230205.FAA03038@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Tolga Acar" Cc: , Subject: Re: representation of IKE DH shared secret In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tolga Acar writes: > 2. the restriction on the first octet regardless of the zero padding > may reveal some of the bits of the shared integer (some of the bits > are zero). And yes, this should be a concern when an attack that > reduces the exhaustive search space of a DES key from 2^56 to 2^47 > is of a concern. > 3. Zero padding problem only makes things worse. It adds an entirely > known 8 bits in front of the shared integer. > Suggestion: (the write up) > Discard octets upto and including the first non-zero octet, and use > the remaining octets in the shared integer as the shared secret. The Diffie-Hellman secret is never directly used to derive any keys. It is used as an input of the prf (usually HMAC-MD5/HMAC-SHA1) whose output is then used to derived the actual keys used in the ISAKMP SA or IPSEC SA encryption. So there is no security problems using the zero padded version of the shared secret in the IKE. I would suggest something like this: g^xy is the Diffie-Hellman shared secret. When this value is included in the SKEYID calculation as a input for prf it MUST be prepended with zero bits up to 8-bit boundary, so that it has same length in octects than group prime number p. When this value is used in the hash calculation it MUST be in network byte order. This is how all the interoperable implementations interpret the current document. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Apr 23 02:51:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA06021; Fri, 23 Apr 1999 02:51:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18163 Fri, 23 Apr 1999 03:30:16 -0400 (EDT) Message-ID: <3720235C.5123D754@lmf.ericsson.se> Date: Fri, 23 Apr 1999 10:38:04 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab, 02420 Jorvas, Finland X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Sunil Vallamkonda CC: ipsec@lists.tislabs.com Subject: Re: info request... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I am looking for Glossary for IKE/IPSec. >(want to know what ARL, HMAC RIPEMD-160, etc,) Try the following: http://www.xs4all.nl/~freeswan/freeswan_trees/freeswan-1.00/doc/glossary.html http://www.rsa.com/rsalabs/faq/html/glossary.html http://www5.zdnet.com/pcmag/pctech/content/special/glossaries/internetsecurity.html http://www.io.com/~ritter/GLOSSARY.HTM Courtesy of FreeSWAN... Other useful links: http://www.vpnc.org/rfcs.html Jari From owner-ipsec@lists.tislabs.com Fri Apr 23 10:55:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13555; Fri, 23 Apr 1999 10:55:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18903 Fri, 23 Apr 1999 08:56:34 -0400 (EDT) Message-Id: <199904231302.JAA01898@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 23 Apr 1999 09:02:12 -0400 To: Tero Kivinen , Dan Harkins From: Dave Clark Subject: Re: representation of IKE DH shared secret Cc: hugh@mimosa.com, ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris In-Reply-To: <199904221732.UAA18528@torni.ssh.fi> References: <199904220153.SAA13986@potassium.network-alchemy.com> <199904220153.SAA13986@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those of us who are unable to attend the meetings, are these types of resolutions announced in some fashion? Posted to this mailing list, or somewhere on the Web, etc.? Thanks in advance. At 08:32 PM 04/22/1999 +0300, Tero Kivinen wrote: >Dan Harkins writes: >> Is this a problem? We seem to have gotten a score (or so) interoperable >> implementations as its written but maybe that's just because a D-H >> secret hasn't been produced yet that began with 8 bits of zero. But >> somehow I doubt it. > >It is mainly because of the interop meetings. I remember seeing >different non-interoperable version because of this in one interop >meeting. After we didn't interoperate the other ends code was changed >to do what everybody else is doing, and then we had interoperable >versions. > >There is some of this kind of things that you can only learn by coming >to the interop meeting and checking out how others are doing things. >-- >kivinen@iki.fi Work : +358-9-4354 3218 >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Fri Apr 23 14:33:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15847; Fri, 23 Apr 1999 14:33:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19775 Fri, 23 Apr 1999 12:43:46 -0400 (EDT) Date: Fri, 23 Apr 1999 12:50:46 -0400 From: canetti Message-Id: <9904231650.AA23864@ornavella.watson.ibm.com> To: ipsec@lists.tislabs.com Subject: Fwd: I-D ACTION:draft-irtf-smug-taxonmy-00.txt Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: IETF-Announce: ; Subject: I-D ACTION:draft-irtf-smug-taxonomy-00.txt From: Internet-Drafts@search.ietf.org Date: Tue, 06 Apr 1999 07:08:12 -0400 Reply-to: Internet-Drafts@search.ietf.org Sender: scoya@ns.cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A taxonomy of multicast security issues Author(s) : R. Canetti, B. Pinkas Filename : draft-irtf-smug-taxonomy-00.txt Pages : 18 Date : 05-Apr-99 With the growth and commercialization of the Internet, the need for secure IP multicast is growing. In this draft we present a taxonomy of multicast security issues. We first sketch some multicast group parameters that are relevant to security, and outline the basic security issues concerning multicast in general, with emphasis on IP multicast. Next we suggest two 'benchmark' scenarios for secure multicast solutions. Lastly we review some previous works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-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-taxonomy-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-taxonomy-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. From owner-ipsec@lists.tislabs.com Fri Apr 23 14:37:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15880; Fri, 23 Apr 1999 14:37:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19794 Fri, 23 Apr 1999 12:51:27 -0400 (EDT) Message-Id: <199904231658.JAA18225@potassium.network-alchemy.com> To: Dave Clark cc: Tero Kivinen , hugh@mimosa.com, ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-reply-to: Your message of "Fri, 23 Apr 1999 09:02:12 EDT." <199904231302.JAA01898@anuxc.mv.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18222.924886688.1@network-alchemy.com> Date: Fri, 23 Apr 1999 09:58:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, they get back into the document. The whole thing about padding the KE payload was because of an incident at a bakeoff where someone's D-H public value began with 8 (or more) zeros and was consequently deemed "too short" by others. The fact that this verbage didn't make it into the representation of the D-H secret was an oversight on my part that we're cleaning up now. I figured it was straightforward but it's not. Dan. On Fri, 23 Apr 1999 09:02:12 EDT you wrote > For those of us who are unable to attend the meetings, are these types > of resolutions announced in some fashion? Posted to this mailing list, > or somewhere on the Web, etc.? Thanks in advance. > > At 08:32 PM 04/22/1999 +0300, Tero Kivinen wrote: > >Dan Harkins writes: > >> Is this a problem? We seem to have gotten a score (or so) interoperable > >> implementations as its written but maybe that's just because a D-H > >> secret hasn't been produced yet that began with 8 bits of zero. But > >> somehow I doubt it. > > > >It is mainly because of the interop meetings. I remember seeing > >different non-interoperable version because of this in one interop > >meeting. After we didn't interoperate the other ends code was changed > >to do what everybody else is doing, and then we had interoperable > >versions. > > > >There is some of this kind of things that you can only learn by coming > >to the interop meeting and checking out how others are doing things. > >-- > >kivinen@iki.fi Work : +358-9-4354 3218 > >SSH Communications Security http://www.ssh.fi/ > >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > From owner-ipsec@lists.tislabs.com Fri Apr 23 14:40:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15905; Fri, 23 Apr 1999 14:40:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19808 Fri, 23 Apr 1999 12:55:20 -0400 (EDT) Message-Id: <199904231700.KAA18247@potassium.network-alchemy.com> To: Tero Kivinen cc: "Tolga Acar" , jburke@cylink.com, ipsec@lists.tislabs.com Subject: Re: representation of IKE DH shared secret In-reply-to: Your message of "Fri, 23 Apr 1999 05:05:50 +0300." <199904230205.FAA03038@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18244.924886858.1@network-alchemy.com> Date: Fri, 23 Apr 1999 10:00:58 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Apr 1999 05:05:50 +0300 you wrote > > I would suggest something like this: > > g^xy is the Diffie-Hellman shared secret. When this value is > included in the SKEYID calculation as a input for prf it MUST > be prepended with zero bits up to 8-bit boundary, so that it has > same length in octects than group prime number p. When this value > is used in the hash calculation it MUST be in network byte order. > > This is how all the interoperable implementations interpret the > current document. Sounds good. I will incorporate this and similar verbage on EC into the document. Thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Apr 23 15:09:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16144; Fri, 23 Apr 1999 15:09:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19905 Fri, 23 Apr 1999 13:24:53 -0400 (EDT) Message-Id: <199904231732.KAA18298@potassium.network-alchemy.com> To: jburke@cylink.com (John Burke) cc: ipsec@lists.tislabs.com Subject: Re: representation of IKE DH shared secret In-reply-to: Your message of "Thu, 22 Apr 1999 18:01:17 PDT." <3.0.32.19990422180116.009dd8e0@cymail.cylink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18295.924888738.1@network-alchemy.com> Date: Fri, 23 Apr 1999 10:32:19 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This email was intentionally not sent to the list and I'm not too happy it was posted without my permission. sigh, Dan. On Thu, 22 Apr 1999 18:01:17 PDT John Burke unethically copied: > Just for the interest of all contributors: > > > At 03:34 PM 4/22/99 -0700, you wrote: > >On Thu, 22 Apr 1999 13:01:55 PDT you wrote > >> At 06:53 PM 4/21/99 -0700, somebody wrote: > >> >On Wed, 21 Apr 1999 01:54:47 EDT you wrote > >> >> > >> >> For a similar case, that of the KE payload, RFC 2409 does specify the > >> >> more about the representation in section 5: > >> >> > >> >> The Diffie-Hellman public value passed in a KE payload, in either a > >> >> phase 1 or phase 2 exchange, MUST be the length of the negotiated > >> >> Diffie-Hellman group enforced, if necessary, by pre-pending the valu >e > >> >> with zeros. > >> [ ... ] > >> >I'm obviously not enough of a pedant so let me try to be one. Webster > says: > >> >"encode: to convert (as a body of information) from one system of > >> >communication into another." So if the KE payload was, say, MIME then we > >> >would have an encoding. The information is not converted into another > >> >system. It's not an encoding. It's no contradiction. > >> > > >> [ ... ] > >> >Is this a problem? We seem to have gotten a score (or so) interoperable > >> >implementations as its written but maybe that's just because a D-H > >> >secret hasn't been produced yet that began with 8 bits of zero. But > >> >somehow I doubt it. > >> > >> I would suggest the attitude showing through in the above does not > >> contribute to the clearest specs. As another responder (Tero Kivinen > >> ) pointed out, some implementors had to go to an > >> interoperation workshop to discover such things. The fact that x percent > >> of twenty people guess right - when not entirely isolated - doesn't make > >> the spec clear. > > > >Nice suggestion John. But it's true. I'm not anal-retentive enough to > >write "clear". I seriously wonder how some people tie their shoes in the > >morning and walk across a street. > > > >> On the other hand there is this in the conclusion: > > > >> >The way to proceed is to write up some suggested text and send it to > >> >the list. If no one complains I'll add it to the next rev which will be > >> [ ... ] > > > >What a completely content-free post. A "suggestion", which is no such thing > >at all, followed by an observation of something that was obvious to all. > >Way to contribute! > > > > Dan, > > > > > From owner-ipsec@lists.tislabs.com Fri Apr 23 15:09:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16152; Fri, 23 Apr 1999 15:09:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19937 Fri, 23 Apr 1999 13:48:01 -0400 (EDT) Message-Id: <3.0.32.19990423110003.009d8910@cymail.cylink.com> X-Sender: jburke@cymail.cylink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 23 Apr 1999 11:00:04 -0700 To: ipsec@lists.tislabs.com From: jburke@cylink.com (John Burke) Subject: Re: Re: representation of IKE DH shared secret Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I want to apologize to Dan and to the list for publishing private communication and on a list where such things don't belong. - John Burke At 10:32 AM 4/23/99 -0700, you wrote: > This email was intentionally not sent to the list and I'm not too >happy it was posted without my permission. > > sigh, > > Dan. > >On Thu, 22 Apr 1999 18:01:17 PDT John Burke unethically copied: >> Just for the interest of all contributors: [ deleted ] From owner-ipsec@lists.tislabs.com Fri Apr 23 15:37:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16381; Fri, 23 Apr 1999 15:37:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19988 Fri, 23 Apr 1999 14:15:03 -0400 (EDT) Date: Fri, 23 Apr 1999 14:16:03 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Dan Harkins cc: Dave Clark , Tero Kivinen , ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-Reply-To: <199904231658.JAA18225@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 | Actually, they get back into the document. The whole thing about | padding the KE payload was because of an incident at a bakeoff where | someone's D-H public value began with 8 (or more) zeros and | was consequently deemed "too short" by others. | | The fact that this verbage didn't make it into the representation of | the D-H secret was an oversight on my part that we're cleaning up now. | I figured it was straightforward but it's not. I'm glad to hear this. I was going to take a stab at crafting wording changes (as you had invited). Do I take it that this is being taken care of? Is there an "issues list" that would give us advance warning about what other problems might be known or being addressed? I have to admit that I've not kept up with the mailing list. I have another spot that I'd like nailed down in RFC 2409 (IKE). It is very much related. From Appendix B: In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the ciphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. This talks about using the public DH value. I'd like it to specify that the representation used is identical to that in the KE payload. I've just found code that does not do this (leading zero bytes were discarded). I didn't write it, but I can fix it. Unfortunately, it is deployed -- knowing this two weeks earlier would have made a big difference. Note that this code has lived through more that one Bakeoff without discovery. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Fri Apr 23 15:56:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16555; Fri, 23 Apr 1999 15:56:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20047 Fri, 23 Apr 1999 14:22:51 -0400 (EDT) Message-Id: <199904231829.LAA18855@potassium.network-alchemy.com> To: hugh@mimosa.com cc: Dave Clark , Tero Kivinen , ipsec@lists.tislabs.com, Henry Spencer , Hugh Daniel , John Gilmore , Richard Guy Briggs , Sandy Harris Subject: Re: representation of IKE DH shared secret In-reply-to: Your message of "Fri, 23 Apr 1999 14:16:03 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18852.924892179.1@network-alchemy.com> Date: Fri, 23 Apr 1999 11:29:39 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Apr 1999 14:16:03 EDT you wrote > | From: Dan Harkins > > | Actually, they get back into the document. The whole thing about > | padding the KE payload was because of an incident at a bakeoff where > | someone's D-H public value began with 8 (or more) zeros and > | was consequently deemed "too short" by others. > | > | The fact that this verbage didn't make it into the representation of > | the D-H secret was an oversight on my part that we're cleaning up now. > | I figured it was straightforward but it's not. > > I'm glad to hear this. > > I was going to take a stab at crafting wording changes (as you had > invited). Do I take it that this is being taken care of? I was going to use Kivinen's text. Is that acceptable? > Is there an "issues list" that would give us advance warning about > what other problems might be known or being addressed? I have to > admit that I've not kept up with the mailing list. There's http://www.lounge.org/ike_doi_errata.html. > I have another spot that I'd like nailed down in RFC 2409 (IKE). It > is very much related. From Appendix B: > > In phase 1, material for the initialization vector (IV material) for > CBC mode encryption algorithms is derived from a hash of a > concatenation of the initiator's public Diffie-Hellman value and the > responder's public Diffie-Hellman value using the negotiated hash > algorithm. This is used for the first message only. Each message > should be padded up to the nearest block size using bytes containing > 0x00. The message length in the header MUST include the length of the > pad since this reflects the size of the ciphertext. Subsequent > messages MUST use the last CBC encryption block from the previous > message as their initialization vector. > > This talks about using the public DH value. I'd like it to specify > that the representation used is identical to that in the KE payload. OK. > I've just found code that does not do this (leading zero bytes were > discarded). I didn't write it, but I can fix it. Unfortunately, it > is deployed -- knowing this two weeks earlier would have made a big > difference. Note that this code has lived through more that one > Bakeoff without discovery. Which is probably because your D-H public values at the bakeoff never began with 8 or more zeros. With a good random number as x in g^x mod p I'd imagine these things would be quite rare. Dan. From owner-ipsec@lists.tislabs.com Sat Apr 24 15:36:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27699; Sat, 24 Apr 1999 15:36:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21920 Sat, 24 Apr 1999 13:53:18 -0400 (EDT) Date: Sat, 24 Apr 1999 13:59:25 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Dan Harkins cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: wording for representation of IKE DH shared secret In-Reply-To: <199904230205.FAA03038@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Here is a possible wording change for RFC2409. I'm not saying this is better than Tero's, but I think that combining some of the ideas might be useful. The Diffie-Hellman public values g^x and g^y, and the DH shared secret values g^xy MUST be represented as a octet stream either to be transmitted in a KE payload or to be input to a PRF or hashing function. [There are several cases in which these values are fed to a PRF or hash. To make the text more robust, I think it would good to avoid enumerating the cases here. The examples I've noticed are SKEYID, HASH, and IV.] For values from a MODP group, the representation used is base 256, in network order. The number of octets used MUST be the minimum needed to represent corresponding the group modulus (which may be more than is required for the actual value being represented). [I would guess that saying "base 256" is not the accepted way of describing this, but I don't know where the standard network representation for binary numbers is described or how to refer to it.] For values from a Galois Field, ... [I don't know how to say the right thing] This could replace the existing paragraph in 5: The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros. | From: Tero Kivinen | I would suggest something like this: | | g^xy is the Diffie-Hellman shared secret. When this value is | included in the SKEYID calculation as a input for prf it MUST | be prepended with zero bits up to 8-bit boundary, so that it has | same length in octects than group prime number p. When this value | is used in the hash calculation it MUST be in network byte order. | | This is how all the interoperable implementations interpret the | current document. I don't think that this catches all the cases where this representation must be used. I hope that this helps, Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Sun Apr 25 18:39:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04977; Sun, 25 Apr 1999 18:39:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24118 Sun, 25 Apr 1999 18:38:35 -0400 (EDT) Message-Id: <4.1.19990425153805.009ab550@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 25 Apr 1999 15:40:33 -0700 To: Dave Clark From: Rodney Thayer Subject: Re: representation of IKE DH shared secret Cc: ipsec@lists.tislabs.com In-Reply-To: <199904231302.JAA01898@anuxc.mv.lucent.com> References: <199904221732.UAA18528@torni.ssh.fi> <199904220153.SAA13986@potassium.network-alchemy.com> <199904220153.SAA13986@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Efforts are made, by several parties, to document what was found at the meetings on the list, in the style of an "ietf working group meeting outside of normal ietf meetings". This intent has probably been imperfectly implemented. So when you come to the next workshop, maybe we'll all ask you to be scribe this time ;-) Seriously, though, we've tried to do this. At 09:02 AM 4/23/99 -0400, Dave Clark wrote: >For those of us who are unable to attend the meetings, are these types >of resolutions announced in some fashion? Posted to this mailing list, >or somewhere on the Web, etc.? Thanks in advance. > >At 08:32 PM 04/22/1999 +0300, Tero Kivinen wrote: >>Dan Harkins writes: >>> Is this a problem? We seem to have gotten a score (or so) interoperable >>> implementations as its written but maybe that's just because a D-H >>> secret hasn't been produced yet that began with 8 bits of zero. But >>> somehow I doubt it. >> >>It is mainly because of the interop meetings. I remember seeing >>different non-interoperable version because of this in one interop >>meeting. After we didn't interoperate the other ends code was changed >>to do what everybody else is doing, and then we had interoperable >>versions. >> >>There is some of this kind of things that you can only learn by coming >>to the interop meeting and checking out how others are doing things. >>-- >>kivinen@iki.fi Work : +358-9-4354 3218 >>SSH Communications Security http://www.ssh.fi/ >>SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ >> From owner-ipsec@lists.tislabs.com Mon Apr 26 13:28:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03290; Mon, 26 Apr 1999 13:28:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26191 Mon, 26 Apr 1999 10:41:07 -0400 (EDT) Message-Id: <199904252216.AAA05619@waldorf.appli.se> To: ipsec@lists.tislabs.com Subject: INITIAL-CONTACT issues Date: Mon, 26 Apr 1999 00:16:25 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was implementing the INITIAL-CONTACT status notification of the IPsec DOI when a few things suddenly struck me. RFC 2408 3.14 states this: Notification which occurs during, or is concerned with, a Phase 1 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected. This directly contradicts what is said a few lines further down (at least I think so, but the "SPI value of 0" wording is a bit vague, and as such I dislike it): o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. I propose the wording of the first paragraph be changed to: Notification which occurs during, or is concerned with, a Phase 1 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI is irrelevant (although there are still some limitations on its representation) because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected. I also propose the other paragraph be changed to: o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) MAY put further restrictions for the DOI-defined notify message types and MUST dictate the SPI Size for other protocols. Maybe my use of MAY & MUST wrt what a DOI should do is bogus, but at least this covers the extra rules RFC 2407 sets in 4.6.3.3 (e.g. for INITIAL-CONTACT). Next thing, RFC 2407 4.6.3.3, is a bit unclear on one point: When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload). The fixed length, to me, meant a null SPI field as well, as that is variable length, and although I had noted that the SPI field should be filled in with data I missed to allocate space for it, mainly due to this wording. Clearly it was an error of mine, but this also shows the wording is a bit unfortunate. I propose: When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of a Notification Payload plus the SPI size). Last, RFC 2407 in 4.6.3 says that INITIAL-CONTACT MUST NOT be sent in Aggressive Mode. This is all fine by me (although I could envision the initiator send his INITIAL-CONTACT in the last message if he chose to encrypt it, which is at its option). I bring this up because draft-jenkins-ipsec-rekeying-01.txt has some text that makes aggressive mode useless if we follow these rules, in 3.1: Initial Phase 1 SA Negotiation: -initiator MUST use INITIAL-CONTACT notification -responder may use INITIAL-CONTACT notification Now, there is at least one voice stating that aggressive mode is useless anyhow, so maybe this is moot. If it is not, however, I suggest Jenkins change his text to cover aggressive mode and talk about the options of sending INITIAL-CONTACT in a separate Informational Exchange (thus without guarantee of delivery) or as extra payload(s) in the first Quick Mode (which may not ever occur). I guess that is the best one can do in aggressive mode? Comments? Niklas From owner-ipsec@lists.tislabs.com Mon Apr 26 15:49:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA04673; Mon, 26 Apr 1999 15:49:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26881 Mon, 26 Apr 1999 13:53:52 -0400 (EDT) Date: Mon, 26 Apr 1999 11:01:31 -0700 (PDT) From: Sunil Vallamkonda X-Sender: sunil@seltzer.mtv.siara.com To: ipsec@lists.tislabs.com Subject: DES and Key... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, 1) Is there a standard for representing a key for a particular algorithm ? (little vs big endian) ?? 2) I am implementing DES and want to know if the results of encrypt is right. Is there any sample/example/table somewhere which tells encrypting a given two 64byte data and result -... example(dummy): encrypt((123456676...),(3333444....)) = 555555555 Thx. Sunil. From owner-ipsec@lists.tislabs.com Mon Apr 26 20:34:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA18808; Mon, 26 Apr 1999 20:33:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28184 Mon, 26 Apr 1999 21:15:45 -0400 (EDT) From: "Evan Caves" To: , , , Subject: May VPN workshop Date: Mon, 26 Apr 1999 18:21:15 -0700 Message-Id: <001c01be904c$3ea33470$7c69c081@evan.acc.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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those of you still sitting on your laurels the Hotel reservation cuttoff is fast approaching. After May 3 the room rates will jump to $245 (from $135) so if you plan to attend please take this into consideration. Information on the workshop can be obtained at http://www.ciug.org:8080/IPSEC-PPP.html. evan - (sorry for the cross posts) From owner-ipsec@lists.tislabs.com Tue Apr 27 11:07:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01981; Tue, 27 Apr 1999 11:07:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29715 Tue, 27 Apr 1999 09:06:42 -0400 (EDT) X-Mailer: exmh version 2.0.2 To: itojun@iijlab.net cc: ipsec@lists.tislabs.com, P.Kirstein@cs.ucl.ac.uk, S.Hailes@cs.ucl.ac.uk Subject: Re: ipv4 IPSec extensions In-reply-to: Your message of "Tue, 27 Apr 1999 20:47:03 +0900." <27465.925213623@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Apr 1999 14:14:31 +0200 Message-ID: <1007.925218871@cs.ucl.ac.uk> From: Theo PAGTZIS Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Itojun, There is also a minor bug with line 358 or thereabouts. It is only visible when doing an IPv4 build The second angle bracket should be out of the #endif /*INET6*/ otherwise if INET6 is not included in the options it would give a parse error since it does not know where to get out of the parent switch Regards (PS. I am including the ipsec list for anyone that may be interested in this) Theo > >> On file ../netinet6/esp_output.c (security payload stuff), it seems that yo >u >>may have slipped a #ifdef INET for lines 408 to 414 and #ifdef INET6 for line >s >>415 to 421, as my build seems to break when I do not specify INET6 (remember >I >>want only the IPSEC extensions for IPv4) >>Let me know if this is true or not. > > Thanks very much, but which operating system, and which version > (KAME SNAP or STABLE, and the date) do you mean? > >itojun From owner-ipsec@lists.tislabs.com Tue Apr 27 11:55:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03086; Tue, 27 Apr 1999 11:55:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00132 Tue, 27 Apr 1999 10:05:22 -0400 (EDT) Message-ID: <01BE9095.E1F1CE40@mtlaurel-dhcp-232.cisco.com> From: Ted Hannock To: "'ipsec@lists.tislabs.com'" Subject: IPSec Throughput Date: Tue, 27 Apr 1999 10:08:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA00096 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To All, Does anyone know what effect IPSec has on a particular transmission? I read the RFC and it stated that the AH is 31 bytes long. Is this the only overhead to an encrypted packet? If not, what else is added and how much overhead? If a 1meg file is encrypted using IPSec, what does the header/encryption add to this file? Any feedback would be appreciated. C I S C O S Y S T E M S Ted Hannock Systems Engineer Cable East Operations || || Voice - 1.609.642.7073 || || Pager (Voice) - 1.800.365.4578 |||| |||| Pager (E-Mail) - thannock@epage.cisco.com |||||| |||||| Fax - 1.609.642.7098 ||||||||| ||||||||| E-mail - thannock@cisco.com 308 Harper Drive, Suite 100 Moorestown, New Jersey 08057 From owner-ipsec@lists.tislabs.com Tue Apr 27 12:18:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03646; Tue, 27 Apr 1999 12:18:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00239 Tue, 27 Apr 1999 10:22:15 -0400 (EDT) X-Mailer: exmh version 2.0.2 To: Ted Hannock cc: "'ipsec@lists.tislabs.com'" Subject: Re: IPSec Throughput In-reply-to: Your message of "Tue, 27 Apr 1999 10:08:21 EDT." <01BE9095.E1F1CE40@mtlaurel-dhcp-232.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Apr 1999 15:29:54 +0200 Message-ID: <1143.925223394@cs.ucl.ac.uk> From: Theo PAGTZIS Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is that only authentication or encryption as well that is required? Theo (UCL) >To All, > >Does anyone know what effect IPSec has on a particular transmission? I read t >he RFC and it stated that the AH is 31 bytes long. Is this the only overhead >to an encrypted packet? If not, what else is added and how much overhead? If > a 1meg file is encrypted using IPSec, what does the header/encryption add to >this file? > >Any feedback would be appreciated. > > C I S C O S Y S T E M S Ted Hannock > Systems Engineer > Cable East Operations > > || || Voice - 1.609.642.7073 > || || Pager (Voice) - 1.800.365.4578 > |||| |||| Pager (E-Mail) - thannock@epage.cisco.com > |||||| |||||| Fax - 1.609.642.7098 > ||||||||| ||||||||| E-mail - thannock@cisco.com > >308 Harper Drive, Suite 100 >Moorestown, New Jersey 08057 > > From owner-ipsec@lists.tislabs.com Tue Apr 27 12:32:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03976; Tue, 27 Apr 1999 12:32:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00377 Tue, 27 Apr 1999 10:40:19 -0400 (EDT) Message-ID: <01BE9099.9DFF41A0@mtlaurel-dhcp-232.cisco.com> From: Ted Hannock To: "'Theo PAGTZIS'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: IPSec Throughput Date: Tue, 27 Apr 1999 10:35:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Both are required. I'm just trying to fully understand the total overhead required per packet. C I S C O S Y S T E M S Ted Hannock Systems Engineer Cable East Operations || || Voice - 1.609.642.7073 || || Pager (Voice) - 1.800.365.4578 |||| |||| Pager (E-Mail) - thannock@epage.cisco.com |||||| |||||| Fax - 1.609.642.7098 ||||||||| ||||||||| E-mail - thannock@cisco.com 308 Harper Drive, Suite 100 Moorestown, New Jersey 08057 -----Original Message----- From: Theo PAGTZIS [SMTP:T.Pagtzis@cs.ucl.ac.uk] Sent: Tuesday, April 27, 1999 9:30 AM To: Ted Hannock Cc: 'ipsec@lists.tislabs.com' Subject: Re: IPSec Throughput Is that only authentication or encryption as well that is required? Theo (UCL) >To All, > >Does anyone know what effect IPSec has on a particular transmission? I read t >he RFC and it stated that the AH is 31 bytes long. Is this the only overhead >to an encrypted packet? If not, what else is added and how much overhead? If > a 1meg file is encrypted using IPSec, what does the header/encryption add to >this file? > >Any feedback would be appreciated. > > C I S C O S Y S T E M S Ted Hannock > Systems Engineer > Cable East Operations > > || || Voice - 1.609.642.7073 > || || Pager (Voice) - 1.800.365.4578 > |||| |||| Pager (E-Mail) - thannock@epage.cisco.com > |||||| |||||| Fax - 1.609.642.7098 > ||||||||| ||||||||| E-mail - thannock@cisco.com > >308 Harper Drive, Suite 100 >Moorestown, New Jersey 08057 > > From owner-ipsec@lists.tislabs.com Tue Apr 27 17:27:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14351; Tue, 27 Apr 1999 17:27:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01238 Tue, 27 Apr 1999 16:21:54 -0400 (EDT) Date: Tue, 27 Apr 1999 16:30:02 -0400 (EDT) From: Tony Mione To: ipsec@lists.tislabs.com Subject: IPSEC-API mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- After talking to a number of people at Minneapolis who are associated with IPSEC, it seemed like it would be a good idea to start a list to discuss APIs for IPSEC. With the foreknowledge Ted T'so of MIT and Paul Hoffman, Director of VPNC, I am starting such a list. The ipsec-api list is for discussing public API designs for the IPsec protocols. If there is enough interest and enough experience, this list may start work on a standard API for the IPsec protocol suite that can be presented in the IETF. In order to subscribe to the list, send email to majordomo@tdmx.rutgers.edu. Place the following commands into the BODY of the message: subscribe ipsec-api end An archive of this list is being kept but is not yet available on the web. ===== Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@noc.rutgers.edu W3: http://noc.rutgers.edu/~mione/ PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 ***** Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by mkpgp2.1, a Pine/PGP interface. iQCVAwUBNyYeJwfNcGHdn+zRAQH2UQQAqhSs8n0y7JEOYypsChd1xsTvDdpHLX5d u3M7oOMxCl7s8DDzQGjxVxUpfDH53gLbx8I7yM3/VuwMNuCx/BzGUFODRPBJ8pZQ uhLc88y5wDjIEBq/+4s9qaaJeNyELIfJFZlcwFPqji0rrTuy6TlopBtsLqSVEUmx +dWz6KOPadg= =v1JV -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 27 17:39:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14873; Tue, 27 Apr 1999 17:39:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01384 Tue, 27 Apr 1999 17:13:57 -0400 (EDT) Message-Id: <199904272121.OAA05689@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: linux-ipsec@clinet.fi, gnu@toad.com Cc: Dan Harkins Cc: Hugo Krawczyk Cc: ipsec@lists.tislabs.com Subject: Decrypting ID payload in Main Mode w/shared secrets Date: Tue, 27 Apr 1999 14:21:40 -0700 From: John Gilmore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Linux IPSEC implementation is trying to make shared secrets and identity protection work for Road Warriors (laptops connected to any place on the Internet, who want a secure tunnel back to home). The current IKE protocol makes this a problem. Dan Harkins' succinct description of the protocol problem is: > The problem is the key used to encrypt the IKE messages is derived > from SKEYID and if you're doing pre-shared key authentication SKEYID > is derived from the pre-shared key. So, the issue is: how do I know > the pre-shared key if I haven't gotten the guy's identity payload yet? > > ... If you're doing Main Mode authenticated with pre-shared keys > the pre-shared key has to be based on the IP address of the peer. > For people with a dynamic IP address that is, indeed, problematic. Now let's discuss proposed solutions. Still quoting Dan: > The "solution" is to use Aggressive Mode and the KEY_ID identity > which is basically an opaque blob that conveys no information to > an evesdropper but can be bound to a pre-shared key by the real parties > to the exchange. This proposed solution permits eavesdroppers to determine that the same person (the same opaque blob) is connecting from a variety of places, even if they don't know the "identity" of that person. (In Aggressive Mode, the ID payload isn't protected under the D-H shared key.) > That or use digital signatures since there is nothing > in the SKEYID generation that is bound to the identity. Note though that > has been described as a weakness of digital signature mode (by Hugo > Krawczyk). Digital signatures are a whole other interesting topic; let's stick with shared secrets for a bit. > Alternately a "solution" would be to define a new exchange that has > the negotiation richness of Main Mode (which is the drawback to Aggressive > Mode) but does not have identity protection. Since I don't want to give up identity protection, this doesn't suit. I have a proposal that provides identity protection against passive attacks, allows the parties to negotiate their identities, and only uses shared secrets. My suggestion is that the "pre-shared key" used to generate SKEYID for the third exchange in Main Mode (the ID payload and the hash) be set to some generic open secret, unless the parties know a secret specific to their IP addresses. Then, after processing these third exchange packets, both parties will change the SKEYID for future packets, by picking a more appropriate pre-shared secret based on the identities claimed in the third exchange. This new SKEYID would protect the subsequent Quick Mode exchange(s) that actually set up IPSEC SAs. I suggest that in the absence of explicit configuration, the generic open secret be the ASCII string: "open secret" The convention that an open secret is used for the 3rd packet's SKEYID is consistent with the existing IKE specs, which say "When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir." The open secret is associated with any IP address for which no other configured secret key exists. Such an open secret is similar to the single "secret shared by all Road Warriors" provided in freeswan-1.00 as the key for IP address 0.0.0.0. If a community of users (in a single VPN) wish to change this open secret to a less-open secret, they would only need to configure a secret key for IP address 0.0.0.0. The advantage of today's proposal (changing the key after packet #3) is that the secret shared with the entire group would then be replaced for all subsequent packets by a secret shared only by the parties involved. > The other option, which is > to remove the pre-shared key from SKEYID generation, has already been > rejected by the WG due to the security impact (again, noted by Hugo). Using an open secret as the pre-shared secret (as opposed to configuring a secret shared by your entire VPN) would seem to have the same security implications as removing the pre-shared secret from the SKEYID generation. I am still looking for the mailing list messages in which Hugo discussed the security implications of such a change. SKEYID was created in draft-ietf-ipsec-isakmp-oakley-03. I found a lively discussion that started with a message by Hugo on 25 Sep 1997, about changes between drafts 3 and 4 in SKEYID generation, and his proposal for further changes. However, this discussion was all about the "encryption mode" of Main Mode (using public keys to authenticate), not about the pre-shared key mode of Main Mode (using pre-shared secrets to authenticate). I found no reference to any insecurities in removing *pre-shared secrets* from SKEYID generation. Can someone feed me a better clue here? John From owner-ipsec@lists.tislabs.com Tue Apr 27 18:22:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16394; Tue, 27 Apr 1999 18:22:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01455 Tue, 27 Apr 1999 18:13:14 -0400 (EDT) Message-Id: <199904272218.PAA06563@potassium.network-alchemy.com> To: John Gilmore cc: linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: Your message of "Tue, 27 Apr 1999 14:21:40 PDT." <199904272121.OAA05689@toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6560.925251525.1@network-alchemy.com> Date: Tue, 27 Apr 1999 15:18:45 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You must have some out-of-band mechanism to distribute this pre-shared key (the real one, not the "open secret") on the scale you desire so why not just distribute public keys bound to identities through that channel and then use the pubic key encryption mode? This gives you deniability and also makes an attacker crack not only the Diffie-Hellman but two public key encryptions. If the RSA patent is in your way then define a new exchange which uses El-Gamal. What you propose would require another exchange anyway since everyone else's implementation doesn't create one set of SKEYID(a_e_d) state and then throw it away and make more. Using a well-known pre-shared key would mean that anybody who knows it could derive the key used to encrypt the identities (which is now based completely on known information: "open secret" and the 2 nonces which are passed in the clear) and that sort of defeats your purpose. And why "open secret" when we have draft-ietf-ipsec-internet-key-00.txt? Dan. On Tue, 27 Apr 1999 14:21:40 PDT you wrote > The Linux IPSEC implementation is trying to make shared secrets and > identity protection work for Road Warriors (laptops connected to any > place on the Internet, who want a secure tunnel back to home). The > current IKE protocol makes this a problem. Dan Harkins' succinct > description of the protocol problem is: > > > The problem is the key used to encrypt the IKE messages is derived > > from SKEYID and if you're doing pre-shared key authentication SKEYID > > is derived from the pre-shared key. So, the issue is: how do I know > > the pre-shared key if I haven't gotten the guy's identity payload yet? > > > > ... If you're doing Main Mode authenticated with pre-shared keys > > the pre-shared key has to be based on the IP address of the peer. > > For people with a dynamic IP address that is, indeed, problematic. > > Now let's discuss proposed solutions. Still quoting Dan: > > > The "solution" is to use Aggressive Mode and the KEY_ID identity > > which is basically an opaque blob that conveys no information to > > an evesdropper but can be bound to a pre-shared key by the real parties > > to the exchange. > > This proposed solution permits eavesdroppers to determine that the same > person (the same opaque blob) is connecting from a variety of places, > even if they don't know the "identity" of that person. (In Aggressive > Mode, the ID payload isn't protected under the D-H shared key.) > > > That or use digital signatures since there is nothing > > in the SKEYID generation that is bound to the identity. Note though that > > has been described as a weakness of digital signature mode (by Hugo > > Krawczyk). > > Digital signatures are a whole other interesting topic; let's stick with > shared secrets for a bit. > > > Alternately a "solution" would be to define a new exchange that has > > the negotiation richness of Main Mode (which is the drawback to Aggressive > > Mode) but does not have identity protection. > > Since I don't want to give up identity protection, this doesn't suit. > > I have a proposal that provides identity protection against passive > attacks, allows the parties to negotiate their identities, and only > uses shared secrets. > > My suggestion is that the "pre-shared key" used to generate SKEYID for > the third exchange in Main Mode (the ID payload and the hash) be set > to some generic open secret, unless the parties know a secret specific > to their IP addresses. Then, after processing these third exchange > packets, both parties will change the SKEYID for future packets, by > picking a more appropriate pre-shared secret based on the identities > claimed in the third exchange. This new SKEYID would protect the > subsequent Quick Mode exchange(s) that actually set up IPSEC SAs. > > I suggest that in the absence of explicit configuration, the generic > open secret be the ASCII string: > > "open secret" > > The convention that an open secret is used for the 3rd packet's SKEYID > is consistent with the existing IKE specs, which say "When using > pre-shared key authentication with Main Mode the key can only be > identified by the IP address of the peers since HASH_I must be > computed before the initiator has processed IDir." The open secret is > associated with any IP address for which no other configured secret > key exists. > > Such an open secret is similar to the single "secret shared by all > Road Warriors" provided in freeswan-1.00 as the key for IP address > 0.0.0.0. If a community of users (in a single VPN) wish to change > this open secret to a less-open secret, they would only need to > configure a secret key for IP address 0.0.0.0. The advantage of > today's proposal (changing the key after packet #3) is that the secret > shared with the entire group would then be replaced for all subsequent > packets by a secret shared only by the parties involved. > > > The other option, which is > > to remove the pre-shared key from SKEYID generation, has already been > > rejected by the WG due to the security impact (again, noted by Hugo). > > Using an open secret as the pre-shared secret (as opposed to > configuring a secret shared by your entire VPN) would seem to have the > same security implications as removing the pre-shared secret from the > SKEYID generation. I am still looking for the mailing list messages > in which Hugo discussed the security implications of such a change. > SKEYID was created in draft-ietf-ipsec-isakmp-oakley-03. I > found a lively discussion that started with a message by Hugo on 25 > Sep 1997, about changes between drafts 3 and 4 in SKEYID generation, > and his proposal for further changes. However, this discussion was > all about the "encryption mode" of Main Mode (using public keys to > authenticate), not about the pre-shared key mode of Main Mode (using > pre-shared secrets to authenticate). I found no reference to any > insecurities in removing *pre-shared secrets* from SKEYID generation. > Can someone feed me a better clue here? > > John > From owner-ipsec@lists.tislabs.com Tue Apr 27 18:27:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16497; Tue, 27 Apr 1999 18:27:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01510 Tue, 27 Apr 1999 18:46:22 -0400 (EDT) Message-Id: <199904272254.PAA08841@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Dan Harkins cc: John Gilmore , linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: <199904272218.PAA06563@potassium.network-alchemy.com> Date: Tue, 27 Apr 1999 15:54:11 -0700 From: John Gilmore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You must have some out-of-band mechanism to distribute this pre-shared > key (the real one, not the "open secret") on the scale you desire so > why not just distribute public keys bound to identities through that > channel and then use the pubic key encryption mode? Shared secrets already work -- we could add this in a day (and we have users who want it yesterday). The PK stuff starts to tie into certs, patents, DNS, and all the rest of the complications, which will take longer to sort out. > What you propose would require another exchange anyway since > everyone else's implementation doesn't create one set of SKEYID(a_e_d) > state and then throw it away and make more. I propose implementing something that the IETF specs explicitly don't permit -- an extension -- so of course we'd only interoperate with others who also implement the extension. If it got popular, of course, IETF could adopt it. From my recent scan of the IPSEC mailing list archives, it seems like a lot of implementers stumbled over this and were looking for a solution. I don't see why it would take another exchange (of packets). > Using a well-known pre-shared key would mean that anybody who knows > it could derive the key used to encrypt the identities (which is now based > completely on known information: "open secret" and the 2 nonces which are > passed in the clear) and that sort of defeats your purpose. I think you're confusing SKEYID and SKEYID_e. RFC2049: SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) The just-computed D-H shared secret (g^xy) is in the encryption key. The identities ARE protected against passive attacks. A man in the middle could impersonate the other side, thereby knowing g^xy, and get the claimed identity of one or both sides. But they would be detected one packet later -- when they couldn't decrypt Quick Mode packets because they didn't know the shared secret matching the identities. > And why "open secret" when we have draft-ietf-ipsec-internet-key-00.txt? You're right, I stand corrected. Is that a standards-track document? :-) What's the derivation of the shared secret it proposes, "mekmitasdigoat". As you can tell, it wasn't as mnemonic for me as "open secret", since I'd forgotten all about that draft. John From owner-ipsec@lists.tislabs.com Tue Apr 27 19:08:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA19408; Tue, 27 Apr 1999 19:08:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01750 Tue, 27 Apr 1999 20:05:52 -0400 (EDT) Message-Id: <199904280011.RAA05502@gallium.network-alchemy.com> To: John Gilmore cc: Dan Harkins , linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: Your message of "Tue, 27 Apr 1999 15:54:11 PDT." <199904272254.PAA08841@toad.com> Date: Tue, 27 Apr 1999 17:11:35 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RE: pre-shared key Another thought... How about we have the road-warrior send an ID_KEY_ID payload in the first Main Mode exchange containing a hash of the road-warrior's pre-shared key identity? That way, the gateway could determine which identity the road-warrior ought to be using while preserving identity protection for the actual ID payloads... Derrell From owner-ipsec@lists.tislabs.com Tue Apr 27 19:34:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA23279; Tue, 27 Apr 1999 19:34:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01863 Tue, 27 Apr 1999 20:30:47 -0400 (EDT) Message-Id: <199904280036.RAA06877@potassium.network-alchemy.com> To: "Derrell D. Piper" cc: John Gilmore , linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: Your message of "Tue, 27 Apr 1999 17:11:35 PDT." <199904280011.RAA05502@gallium.network-alchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6874.925259788.1@network-alchemy.com> Date: Tue, 27 Apr 1999 17:36:28 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yet another thought. How about an exchange ala New Group Mode that is New ID_KEY_ID mode? Upon successful authentication using an identity of ID_KEY_ID this can be used to associate a new ID_KEY_ID with an existing pre-shared key. That way you don't use the same ID_KEY_ID every time and whatever sort of identity traffic analysis you were imagining would be impossible. Yet another thought. After someone authenticates with an identity that's an ID_KEY_ID have each side recompute a new ID_KEY_ID based upon the old one: new-key-id = prf(SKEYID_d, old-key-id). This behavior could (should) be protected by a vendor ID payload. Dan. On Tue, 27 Apr 1999 17:11:35 PDT you wrote > RE: pre-shared key > > Another thought... > > How about we have the road-warrior send an ID_KEY_ID payload in the first Mai >n > Mode exchange containing a hash of the road-warrior's pre-shared key identity >? > That way, the gateway could determine which identity the road-warrior ought t >o > be using while preserving identity protection for the actual ID payloads... > > Derrell > > From owner-ipsec@lists.tislabs.com Tue Apr 27 21:42:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA06974; Tue, 27 Apr 1999 21:42:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02108 Tue, 27 Apr 1999 22:27:57 -0400 (EDT) Date: Tue, 27 Apr 1999 22:31:19 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: John Gilmore cc: linux-ipsec@clinet.fi, Dan Harkins , Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets In-Reply-To: <199904272121.OAA05689@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: John Gilmore | My suggestion is that the "pre-shared key" used to generate SKEYID for | the third exchange in Main Mode (the ID payload and the hash) be set | to some generic open secret, unless the parties know a secret specific | to their IP addresses. I think that this is a reasonable stab at trading a little to get support for an unknown IP address. This requires each party to know whether the other party knows its IP address -- one piece of information beyond what is needed. Perhaps it would be better to allow the sender to use either form of SKEYID and require the receiver to try both if it can generate both. The sender can use the universal shared secret if (a) it is not sure that the receiver knows its identity from its IP address, and (b) it is willing to give up one layer of man-in-the-middle protection. This could be generalized to, say, a hierarchy of shared secrets, but I think that way lies madness. In a sense this is backward compatible. For the possibly-unknown case, it doesn't work with old IKEs, but there was no other way that would. For the know-to-be-known case, this is compatible. Perhaps a more conservative approach would be to add either a header flag or a new exchange type for this. Implementors (and others): - What have you implemented for this problem? - Would you be willing to throw this proposal into your system? Sooner rather than later? - Is there another approach that you find more appealling? We want to solve this problem AND interoperate. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Wed Apr 28 06:40:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA25091; Wed, 28 Apr 1999 06:40:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03512 Wed, 28 Apr 1999 06:36:35 -0400 (EDT) Message-ID: <0069C33D83BCD111912B00805F9F52CB24C3D9@exchange1.abl.ca> From: Dominique Bastien To: Sunil Vallamkonda , ipsec@lists.tislabs.com Subject: RE: DES and Key... Date: Wed, 28 Apr 1999 06:43:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, To validate your DES algorithm you can find some examples in the following link: http://www.itl.nist.gov/div897/pubs/fip81.htm Regards, Dominique From owner-ipsec@lists.tislabs.com Wed Apr 28 11:20:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27809; Wed, 28 Apr 1999 11:20:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03713 Wed, 28 Apr 1999 07:59:38 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA0956B@exchange> From: Tim Jenkins To: Niklas Hallqvist , ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Wed, 28 Apr 1999 08:09:33 -0400 X-MS-TNEF-Correlator: <319A1C5F94C8D11192DE00805FBBADDFA0956B@exchange> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE916F.FA49A320" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE916F.FA49A320 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Niklas Hallqvist [mailto:niklas@appli.se] > Sent: April 25, 1999 6:16 PM > To: ipsec@lists.tislabs.com > Subject: INITIAL-CONTACT issues > Last, RFC 2407 in 4.6.3 says that INITIAL-CONTACT MUST NOT be sent in > Aggressive Mode. This is all fine by me (although I could envision > the initiator send his INITIAL-CONTACT in the last message if he chose > to encrypt it, which is at its option). I bring this up because > draft-jenkins-ipsec-rekeying-01.txt has some text that makes > aggressive mode useless if we follow these rules, in 3.1: > > Initial Phase 1 SA Negotiation: > -initiator MUST use INITIAL-CONTACT notification > -responder may use INITIAL-CONTACT notification > > Now, there is at least one voice stating that aggressive mode is > useless anyhow, so maybe this is moot. If it is not, however, I > suggest Jenkins change his text to cover aggressive mode and talk > about the options of sending INITIAL-CONTACT in a separate > Informational Exchange (thus without guarantee of delivery) or as > extra payload(s) in the first Quick Mode (which may not ever occur). > I guess that is the best one can do in aggressive mode? > > Comments? > > Niklas > > In the document, I did not discuss specific issues such as the use of INITIAL-CONTACT with the phase 1 modes, so your question is a very good one. What I would like to see is a clarification of the logic. Here is the text referred to: These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange. Is this comment still valid if the third aggressive mode message is sent encrypted? The INITIAL-CONTACT notification is important for recovery of systems, so I would like to see more discussion with respect to this issue. Tim ------_=_NextPart_000_01BE916F.FA49A320 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiMMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcEABwACAAJACEAAwArAQEggAMADgAAAM8HBAAc AAgACQAhAAMAKwEBCYABACEAAABGMDVGOTE5RTYxRkREMjExOEEyMTAwODBDNzk0NUU2QwAgBwEE gAEAGwAAAFJFOiBJTklUSUFMLUNPTlRBQ1QgaXNzdWVzAPAHAQ2ABAACAAAAAgACAAEDkAYALAsA ADEAAAALAAIAAQAAAAsAKwAAAAAAAwAuAAAAAABAADkAcDo6+m+RvgEeAHAAAQAAABcAAABJTklU SUFMLUNPTlRBQ1QgaXNzdWVzAAACAXEAAQAAABsAAAABvo/1kC8nKqB0+6UR0pNQABBLaqjYAF5Q RHAAHgAxQAEAAAAJAAAAVEpFTktJTlMAAAAAAwAaQAAAAAAeADBAAQAAAAkAAABUSkVOS0lOUwAA AAADABlAAAAAAAIBCRABAAAAGAYAABQGAABxCgAATFpGdUvDW3YDAAoAcmNwZzEyNeIyA0N0ZXgF QQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cw EiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwdwrjCoQKgC0d8B00B2Eg+koJ8GsL gAQgHz8fkwdiSlMOsHASIXJwBbBhTHRpAiAdNHRqHtRAdyGgB4Eg8S4FoB6gH5doQQJAcDovL3ck oC4DItodNCg2MTMpIFA1OTktHCAxFlB4EDQzMDQfnUZheDQ6ICYLNx06HTo+IOsd8R3wTwUQZwuA B0AF0GEHkHNhZ2UrAyqGRmMDYShgTmlrC2AEIEixB0BscXYEAAVAWwDAMQMQdG86AwAtokBh0nAL UGkuFBBdKoYGYHMCMChgQXAFEAMgDjAsBCAxJnA5IDY6MVA2IFBNKoZULvAgswUgFBBjQC+wIxBz JNE6cwtgYjOwJXcwcXViBSJQYzDBSU5JVEkAQUwtQ09OVEFcQ1QzAAQQClBzHTo8znMDACRgLXUn ICNhB4DPAjAEIAIgOSB0aBKBNpRaIAEAbBQgCYA+KixMRS3AdDFwUkZDMUA0DDA3MwADoDQuNi70 MyAsEHkEIDlwIZA1j0hNVVM2cE5PNnBinmU9ADChPHEqhkFnCcGpBBBpdj9QTQRxLiCBlmgEADaB IC4BIGYLgPE/UGJ5IAeAKHAHQDlwGQhgZ2g9oDiRdWxkfiAJ8C5BIbcq4DlxPHFp/yGgIZAFsT9x Q/BBkjWfA6C/RRItsQVAB4EsEjMAZiQg2z9QE9BvFBBEl29EAQUA7nkFMUVwMXB3QZAT0EHDb0qC OREFMCGxKUFRQ5Bi2QUQbmc9UUGhdSEQP0BoY2F1SVhkIYABgC0VIlUtMxMtGCBrZXnxTMEtMDEk 0A7RE+AEIP5zA3A/UA6zPWMAwE/QNuX/KuAsIECHBGJNQBQQOlAEEd1IwXc/UAIQLhBvB+A5cXkU ECByQ9AHkDFwPIEzuC4xOiqGKoYfk0lFY60DIFBQsT9QMQYAQQex/mc5YEWRIbFWNx+UT0BFZ/c+ s03BRn9uWPFCQE2gIaj/WedAkSFgRhASgQDAQqBbb/tcf1ZsTlTQMXA5ckUxS1PPOlBIAgIgP1B2 bw3gP1H/AZAhoEzTPYFSvgQAKoZTtv0AcHlDMGJRUPBe4j9BTQP/QaEEYDlgTFJI0EVwQcJgcasx cGdhZUDgcjFwSSqG/zawQHAjAR63E9FM0D9QQZL/UURKAAWgalFlDwBwQ/ABkOxsa1I3BuB1UXI/ UEvkvzkRSNBF8kzCRo8DoGE/Yd8KsSGQSWdXkAIQcgDAIaLpK7FFeGw1KDlwTcBK0OdFcEMxBUBn dXMRAjAJ4P9w0joxQNFKUCZABbEtwCqGKw7BIYAgCrB5F7BhZHwocyZAR4VCQBQABUBR+nUN4GtB AyhwSuRe8mBx40QAbYJvY2MIcExAc2f/diFT8j1jbLJFIT9AY3VNoN0DoGRKAHKSUsw/Vk4IUP84 xICfLYRWTh06V5BFA39A73xgONJqgTogaUPwe7JxQPcE8E3AUNFwBZBgojm2NrD/SxEtwTlxHTRf MnDhcZ51sr1FA3BYJQRiVaFnsXkIYfwgcTbBIahB0mPQd1F2IN9o0EPwY6F8pR00Vz1zStD/Q8Mv sE/QSeIUEGLEOJALYK8GgVz1cNJHs28rgGNBUL5IYqGNh0USDrMYIGYEkP8YIUnhVjUdNCByVRNI RQQg/z6/PIFAbXhhbDRnkQuAZBD/lfeYvn9AB5F7sjEAbXCGkP9oIj9QQmBkECwBjlGcwQ6w9zVQ klJJ8WILgG7hiRYfkf9iMGCRQqAg4CGQdYEr5Uni90USmbaPC0k9QkGhOKVkMfsDEAMgdgdAhpFI wZRDQZD/CyBtv0hFjYc/c0olCYCCJf8eJUUhX39giUHCB3AhYQGQfz+RdAGUwW1jQqBw4B00c/s9 MA6wbYxUkC92oQRgYrH/hwWSUosDXlI1QSHloYJBoy82sY8LB2EdNH20AB4AQhABAAAAKQAAADwx OTk5MDQyNTIyMTYuQUFBMDU2MTlAd2FsZG9yZi5hcHBsaS5zZT4AAAAAAwDeP69vAAALAAOACCAG AAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAA AwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeAAGACCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA4LjUAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAA AADAAAAAAAAARgAAAAAOhQAAAAAAAAMABoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAH gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAA AQAAAAEAAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ACoAI IAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAAuACyAGAAAAAADAAAAAAAAARgAA AAAAiAAAAAAAAAsADIALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAACwCZgAggBgAAAAAAwAAA AAAAAEYAAAAAgoUAAAEAAAALAEGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMA8T8JBAAA AwAmAAAAAAADADYAAAAAAAMA/T/kBAAAAwCAEP////8CAUcAAQAAADoAAABjPVVTO2E9IDtwPVRp bWVTdGVwIENvcnBvcmE7bD1FWENIQU5HRS05OTA0MjgxMjA5MzNaLTgxODQAAAAeADhAAQAAAAkA AABUSkVOS0lOUwAAAAAeADlAAQAAAAkAAABUSkVOS0lOUwAAAABAAAcwgD40+m+RvgFAAAgwIKNJ +m+RvgEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAAFwAAAElOSVRJQUwtQ09OVEFDVCBpc3N1 ZXMAAB4ANRABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkEwOTU2QkBl eGNoYW5nZT4AAAALACkAAAAAAAsAIwAAAAAAAwAGEMXvfM8DAAcQWQYAAAMAEBAAAAAAAwAREAAA AAAeAAgQAQAAAGUAAAAtLS1USU1KRU5LSU5TVElNRVNURVBDT1JQT1JBVElPTlRKRU5LSU5TQFRJ TUVTVEVQQ09NSFRUUDovL1dXV1RJTUVTVEVQQ09NKDYxMyk1OTktMzYxMFg0MzA0RkFYOig2MTMp AAAAAAIBfwABAAAAMgAAADwzMTlBMUM1Rjk0QzhEMTExOTJERTAwODA1RkJCQURERkEwOTU2QkBl eGNoYW5nZT4AAAAZ2g== ------_=_NextPart_000_01BE916F.FA49A320-- From owner-ipsec@lists.tislabs.com Wed Apr 28 14:47:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29398; Wed, 28 Apr 1999 14:47:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04593 Wed, 28 Apr 1999 12:43:13 -0400 (EDT) Message-ID: From: "Volpe, Victor" To: ipsec@lists.tislabs.com Subject: 112 bit 3DES Date: Wed, 28 Apr 1999 12:50:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All: According to the 3DES draft "draft-ietf-ipsec-ciph-des3-00.txt", 112 bit 3DES must not be negotiated via IKE and is therefore a non-compliant key length for 3DES. Did I read this correctly? What is the status of the draft? Victor /*************************************************************************** *****/ Victor Volpe Altiga Networks, Inc. Principal Software Engineer 124 Grove Street, Suite 309 vvolpe@altiga.com Franklin, MA 02038 Phone: (508) 541-7300 x105 Fax : (508) 541-7030 www.altiga.com /*************************************************************************** *****/ From owner-ipsec@lists.tislabs.com Wed Apr 28 15:08:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29548; Wed, 28 Apr 1999 15:08:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04581 Wed, 28 Apr 1999 12:38:41 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Tim Jenkins'" , Niklas Hallqvist , ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Wed, 28 Apr 1999 09:46:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A question I have in this regard is Isn't the problem of state cleanup faced by IPSec end systems similiar to TCP state cleanup. TCP end-points can be left hanging if the peer reboots. It is my understanding that TCP overcomes this problem by providing KEEPALIVE mechanism. Can IPSec not do the same thing and make use of KEEPALIVE mechanism for this purpose. Another question I have in this context is Many of the state machine problems IPSec is trying to solve (like timeouts, race conditions due to out-of-order and dropped messages) all seemed to be similar to one solved by TCP state machine. So why not use TCP transport to implement IKE state machine. The RFC's don't seem to perclude using TCP as a transport. Is there anything in the IKE design that percludes using a reliable transport? What am I missing? Thanks, -- sankar -- -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Wednesday, April 28, 1999 5:10 AM To: Niklas Hallqvist; ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Niklas Hallqvist [mailto:niklas@appli.se] > Sent: April 25, 1999 6:16 PM > To: ipsec@lists.tislabs.com > Subject: INITIAL-CONTACT issues > Last, RFC 2407 in 4.6.3 says that INITIAL-CONTACT MUST NOT be sent in > Aggressive Mode. This is all fine by me (although I could envision > the initiator send his INITIAL-CONTACT in the last message if he chose > to encrypt it, which is at its option). I bring this up because > draft-jenkins-ipsec-rekeying-01.txt has some text that makes > aggressive mode useless if we follow these rules, in 3.1: > > Initial Phase 1 SA Negotiation: > -initiator MUST use INITIAL-CONTACT notification > -responder may use INITIAL-CONTACT notification > > Now, there is at least one voice stating that aggressive mode is > useless anyhow, so maybe this is moot. If it is not, however, I > suggest Jenkins change his text to cover aggressive mode and talk > about the options of sending INITIAL-CONTACT in a separate > Informational Exchange (thus without guarantee of delivery) or as > extra payload(s) in the first Quick Mode (which may not ever occur). > I guess that is the best one can do in aggressive mode? > > Comments? > > Niklas > > In the document, I did not discuss specific issues such as the use of INITIAL-CONTACT with the phase 1 modes, so your question is a very good one. What I would like to see is a clarification of the logic. Here is the text referred to: These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange. Is this comment still valid if the third aggressive mode message is sent encrypted? The INITIAL-CONTACT notification is important for recovery of systems, so I would like to see more discussion with respect to this issue. Tim From owner-ipsec@lists.tislabs.com Wed Apr 28 15:42:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29940; Wed, 28 Apr 1999 15:42:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04820 Wed, 28 Apr 1999 13:54:59 -0400 (EDT) Message-ID: <37274D62.793FBB79@sympatico.ca> Date: Wed, 28 Apr 1999 14:03:14 -0400 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: 112 bit 3DES References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Volpe, Victor" wrote: > According to the 3DES draft "draft-ietf-ipsec-ciph-des3-00.txt", 112 bit > 3DES must not be negotiated via IKE and is therefore a non-compliant key > length for 3DES. Did I read this correctly? What is the status of the > draft? RFC 2409, page 38: The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. From owner-ipsec@lists.tislabs.com Wed Apr 28 15:51:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00162; Wed, 28 Apr 1999 15:51:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04847 Wed, 28 Apr 1999 13:59:39 -0400 (EDT) Message-ID: <37275ab5.uincaa@incaa.nl> From: RL@incaa.nl (Robert Luursema) Organization: INCAA Datacom b.v. To: ipsec@lists.tislabs.com Date: Wed, 28 Apr 1999 18:45:17 +0200 Subject: Java crypto Cipher-Block-Chaining isn't chaining Reply-to: RL@incaa.nl X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here a question for a cryptography specialist. I just found out that the Java JCE (java Cryto Extension API) as it is designed by Sun and implemented by many others, that its Cipher-Block-Chaining code (for DES, DESede, idea, etc.) is not doing any chaining between blocks of data. That is, the IV that carries the cipher end state of previous encrypted block of data to the next one, stays the same from block to block. It is only randomly determined upon cipher initialization, and there is a way to set and to get it. The IV is however not changed when encrypting data. To me this defeats the purpose of Cipher-Block-Chaining, which guarantees that each block (exchange) of encrypted data depends on the previous one. But what do you crypto specialists think about this? -- Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v. From owner-ipsec@lists.tislabs.com Wed Apr 28 16:33:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00786; Wed, 28 Apr 1999 16:33:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04743 Wed, 28 Apr 1999 13:33:40 -0400 (EDT) Message-Id: <199904281739.KAA08378@potassium.network-alchemy.com> To: hugh@mimosa.com cc: John Gilmore , linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: Your message of "Tue, 27 Apr 1999 22:31:19 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8375.925321157.1@network-alchemy.com> Date: Wed, 28 Apr 1999 10:39:18 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't understand the need for pre-shared keys in solving the problem described. You don't want the problems with DNS, certificates, and patents? OK, don't use certificates, and don't check DNS. Just create DSA keys bound to some identity (like you bind pre-shared keys to an identity) and distribute them in the same manner you want to distribute pre-shared keys. Making and using 4 unauthenticated keys, throwing them away and the making 4 authenticated keys sounds like a hack. If you're going to make a hack then do El-Gamal public key encryption using manually distributed public keys. No certs. No DNS worries. No patents. It also provides ID protection against an active man-in-the-middle attack. I'm also a bit confused about the problem using ID_KEY_ID. As described by John Gilmore: This proposed solution permits eavesdroppers to determine that the same person (the same opaque blob) is connecting from a variety of places, even if they don't know the "identity" of that person. That would require large scale traffic analysis to derive this information and I'm not sure what use can be made of it-- that some opaque blob (the same person) is connecting from a variety of places. If that's scary in your environment than why isn't an active attack against "open secret" scary? Yes, the Quick Mode exchange would break down but now this attacker knows who (the actual identity, not just "the same opaque blob") and where. If I was running a hit squad that would be valuable intelligence; knowing that an opaque blob is running around connecting from various POPs would not. Dan. On Tue, 27 Apr 1999 22:31:19 EDT you wrote > | From: John Gilmore > > | My suggestion is that the "pre-shared key" used to generate SKEYID for > | the third exchange in Main Mode (the ID payload and the hash) be set > | to some generic open secret, unless the parties know a secret specific > | to their IP addresses. > > I think that this is a reasonable stab at trading a little to get > support for an unknown IP address. > > This requires each party to know whether the other party knows its IP > address -- one piece of information beyond what is needed. Perhaps it > would be better to allow the sender to use either form of SKEYID and > require the receiver to try both if it can generate both. The sender > can use the universal shared secret if (a) it is not sure that the > receiver knows its identity from its IP address, and (b) it is willing > to give up one layer of man-in-the-middle protection. > > This could be generalized to, say, a hierarchy of shared secrets, but > I think that way lies madness. > > In a sense this is backward compatible. For the possibly-unknown case, it doesn't work with old IKEs, but there was no other way that > would. For the know-to-be-known case, this is compatible. > > Perhaps a more conservative approach would be to add either a header > flag or a new exchange type for this. > > Implementors (and others): > > - What have you implemented for this problem? > > - Would you be willing to throw this proposal into your system? > Sooner rather than later? > > - Is there another approach that you find more appealling? > > We want to solve this problem AND interoperate. > > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 > From owner-ipsec@lists.tislabs.com Wed Apr 28 17:05:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01148; Wed, 28 Apr 1999 17:05:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05035 Wed, 28 Apr 1999 15:14:27 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA09808@exchange> From: Paul Kierstead To: ipsec@lists.tislabs.com Cc: linux-ipsec@clinet.fi Subject: RE: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets Date: Wed, 28 Apr 1999 15:24:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Wednesday, April 28, 1999 1:39 PM > To: hugh@mimosa.com > Cc: John Gilmore; linux-ipsec@clinet.fi; Hugo Krawczyk; > ipsec@lists.tislabs.com > Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared > secrets > ---- snip ---- > I'm also a bit confused about the problem using ID_KEY_ID. > As described > by John Gilmore: > > This proposed solution permits eavesdroppers to determine > that the same > person (the same opaque blob) is connecting from a variety > of places, > even if they don't know the "identity" of that person. > > That would require large scale traffic analysis to derive > this information > and I'm not sure what use can be made of it-- that some > opaque blob (the same > person) is connecting from a variety of places. If that's > scary in your > environment than why isn't an active attack against "open > secret" scary? > Yes, the Quick Mode exchange would break down but now this > attacker knows > who (the actual identity, not just "the same opaque blob") > and where. If > I was running a hit squad that would be valuable > intelligence; knowing that > an opaque blob is running around connecting from various POPs > would not. ---- Snip --- You could take this further ... you should be able to easily develop a new protocol (or a new exchange, config exchange, whatever) that could modify the ID once the session has been authenticated. Assumming this exchange is encrypted, you could use a different ID every time . If a given implementation did not support the change request, you could go on using the old one. Backwards compatibility and works too... I'm probably missing some giant hole here :) Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com From owner-ipsec@lists.tislabs.com Wed Apr 28 18:21:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA01731; Wed, 28 Apr 1999 18:21:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05650 Wed, 28 Apr 1999 18:14:35 -0400 (EDT) Date: Wed, 28 Apr 1999 18:22:04 -0400 (EDT) From: Henry Spencer To: "Volpe, Victor" cc: IP Security List Subject: Re: 112 bit 3DES 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, 28 Apr 1999, Volpe, Victor wrote: > According to the 3DES draft "draft-ietf-ipsec-ciph-des3-00.txt", 112 bit > 3DES must not be negotiated via IKE and is therefore a non-compliant key > length for 3DES. Did I read this correctly? Yes. IPSEC (RFC 2451) 3DES does not have variable key length; a 3DES key is 192 bits exactly, and no excuses (although 24 of those bits are parity bits which do not participate in the cipher, making the real key length 168 bits). Each of the three DES stages in it has a separate, distinct key. There is no provision for giving two of the stages identical keys. "112 bit 3DES" has no particular advantage over real 3DES, and has some known weaknesses (none of them looks like a practical attack route, last I heard, but they make people nervous). > What is the status of the draft? RFC 2451 is currently at Proposed Standard status, I believe. The draft you refer to is long obsolete. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Apr 28 23:34:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA14470; Wed, 28 Apr 1999 23:34:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06293 Thu, 29 Apr 1999 00:11:58 -0400 (EDT) Date: Thu, 29 Apr 1999 00:18:49 -0400 (EDT) From: Henry Spencer To: Ted Hannock cc: "'ipsec@lists.tislabs.com'" Subject: Re: IPSec Throughput In-Reply-To: <01BE9095.E1F1CE40@mtlaurel-dhcp-232.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Apr 1999, Ted Hannock wrote: > Does anyone know what effect IPSec has on a particular transmission? > I read the RFC and it stated that the AH is 31 bytes long. Is this the > only overhead to an encrypted packet? If not, what else is added and > how much overhead? The details depend very much on what encryption algorithm is being used, what authentication algorithm is being used, and certain other details. There is no single number which is *the* overhead involved. > If a 1meg file is encrypted using IPSec, what does > the header/encryption add to this file? IPSEC encrypts packets, not files. The overhead involved depends not only on the variables mentioned above, but on how the file gets broken up into packets, which in turn also depends on what application-level protocol is being used to transfer it. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Apr 29 19:26:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA05240; Thu, 29 Apr 1999 19:26:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08677 Thu, 29 Apr 1999 15:25:08 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC0410AD@new-exc1.ctron.com> From: "Bassett, John Robert" To: "'ipsec@lists.tislabs.com'" Subject: How is CONNECTED notify authenticated ? Date: Thu, 29 Apr 1999 20:33:07 +0100 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 Hi all, When the COMMIT bit is used in quick mode is the CONNECTED notify authenticated i.e. HDR*, HASH(4), N If it is, exactly what information is included in HASH(4) ? Message ID? Ni_b&Nr_b ? Thanks in advance, John B. Cabletron Systems Ltd +44 118 988 0016 From owner-ipsec@lists.tislabs.com Fri Apr 30 00:56:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA29812; Fri, 30 Apr 1999 00:56:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09844 Fri, 30 Apr 1999 01:22:24 -0400 (EDT) Message-Id: <3.0.3.32.19990429222840.00c62ab0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 29 Apr 1999 22:28:40 -0700 To: RL@incaa.nl, ipsec@lists.tislabs.com From: Alex Alten Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining In-Reply-To: <37275ab5.uincaa@incaa.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:45 PM 4/28/99 +0200, Robert Luursema wrote: >Here a question for a cryptography specialist. > >I just found out that the Java JCE (java Cryto Extension API) as it is >designed by Sun and implemented by many others, that its >Cipher-Block-Chaining code (for DES, DESede, idea, etc.) is not doing >any chaining between blocks of data. That is, the IV that carries the >cipher end state of previous encrypted block of data to the next one, >stays the same from block to block. It is only randomly determined >upon cipher initialization, and there is a way to set and to get it. >The IV is however not changed when encrypting data. > >To me this defeats the purpose of Cipher-Block-Chaining, which >guarantees that each block (exchange) of encrypted data depends on the >previous one. > >But what do you crypto specialists think about this? Interesting. Looks like the JCE needs to be fixed. Also I wonder why Sun's version doesn't support RSA signing/verification? - Alex -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@lists.tislabs.com Fri Apr 30 15:34:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08481; Fri, 30 Apr 1999 15:34:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11820 Fri, 30 Apr 1999 14:42:09 -0400 (EDT) Message-Id: <199904301849.LAA27263@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Dan Harkins cc: linux-ipsec@clinet.fi, Hugo Krawczyk , ipsec@lists.tislabs.com, gnu@toad.com Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: <199904281739.KAA08378@potassium.network-alchemy.com> Date: Fri, 30 Apr 1999 11:49:53 -0700 From: John Gilmore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, your replies sound disingenuous. This isn't rocket-science. Why anyone would want to help us design a protocol that promises security and anonymity, but doesn't actually deliver it, I would have no idea... > This proposed solution permits eavesdroppers to determine that the same > person (the same opaque blob) is connecting from a variety of places, > even if they don't know the "identity" of that person. > > That would require large scale traffic analysis to derive this information > and I'm not sure what use can be made of it-- that some opaque blob (the same > person) is connecting from a variety of places. I certainly can't think of any secretive three-letter organizations that are doing large scale traffic analysis. Can you? Once ANY corroborating information makes it possible to link that blob to a person, EVERY communication that person has had in the past, or will have in the future, has been identified to them. It's easy to link a blob with many other identifying bits of information. If airline flight records (passed to the State Dept for every international flight, for passport clearance) show you in twenty cities on specified dates over three years, and there are connections by that blob from eighteen of those cities at the right times... If you plug in in an Internet cafe and your image is recorded on the security camera, or perhaps you pay for the session and some lunch with a credit card... If you dial an ISP which authenticates your PPP login/password over the net in the clear, and then that blob comes from that IP address twelve seconds later... If your telephone bills (available to the police in the US with *no* warrant, even assuming the intelligence services haven't infiltrated the telco billing computers) show that your home phone or cellophone has made calls to an ISP at the same times that blob appeared on the 'net... > If that's scary in your > environment than why isn't an active attack against "open secret" scary? Active attacks are detectable by the parties to the communication. Secretive three-letter organizations hate for the parties to know that they're watching. It encourages the parties to take active measures against the watchers. Also, active attacks require more than merely passive monitoring of e.g. satellite or undersea-cable communications, which is well within the realm of undetectable technology. Active attacks would require injecting packets covertly into the Internet -- a process that can be tracked back to the source, with enough work, the way that Shimomura tracked Mitnick, from router to router, and through compromised and doctored phone switches. Active attacks are much harder to do on a mass scale. If done on that scale, the probability of detection is very great. Whereas worldwide passive wiretapping on a mass scale has been going on for decades without much significant confirmed detection -- merely very strong suspicion. Active attacks can be witnessed by reliable third parties, and credible evidence brought to a judge; they can't be prevented from disclosure to the target or the public as "classified information". Furthermore, if a single connection's identity is revealed by an active attack against a single IKE negotiation, that identity will not be linked to any previous or future IKE negotiations by the same person. Each one is protected by the Diffie-Hellman exchange. Are those a few good reasons, Dan? > Yes, the Quick Mode exchange would break down but now this attacker knows > who (the actual identity, not just "the same opaque blob") and where. If > I was running a hit squad that would be valuable intelligence; knowing that > an opaque blob is running around connecting from various POPs would not. It was certainly useful in WW2 to know that a given opaque U-boat callsign was running around connecting from various POPs and BANGs, even if its "identity" wasn't known. The blob *is* the identity, for many useful purposes. Traffic analysis alone -- including radio direction-finding -- provided a very large fraction of the useful information the Allies received in WW2. I doubt the situation has changed today. John From owner-ipsec@lists.tislabs.com Fri Apr 30 16:46:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09216; Fri, 30 Apr 1999 16:46:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12162 Fri, 30 Apr 1999 17:39:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 30 Apr 1999 15:39:48 -0600 From: "Hilarie Orman" To: , Cc: , , , Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA12159 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would you humor me for a moment and help me get oriented in the requirements? It seems to me that you've ended up in an odd place, and I'm wondering why. The original design has the two parties doing a non-authenticated DH exchange, and the shared secret from that protects the identities. You have to be an active person in the middle to learn the identities. That would seem to satisfy the criteria set out in your most recent note; so why not use that, and is it not supported in IKE, now? If you want to protect absolutely against person in the middle, then you can most likely use Denker's suggestion to have the client use the server's PK and send {K, DES(K, ID}}PK(svr) using public key encryption. This needs some further analysis in the context of the whole protocol in order for one to be certain that it protects against person in the middle during the whole exchange, but it is promising. Hilarie (joined Novell several weeks ago; Utah is a beautiful place) From owner-ipsec@lists.tislabs.com Fri Apr 30 16:58:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09330; Fri, 30 Apr 1999 16:58:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12145 Fri, 30 Apr 1999 17:35:58 -0400 (EDT) Message-Id: <199904302142.OAA02145@potassium.network-alchemy.com> To: John Gilmore cc: linux-ipsec@clinet.fi, ipsec@lists.tislabs.com Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets In-reply-to: Your message of "Fri, 30 Apr 1999 11:49:53 PDT." <199904301849.LAA27263@toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2142.925508550.1@network-alchemy.com> Date: Fri, 30 Apr 1999 14:42:30 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I'll concede this. Some organization may be able to correlate airline flight records, images from Internet cafe video cameras, ISP logs, and telephone bills into a damning indictment on a single individual. Impressive but not beyond my imagination. Don't you also think that there's some hit squad in some repressive dictatorship that would rather find out that a wanted man is in some exact location at an exact time? "He's in the El Mariachi Internet Cafe! Move!" But this kind of posturing is better done face-to-face with some libation in hand. An active attack on what you describe may be easier to hide than you imagine. As soon as the IKE SA is "authenticated" and the identities determined delete messages are sent back to the parties to delete the SA. Since the packets that initiated the IKE exchange in the first place are still in the hopper waiting for an IPSec SA it'll initiate another exchange. This 2nd one will succeed. The user sees a slight delay which might be normal for the local PTT. But this is bizarre. You're arguing _for_ doing something that allows for an active attack when you have perfectly good options that will solve your problem and not open you up to attack. Is there a problem with El-Gamal keys? Is there a problem with the reconstitued ID_KEY_ID scheme I described? Why not use GNU Privacy Guard DSA keys? That would seem to advance two products in tandem, which would be a good thing (actually GNU Privacy Guard El-Gamal encryption keys would be better). If I was paranoid I'd think you had an ulterior motive. Dan. On Fri, 30 Apr 1999 11:49:53 PDT you wrote > Dan, your replies sound disingenuous. This isn't rocket-science. > Why anyone would want to help us design a protocol that promises security > and anonymity, but doesn't actually deliver it, I would have no idea... > > > This proposed solution permits eavesdroppers to determine that the same > > person (the same opaque blob) is connecting from a variety of places, > > even if they don't know the "identity" of that person. > > > > That would require large scale traffic analysis to derive this information > > and I'm not sure what use can be made of it-- that some opaque blob (the sa >me > > person) is connecting from a variety of places. > > I certainly can't think of any secretive three-letter organizations > that are doing large scale traffic analysis. Can you? > > Once ANY corroborating information makes it possible to link that blob > to a person, EVERY communication that person has had in the past, or > will have in the future, has been identified to them. > > It's easy to link a blob with many other identifying bits of > information. If airline flight records (passed to the State Dept for > every international flight, for passport clearance) show you in twenty > cities on specified dates over three years, and there are connections > by that blob from eighteen of those cities at the right times... If > you plug in in an Internet cafe and your image is recorded on the > security camera, or perhaps you pay for the session and some lunch > with a credit card... If you dial an ISP which authenticates your PPP > login/password over the net in the clear, and then that blob comes > from that IP address twelve seconds later... If your telephone bills > (available to the police in the US with *no* warrant, even assuming > the intelligence services haven't infiltrated the telco billing > computers) show that your home phone or cellophone has made calls to > an ISP at the same times that blob appeared on the 'net... > > > If that's scary in your > > environment than why isn't an active attack against "open secret" scary? > > Active attacks are detectable by the parties to the communication. > Secretive three-letter organizations hate for the parties to know that > they're watching. It encourages the parties to take active measures against > the watchers. > > Also, active attacks require more than merely passive monitoring of > e.g. satellite or undersea-cable communications, which is well within > the realm of undetectable technology. Active attacks would require > injecting packets covertly into the Internet -- a process that can be > tracked back to the source, with enough work, the way that Shimomura > tracked Mitnick, from router to router, and through compromised and > doctored phone switches. > > Active attacks are much harder to do on a mass scale. If done on that > scale, the probability of detection is very great. Whereas worldwide > passive wiretapping on a mass scale has been going on for decades > without much significant confirmed detection -- merely very strong > suspicion. Active attacks can be witnessed by reliable third > parties, and credible evidence brought to a judge; they can't be > prevented from disclosure to the target or the public as "classified > information". > > Furthermore, if a single connection's identity is revealed by an > active attack against a single IKE negotiation, that identity will not > be linked to any previous or future IKE negotiations by the same > person. Each one is protected by the Diffie-Hellman exchange. > > Are those a few good reasons, Dan? > > > Yes, the Quick Mode exchange would break down but now this attacker knows > > who (the actual identity, not just "the same opaque blob") and where. If > > I was running a hit squad that would be valuable intelligence; knowing that > > an opaque blob is running around connecting from various POPs would not. > > It was certainly useful in WW2 to know that a given opaque U-boat > callsign was running around connecting from various POPs and BANGs, > even if its "identity" wasn't known. The blob *is* the identity, for > many useful purposes. Traffic analysis alone -- including radio > direction-finding -- provided a very large fraction of the useful > information the Allies received in WW2. I doubt the situation has > changed today. > > John