From owner-ipsec Mon Dec 1 10:59:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28939 for ipsec-outgoing; Mon, 1 Dec 1997 10:48:27 -0500 (EST) Message-Id: <199712011552.KAA16317@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-03.txt Date: Mon, 01 Dec 1997 10:52:28 -0500 Sender: owner-ipsec@ex.tis.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 Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-ietf-ippcp-protocol-03.txt Pages : 8 Date : 26-Nov-97 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. Internet-Drafts are 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-ippcp-protocol-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-protocol-03.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971126142603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126142603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Dec 1 11:15:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29080 for ipsec-outgoing; Mon, 1 Dec 1997 11:14:27 -0500 (EST) Message-Id: <199712011624.LAA17393@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-00.txt Date: Mon, 01 Dec 1997 11:24:45 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Mode for ISAKMP/Oakley Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-00.txt Pages : 8 Date : 26-Nov-97 This document describes an alternate authentication method for ISAKMP/Oakley which makes use of GSS-API to authenticate the Diffie- Hellman exchange. The mechanism described here extends the authentication modes defined in [Harkins97] without introducing any modifications to the ISAKMP/Oakley key exchange protocol. This constraint however, necessarily restricts the number of GSS-API exchanges and may limit the broader applicability of this method. Additional work is needed to provide a fully generalized solution. Such a solution will require ISAKMP/Oakley protocol modifications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-gss-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971126151606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126151606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Dec 2 13:25:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08128 for ipsec-outgoing; Tue, 2 Dec 1997 13:16:40 -0500 (EST) Date: Tue, 2 Dec 1997 14:30:26 -0300 From: Gordon Oliver Subject: Security Arch and ICMP. To: ipsec@tis.com Message-Id: X-Mailer: TkMail 4.0beta9 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. In trying to deal with ICMP I have several questions for which the answers are not clear from the Security architecture document (draft...arch-sec-03) First, when we get back an ICMP packet that signifies an error that will not necessarily recover (i.e. not MTU), we may fail to have enough information to forward the ICMP packet (the ICMP contains only enough for the IPsec headers) What should be done? Dropping the ICMP on the floor will cause poor behaviour on the network... (suppose it'd work though) Second, when the IPsec headers drop the PMTU below the acceptable limit (e.g. below zero), what should be passed up/forwarded to other hosts. It seems that low MTU's should be handled by lying to the sender, and fragmenting. Otherwise the IPsec headers are going to eat an unreasonable amount of bandwidth. Third, and finally, perhaps more thourough checks should be specified for ICMP. I.e. MUST verify that the given SA has been used, MUST verify that the packet header could be associated with the SA, etc. -gordo -- --------------------------------------------------------------- Gordon Oliver (gordo@telsur.cl) Independent Consultant ... Available for consulting on Linux ... From owner-ipsec Tue Dec 2 13:28:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08188 for ipsec-outgoing; Tue, 2 Dec 1997 13:28:39 -0500 (EST) Date: Tue, 2 Dec 1997 13:38:33 -0500 (EST) From: "M.C.Nelson" To: Michael Giniger cc: ipsec@tis.com Subject: Re: ISAKMP gateway function In-Reply-To: <347C6D4D.9F1F9DF1@tiac.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk This question from Michael Giniger touches on one of the things that I have never understood about the IPSEC security architecture. It seems that 68-80% of the attacks for which encryption would provide some protection are on the local network. The classic example of course, is sniffing a password on LAN #1, for a machine on LAN #2, while the machine on LAN #2 is being accessed by a user on LAN #1. Imagine that you are operating LAN #2, that your are required to allow access from other LANs, and that you have know of way of enforcing end-to-end encryption on the other LANs. Is there something in the current IPSEC documents that answers this? Regards, Mitch Nelson On Wed, 26 Nov 1997, Michael Giniger wrote: > Hi > > I've read through ISAKMPv8 and I was wondering if anyone could answer a > question for me. > > Does ISAKMP/OAKLEY support the use of a gateway host that negotiates > IPSEC SAs on behalf of other end systems. For example gateway host A > negotiates an ISAKMP SA (phase 1) with host Z. Then can host A > negotiate IPSEC SAs on behalf of end systems C, D, and E. Host A would > then have to provide C, D, and E with the requisite keying material, > etc. > Is this supported by ISAKMP and if so how is this done? > If not, then does this mean that any end system that wants to have an > IPSEC SA with another end system must negotiate directly with that end > system? > > Every end system would then have to store and run a copy of ISAKMP. > > I appreciate any information you can provide > > Sincerely > Michael Giniger > > > From owner-ipsec Tue Dec 2 16:37:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09250 for ipsec-outgoing; Tue, 2 Dec 1997 16:34:42 -0500 (EST) Date: Tue, 2 Dec 1997 16:45:32 -0500 Message-Id: <199712022145.QAA04023@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "M.C.Nelson" Cc: Michael Giniger , ipsec@tis.com In-Reply-To: M.C.Nelson's message of Tue, 2 Dec 1997 13:38:33 -0500 (EST), Subject: Re: ISAKMP gateway function Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 2 Dec 1997 13:38:33 -0500 (EST) From: "M.C.Nelson" This question from Michael Giniger touches on one of the things that I have never understood about the IPSEC security architecture. It seems that 68-80% of the attacks for which encryption would provide some protection are on the local network. The classic example of course, is sniffing a password on LAN #1, for a machine on LAN #2, while the machine on LAN #2 is being accessed by a user on LAN #1. Imagine that you are operating LAN #2, that your are required to allow access from other LANs, and that you have know of way of enforcing end-to-end encryption on the other LANs. Is there something in the current IPSEC documents that answers this? IPSEC can also be used in a host-to-host mode, which is far better mode to use due to the end-to-end arguments that you cite. The problem is that for many companies, it's much cheaper to simply put up a firewall and hope that that all of the bad guys are on the outside of the firewall. IPSEC is designed to work either in the end-host or in a security gateway. - Ted From owner-ipsec Wed Dec 3 09:00:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA14230 for ipsec-outgoing; Wed, 3 Dec 1997 08:57:11 -0500 (EST) Message-ID: <01BCFFFB.AF39B480@kai-pc.imib.med.tu-dresden.de> From: Kai Martius To: "'ipsec@tis.com'" Subject: RE: ISAKMP gateway function Date: Wed, 3 Dec 1997 14:56:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id IAA14227 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Ted Ts'o wrote: > of the firewall. IPSEC is designed to work either in the end-host or in > a security gateway. Or in both ;-)... On Wed, 26 Nov 1997, Michael Giniger wrote: ... > Is this supported by ISAKMP and if so how is this done? Phase II proxy exchange could handle this, I think. Depending on the interface of the ISAKMP daemon other hosts can request keys from it. However, the problem is that - the requested keys will be delivered in clear over the local network (regarding to the statement of Mitch Nelson, that "68-80% of the attacks for which encryption would provide some protection are on the local network." this isn't very nice...) - the host requesting the keys must trust the "ISAKMP-host" because it knows the final keys in every case. > If not, then does this mean that any end system that wants to have an > IPSEC SA with another end system must negotiate directly with that end > system? > Every end system would then have to store and run a copy of ISAKMP. Yes, if it doesn't accept the restrictions. If ISAKMP (and IPSEC) runs on host(s) and gateways(s) this leads to some other wellknown problems, like - application of security policies on gateways - eventually no direct communication between end systems possible - finding responsible gateways [I've written down some ideas for an "extended key exchange over security gateways" based on ISAKMP/Oakley, where gateways and end systems can apply their security policies. May be, someone is interested in it - simply send a message to me...] Regards Kai From owner-ipsec Wed Dec 3 13:15:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15923 for ipsec-outgoing; Wed, 3 Dec 1997 13:12:12 -0500 (EST) Message-Id: <199712031815.NAA02839@ogham.hq.tis.com> To: ipsec@tis.com Subject: Re: ISAKMP gateway function Date: Wed, 03 Dec 1997 13:15:17 -0500 From: dreeder Sender: owner-ipsec@ex.tis.com Precedence: bulk Kai Martius writes on Wed, 3 Dec 1997 14:56:48 +0100: . > Is this supported by ISAKMP and if so how is this done? . . Phase II proxy exchange could handle this, I think. Depending on the interface of the ISAKMP daemon other hosts can request keys from it. However, the problem is that . - the requested keys will be delivered in clear over the local network (regarding to the statement of Mitch Nelson, that "68-80% of the attacks for which encryption would provide some protection are on the local network." this isn't very nice...) . - the host requesting the keys must trust the "ISAKMP-host" because it knows the final keys in every case. . This brings up yet another question. An SA is generated by a KMd on host B at the request of host A. B ships the SA to A. How do B and A talk with one another over the network, do they use AF_KEY? (Is there any intent to standardize this relationship?) Then, of course, this traffic must be secured (regardless of the protocol A and B use), but by definition there is no KMd on A to create a secure channel to B... D. Reeder From owner-ipsec Wed Dec 3 13:40:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16126 for ipsec-outgoing; Wed, 3 Dec 1997 13:35:14 -0500 (EST) Message-Id: <199712031846.KAA03773@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: dreeder Cc: ipsec@tis.com Subject: Re: ISAKMP gateway function In-Reply-To: Your message of "Wed, 03 Dec 1997 13:15:17 EST." <199712031815.NAA02839@ogham.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 03 Dec 1997 10:46:06 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry to jump in so late on this but I've been having trouble getting IPSec mail lately. In any event... > Kai Martius writes on Wed, 3 Dec 1997 14:56:48 +0100: > . > Is this supported by ISAKMP and if so how is this done? > . > . Phase II proxy exchange could handle this, I think. Depending on the > interface of the ISAKMP daemon other hosts can request keys from it. > However, the problem is that > . - the requested keys will be delivered in clear over the local network > (regarding to the statement of Mitch Nelson, that "68-80% of the attacks > for which encryption would provide some protection are on the local > network." this isn't very nice...) > . - the host requesting the keys must trust the "ISAKMP-host" because it > knows the final keys in every case. > . Phase II proxy is not for this purpose. The ISAKMP peer always does IPSec. You never want to have one host obtain authenticated keys and then ship them over the network to the guy who's going to use them. There's a huge chicken-and-egg problem there and it also just doesn't make a whole lot of sense. If you do IPSec and not ISAKMP then all you can do is manually keyed SAs. If you do ISAKMP and not IPSec then you don't do much of anything at all. You can't take a host that only does ISAKMP and have it negotiate for a host that does not. Phase II proxy is when the end point of the communication is not doing IPSec. In that case the gateway constructs a tunnel through which packets destined to and from that host go. The tunnel terminates at the gateway. > This brings up yet another question. An SA is generated by a KMd on host B > at the request of host A. B ships the SA to A. How do B and A talk with > one another over the network, do they use AF_KEY? (Is there any intent to > standardize this relationship?) Then, of course, this traffic must be > secured (regardless of the protocol A and B use), but by definition there > is no KMd on A to create a secure channel to B... PF_KEY (or AF_KEY) is a raw socket and is not suitable for host-to-host communication. It's used for a user-space entity like ISAKMP to communicate with a kernel space entity like IPSec. Whether it's going to be standardized or not, I dunno. Dan. From owner-ipsec Thu Dec 4 09:46:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22743 for ipsec-outgoing; Thu, 4 Dec 1997 09:42:20 -0500 (EST) Date: Thu, 4 Dec 1997 09:52:53 -0500 From: bchappe@nswc.navy.mil (Brett Chappell x1568) Message-Id: <199712041452.JAA10075@sholeh.b35ita.sunoco> To: boyter@afiwc01.af.mil, rgm3@chrysler.com Cc: ipsec@tis.com Subject: Re: IPSEC Security Policy Management Sender: owner-ipsec@ex.tis.com Precedence: bulk > From rgm3@chrysler.com Wed Nov 26 11:36:36 1997 > X-Sender: rgm3@pop3hub.is.chrysler.com > Date: Wed, 26 Nov 1997 11:20:11 -0500 > To: "Boyter, Brian A." > From: Robert Moskowitz > Subject: Re: IPSEC Security Policy Management > Cc: "'ipsec@tis.com'" > Mime-Version: 1.0 > X-Mime-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA25959 > Content-Transfer-Encoding: quoted-printable > X-Mime-Autoconverted: from 8bit to quoted-printable by portal.ex.tis.com id LAB25962 > > At 09:50 AM 11/26/97 -0600, Boyter, Brian A. wrote: [snip] > > >Is there an opportunity to discuss this > >requirement??? Should an IPSEC secpol > >subgroup be created??? > > Ted and I are working on finishing the agenda for the IPsec session. Thi= > s > will be on there somehow, but lots of things happen in the hall and the > terminal room. I would also be interested in this discussion. I have been monitoring IPSEC as a possible technology that could be used in the Navy's environment. > > >> One idea I am playing with is to right the security policy in PolicyMa= > ker > >=D8 and put it in a certificate from the policy server.... > > > >Interesting idea... Is this the AT&T PolicyMaker??? > > Yes, I am quite intrigue with it. I would send you the URL, but I am > having trouble checking what I thought it was :( > > >From the Air Force's standpoint, we are in favor of almost > >any method of creating + storing + disseminating policy - > >we just want all of the vendor products to use the same > >standard.... > > > >What about using the attribute certificate > >(http://lists.w3.org/Archives/Public/ietf-tls/msg02442.html) > >(http://lists.w3.org/Archives/Public/ietf-tls/msg00796.html)???? > >Isn't this the "standard" for SSL security policy???? > > I have trouble with the direction of attribute certificates. I will be > spending time at DC trying to scope this out, but I have management scali= > ng > problems in a distributed responsibility model like I need here (you migh= > t > not, as the USAF is basically one command structure). Yes, but there may be some similarities between your environment and DoD's environment in that joint operations between the different branches must be taken in account. > > > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > Brett Chappell From owner-ipsec Thu Dec 4 22:10:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26782 for ipsec-outgoing; Thu, 4 Dec 1997 22:04:37 -0500 (EST) Date: Thu, 4 Dec 1997 22:15:31 -0500 Message-Id: <199712050315.WAA05539@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IPSEC document reading party! Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Bob and I are very concerned that few people are actually reading all of the IPSEC drafts, and so there may be internal inconsistency and other problems across the various drafts, that perhaps won't be discovered until after they are published as RFC's. That, as they say, would be Bad. In order to try to avoid this, we are planning an IPSEC document reading party, to be held Monday evening at the IETF meeting. The logistical details are still be being finalized, but it will probably start at either 6:00 or 7:30. (If it starts at 6:00, food will be provided.) We are looking for a people who are willing to put in a couple of hours of real work, by reading over the documents, with a particular attention towards finding consistency problems and other problems with the drafts. Please come only if you are prepared to work! Also, please bring your own copies of the documents to read. In the interests of getting work done, we're not looking for quality, not quantity, in terms of the number of people we have participating. Document editors are especially asked to come so that they will be available for questions should they arise from the readers. If you are interested in particpating, please RSVP to Bob and I. Information about the location, etc. will be announced later (probably at the IETF meeting itself; check the announcements board.) If you have any questions, please let either Bob or I know. - Ted From owner-ipsec Fri Dec 5 11:12:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00656 for ipsec-outgoing; Fri, 5 Dec 1997 11:06:44 -0500 (EST) Message-Id: <199712051618.LAA15770@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doc-roadmap-02.txt Date: Fri, 05 Dec 1997 11:18:36 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Security Document Roadmap Author(s) : R. Thayer, N. Doraswamy, R. Glenn Filename : draft-ietf-ipsec-doc-roadmap-02.txt Pages : 10 Date : 04-Dec-97 The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and Authentication Algorithm documents are described. Internet-Drafts are 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-doc-roadmap-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204153517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doc-roadmap-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204153517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 11:45:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00983 for ipsec-outgoing; Fri, 5 Dec 1997 11:44:44 -0500 (EST) Date: Fri, 5 Dec 1997 12:05:43 -0500 From: canetti@watson.ibm.com (Ran Canetti) Message-Id: <9712051705.AA17214@ornavella.watson.ibm.com> To: ddp@network-alchemy.com, ipsec@tis.com Subject: GSS-API Authentication Mode for ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Derrell, I'm having hard time understanding the GSS-API authentication mode fo ISAKMP/Oakley (draft-ietf-ipsec-isakmp-gss-auth-00.txt). First, to put us on a common ground: I understand that the premise of the draft is that the GSS-API is acting as a key-distribution center of a Kerberos-like system. Thus the GSSi and GSSr are tokens that contain (among other things) a shared key K for the initiator and responder; in GSSi the value K is encrypted with the initiator's key, and in GSSr the value K is encrypted with the responder's key. The center knows both the initiator's and responder's keys. Please correct me if I'm wrong here. My most immediate problem with the draft is that the exchange (in 4.2) does not seem authenticated at all: it looks as if a straightforward man-in-the-middle attack would work. This is because the only secret information in HASH_i and HASH_r is g^xy. Thus, a man in the middle can successfully pretend to be the other party by choosing its own x,g^x and playing the exchange in a straightforward way. What am I missing here? Another, more basic problem has to do with the approach taken here. It seems that "the right way" to design this mode would be to let the parties first agree on a shared key K using the kerberos-style exchange via the GSS-API, and then have the parties do the ISAKMP/Oakley exchange in pre-shared key mode, with key K as the preshared key. (True, some technical protocol problems arise here, such as that the pre-shared key mode does not currently allow for key-id to be transmitted. But this can be solved in a number of ways, say by adding a GSS-token type to the ISAKMP ID payload, and using this field to transmit the key id.) Certainly there seems to be no need to design a new cryptographic exchange here. We can discuss it more in DC if you wish. Ran Canetti I'd like to thank Pau-Chen Cheng and Hugo Krawczyk for reading and discussing the draft with me. From owner-ipsec Fri Dec 5 11:45:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00996 for ipsec-outgoing; Fri, 5 Dec 1997 11:45:44 -0500 (EST) Message-Id: <199712051656.LAA17245@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-00.txt Date: Fri, 05 Dec 1997 11:56:38 -0500 Sender: owner-ipsec@ex.tis.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 : Dynamic remote host configuration over IPSEC using DHCP Author(s) : B. Patel Filename : draft-ietf-ipsec-dhcp-00.txt Pages : 5 Date : 04-Dec-97 IPSEC is a protocol suite defined by IETF working group on IP security to secure communication at the network layer between communicating peers. This protocol is comprised of three primary elements: 1) ISAKMP/Oakley[2], 2) IPSEC AH [4]and 3) IPSEC ESP [5]. ISAKMP/Oakley is the key management protocol while AH and ESP are used to protect IP traffic. Both AH and ESP can be used in tunnel or transport mode. Among many applications enabled by IPSEC tunnel and transport modes, an interesting and useful application is connect a remote host (e.g., roaming user) to the intranet through firewall (or secure network gateway) using IPSEC tunnels. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-dhcp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204162232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204162232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 11:56:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01043 for ipsec-outgoing; Fri, 5 Dec 1997 11:55:45 -0500 (EST) Message-Id: <199712051706.MAA17582@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-SA-revised-00.txt Date: Fri, 05 Dec 1997 12:06:27 -0500 Sender: owner-ipsec@ex.tis.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 : Revised SA negotiation mode for ISAKMP/Oakley Author(s) : B. Patel, M. Jeronimo Filename : draft-ietf-ipsec-isakmp-SA-revised-00.txt Pages : 5 Date : 04-Dec-97 ISAKMP/OAKLEY [2][3] is the key management protocol defined by IPSEC working to be a framework for authentication, security association negotiation and key management. The protocol defines two phases whereby, in the phase 1, the peers are authenticates, the security association (SA) for ISAKMP/Oakley, and keying material is agreed upon by the peers to secure ISAKMP messages. The phase 2 is used to negotiate security association for security applications (e.g., IPSEC AH and ESP). When perfect forward secrecy is required, phase 2 is also used to exchange keying material for the application. However, when perfect forward secrecy is not a requirement, the keying material from the phase 1 is used to generate session keys for the secure communication applications. The proposal in this document is based on the observation that when perfect forward secrecy is not a requirement, if application specific SA was negotiated during phase 1, the application can start immediately after phase 1. The phase 2 can be used subsequently for key refresh on per need bases in the future. Therefore, this proposal reduces startup time for communication and improves the efficiency of the protocol. Remark: This document is NOT self-contained, it is intended as an addendum to [2][3]. Thus, it is best read in conjunction with [2][3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-SA-revised-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-SA-revised-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-SA-revised-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204162749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-SA-revised-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-SA-revised-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204162749.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 13:13:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01624 for ipsec-outgoing; Fri, 5 Dec 1997 13:11:46 -0500 (EST) Message-Id: <199712051822.NAA19414@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-des-expiv-01.txt Date: Fri, 05 Dec 1997 13:22:32 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Cipher Algorithm With Explicit IV Author(s) : N. Doraswamy, C. Madson Filename : draft-ietf-ipsec-ciph-des-expiv-01.txt Pages : 7 Date : 04-Dec-97 This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-des-expiv-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-des-expiv-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204165556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des-expiv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des-expiv-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204165556.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 13:53:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01992 for ipsec-outgoing; Fri, 5 Dec 1997 13:52:46 -0500 (EST) Message-Id: <199712051903.OAA20720@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-00.txt Date: Fri, 05 Dec 1997 14:03:01 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira Filename : draft-ietf-ipsec-isakmp-xauth-00.txt Pages : 6 Date : 04-Dec-97 This document describes a method for utilizing authentication mechanisms that are either unidirectional in nature or that work with the base ISAKMP authentication mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-xauth-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204175813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204175813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 13:58:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02066 for ipsec-outgoing; Fri, 5 Dec 1997 13:57:57 -0500 (EST) Message-Id: <199712051908.OAA21029@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-01.txt Date: Fri, 05 Dec 1997 14:08:54 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP CBC-Mode Cipher Algorithms Author(s) : R. Adams, R. Pereira Filename : draft-ietf-ipsec-ciph-cbc-01.txt Pages : 13 Date : 04-Dec-97 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-cbc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-cbc-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204180045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204180045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Dec 5 15:03:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02733 for ipsec-outgoing; Fri, 5 Dec 1997 15:01:47 -0500 (EST) Message-Id: <199712051941.OAA02739@ghostwheel.ncsl.nist.gov> Date: Fri, 5 Dec 1997 14:41:35 -0500 (EST) To: ipsec@tis.com Cc: rob.glenn@nist.gov From: rob.glenn@nist.gov Subject: NIST Cerberus, An IPsec Reference Implementation for Linux X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The first release of NIST Cerberus, an IPsec Reference Implementation for Linux is finished and available for distribution. This is an IPsec-only (i.e. no key management, yet) IPv4 prototype that implements the current ESP and AH protocols with a number of the currently specified algorithms. This is also the IPsec engine used in IPsec-WIT (The NIST IPsec Web Interoperability Tester - to be announced next week). To obtain the code you need to be a US Citizen, and fill out and submit the form at http://www.antd.nist.gov/cerberus/ipsec-form.html. For additonal information on the prototype or on obtaining a copy of the software go to http://www.antd.nist.gov/cerberus/ Best Regards, Rob G. rob.glenn@nist.gov (301)975-3667 From owner-ipsec Fri Dec 5 16:09:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03280 for ipsec-outgoing; Fri, 5 Dec 1997 16:07:49 -0500 (EST) Message-ID: <01BD017F.48D1B820@bix.jf.intel.com> From: "Baiju V. Patel" To: "'Theodore Y. Ts'o'" , "ipsec@tis.com" Subject: RE: IPSEC document reading party! Date: Fri, 5 Dec 1997 13:21:10 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk I would be interested in participating IPSEC document reading. I would be perticularly intereseted in reading IPSEC archiecture document which would probably take most to the two hours. If there is time, I would be interested in reading IPSEC DOI, or ISAKMP/Oakley resolution document. -----Original Message----- From: Theodore Y. Ts'o [SMTP:tytso@MIT.EDU] Sent: Thursday, December 04, 1997 7:35 PM To: ipsec@tis.com Subject: IPSEC document reading party! Hi, Bob and I are very concerned that few people are actually reading all of the IPSEC drafts, and so there may be internal inconsistency and other problems across the various drafts, that perhaps won't be discovered until after they are published as RFC's. That, as they say, would be Bad. In order to try to avoid this, we are planning an IPSEC document reading party, to be held Monday evening at the IETF meeting. The logistical details are still be being finalized, but it will probably start at either 6:00 or 7:30. (If it starts at 6:00, food will be provided.) We are looking for a people who are willing to put in a couple of hours of real work, by reading over the documents, with a particular attention towards finding consistency problems and other problems with the drafts. Please come only if you are prepared to work! Also, please bring your own copies of the documents to read. In the interests of getting work done, we're not looking for quality, not quantity, in terms of the number of people we have participating. Document editors are especially asked to come so that they will be available for questions should they arise from the readers. If you are interested in particpating, please RSVP to Bob and I. Information about the location, etc. will be announced later (probably at the IETF meeting itself; check the announcements board.) If you have any questions, please let either Bob or I know. - Ted From owner-ipsec Sun Dec 7 12:57:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16582 for ipsec-outgoing; Sun, 7 Dec 1997 12:45:50 -0500 (EST) Date: Sun, 7 Dec 1997 12:55:54 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" To: ipsec@tis.com From: Stephen Kent Subject: responses to comments in the Architecture Document Sender: owner-ipsec@ex.tis.com Precedence: bulk TimesFolks, Ted asked me to review the comments that have arrived over the last two weeks, re the IPsec Architecture Document. I apologize for not having responded to each of these as they arrived, but the Thanksgiving holidays and other job-related matters have fully occupied my time. The approach I have taken is to provide responses to comments in an integrated fashion, not on a per-commenter basis, proceeding serially through the document. Karen Seo scanned all of the messages and keyed them to the document in this fashion, in hopes of integrating related comments from various sources. However, a few comments that I've received privately were not forwarded to Karen and thus were not addressed in this response. I'll get to those soon. I'd like to extend a special thanks to Cheryl Madson who wins the prize for the greatest range and number of comments on the current draft. Steve --------------- Section 3.0 We now require any IPsec implementation to incorporate an explicit discard function, at the same (selector) granularity as any other IPsec processing. It has been noted that this may be redundant if a firewall is "behind" the IPsec implementation, prepared to effect discarding for traffic. I assume the suggested change would be to bypass any traffic for which no IPsec processing was specified, and make provision of an explicit discard function a "MAY" feature. The argument in favor of the status quo is that inclusion of this facility makes for a complete security implementation re packet filtering, whereas omission of the facility implies reliance on some other components of possibly unknown security quality. I think this is largely an issue of implementation complexity. In practice, if one has a firewall behind an IPsec device and wants the firewall to perform the discard function, then one can arrange to bypass all non IPsec traffic. I'm not sure that there is a performance penalty if discard is not turned on for any traffic, e.g., under such circumstances. We've heard one or two suggestions to remove this requirement, and a similar number to retain it, so we currently plan to make no change here. Section 4.2 It was suggested that the discussion of traffic flow confidentiality here may be misleading in that fine granularity SAs tend to allow more traffic analysis that coarse granularity ones. This is a valid point and we will reword this section to better express that notion. Section 4.3 The question was raised what sort of treatment is afforded ISAKMP packets in the context of iterated tunneling. Cheryl's example involved a host with a tunnel to a security gateway, and that tunnel was itself encapsulated in a tunnel between two security gateways. We did not anticipate any special treatment for ISAKMP traffic at intermediate security gateways, other than what can be specified through appropriate SPD entries. A coarse granularity tunnel between two security gateways would have no trouble carrying ISAKMP traffic along with all other traffic. If multiple, fine-grained tunnels are constructed, then one might have to make explicit provision for ISAKMP traffic, depending on the sets of selectors employed. Section 4.4.1 The discussion of the requirement for ordering of SPD entries arises here, on page 14. There has been some question about whether the SPD entries need to be ordered. The motivation for ordering arises from several concerns. First, it seem critical that an administrator be able to express his security policy, not constrained by any artifacts. Second, the results of applying the policy must be consistent, not affected such things as the order in which traffic arrives, so that the effects of the policy are predictable. Third, we support a variety of selectors, several of which allow for wildcarding. Given this set of selectors, it didn't seem possible to specify a useful, canonical ordering that would free an administrator from the need to explicitly order entries. In fact, the previous version of the document tried to optimize the lookup process and in doing so it violated the second goal, as Ly Loi (3COM) pointed out to me in a series of private messages. So, the ordering requirement is a response to these goals/constraints. If the WG changes these goals or any of the constraints, we could revisit this derived requirement for SPD entry ordering. --- In this section on page 14, the following text appears: "For each selector, the policy entry specifies which of the following values should be used in the SA: (a) the value in the packet, (b) the value associated with the policy, or (c) a wildcard." Someone expressed confusion about case (a). On further reading, I agree that this is confusing and we'll clarify this and add better examples in the paragraphs that follow, onto the top of page 15. In fact, I no longer recall why we call out the last two cases separately. What I think this is referring to is the issue of how a SAD entry is constructed from the SPD. In case (a), the SAD has an entry with values taken from the packet as it was looked up in the SPD. In case (b), the value from the SAD is used, and in case (c), that value is a wildcard. This is an important feature because it allows an administrator to distinguish between a wildcard selector that is intended to create exactly one SA for all traffic matching that selector, vs. a wildcard selector that is intended to be shorthand for creating one SA for EACH different traffic stream that matches the selector. Also in this page, immediately below the text above, is a discussion of how SA bundles may be shared, and why case (c) is important to that. The notion of an SA bundle was introduced in the architecture document back in the July draft, after some discussion on the WG list earlier in the year. The goal is to allow reuse of an SA when there is SA nesting. People have express concern over possible creation of unnecessary SAs because of nesting and this is the proposed approach to dealing with that potential problem. We mention that motivation near the bottom of page 15 When we had the SAM as an intermediate database, bundles were easy to manage. Now, without the SAM (which created problems alluded to earlier), the management of bundles is getting harder, but we have assumed that folks still want them as a means of avoiding redundant SA creation. (See the discussion of inbound processing in section 5.2.1, for example.) Charlie Lynn has done most of the analysis on this topic, so I'll point you to Charlie for good examples. maybe we have to change terminology if there is a conflict with the use of this term in the IPsec DOI document. Finally, at the end of this section, someone raised the issue mentioned in 4.3, i.e., what about ISAKMP traffic traversing a security gateway that normally does not allow transit traffic to be encrypted. The answer is that the SPD must have a suitable entry to allow such traversal, if the administrator want to permit IPsec connections from systems "behind" the security gateway. We can look at rewording this last paragraph to better convey that notion, i.e., that the SPD is used to control the flow of ALL traffic through an IPsec system, including ISAKMP traffic from entities behind a security gateway. Section 4.4.2 This is the section that has the most items that need revision, based on comment to date. There are mismatches between the ISAKMP documents, e.g., the DOI, and what is called for here. We noted these discrepancies back in Munich, but unfortunately none of the authors of the relevant documents managed to get together since then to resolve these problems. As Cheryl Madson points out, the big mismatch here is in terms of what can be negotiated for an SA, vs. what one might use in the SPD. However, the general model of the SPD does allow for 1-1 maps to SAs, in which case this distinction becomes moot and the problem is with us again. If the WG wants to move ahead as quickly as possible, and not require DOI (and implementation) changes, then we'll just have to remove these selector requirements for SAs and defer them to IPsecond. Specifically, Cheryl notes that the DOI does not support value ranges for any selector value other than IP addresses. So, we'll have to remove this facility from the rest of the selectors. Also, enumerated lists of values are not supported at all, and so these too need to be removed as selector values. Cheryl also notes that TOS is not supported in the DOI, and I wonder if IPv6 Class and Flow Label are included? These can be removed entirely if the goal is to get the spec out the door, as I suspect that few folks will miss these last three selector types (at least for a while). Cheryl also asked why we had separated out IPsec protocol type vs. Transport Protocol, a change from the July version. Let me see if I can recall the rationale here. Imagine a security gateway that examines an inbound packet and determines that it appears to have had AH applied to it. It might also examine the next protocol field inside the AH header and make use of it in the access control decision. Here too, Charlie is probably a better source for examples. Cheryl also noted her belief that negative entries would be important as selectors. We do have that facility implicit in the SPD, in that DISCARD is a processing option for traffic. Other folks have pointed out that the current definition of SPD entry types omits an important class of selector, i.e., names. The obvious case where this is necessary is when a mobile user is dynamically assigned an address and thus no static IP address entry in the SPD can be appropriate for this type of user. If the user has a certificate with a name in it, e.g., a DNS name, then he (his computer) can be authenticated during SA establishment and we should be able to make use of an appropriate SPD entry to accommodate such users. This scenario is a bit trickier in that lookups for outbound traffic must be matched against this dynamic address, instead of the DNS name, at least if the SA terminates as a security gateway. Another motivation for using names (vs. IP addresses) was suggested, i.e., ease of management for larger communities. Here too, use of DNS names, with wildcarding, could ease the management burden. However, we have to be careful to not become dependent on DNS names here unless we are using authenticated names, .e.g., in conjunction with the secure DNS technology. Also, security gateways will usually not have access to the names (vs. IP addresses) associated with traffic traversing them. So, unless we have secure inverse DNS lookups available, use of names in SPD entries poses problems in this context. So, I propose that we add (DNS?) names as another selector type for use in the SPD. Should this be a mandatory selector, like the others, and if so, is it mandatory for both hosts and security gateways? Section 4.5 Cheryl notes that nested SAs of the sort described here may require multiple ISAKMP negotiations, though she didn't see that as a show stopper. However, we should make sure that the results of multiple negotiations can be linked in a consistent fashion, to support the checks called for in Section 5.2. Section 5 We'll change the wording of section titles here to reflect the fact that all traffic is subjected to this processing, whether it's IPsec traffic or not. Section 5.1 The question is raised as to what is the default processing if no matching rule is found in the SPD. Good point. The safe default is to discard the traffic, and this applies to both inbound and outbound traffic. We'll make that explicit and maybe more it to the beginning of section 5. Section 5.2 In response to a suggestion that we make explicit mention of the need to consult the SPD for inbound, non-IPsec traffic, we'll make it clear that inbound processing check apply to all traffic, not just IPsec, and note this at the beginning of Section 5. Section 5.2.1 Cheryl reiterated the importance of checking that all the prescribed IPsec headers are applied to a received packet and that they were applied in order, which is consistent with the text. Our only residual concern is the ability of ISAKMP and the IPsec DOI to specify the ordering constraints. We need someone to verify this. Another commenter asked if post-IPsec processing could include forwarding and additional IPsec processing. In the case of a security gateway, that could happen, e.g., if the gateway supports concatenated SAs for linking to internal IPsec-capable hosts. We currently do not require such support, but it could be an optional feature. Section 6. Cheryl asked what set of ICMP messages were being addressed here, e.g., error messages vs. Echo/Reply messages. The latter, if IPsec protected, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion. So, yes, the focus of this section is on error messages and we will revise the text to reflect that distinction. Cheryl's next question was why router-generated, IPsec-protected ICMP (error) messages were not subjected to source address checks. Well, if the message comes directly from that router, the address check would be appropriate. However, if the router is forwarding an ICMP message from another router, the check would fail. This gets to a point raised by Mike Richardson, and reiterated by Cheryl, i.e., should a security gateway that receives a PMTU message not directed to it forward that message in an IPsec tunnel. The concern is that such forwarding lends the imprimatur of the IPsec-capable gateway to this message. So, the resolution to this issue depends in large part on the answer to this latter question. We could make the checking a local policy matter and merely warn folks of the problem for now, in an effort to reach closure on this. Another issue raised here is that of the authenticity of the returned IP header in an ICMP error message. Even if the source is authenticated, we can't be certain that the returned traffic is valid. It was suggested that additional checks be added, e.g., ensure that the returned header info is consistent with the SA over which an authenticated ICMP is received. We can add text to that effect, and we will add a warning about the residual vulnerabilities associated with processing ICMP error messages in general. Section 6.1.2.1 Cheryl raised the question of why propagation of the PMTU by the security gateway was a MUST, as it seems beyond what would normally be required for a router implementing a tunnel. I don't recall whether this is required by RFC 1191, but the motivation here is to ensure that the host learns, as quickly as possible, that there is an MTU problem downstream, so that the host can respond appropriately. Is there a strong desire to have this be a SHOULD vs. a MUST? if so, we can change the requirement level. Section 6.1.2.2 The question was raised as to how a socket-based, host IPsec implementation should deal with a PMTU message, given that the socket interface would already be cognizant of the space devoted to local use of IPsec (on the socket in question). The answer is that the notification provided by IPsec to the upper layers (in response to receipt of an ICMP PMTU) ought to be consistent with whatever IPsec overhead is being applied and with the MTU size reelected to the upper layers. (Whew, that's a mouthful.) Section 6.1.2.4 Cheryl's comment here was really a question for the list, i.e., should we be following the RFC 1191 vs. 2003 behavior re forwarding of a too big packet. She observed that the WG list didn't seem to come to closure on that. However, her comment makes we want to check to see why we're citing 1191 vs. 2003 here. We'll look into that and get back with a response, but I think the WG chairs have to weigh in on this too. Section 8 I'll chime in here. Dan MacDonald worked with several other folks to provide this section which would otherwise have been deferred to IPsecond. The intro to this section still needs some work, as the goal is that these requirements are applicable to a wider range of systems than those characterized as "MLS." So, expect a few changes here as well. References Cheryl noted that we seem to have a lot of them, many out of date. We'll clean up this list, paring it down substantially, getting rid of historically interesting but not currently relevant citations. From owner-ipsec Tue Dec 9 13:32:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04511 for ipsec-outgoing; Tue, 9 Dec 1997 13:18:26 -0500 (EST) Message-Id: <199712091824.NAA03610@smb.research.att.com> From: Steve Bellovin To: ipsec@tis.com Subject: IV generation Date: Tue, 09 Dec 1997 13:24:05 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk There's an attack I've heard about that's worth mentioning. The current relevant drafts (draft-ietf-ipsec-ciph-des-expiv-01.txt and draft-ietf-ipsec-ciph-cbc-01.txt) suggest the proper behavior, but don't describe the attack, and don't bar the dangerous behavior. It would be useful to describe the attack, if for no other reason than to warn other implementors. The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because as I demonstrated in a paper last February, many blocks of actual plaintext don't change very much from packet to packet, either. For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks. So -- I suggest that the following text be added to the two documents cited above: To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. (I don't like the same text being in two different documents, but both of these are on CBC encryption. Arguably, those shouldn't have been different documents, but I *don't* want to merge them now... Neither the architecture document nor the ESP document discuss IV selection, so it can't go in them.) From owner-ipsec Fri Dec 12 23:08:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03454 for ipsec-outgoing; Fri, 12 Dec 1997 22:58:03 -0500 (EST) Date: Fri, 12 Dec 1997 23:20:10 -0500 From: canetti@watson.ibm.com (Ran Canetti) Message-Id: <9712130420.AA23502@ornavella.watson.ibm.com> To: rpereira@TimeStep.com Subject: Extended authentication with ISAKMP/Oakley draft Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Roy, Reading the new extended authentication within ISAKMP/Oakley draft (draft-ietf-ipsec-isakmp-xauth-00.txt), I have the following problem. Why do the extra Secure-ID authentication as part of the ISAKMP/Oakley key exchange? It seems easier to do the Secure-ID authentication (that is, the NOTIFY messages) *after* the ISAKMP oakley exchange is completed. The NOTIFY messages can be then transmitted securely using, say, ESP. This is a more modular design. In particular: * You can use *any* ISAKMP/Oakley mode. * There is no need to modify/add new modes to ISAKMP/Oakley * This way, the NOTIFY messages can be simplified considerably, since now they get their authentication from ESP. But this is a concern of the Secure_ID/RADIUS guys. True, the cost of this modularity is another 1.5 round trips. But this may be well worth it. (In ISAKMP we pay much more for modularity and good uniform design.) Ran Canetti From owner-ipsec Sat Dec 13 08:16:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06242 for ipsec-outgoing; Sat, 13 Dec 1997 08:14:05 -0500 (EST) Date: Fri, 12 Dec 1997 18:21:01 -0300 From: Gordon Oliver Subject: Re: IPSEC document reading party! To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Message-Id: X-Mailer: TkMail 4.0beta9 In-Reply-To: <199712050315.WAA05539@dcl.MIT.EDU> Sender: owner-ipsec@ex.tis.com Precedence: bulk ... Theodore Y. Ts'o said ... > Bob and I are very concerned that few people are actually >reading all of the IPSEC drafts, and so there may be internal >inconsistency and other problems across the various drafts, that perhaps >won't be discovered until after they are published as RFC's. That, as >they say, would be Bad. some comments on the documents and consistencies. - in the DOI document there is a reference to using ESP with a NULL encryption routine in order to do tunnelling. At least for AH it specifies that this should never happen in a real system (and probably should not for ESP either). - I am extremely uncomfortable with the idea that the Security Architecture document suggests that the entire database must be searched for matching SA's. This seems to make it impossible to specify policies s.t. each connection gets a private SA (or similar types of policies). It also makes the implementation slower and more painful. - There is very little said about ICMP handling, perhaps there should be something said about echoing confidential (i.e. ESP) data in an ICMP packet that does not have ESP. - There is nothing much said about what kinds of policies are allowed, and the associations between policies and bundles. -gordo -- --------------------------------------------------------------- Gordon Oliver (gordo@telsur.cl) Independent Consultant ... Available for consulting on Linux ... From owner-ipsec Sat Dec 13 10:39:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07093 for ipsec-outgoing; Sat, 13 Dec 1997 10:38:05 -0500 (EST) From: John Ioannidis Date: Sat, 13 Dec 1997 10:44:43 -0500 (EST) Message-Id: <199712131544.KAA00118@bual.research.att.com> To: gordo@telsur.cl, tytso@MIT.EDU Cc: ipsec@tis.com Subject: Re: IPSEC document reading party! Sender: owner-ipsec@ex.tis.com Precedence: bulk > - in the DOI document there is a reference to using ESP with a NULL He's right. If a policy calls for tunneling, the mechanisms should be IP-in-IP encapsulation, plain and simple. In other words, it's not that ESP should be used with no encryption; it's that ESP should not be used at all! /ji From owner-ipsec Sat Dec 13 11:16:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07381 for ipsec-outgoing; Sat, 13 Dec 1997 11:16:05 -0500 (EST) Message-ID: From: Roy Pereira To: "'canetti@watson.ibm.com'" Cc: "'ipsec@tis.com'" Subject: RE: Extended authentication with ISAKMP/Oakley draft Date: Sat, 13 Dec 1997 11:26:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The main reason that this proposal is presented this way is because SecureID/RADIUS/TACACS+/AXENT are just methods of authentication and thus they should be placed where other methods of authentication are now. Mainly in the authentication exchange of ISAKMP (phase I). Your suggestion of performing the extra authentication after ISAKMP has created both a ISAKMP SA and an ESP SA, in my view, defeats the purpose of authentication. In the proposal, if SecureID authentication fails, then no ISAKMP SA is created and we do not move on to phase II (to build an ESP SA). >Reading the new extended authentication within ISAKMP/Oakley draft >(draft-ietf-ipsec-isakmp-xauth-00.txt), I have the following problem. >Why do the extra Secure-ID authentication as part of the ISAKMP/Oakley >key exchange? It seems easier to do the Secure-ID authentication >(that is, the NOTIFY messages) *after* the ISAKMP oakley exchange is >completed. The NOTIFY messages can be then transmitted securely using, >say, ESP. This is a more modular design. In particular: > >* You can use *any* ISAKMP/Oakley mode. > The only reason that MainMode was chosen was because it encrypts the authentication exchange. If you don't mind sending user names and passcodes in the clear, then you may use Aggressive Mode. But I don't think people should do that. > >* There is no need to modify/add new modes to ISAKMP/Oakley > No new modes are being added to ISAKMP. This is an extention to Main Mode. > >* This way, the NOTIFY messages can be simplified considerably, >since now they get their authentication from ESP. But this is a concern >of the Secure_ID/RADIUS guys. > The notify messages in the proposal are already simplified and they use ISAKMP NOTIFY payloads. Thus we do not have to build yet another protocol. It is very clean. >True, the cost of this modularity is another 1.5 round trips. But this may >be well worth it. (In ISAKMP we pay much more for modularity and good >uniform design.) > > >Ran Canetti > From owner-ipsec Sat Dec 13 13:52:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08374 for ipsec-outgoing; Sat, 13 Dec 1997 13:50:05 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Sat, 13 Dec 1997 12:48:34 -0600 Message-ID: <492EBB80.3000@usr.com> To: gordo@telsur.cl, tytso@MIT.EDU, John Ioannidis Cc: ipsec@tis.com Subject: Re[2]: IPSEC document reading party! Content-Type: multipart/mixed; boundary="IMA.Boundary.238340288" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.238340288 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part ESP tunneling without encryption cannot be substituted with IP-in-IP tunneling. It provides authentication and integrity services to the encapsulated packet. Note that this is different from AH which will cover the outer IP headers and options also. Sumit A. Vakil 3Com, Corp. ______________________________ Reply Separator _________________________________ Subject: Re: IPSEC document reading party! Author: John Ioannidis at Internet Date: 12/13/97 10:44 AM > - in the DOI document there is a reference to using ESP with a NULL He's right. If a policy calls for tunneling, the mechanisms should be IP-in-IP encapsulation, plain and simple. In other words, it's not that ESP should be used with no encryption; it's that ESP should not be used at all! /ji --IMA.Boundary.238340288 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 492D8B80; Sat, 13 Dec 97 12:49:28 -0600 Received: from portal.ex.tis.com by usr.com (8.8.5/3.1.090690-US Robotics) id LAA28864; Sat, 13 Dec 1997 11:23:48 -0600 (CST) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07093 for ipsec-outgoing; Sat, 13 Dec 1997 10:38:05 -0500 (EST) From: John Ioannidis Date: Sat, 13 Dec 1997 10:44:43 -0500 (EST) Message-Id: <199712131544.KAA00118@bual.research.att.com> To: gordo@telsur.cl, tytso@MIT.EDU Cc: ipsec@tis.com Subject: Re: IPSEC document reading party! Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.238340288-- From owner-ipsec Sat Dec 13 14:07:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08515 for ipsec-outgoing; Sat, 13 Dec 1997 14:07:05 -0500 (EST) Message-ID: From: Roy Pereira To: "'svakil@usr.com'" , "'gordo@telsur.cl'" , "'tytso@MIT.EDU'" , "'John Ioannidis'" Cc: "'ipsec@tis.com'" Subject: RE: Re[2]: IPSEC document reading party! Date: Sat, 13 Dec 1997 14:17:16 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk What John was trying to say, I think, is that tunneled ESP without encryption and _integrity_ would be better served by just using IP-in-IP. >-----Original Message----- >From: svakil@usr.com [SMTP:svakil@usr.com] >Sent: Saturday, December 13, 1997 1:49 PM >To: gordo@telsur.cl; tytso@MIT.EDU; John Ioannidis >Cc: ipsec@tis.com >Subject: Re[2]: IPSEC document reading party! > > ESP tunneling without encryption cannot be substituted with IP-in-IP > tunneling. It provides authentication and integrity services to the > encapsulated packet. Note that this is different from AH which will > cover the outer IP headers and options also. > > > Sumit A. Vakil > 3Com, Corp. > > >______________________________ Reply Separator >_________________________________ >Subject: Re: IPSEC document reading party! >Author: John Ioannidis at Internet >Date: 12/13/97 10:44 AM > > >> - in the DOI document there is a reference to using ESP with a NULL > >He's right. If a policy calls for tunneling, the mechanisms should be >IP-in-IP encapsulation, plain and simple. In other words, it's not that >ESP should be used with no encryption; it's that ESP should not be used at >all! > >/ji << File: RFC822 message headers.txt >> From owner-ipsec Sat Dec 13 19:14:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10121 for ipsec-outgoing; Sat, 13 Dec 1997 19:13:06 -0500 (EST) Message-Id: <199712140023.TAA21523@relay.hq.tis.com> To: Roy Pereira cc: "'svakil@usr.com'" , "'gordo@telsur.cl'" , "'tytso@MIT.EDU'" , "'John Ioannidis'" , "'ipsec@tis.com'" Subject: Re: Re[2]: IPSEC document reading party! In-reply-to: Your message of "Sat, 13 Dec 1997 14:17:16 EST." Date: Sat, 13 Dec 1997 16:23:03 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >What John was trying to say, I think, is that tunneled ESP without >encryption and _integrity_ would be better served by just using >IP-in-IP. I'd agree with that. But that wasn't clear from John's message. I'll add a statement to this regard in the next rev of the DOI. Derrell >-----Original Message----- >From: svakil@usr.com [SMTP:svakil@usr.com] >Sent: Saturday, December 13, 1997 1:49 PM >To: gordo@telsur.cl; tytso@MIT.EDU; John Ioannidis >Cc: ipsec@tis.com >Subject: Re[2]: IPSEC document reading party! > > ESP tunneling without encryption cannot be substituted with IP-in-IP > tunneling. It provides authentication and integrity services to the > encapsulated packet. Note that this is different from AH which will From owner-ipsec Sun Dec 14 05:57:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA13113 for ipsec-outgoing; Sun, 14 Dec 1997 05:51:05 -0500 (EST) Date: Sun, 14 Dec 1997 12:59:31 +0200 (IST) From: Hugo Krawczyk Message-Id: <199712141059.MAA25688@ee.technion.ac.il> To: rpereira@TimeStep.com Subject: RE: Extended authentication with ISAKMP/Oakley draft Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, I haven't read your draft (yet). I agree with placing the SecureID and alike mechanisms together with the Phase1 authentication. Just one comment on your remark about using aggressive mode: > The only reason that MainMode was chosen was because it encrypts the > authentication exchange. If you don't mind sending user names and > passcodes in the clear, then you may use Aggressive Mode. But I don't > think people should do that. Notice that one advantage of the public key encryption mode of authentication is that it allows to encrypt the above information also in Aggressive Mode. Hugo From owner-ipsec Sun Dec 14 10:01:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA14250 for ipsec-outgoing; Sun, 14 Dec 1997 09:58:05 -0500 (EST) Date: Sun, 14 Dec 1997 10:20:05 -0500 From: canetti@watson.ibm.com (Ran Canetti) Message-Id: <9712141520.AA22756@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, rpereira@TimeStep.com Subject: RE: Extended authentication with ISAKMP/Oakley draft Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, When I said "adding new modes for ISAKMP/Oakley" I meant adding new methods for carrying out phase 1 (on top of signature, encryption, etc). My point was that there is no necessity in modifying anything to the ISAKMP/Oakley exchange itself. You can do the extra authentication messages after the exchange is done (and just drop the connection if things go wrong). But I see that there is value in piggybacking the NOTIFY messages on the phase 1 messages. So I do not object to that. In any case, the current draft only describes how to do the piggibacking with the signature mode of phase 1. One should also specify how to do the piggibacking with the other modes of phase 1 (encryption, revised encryption, pre-shared key.) In fact, perhaps one can describe a general method of piggybacking and say that it applies to all modes. Ran > The main reason that this proposal is presented this way is because > SecureID/RADIUS/TACACS+/AXENT are just methods of authentication and > thus they should be placed where other methods of authentication are > now. Mainly in the authentication exchange of ISAKMP (phase I). > > Your suggestion of performing the extra authentication after ISAKMP has > created both a ISAKMP SA and an ESP SA, in my view, defeats the purpose > of authentication. In the proposal, if SecureID authentication fails, > then no ISAKMP SA is created and we do not move on to phase II (to build > an ESP SA). > > >Reading the new extended authentication within ISAKMP/Oakley draft > >(draft-ietf-ipsec-isakmp-xauth-00.txt), I have the following problem. > >Why do the extra Secure-ID authentication as part of the ISAKMP/Oakley > >key exchange? It seems easier to do the Secure-ID authentication > >(that is, the NOTIFY messages) *after* the ISAKMP oakley exchange is > >completed. The NOTIFY messages can be then transmitted securely using, > >say, ESP. This is a more modular design. In particular: > > > >* You can use *any* ISAKMP/Oakley mode. > > > The only reason that MainMode was chosen was because it encrypts the > authentication exchange. If you don't mind sending user names and > passcodes in the clear, then you may use Aggressive Mode. But I don't > think people should do that. > > > >* There is no need to modify/add new modes to ISAKMP/Oakley > > > No new modes are being added to ISAKMP. This is an extention to Main > Mode. > > > >* This way, the NOTIFY messages can be simplified considerably, > >since now they get their authentication from ESP. But this is a concern > >of the Secure_ID/RADIUS guys. > > > The notify messages in the proposal are already simplified and they use > ISAKMP NOTIFY payloads. Thus we do not have to build yet another > protocol. It is very clean. > > >True, the cost of this modularity is another 1.5 round trips. But this may > >be well worth it. (In ISAKMP we pay much more for modularity and good > >uniform design.) > > > > > >Ran Canetti > > > From owner-ipsec Sun Dec 14 11:53:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14836 for ipsec-outgoing; Sun, 14 Dec 1997 11:52:05 -0500 (EST) Message-Id: <199712141714.MAA03883@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Extended authentication with ISAKMP/Oakley draft In-reply-to: Your message of "Sun, 14 Dec 1997 10:20:05 EST." <9712141520.AA22756@ornavella.watson.ibm.com> Date: Sun, 14 Dec 1997 12:14:17 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ran" == Ran Canetti writes: Ran> Roy, Ran> When I said "adding new modes for ISAKMP/Oakley" I meant adding new Ran> methods for carrying out phase 1 (on top of signature, encryption, etc). There was some informal discussion about whether to perform the undirectional user->server authentication during phase I or phase II. Many OTP's may require *multiple* traversals to properly authenticate. SecurID in NextPIN mode is one good example. X9.9/radius has less clear requirements. They also benefit greatly from having their communication channel encrypted, which the ISAKMP SA inherently provides. Marcus also mentioned that doing the user->server authentication afterward maps very nicely to the STS-III protocol, which has been extensively analysed. Marcus also pointed out that in many environments issuing certificates to users' is still too difficult, but that issuing certificates to gateways wasn't difficult. This motivates doing token based authentication even when the client software can handle certificates. I was thinking that the authentication should go in phase I as well. :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNJQT56ZpLyXYhL+BAQFRigL+NAiTKmBUGA6lUl1rGXLfQkNO0HybKSZP RKI5HvFxrnQT5KzQcJ66Y785IEzIDBqm9ySqi7wyp4BmlU751jXw9VA0hdcpnOcf rKWrwqn3CWaLcWahv1yGLniTcaNeM1kt =HHxH -----END PGP SIGNATURE----- From owner-ipsec Sun Dec 14 12:32:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15016 for ipsec-outgoing; Sun, 14 Dec 1997 12:32:05 -0500 (EST) Message-Id: <199712141738.MAA18118@postal.research.att.com> To: ipsec@tis.com Subject: Re: Extended authentication with ISAKMP/Oakley draft Date: Sun, 14 Dec 1997 12:38:23 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Let's all agree on one thing, though -- barring a *major* flaw in the protocol, we are *not* changing ISAKMP/Oakley at this point. If you have new variants that don't change the basic protocol, they should be written up in new RFCs. From owner-ipsec Sun Dec 14 12:49:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15071 for ipsec-outgoing; Sun, 14 Dec 1997 12:49:04 -0500 (EST) Message-Id: <199712141810.NAA04060@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: IPSECond: Re: Extended authentication with ISAKMP/Oakley draft ) In-reply-to: Your message of "Sun, 14 Dec 1997 12:38:23 EST." <199712141738.MAA18118@postal.research.att.com> Date: Sun, 14 Dec 1997 13:10:51 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Steven" == Steven Bellovin writes: Steven> Let's all agree on one thing, though -- barring a *major* flaw in Steven> the protocol, we are *not* changing ISAKMP/Oakley at this point. Steven> If you have new variants that don't change the basic protocol, Steven> they should be written up in new RFCs. Agreed. That doesn't prevent us from discussing different ways of doing things, nor does it prevent us from getting some private operational experience with extensions. I'd like to propose that any discussion about things to occur after proposed standard stage be prefixed life I've done above. :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNJQhKqZpLyXYhL+BAQE9xQMAtZqrVgl0y69E3uqRm/a3dSE1EHpKXkCE Sh3/74hV92Y2Aq223UWPVbwbg1kdI5EuyABJwuz6d5P0W72/PO2BL6wDci0bphzG FBQrsQSiuXdMUY3+yIKHRQeF1Z3jFRdZ =AvkP -----END PGP SIGNATURE----- From owner-ipsec Sun Dec 14 13:32:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15331 for ipsec-outgoing; Sun, 14 Dec 1997 13:31:06 -0500 (EST) Message-ID: From: Roy Pereira To: "'canetti@watson.ibm.com'" Cc: "'ipsec@tis.com'" Subject: RE: Extended authentication with ISAKMP/Oakley draft Date: Sun, 14 Dec 1997 13:42:26 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, actually the draft presents Main Mode as an example only. The draft describes a template method that can be applied to any mode at any exchange. The draft does go on to say what exchanges and modes that MUST NOT be used for various reasons. And the draft does allow for any type of ISAKMP phase I authentication (shared-secret, RSA-sig, RSA-enc, DSS, RSA-new-enc). >In any case, the current draft only describes how to do the piggibacking >with the signature mode of phase 1. One should also specify how to do >the piggibacking with the other modes of phase 1 (encryption, >revised encryption, pre-shared key.) In fact, perhaps one can describe >a general method of piggybacking and say that it applies to all modes. > > From owner-ipsec Sun Dec 14 13:36:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15363 for ipsec-outgoing; Sun, 14 Dec 1997 13:36:05 -0500 (EST) Message-ID: From: Roy Pereira To: "'Steven Bellovin'" , "'ipsec@tis.com'" Subject: RE: Extended authentication with ISAKMP/Oakley draft Date: Sun, 14 Dec 1997 13:46:06 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Yikes, no we are not changing ISAKMP/Oakley. This 'variant' as you called it is in a completely new draft that is suppose to be for IPSecond. >-----Original Message----- >From: Steven Bellovin [SMTP:smb@research.att.com] >Sent: Sunday, December 14, 1997 12:38 PM >To: ipsec@tis.com >Subject: Re: Extended authentication with ISAKMP/Oakley draft > >Let's all agree on one thing, though -- barring a *major* flaw in >the protocol, we are *not* changing ISAKMP/Oakley at this point. If >you have new variants that don't change the basic protocol, they should >be written up in new RFCs. From owner-ipsec Mon Dec 15 11:32:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22880 for ipsec-outgoing; Mon, 15 Dec 1997 11:23:09 -0500 (EST) Message-Id: <3.0.3.32.19971215112949.00b2a4d0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 15 Dec 1997 11:29:49 -0500 To: Steven Bellovin , ipsec@tis.com From: Robert Moskowitz Subject: Re: Extended authentication with ISAKMP/Oakley draft In-Reply-To: <199712141738.MAA18118@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:38 PM 12/14/97 -0500, Steven Bellovin wrote: >Let's all agree on one thing, though -- barring a *major* flaw in >the protocol, we are *not* changing ISAKMP/Oakley at this point. If >you have new variants that don't change the basic protocol, they should >be written up in new RFCs. > This is all discussion on the next round for IPsec. They will not get into the current stuff... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Mon Dec 15 12:16:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23167 for ipsec-outgoing; Mon, 15 Dec 1997 12:14:12 -0500 (EST) Date: Mon, 15 Dec 1997 12:24:22 -0500 (EST) Message-Id: <199712151724.MAA16395@carp.morningstar.com> From: Ben Rogers To: "Derrell D. Piper" Cc: Roy Pereira , "'svakil@usr.com'" , "'gordo@telsur.cl'" , "'tytso@MIT.EDU'" , "'John Ioannidis'" , "'ipsec@tis.com'" Subject: Re: Re[2]: IPSEC document reading party! In-Reply-To: <199712140023.TAA21523@relay.hq.tis.com> References: <199712140023.TAA21523@relay.hq.tis.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper writes: > >What John was trying to say, I think, is that tunneled ESP without > >encryption and _integrity_ would be better served by just using > >IP-in-IP. > > I'd agree with that. But that wasn't clear from John's message. I'll add a > statement to this regard in the next rev of the DOI. I'm not certain that this makes much sense. If we negotiate ESP, then I would expect packets to contain a true ESP payload. If we want to be able to negotiate a simple IP-in-IP tunnel, then there should be another mechanism for doing so. However, I'd claim that this does not belong in ISAKMP, because there would be an ambiguity in how to manage the SA's (from the IPsec perspective), and ISAKMP never seems to have been intended to be used as a tunnel management protocol. If someone wants to negotiate an IP-in-IP tunnel, they should find another method for doing so. I think that the DOI already makes ISAKMP look too much like a tunnel management protocol, making it difficult to use for pure SA and Key Management. If we had more time, I would suggest jettisoning all tunnel management to another protocol, which cooperated with ISAKMP to negotiate the tunnel-policy/tunnel-parameters pair. Please do not make this change. ben > > Derrell > > >-----Original Message----- > >From: svakil@usr.com [SMTP:svakil@usr.com] > >Sent: Saturday, December 13, 1997 1:49 PM > >To: gordo@telsur.cl; tytso@MIT.EDU; John Ioannidis > >Cc: ipsec@tis.com > >Subject: Re[2]: IPSEC document reading party! > > > > ESP tunneling without encryption cannot be substituted with IP-in-IP > > tunneling. It provides authentication and integrity services to the > > encapsulated packet. Note that this is different from AH which will From owner-ipsec Mon Dec 15 12:29:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23251 for ipsec-outgoing; Mon, 15 Dec 1997 12:27:12 -0500 (EST) Message-Id: <199712151740.MAA20299@relay.rv.tis.com> To: ben@Ascend.COM (Ben Rogers) cc: Roy Pereira , "'svakil@usr.com'" , "'gordo@telsur.cl'" , "'tytso@MIT.EDU'" , "'John Ioannidis'" , "'ipsec@tis.com'" Subject: Re: Re[2]: IPSEC document reading party! In-reply-to: Your message of "Mon, 15 Dec 1997 12:24:22 EST." <199712151724.MAA16395@carp.morningstar.com> Date: Mon, 15 Dec 1997 09:37:11 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, The change I was going to make was to add a restriction that ESP_NULL not be used without integrity. Are you opposed to that? Derrell From owner-ipsec Mon Dec 15 12:31:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23268 for ipsec-outgoing; Mon, 15 Dec 1997 12:30:14 -0500 (EST) Date: Mon, 15 Dec 1997 12:40:45 -0500 (EST) Message-Id: <199712151740.MAA16421@carp.morningstar.com> From: Ben Rogers To: "Derrell D. Piper" Cc: ben@Ascend.COM (Ben Rogers), Roy Pereira , "'svakil@usr.com'" , "'gordo@telsur.cl'" , "'tytso@MIT.EDU'" , "'John Ioannidis'" , "'ipsec@tis.com'" Subject: Re: Re[2]: IPSEC document reading party! In-Reply-To: <199712151737.JAA25428@drawbridge.ascend.com> References: <199712151724.MAA16395@carp.morningstar.com> <199712151737.JAA25428@drawbridge.ascend.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper writes: > Ben, > > The change I was going to make was to add a restriction that ESP_NULL not > be used without integrity. Are you opposed to that? > > Derrell oops. Now that I understand what you were really wanting to do, I have no problems... :) ben From owner-ipsec Mon Dec 15 13:35:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23795 for ipsec-outgoing; Mon, 15 Dec 1997 13:34:12 -0500 (EST) From: Dan McDonald Message-Id: <199712151845.KAA25825@kebe.eng.sun.com> Subject: IPv6 questions at the document ready party... To: ipsec@tis.com, ipng@sunroof.eng.Sun.COM Date: Mon, 15 Dec 1997 10:45:07 -0800 (PST) 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@ex.tis.com Precedence: bulk This note is primarily for the IPsec list, but I'm sending it to IPng as well. Two questions/issues that came up during the part of the document reading party in Washington were: 1.) The fragment header in reassembled packets and its impact on AH? People were concerned (I think) that after packet reassembly, an IPv6 datagram _might_ be delivered to AH looking like: IP + + AH + An IPv6 implementation MUST NOT deliver such a datagram to a higher-level-protocol, including other IPv6 option types. Once reassembly is performed, the fragment header is stripped out. Lemme quote the relevant section from RFC 1883... > At the destination, fragment packets are reassembled into their > original, unfragmented form, as illustrated: > > reassembled original packet: > > +------------------+----------------------//------------------------+ > | Unfragmentable | Fragmentable | > | Part | Part | > +------------------+----------------------//------------------------+ Note the consipicuous absence of a fragment header. :) 2.) What protocol number for inner-payload == IPv6? The answer is 41 (IPv6-in-IP??), not 4(IP-in-IP), but 41. Hope this helps. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Tue Dec 16 07:45:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00127 for ipsec-outgoing; Tue, 16 Dec 1997 07:36:22 -0500 (EST) Message-Id: <199712161248.HAA00805@ghostwheel.ncsl.nist.gov> Date: Tue, 16 Dec 1997 07:48:46 -0500 (EST) To: ipsec@tis.com Cc: rob.glenn@nist.gov From: rob.glenn@nist.gov Subject: NIST IPsec-WIT (Web-based Interoperability Tester) on-line X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The NIST IPsec-WIT (Web-based Interoperability Tester) is on-line and ready for use. IPsec-WIT is an interoperability test system built around the NIST Cerberus IPsec reference implementation and commonly available WWW technology. IPsec-WIT allows its users to remotely control and execute series of interoperability tests with the Cerberus prototype. Test case selection, configuration, execution and results analysis are all controlled remotely by WWW browser. IPsec-WIT is currently operational for IPv4 IPsec protocols (with over 60 test cases) and will soon support IPv6 as well as key management protocol testing. For access to IPsec-wit and additional information see: http://ipsec-wit.antd.nist.gov. It is recommended that you read through the tutorial before testing for the first time. Comments and recommendations can be sent to ipsec-wit-dev@mail.antd.nist.gov. Best Regards, Rob G. rob.glenn@nist.gov PS - Sorry if you have already seen this once. I sent it out yesterday afternoon and haven't seen it yet. From owner-ipsec Tue Dec 16 11:50:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02082 for ipsec-outgoing; Tue, 16 Dec 1997 11:43:29 -0500 (EST) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB4491C8@scc-server3.semaphorecom.com> From: CJ Gibson To: "'ipsec'" Subject: don't-fragment-flag on ftp & icmp Date: Tue, 16 Dec 1997 09:04:28 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a question about encryption: My IPSec implementation sits on an Ethernet LAN which has a max PDU size of 1500. I've noticed that ftp builds IP packets at this max size and then sends them with the don't-fragment-flag set to 1. Encryption obviously adds bytes to the packet so how can I encrypt this without fragmenting it? Are we supposed to ignore the flag & fragment anyway? And how about ICMP (ping on my Sun sets the don't-fragment-flag as well)?? What are the rest of you doing in this case?? Thanx for your input.. CJ From owner-ipsec Tue Dec 16 12:17:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02366 for ipsec-outgoing; Tue, 16 Dec 1997 12:15:29 -0500 (EST) From: Dan McDonald Message-Id: <199712161727.JAA04999@kebe.eng.sun.com> Subject: Re: don't-fragment-flag on ftp & icmp To: cjgibson@semaphorecom.com (CJ Gibson) Date: Tue, 16 Dec 1997 09:27:15 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <0171F2F8F9E5D011A4D10060B03CFB4491C8@scc-server3.semaphorecom.com> from "CJ Gibson" at Dec 16, 97 09:04:28 am 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@ex.tis.com Precedence: bulk > My IPSec implementation sits on an Ethernet LAN which has a max PDU size > of 1500. I've noticed that ftp builds IP packets at this max size and > then sends them with the don't-fragment-flag set to 1. Encryption > obviously adds bytes to the packet so how can I encrypt this without > fragmenting it? Are we supposed to ignore the flag & fragment anyway? Well, this depends a lot on your implementation. It sounds like you have a "bump in the stack" implementation, where you aren't otherwise tied into the IP implementation on your system. A fix for the problem you have is to somehow convince your IP that its on a differently-sized device, with a frame size of 1500 - sizeof (IPsec overhead). If I'm wrong about your implementation, and you are embedded with your IP code, you should be making fragmentation decisions only AFTER you apply IPsec. Dan From owner-ipsec Tue Dec 16 14:45:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03570 for ipsec-outgoing; Tue, 16 Dec 1997 14:43:35 -0500 (EST) From: "Alexei V. Vopilov" To: "CJ Gibson" , "'ipsec'" Subject: Re: don't-fragment-flag on ftp & icmp Date: Tue, 16 Dec 1997 22:48:19 +0300 Message-ID: <01bd0a5b$8f3419e0$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA03567 Sender: owner-ipsec@ex.tis.com Precedence: bulk It would be correct if you reduce the MTU value with configuring LAN interfaces. You'll need to write your own network configuration script. That can be done as well from within the IPsec kernel driver during network stream construction time. If you fail with above, as a trick, you can drop a big packet, generate 'Need Fragmented' ICMP message and sent it up to network stream. Probably, you'll be able 'teach' upper software this way to reduce downstream packets size. In turn, the SunOS TCP/IP software should not set DF bit by default, check /dev/ip variables setting (or at least I've never observed such behavior.) regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: CJ Gibson To: 'ipsec' Date: 16 ДЕЙЮАПЪ 1997 Ц. 22:23 Subject: don't-fragment-flag on ftp & icmp :I have a question about encryption: :My IPSec implementation sits on an Ethernet LAN which has a max PDU size :of 1500. I've noticed that ftp builds IP packets at this max size and :then sends them with the don't-fragment-flag set to 1. Encryption :obviously adds bytes to the packet so how can I encrypt this without :fragmenting it? Are we supposed to ignore the flag & fragment anyway? :And how about ICMP (ping on my Sun sets the don't-fragment-flag as :well)?? :What are the rest of you doing in this case?? : :Thanx for your input.. : CJ : From owner-ipsec Tue Dec 16 15:32:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03913 for ipsec-outgoing; Tue, 16 Dec 1997 15:32:35 -0500 (EST) From: "Alexei V. Vopilov" To: Subject: parties ID handling under ISAKMP-OAKLEY Date: Tue, 16 Dec 1997 23:43:41 +0300 Message-ID: <01bd0a63$4b1be000$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA03910 Sender: owner-ipsec@ex.tis.com Precedence: bulk One of observations on the latest IPsec drafts is the handling of the parties ID information during a SA phase two negotiation. I trust that a serious discussion had preceded the discussion to put the scope of negotiating SA in the ID payload, I mean TCP/UDP protocol, and ports. However, it is not clear in documents how to negotiated a SA, say from an initiator TCP port X to responder TCP port Y. Probably, I missed some point, but ... 1. A DOI reserves 'proto' an 'port' for the ID payload, but does not say exactly whether these values belong to initiator (data sender) or responder side. I guess it should describe the destination point of SA even been included in the initiator ID payload. 2. The only way to include _both_ IDs in the proposal as per ISAKMP-OAKLEY is to use Quick Mode with full context. If an initiator did not include _both_ IDs in the proposal, the responder cannot predict the missing part and thus respond with own ID, which include other than 0 port information. Do you feel the serious security problem due to that? I do, especially for multi-user IPsec environment running number of client applications. 3. Since there can be only one pair of IDs in the proposal, multiple SAs cannot be negotiated at the same time or they will be just identical by scope, i.e. will protect the same connection streams. 4. Q: Can I negotiate two ICMP SAs of different ICMP types which will have different SPIs? If it can be done using the Id payload 'port' field for the ICMP 'type' one, that should be stated in the DOI draft. 5. Q: There cannot be a 'ports range' negotiated according to the current DOI-06, right? 6. Q: If an initiator needs to negotiate a SA been stuck to specific IP address+key_ID values, how it can be done with current ISAKMP-OAKLEY, DOI drafts. Another word, is it possible for a party to provide more than one ID payload for itself? If I'm completely wrong, just give me the right hint. thanx. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: Theodore Y. Ts'o To: ipsec@tis.com Date: 5 декабря 1997 г. 8:54 Subject: IPSEC document reading party! : :Hi, : : Bob and I are very concerned that few people are actually :reading all of the IPSEC drafts, and so there may be internal :inconsistency and other problems across the various drafts, that perhaps :won't be discovered until after they are published as RFC's. That, as :they say, would be Bad. : : In order to try to avoid this, we are planning an IPSEC document :reading party, to be held Monday evening at the IETF meeting. The :logistical details are still be being finalized, but it will probably :start at either 6:00 or 7:30. (If it starts at 6:00, food will be :provided.) : : We are looking for a people who are willing to put in a couple :of hours of real work, by reading over the documents, with a particular :attention towards finding consistency problems and other problems with :the drafts. Please come only if you are prepared to work! Also, please :bring your own copies of the documents to read. : : In the interests of getting work done, we're not looking for :quality, not quantity, in terms of the number of people we have :participating. Document editors are especially asked to come so that :they will be available for questions should they arise from the readers. : : If you are interested in particpating, please RSVP to Bob and I. :Information about the location, etc. will be announced later (probably :at the IETF meeting itself; check the announcements board.) : : If you have any questions, please let either Bob or I know. : : - Ted : : : : From owner-ipsec Wed Dec 17 10:38:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10788 for ipsec-outgoing; Wed, 17 Dec 1997 10:35:46 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Wed, 17 Dec 1997 08:57:46 -0600 Message-ID: <49801830.3000@usr.com> To: , "Alexei V. Vopilov" Subject: Re: parties ID handling under ISAKMP-OAKLEY Content-Type: multipart/mixed; boundary="IMA.Boundary.090773288" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.090773288 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: cc:Mail note part Alexei, Please see my comments below. = Sumit A. Vakil 3Com, Corp. ______________________________ Reply Separator __________________________= _______ Subject: parties ID handling under ISAKMP-OAKLEY Author: "Alexei V. Vopilov" at Internet Date: 12/16/97 11:43 PM One of observations on the latest IPsec drafts = is the handling of the parties ID information = during a SA phase two negotiation. I trust that a serious discussion had preceded the = discussion to put the scope of negotiating SA in = the ID payload, I mean TCP/UDP protocol, and ports. However, it is not clear in documents how to negotiated = a SA, say from an initiator TCP port X to responder TCP = port Y. Probably, I missed some point, but ... = 1. A DOI reserves 'proto' an 'port' for the ID payload, = but does not say exactly whether these values belong to initiator (data sender) or responder side. I guess it should describe the destination point of SA even = been included in the initiator ID payload. Sumit>> From section 5.5 of the ISAKMP/Oakley resolution = draft, "If ISAKMP is acting as a client negotiator on behalf of = another party the identities of the parties MUST be passed as = IDci and then IDcr.... If IDs are not exchanged, the = negotiation MAY assumed to be done on behalf of each ISAKMP = peer." This means that if ISAKMP is doing the phase 2 on behalf of = another party, the client ids on both sides must be present = in the message, and the ordering (IDci, IDcr) must be = maintained. = 2. The only way to include _both_ IDs in the proposal as per ISAKMP-OAKLEY is to use Quick Mode with full context. = If an initiator did not include _both_ IDs in the proposal, the responder cannot predict the missing part and thus = respond with own ID, which include other than 0 port information. = Do you feel the serious security problem due to that? I do, especially for multi-user IPsec environment running number of = client applications. Sumit>> See above. Both Ids must be supplied. = 3. Since there can be only one pair of IDs in the proposal, multiple = SAs cannot be negotiated at the same time or they will be just = identical by scope, i.e. will protect the same connection streams. Sumit>> You are correct. Multiple SAs can be negotiated, but they = will have the same scope. The idea behind this is to allow fast = re-keying. From section 9 of the resolution draft, "An implementation may wish to negotiate a range of SAs when = performing Quick Mode. By doing this they can speed up the = "re-keying". Quick Mode defines how KEYMAT is defined for a range of = SAs. When one peer feels it is time to change SAs they simply use = the next one within the stated range. A range of SAs can be = established by negotiating multiple SAs (identical attributes, = different SPIs) with one Quick Mode. = 4. Q: Can I negotiate two ICMP SAs of different ICMP types which will have different SPIs? If it can be done using the Id payload 'port' field for the ICMP = 'type' one, that should be stated in the DOI draft. Sumit>> Not sure. = 5. Q: There cannot be a 'ports range' negotiated according to the current DOI-06, right? Sumit>> That's how I understand it, too. However, 0 is supposed to be a wildcard. = 6. Q: If an initiator needs to negotiate a SA been stuck to specific IP address+key_ID values, how it can be done with = current ISAKMP-OAKLEY, DOI drafts. Another word, is it possible for a party to provide = more than one ID payload for itself? Sumit>> No, there can be only one Id payload pair in a = phase 2 exchange. The Id payloads are used to determine = the local security policy. They are also used to identify = data flows to be protected using a negotiated association. = The data flow Ids don't necessarily have to be restricted = to pairs of IP addresses and pairs of TCP ports. If you = want to use the same phase 2 association for packets = between multiple sources, you simply need to re-define the = Ids in your policy to allow subnets, range of IP addresses, = etc.. The IP DOI allows the Id to be subnets or ranges of = IP addresses, with wildcard upper layer protocols and = ports. I'm not sure if this answers your question. = If I'm completely wrong, just give me the right hint. = thanx. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 = Software Architecture&Development Consultant. --- -----Original Message----- From: Theodore Y. Ts'o = To: ipsec@tis.com Date: 5 =C4=C5EAAO=D1 1997 =C7. 8:54 Subject: IPSEC document reading party! = = : :Hi, : : Bob and I are very concerned that few people are actually = :reading all of the IPSEC drafts, and so there may be internal :inconsistency and other problems across the various drafts, that perhaps= = :won't be discovered until after they are published as RFC's. That, as = :they say, would be Bad. : : In order to try to avoid this, we are planning an IPSEC document = :reading party, to be held Monday evening at the IETF meeting. The = :logistical details are still be being finalized, but it will probably = :start at either 6:00 or 7:30. (If it starts at 6:00, food will be = :provided.) : : We are looking for a people who are willing to put in a couple :of hours of real work, by reading over the documents, with a particular = :attention towards finding consistency problems and other problems with = :the drafts. Please come only if you are prepared to work! Also, please= = :bring your own copies of the documents to read. : : In the interests of getting work done, we're not looking for = :quality, not quantity, in terms of the number of people we have = :participating. Document editors are especially asked to come so that :they will be available for questions should they arise from the readers.= = : : If you are interested in particpating, please RSVP to Bob and I. = :Information about the location, etc. will be announced later (probably = :at the IETF meeting itself; check the announcements board.) : : If you have any questions, please let either Bob or I know. = : : - Ted : : : : = --IMA.Boundary.090773288 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 49716C00; Tue, 16 Dec 97 18:03:12 -0600 Received: from portal.ex.tis.com by usr.com (8.8.5/3.1.090690-US Robotics) id QAA04219; Tue, 16 Dec 1997 16:37:18 -0600 (CST) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03913 for ipsec-outgoing; Tue, 16 Dec 1997 15:32:35 -0500 (EST) From: "Alexei V. Vopilov" To: Subject: parties ID handling under ISAKMP-OAKLEY Date: Tue, 16 Dec 1997 23:43:41 +0300 Message-ID: <01bd0a63$4b1be000$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA03910 Sender: owner-ipsec@ex.tis.com Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by usr.com id QAA04219 --IMA.Boundary.090773288-- From owner-ipsec Wed Dec 17 13:05:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11967 for ipsec-outgoing; Wed, 17 Dec 1997 13:01:43 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <9712178823.AA882381231@csg.stercomm.com> X-Mailer: ccMail Link to SMTP R6.01.01 Date: Wed, 17 Dec 97 11:14:44 -0600 To: , , Subject: Re[2]: don't-fragment-flag on ftp & icmp Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy. I'm new to IPSec list. If you reduce your MTU to make room for your VPN headers (ESP or AH), you can still have a problem with fragmentation. You still need to add the headers before the fragmentation is done. Sun Solaris systems (at least 2.5 and up) do Path MTU discovery. This is done by sending maximum sized ICMP packets with the "don't fragment" flag set. Once the Path MTU for the destination has been identified, all packets sent to that destination will have the "don't fragment" flag set. One of the purposes of this is to detect if a network route has changed to a network with a smaller MTU. I know SunOS 4.x systems do not do Path MTU discovery and, therefore, do not set the "don't fragment" flag. Brian St. Denis bstdenis@paranet.com ______________________________ Reply Separator _________________________________ Subject: Re: don't-fragment-flag on ftp & icmp Author: "Alexei V. Vopilov" at Internet-mail Date: 12/16/97 10:48 PM It would be correct if you reduce the MTU value with configuring LAN interfaces. You'll need to write your own network configuration script. That can be done as well from within the IPsec kernel driver during network stream construction time. If you fail with above, as a trick, you can drop a big packet, generate 'Need Fragmented' ICMP message and sent it up to network stream. Probably, you'll be able 'teach' upper software this way to reduce downstream packets size. In turn, the SunOS TCP/IP software should not set DF bit by default, check /dev/ip variables setting (or at least I've never observed such behavior.) regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: CJ Gibson To: 'ipsec' Date: 16 ДЕЙЮАdЪ 1997 a. 22:23 Subject: don't-fragment-flag on ftp & icmp :I have a question about encryption: :My IPSec implementation sits on an Ethernet LAN which has a max PDU size :of 1500. I've noticed that ftp builds IP packets at this max size and :then sends them with the don't-fragment-flag set to 1. Encryption :obviously adds bytes to the packet so how can I encrypt this without :fragmenting it? Are we supposed to ignore the flag & fragment anyway? :And how about ICMP (ping on my Sun sets the don't-fragment-flag as :well)?? :What are the rest of you doing in this case?? : :Thanx for your input.. : CJ : From owner-ipsec Wed Dec 17 13:29:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12132 for ipsec-outgoing; Wed, 17 Dec 1997 13:29:33 -0500 (EST) From: "Alexei V. Vopilov" To: , , Subject: Re: Re[2]: don't-fragment-flag on ftp & icmp Date: Wed, 17 Dec 1997 21:33:11 +0300 Message-ID: <01bd0b1a$3ab2e620$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA12129 Sender: owner-ipsec@ex.tis.com Precedence: bulk -------------Brian St. Denis wrote: > . . . > If you reduce your MTU to make room for your VPN headers (ESP or AH), > you can still have a problem with fragmentation. You still need to > add the headers before the fragmentation is done. Adding ESP/AH headers still can be done after fragmenttion, but you will have to stick to tunell mode (you cannot do the transport one!). > . . . > Once the Path MTU for the destination has been identified, all packets > sent to that destination will have the "don't fragment" flag set. One > of the purposes of this is to detect if a network route has changed to > a network with a smaller MTU. > >. . . --Alexei ______________________________ Reply Separator _________________________________ Subject: Re: don't-fragment-flag on ftp & icmp Author: "Alexei V. Vopilov" at Internet-mail Date: 12/16/97 10:48 PM It would be correct if you reduce the MTU value with configuring LAN interfaces. You'll need to write your own network configuration script. That can be done as well from within the IPsec kernel driver during network stream construction time. If you fail with above, as a trick, you can drop a big packet, generate 'Need Fragmented' ICMP message and sent it up to network stream. Probably, you'll be able 'teach' upper software this way to reduce downstream packets size. In turn, the SunOS TCP/IP software should not set DF bit by default, check /dev/ip variables setting (or at least I've never observed such behavior.) regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: CJ Gibson To: 'ipsec' Date: 16 ДЕЙЮАdЪ 1997 a. 22:23 Subject: don't-fragment-flag on ftp & icmp :I have a question about encryption: :My IPSec implementation sits on an Ethernet LAN which has a max PDU size :of 1500. I've noticed that ftp builds IP packets at this max size and :then sends them with the don't-fragment-flag set to 1. Encryption :obviously adds bytes to the packet so how can I encrypt this without :fragmenting it? Are we supposed to ignore the flag & fragment anyway? :And how about ICMP (ping on my Sun sets the don't-fragment-flag as :well)?? :What are the rest of you doing in this case?? : :Thanx for your input.. : CJ : From owner-ipsec Wed Dec 17 15:59:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13201 for ipsec-outgoing; Wed, 17 Dec 1997 15:55:52 -0500 (EST) Message-ID: <34983EB0.E7D80F14@newoak.com> Date: Wed, 17 Dec 1997 16:05:52 -0500 From: rshea@newoak.com (Rich Shea) Reply-To: rshea@newoak.com Organization: New Oak Communications X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com CC: Richard Shea Subject: IPSEC in non-IP networks? X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd like to know if anyone on this list (I know there are at least some) has considered using IPSEC as a security method for non IP networks? The reason I ask is because draft-ietf-l2tp-security-00.txt specifies a method for using IPSEC to secure L2TP traffic on non-IP networks in a way which I believe is non-extensible. I believe this non-extensibility is an issue which would be of concern in the IPSEC area. The proposal is to use UDP (ISAKMP) and ESP encapsulated directly over a non-IP medium. This would probably work fine, except the draft proposes using 0 (zero) in the next-protocol field of the ESP header to indicate L2TP next (since L2TP does not yet have a protocol number). Even though the ESP header will not be preceded by an IP header, this should not change the rules for the values and their meanings of what can be found in the next-proto field of the ESP header. I received no response on this point on the L2TP list (including when I re-sent the inquiry), and I have no indication that this was just put in the draft as a placeholder until L2TP receives a protocol number. I hope to resolve the issue without cross-pollinating the L2TP and IPSEC lists. I believe that if IPSEC should be used to secure L2TP payload on non-IP networks, then it should follow an extensible specification that the IPSEC crowd agrees with -- whether it is similar to the approach of draft-ietf-l2tp-security-00.txt or not. Comments please. The best way to do this conversation may be to keep it on this list, and I will summarize the conversation to the L2TP list when it converges. A will send a copy of this email to the L2TP list as well, so people there are aware of the conversation over here, and can follow it on their own as they wish. Richard Shea Senior Software Engineer New Oak Communications From owner-ipsec Wed Dec 17 16:05:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13272 for ipsec-outgoing; Wed, 17 Dec 1997 16:04:51 -0500 (EST) Date: Wed, 17 Dec 1997 15:15:29 -0600 Message-Id: <199712172115.PAA27023@beavis.smallworks.com> From: Jim Thompson To: owner-ipsec@ex.tis.com CC: cjgibson@semaphorecom.com, ipsec@tis.com, alx@elnet.msk.ru In-reply-to: <9712178823.AA882381231@csg.stercomm.com> (owner-ipsec@ex.tis.com) Subject: Re: don't-fragment-flag on ftp & icmp Sender: owner-ipsec@ex.tis.com Precedence: bulk Brian St. Denis wrote: > Sun Solaris systems (at least 2.5 and up) do Path MTU discovery. This > is done by sending maximum sized ICMP packets with the "don't > fragment" flag set. Not quite. In IPv4, (which I'll assume is the topic of discussion) ,Path MTU discovery (RFC1981) uses the DF bit in the IP header. As such, it may be present in any IP packet, TCP, UDP, ICMP, etc. If a router along the path has a MTU that would require fragmentation, then it sends a "fragmentation needed and DF set" ICMP message back (and drops the original packet on the floor.) Packets are never bigger than the 'first hop MTU'. A maximally-sized IP packet would be 65536 bytes long. The only interface I know of with a MTU this large is Hyperchannel (RFC1044). > Once the Path MTU for the destination has been identified, all packets > sent to that destination will have the "don't fragment" flag set. One > of the purposes of this is to detect if a network route has changed to > a network with a smaller MTU. Though this how Solaris handles things, there is no requirement that this happen. (In fact, the RFC explicitly allows a host to stop sending packets with DF set.) > I know SunOS 4.x systems do not do Path MTU discovery and, therefore, > do not set the "don't fragment" flag. Path MTU discovery is not the only only use for the DF bit. -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax "Faster, faster, until the thrill of speed overcomes the fear of death." --Hunter S. Thompson From owner-ipsec Thu Dec 18 11:05:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20557 for ipsec-outgoing; Thu, 18 Dec 1997 10:59:03 -0500 (EST) From: "Alexei V. Vopilov" To: "IPsec MailList" Subject: a drop/bypass action negotiation issue Date: Thu, 18 Dec 1997 18:55:49 +0300 Message-ID: <01bd0bcd$68df2e60$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk The arch. draft introduces two additional supported filtering actions, such as 'drop' and 'bypass'. Unfortunately, there is no defined way to _negotiate_ these actions with a remote peer. Does it seem appropriate to support such capability in the next drafts? Consider following examples. 1. An application wants to get access to some bandwidth consuming service. It is reasonably to protect the request for a service (e.g. to have secured control channel), but it is desirable to not have performance impact upon _using_ that service (for ex. a movie played over Internet). Thus, a control-application should be aware that the negotiation of a 'plain' connection is done before starting corresponded service application. Otherwise, the only way to resolve a problem with somehow blocked channel is through the time-proven approach, I mean the phone call ;-) 2. A client application (assuming the absence of corresponded local SPD entry) needs to check whether particular service is allowed for using at a remote server right now. The 'negotiation' of a disabled SA can simply provide required context of unavailability of some remote service. The SA lifetime (if any) can be a hint for a client on when to apply renegotiations with a remote peer. This seems to be quite common situation when a light-weight (and cheap) IPsec client does not need a sophisticated policy management, but instead relies on the policy dictated by the server side. I think that support of the above examples will serve towards synchronization of security polices on both ends of a communication channel. Overall IPsec approach (unlike other closed technologies) gives users a _hope_ that it can be done, but does not even highlight the policy negotiation/management technique at the current development stage. >From my experience the lack of standards for flexible security policy management will be the most barrier for wide deployment corresponded network security products. In turn, the administrative cost of the management of a network security system gets much higher if there is no low-level support for that built into underlined technology. Does the mentioned problem make any sense for IPsec folk to discuss even under 'IPsecond' label? regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- From owner-ipsec Thu Dec 18 11:05:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20559 for ipsec-outgoing; Thu, 18 Dec 1997 10:59:06 -0500 (EST) From: "Alexei V. Vopilov" To: , "IPsec MailList" Subject: Re: parties ID handling under ISAKMP-OAKLEY Date: Thu, 18 Dec 1997 14:51:15 +0300 Message-ID: <01bd0bab$3f0139c0$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA20549 Sender: owner-ipsec@ex.tis.com Precedence: bulk Thank you, Sumit, for the feedback. At least I got awareness that I do understand IPsec documents the same way as somebody else ;-) I should rephrase some of my topics. 1. Although it's clear that IDci and IDcr are to identify parties, the DOI does not clarify whether the proto and port fields of _IDci_ (initiator) do correspond to the initiator or responder values. If one will send in IDci proto=TCP, port=21 does it means that the _initiator_ will sent data on the _responder_ TCP 21 port. If yes, the DOI should clarify that case, because _initiator_ ID includes the port actually associated with the _responder_ service. If DOI assumes other, I don't see the way how client can request particular remote service under current DOI. 2. When doing host-to-host negotiations (on behalf of each ISAKMP peer!), and if IDs are not present, there is no way to select the scope for a SA other but all traffic between two hosts. Right? If yes, the fine-grained IPsec implementation must always use Quick mode at the full context. It should be noted in the current version of ISAKMP-OAKLEY. 6. The ID payload type allows select either party IP_address or key_ID, but not both. That means with using preloaded shared keys (where key_id is required for a negotiation) there is no way for a gateway employ different local keys for different protected systems resided behind it. The same can be applied for multiple local certificates of a gateway, since documents say that 'Cert' payload (if included in a SA negotiation) must be the one identified by the 'ID' payload. It seems impossible to say for a responder:'I request a SA originated from that IP address using that long-term keying material'. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: svakil@usr.com To: ipsec@tis.com ; Alexei V. Vopilov Date: 17 ДЕЙЮАПЪ 1997 Ц. 18:47 Subject: Re: parties ID handling under ISAKMP-OAKLEY Alexei, Please see my comments below. Sumit A. Vakil 3Com, Corp. ______________________________ Reply Separator _________________________________ Subject: parties ID handling under ISAKMP-OAKLEY Author: "Alexei V. Vopilov" at Internet Date: 12/16/97 11:43 PM One of observations on the latest IPsec drafts is the handling of the parties ID information during a SA phase two negotiation. I trust that a serious discussion had preceded the discussion to put the scope of negotiating SA in the ID payload, I mean TCP/UDP protocol, and ports. However, it is not clear in documents how to negotiated a SA, say from an initiator TCP port X to responder TCP port Y. Probably, I missed some point, but ... 1. A DOI reserves 'proto' an 'port' for the ID payload, but does not say exactly whether these values belong to initiator (data sender) or responder side. I guess it should describe the destination point of SA even been included in the initiator ID payload. Sumit>> From section 5.5 of the ISAKMP/Oakley resolution draft, "If ISAKMP is acting as a client negotiator on behalf of another party the identities of the parties MUST be passed as IDci and then IDcr.... If IDs are not exchanged, the negotiation MAY assumed to be done on behalf of each ISAKMP peer." This means that if ISAKMP is doing the phase 2 on behalf of another party, the client ids on both sides must be present in the message, and the ordering (IDci, IDcr) must be maintained. 2. The only way to include _both_ IDs in the proposal as per ISAKMP-OAKLEY is to use Quick Mode with full context. If an initiator did not include _both_ IDs in the proposal, the responder cannot predict the missing part and thus respond with own ID, which include other than 0 port information. Do you feel the serious security problem due to that? I do, especially for multi-user IPsec environment running number of client applications. Sumit>> See above. Both Ids must be supplied. 3. Since there can be only one pair of IDs in the proposal, multiple SAs cannot be negotiated at the same time or they will be just identical by scope, i.e. will protect the same connection streams. Sumit>> You are correct. Multiple SAs can be negotiated, but they will have the same scope. The idea behind this is to allow fast re-keying. From section 9 of the resolution draft, "An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re-keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. 4. Q: Can I negotiate two ICMP SAs of different ICMP types which will have different SPIs? If it can be done using the Id payload 'port' field for the ICMP 'type' one, that should be stated in the DOI draft. Sumit>> Not sure. 5. Q: There cannot be a 'ports range' negotiated according to the current DOI-06, right? Sumit>> That's how I understand it, too. However, 0 is supposed to be a wildcard. 6. Q: If an initiator needs to negotiate a SA been stuck to specific IP address+key_ID values, how it can be done with current ISAKMP-OAKLEY, DOI drafts. Another word, is it possible for a party to provide more than one ID payload for itself? Sumit>> No, there can be only one Id payload pair in a phase 2 exchange. The Id payloads are used to determine the local security policy. They are also used to identify data flows to be protected using a negotiated association. The data flow Ids don't necessarily have to be restricted to pairs of IP addresses and pairs of TCP ports. If you want to use the same phase 2 association for packets between multiple sources, you simply need to re-define the Ids in your policy to allow subnets, range of IP addresses, etc.. The IP DOI allows the Id to be subnets or ranges of IP addresses, with wildcard upper layer protocols and ports. I'm not sure if this answers your question. If I'm completely wrong, just give me the right hint. thanx. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: Theodore Y. Ts'o To: ipsec@tis.com Date: 5 деEAAOя 1997 г. 8:54 Subject: IPSEC document reading party! : :Hi, : : Bob and I are very concerned that few people are actually :reading all of the IPSEC drafts, and so there may be internal :inconsistency and other problems across the various drafts, that perhaps :won't be discovered until after they are published as RFC's. That, as :they say, would be Bad. : : In order to try to avoid this, we are planning an IPSEC document :reading party, to be held Monday evening at the IETF meeting. The :logistical details are still be being finalized, but it will probably :start at either 6:00 or 7:30. (If it starts at 6:00, food will be :provided.) : : We are looking for a people who are willing to put in a couple :of hours of real work, by reading over the documents, with a particular :attention towards finding consistency problems and other problems with :the drafts. Please come only if you are prepared to work! Also, please :bring your own copies of the documents to read. : : In the interests of getting work done, we're not looking for :quality, not quantity, in terms of the number of people we have :participating. Document editors are especially asked to come so that :they will be available for questions should they arise from the readers. : : If you are interested in particpating, please RSVP to Bob and I. :Information about the location, etc. will be announced later (probably :at the IETF meeting itself; check the announcements board.) : : If you have any questions, please let either Bob or I know. : : - Ted : : : : From owner-ipsec Fri Dec 19 11:32:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29921 for ipsec-outgoing; Fri, 19 Dec 1997 11:15:37 -0500 (EST) Message-Id: <199712191628.LAA23019@relay.rv.tis.com> Date: Fri, 19 Dec 97 10:52:30 EST From: Charles Lynn To: "Alexei V. Vopilov" cc: IPsec MailList Subject: Re: a drop/bypass action negotiation issue Sender: owner-ipsec@ex.tis.com Precedence: bulk Alexei > The arch. draft introduces two additional > supported filtering actions, such as 'drop' and 'bypass'. > Unfortunately, there is no defined way to _negotiate_ > these actions with a remote peer. You have raised an interesting point. I have been thinking about the drop and bypass functions as mechanisms used by the security administrator to specify policy. From that perspective, I would not want any one else to be able to _negotiate_ any changes to the local policy. However, if the local policy is to permit some trusted parties to poke holes in the firewall, then I can see your view. However, it could still be argued that the local policy is not being negotiated, only the use of a different preexisting policy entry. IPSecond seems like the right place to explore the requirements. Charlie From owner-ipsec Fri Dec 19 14:55:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01532 for ipsec-outgoing; Fri, 19 Dec 1997 14:50:21 -0500 (EST) Date: Fri, 19 Dec 1997 15:01:25 -0500 Message-Id: <199712192001.PAA25375@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Results of the IPSEC document reading party Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, Below please find the collected results of the IPSEC document reading party. My apologies for the delay in getting these out; I should have pushed them out before the end of the IETF meeting, before I took a few days off visiting friends in the Washinton area. - Ted From: John Ioannidis Date: Tue, 9 Dec 1997 12:55:53 -0500 (EST) To: tytso@MIT.EDU Subject: results from last night's document reading Here are the comments my group (ESP) came up with. Marc Hasson Richard Briggs Inder Monga John Ioannidis draft-ietf-ipsec- arch-sec-02.txt ==================== In -ciph-des-expiv-01, section 4 reads ... [ESP] describes the general mechanism to derive keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manually- and automatically-keyed security associations. ... The description is NOT in the [ESP] document, but in the architecture document, in section 4.6.2. The reference should be changed to [arch]. ==================== In auth-hmac-md5-96-01.txt, section 3., the same problem exists: change: ... [ESP] describes the general mechanism to obtain keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manual and automatic key management mechanisms. ... to [arch]... ==================== In -ciph-cbc-01.doc, section 3.2, reads: ... 3.2 Keying Material The minimum number of bits sent from the key exchange protocol to this ESP algorithm must be greater or equal to the key size. The cipher's encryption and decryption key is taken from the first bits of the keying material, where represents the required key size. ... This section should reference section 4.6.2 in the [arch] document. ==================== -esp-v2-02.txt, section 3.1, reads: ... Support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. ... but the architecture document, section 4.5, reads: ... the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. ... these two sections are not exactly consistent; we suggest -esp-v2-02.txt be fixed. The exact same problem exists in the -auth-header-03.txt document. ==================== Tunnel mode, issue #1: Nowhere in the documents is it mentioned what protocol should be used in the next header field for tunnel mode. Traditionally, it has been protocol 4 (IP-in-IP), which is not really documented anywhere, but simply involves encapsulating an entire IP datagram. We think this should be made explicit in the architecture document, probably where tunnel mode is discussed in section 5.1.2.1 in the architecture document (it is implicitely assumed by a reference to rfc2003). Tunnel mode, issue #2: This goes beyond IPSEC, really; the question is what happens when we want to tunnel an IPv6 datagram inside IPv4 IPSEC; The headers would go like this: [ipv4, next_header=50 [ESP, next_header=xxx [IPv6 datagram]]] If we were tunneling an IPv4 datagram, xxx would be 4; if we tunnel IPv6, do we use 4 again, and rely on the version field of the IPv6 header to correctly interpret the inner datagram as IPv6? Or do we use the ( ), much like we have separate ether-types and ppp types for IPv6 (so as not to rely on implementations checking the protocol version)? ==================== In -esp-v2-03.txt, section 3.4.1 ... packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, ... this is confusing; it seems to imply that a packet may be sent which causes this to happen. After discussing it with Steve Kent, it turns out that it is a "belt-and-suspenders" point; a well-functioning IP stack should never pass a fragment up to ESP, but in case it happens, ESP should be prepared for it and discard the packet. ==================== ---------------------------------------------------------- From: Steve Bellovin To: tytso@MIT.EDU, rgm3@chrysler.com Subject: ESP document inconsistencies Date: Mon, 08 Dec 1997 19:17:59 -0500 Sender: smb@research.att.com In draft-ietf-ipsec-ciph-des-expiv-01.txt: There is confusion about rejection of weak keys. Section 4 says "Weak key checks will be performed". Should that be MUST? The whole sentence is in the passive mode, which is especially bad here, since the reader doesn't know who is to perform the checks. The next section, 4.1, says that implementations "SHOULD take care" not to pick such keys. Which is it? This also conflicts with draft-ietf-ipsec-ciph-cbc-01.txt, which says that weak keys MUST be rejected. draft-ietf-ipsec-ciph-cbc-01.txt See the above comments on weak key processing. 2.5 has very bad terminology. It is not how "how many times a block is encrypted"; rather, it is how many rounds must be performed to accomplish one encryption. The description of the status of the different ciphers is incomplete. For example, I believe that RC5 and CAST are patented. This should be stated, just as it is for IDEA> (But CAST has been released, I think.) There are two different discussions of IV selection. The second is much better. Should we say that a simple counter MUST NOT be used for an IV? I think so. draft-ietf-ipsec-esp-v2-02.txt 3.1 Say that tunnel mode *MUST* be used. 3.3.5 I'm not convinced that the description of how to do fragmentation is correct. I'm especially concerned that transport and tunnel modes require different processing. The interaction of the rules here with IPv6 fragmentation is especially worthy of attention. (See the discussion of fragmentation in Wagner and Bellovin's "A Bump in the Stack Encryptor for MS-DOS", http://www.research.att.com/~smb/papers/bisconf.ps) 3.4.1 A fragment being passed to ESP is a host bug, not an auditable event. The lower layer should have reassembled the fragment, as it does for all higher-layer protocols. 3.4.5 There are many more ways in which decryption can "fail". For example, it can yield an illegal pad length, illegal pad values, or (maybe) a bad "next protocol" value. ------------------------------------------------------------------------- X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: tytso@MIT.EDU, rgm3@chrysler.com Cc: ddp@network-alchemy.com Subject: results from the reading "party" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Dec 1997 15:03:29 -0800 From: Daniel Harkins Ted, Bob, Here's the results of the ISAKMP, ISAKMP/Oakley, and DOI document reading party. Dan. ------------------------------------------------------------------------ Issues with the resolution document and the base ISAKMP spec ------------------------------------------------------------------------ 0. isakmp-09 reference in resolution doc should be to -08, but if we're re-reving all these I should just leave it. 1. DOI of 0 in phase 1 says to use the ID semantics from the base ISAKMP draft but the base ISAKMP draft doesn't define any semantics. A minimal set of ID types has to be added to the base ISAKMP draft. 2. 3DES-CBC-MAC is not defined. Issues with it are: 1) what to do if the key is exactly 24 bytes; and, 2) what about padding? Ben Rogers volunteered to write such a description. Desires for more restrictive language in the resolution document and DOI ---------------------------------------------------------------------------- 0. should add: MUST NOT send a key length attribute with a fixed length cipher; needs to be consistent in DOI and resolution document too. 1. should mention that phase 2 proposals that are logically related must be consistent and if PFS is desired the same group must be in all proposals. 2. should mention that phase 1 SA offers consist of a single proposal with possibly multiple transforms and not multiple proposals-- the protocol has to be ISAKMP anyway so multiple proposals doesn't really make sense. 3. mention that attributes described in the DOI as basic MUST NOT be encoded as VPIs. Also mention that if the initiator offers an attribute encoded as a VPI that could physically be encoded as a basic (e.g. it's value can fit in 2 octets) the responder MAY encode the response as a basic. Issues outside our scope that came up anyway ------------------------------------------------- 0. there is no way to negotiate cascaded SAs. This may be moot based on the results of the Arch+DOI partiers. 1. encapsulation attribute semantics may cause interoperability problems. This may be moot based on the results of the Arch+DOI partiers. 2. Arch doc seems to mandate that the "first" SA bundle be used to protect targeted packets and not the most restrictive. E.g. if there are SAs in the SADB currently for: all packets from net A to net B all telnet packets from host a to host b all packets from host a to host b (in that order) and a telnet packet from host a to host b comes along the most restrictive SA (the one with the most exact matches vs. wild- card matches), the one specifically for telnet packets from a to b should be used and not "the first". I'm not sure I agree with this contention but the issue did arise. As an aside, we (cisco) _always_ use the most restrictive SA as that seems the best way to build and properly use shared SAs. ----------------------------------------------------------------------- X-Sender: rmonsour@earthlink.net (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 08 Dec 1997 21:10:29 -0800 To: rgm3@chrysler.com, tytso@MIT.EDU From: Bob Monsour Subject: Roadmap and related doc review Cc: rfriend@hifn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bob & Ted, Below are comments from Rob Friend and myself on the roadmap doc and on some of the documents they relate to. The approach we took was to review the requirements for the encryption and authentication algorithms and to relate those to the mandatory drafts (expiv-01, md5-96-01, and sha196-01 - or whatever the current names are). As you'll see some of the three don't quite measure up. We also identified some ESP doc issues that tie in to the issues we identified. Regards, Bob & Rob ROADMAP DOCUMENT COMMENTS ------------------------- Issue 0: Section 3 is titled Keying Material, and would seem to better fit under section 4 as it applies to both encryption and authentication algorithms. Section 4.1 Encryption and Authentication Algorithms This section describes the requirements that are common to encryption and authentication algorithms. The following 4 issues all relate to section 4.1 of the roadmap doc. Issue 1: There is a requirement to discuss random number generator techniques. The des-expiv-01 doc does not cover this topic. Issue 2: There is a requirement to discuss the "format of keying material". The des-expiv-01 doc does not cover this topic. Issue 3: There is a requirement that "requirements and/or recommendations on how often keying material should be refreshed" should be in the algorithm docs. There are 2 sub-issues related to this: (a) We question whether this should really be in the algorithm documents, and (b) The des-expiv-01 doc states "there are no current recommendations for key lifetime." Also, the term key lifetime seems inappropriate in the des doc. Issue 4: There is a requirement that the Security Considerations section include discussion of "any relevant validation procedures". The des-expiv-01 doc does not cover this topic, either in the Security Considerations section, nor anywhere else in the document. MD5-96-01 and SHA196-01 COMMENTS -------------------------------- Issue 1: Section 3. Keying Material - The 4th paragraph references the ESP doc (and not AH) as to how to obtain and process keying material. We question why this paragraph exists at all. In addition, the ESP has NO such description of how to do these things. Issue 2: There is a requirement that "requirements and/or recommendations on how often keying material should be refreshed" should be in the algorithm docs. There are 2 sub-issues related to this: (a) We question whether this should really be in the algorithm documents, and (b) The MD-96-01 and SHA196-01 docs states "current literature does not include any recommended key lifetimes". Also, the term key lifetime seems inappropriate in the des doc. Issue 3: There is a requirment that "any known attacks" be discussed in the Security Considerations section. The MD5-96-01 doc does not discuss this. DES-EXPIV-01 COMMENTS --------------------- Issue 1: Section 4. Key Material - The 2nd paragraph references the ESP, stating that it contains a mechanism to derive keying material for the ESP transform. We question why this paragraph exists at all. In addition, the ESP has NO such description of how to do these things. ---------------------------------------------------------------- Bob Monsour Hi/fn Inc. rmonsour@hifn.com 2105 Hamilton Avenue 408-558-8065 Suite 230 408-558-8074 fax San Jose, CA 95125 ---------------------------------------------------------------- From owner-ipsec Fri Dec 19 15:32:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01814 for ipsec-outgoing; Fri, 19 Dec 1997 15:30:20 -0500 (EST) Message-ID: From: "Borovoy, Noam" To: "'Alexei V. Vopilov'" , IPsec MailList Subject: RE: a drop/bypass action negotiation issue Date: Fri, 19 Dec 1997 12:39:45 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk You're raising two very different issues: the first: securing some "control" communication while allowing the resulting service trafic to go in the clear, there are basically two possible situations: -the control trafic uses different protocols or ports from the service trafic - in this case the currently defined selectors should be enough. - the control trafic uses the same protocol and port as the service trafic, in this case the overhead to change the control application to negotiate a 'clear' connection for the service trafic would be probably greater than simply changing it to use a different protocol or port that would be defined by policy to be in the clear. On the second issue - policy management and distribution - there needs to be a lot of work done in IPsecond to enable future interoperability. I'll second you on policy negotiation and management being key to any wide deployment, there certainly should be more discussion on this topic. Regards, Noam Borovoy From owner-ipsec Fri Dec 19 15:39:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01875 for ipsec-outgoing; Fri, 19 Dec 1997 15:37:20 -0500 (EST) Date: Fri, 19 Dec 1997 15:48:54 -0500 (EST) Message-Id: <199712192048.PAA20633@carp.morningstar.com> From: Ben Rogers To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Results of the IPSEC document reading party In-Reply-To: <199712192001.PAA25375@dcl.MIT.EDU> References: <199712192001.PAA25375@dcl.MIT.EDU> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes: > Tunnel mode, issue #1: > > Nowhere in the documents is it mentioned what protocol should be used > in the next header field for tunnel mode. Traditionally, it has been > protocol 4 (IP-in-IP), which is not really documented anywhere, but > simply involves encapsulating an entire IP datagram. We think this > should be made explicit in the architecture document, probably where > tunnel mode is discussed in section 5.1.2.1 in the architecture > document (it is implicitely assumed by a reference to rfc2003). This is a bad idea, because the tunneling which is proposed in the architecture document is _not_ IP-in-IP. Of note, rfc2003 states: When subsequent datagrams arrive that would transit the tunnel, the encapsulator checks the soft state for the tunnel. If the datagram would violate the state of the tunnel (for example, the TTL of the new datagram is less than the tunnel "soft state" TTL) the encapsulator sends an ICMP error message back to the sender of the original datagram, but also encapsulates the datagram and forwards it into the tunnel. while the architecture document reads: o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PMTU information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging"). It has been my experience that this is not an isolated inconsistency. If we are planning on using IP-in-IP as the tunnel mechanism for IPsec, then why not simply refer to that RFC? If not (as seems to be the case) we'll need to register a new protocol number for IPsec-tunnel-IPv4. Of course, I'd ask why bother duplicating an existing protocol in the first place... -isakmp-oakley-05.txt > 2. 3DES-CBC-MAC is not defined. Issues with it are: 1) what to do if the > key is exactly 24 bytes; and, 2) what about padding? Ben Rogers > volunteered to write such a description. I'm guessing that most people will want to take 24 bytes and set the parity bits appropriately? (Instead of taking a 21 byte key and expanding it.) If I don't hear otherwise, I'll get that written up. And also, what happened to the output of the arch-sec/ipsec-doi group? I seem to remember being a part of a rather important discussion which I thought was more important than should be addressed by that small group and I'm curious as to what happened to it. ben From owner-ipsec Fri Dec 19 15:53:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01972 for ipsec-outgoing; Fri, 19 Dec 1997 15:51:20 -0500 (EST) Date: Fri, 19 Dec 1997 15:57:25 -0500 Message-Id: <199712192057.PAA00154@pobox.engeast.BayNetworks.COM> From: Indermohan Singh Monga To: "Borovoy, Noam" Cc: "'Alexei V. Vopilov'" , IPsec MailList Subject: RE: a drop/bypass action negotiation issue In-Reply-To: References: Sender: owner-ipsec@ex.tis.com Precedence: bulk BN> On the second issue - policy management and distribution - there needs BN> to be a lot of work done in IPsecond to enable future interoperability. BN> I'll second you on policy negotiation and management being key to any BN> wide deployment, there certainly should be more discussion on this BN> topic. I do believe in the solving the problem of policy management and distribution. This is especially true if every desktop will be able to negotiate security associations based on company security policy. I disagree with policy negotiation, this can become a considerable security hole which a network administrator configuring policy cannot comprehend. Does this negotiation mean, secure when you can, not-so-secure when you can't? (borrowing very common phrase..). Can you give me an example where such negotiation would help security? Thanks, Inder From owner-ipsec Fri Dec 19 16:10:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02089 for ipsec-outgoing; Fri, 19 Dec 1997 16:08:20 -0500 (EST) Message-Id: <97Dec19.162025est.11649@janus.tor.securecomputing.com> To: ben@Ascend.COM (Ben Rogers) cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: Results of the IPSEC document reading party References: <199712192001.PAA25375@dcl.MIT.EDU> <199712192048.PAA20633@carp.morningstar.com> In-reply-to: ben's message of "Fri, 19 Dec 1997 15:48:54 -0500". <199712192048.PAA20633@carp.morningstar.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 19 Dec 1997 16:20:01 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199712192048.PAA20633@carp.morningstar.com>, Ben Rogers writes: > > This is a bad idea, because the tunneling which is proposed in the > architecture document is _not_ IP-in-IP. Of note, rfc2003 states: The encapsulation protocol and algorithms used are independent from the Payload Type/Next Header/Protocol field. If the Payload is an IPV4 datagram, then the Payload Type should indicate such, and should be protocol 4. Having said that, I'll also mention that IPsec tunneling, and RFC 2003 IP-in-IP are trying to solve slightly different problems; note that the Abstract for 2003 explicitly mentions Mobile IP :-). -- Harald Koch From owner-ipsec Fri Dec 19 17:17:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02513 for ipsec-outgoing; Fri, 19 Dec 1997 17:13:21 -0500 (EST) From: "Alexei V. Vopilov" To: "IPsec MailList" Subject: IPsecond place? Date: Sat, 20 Dec 1997 01:25:45 +0300 Message-ID: <01bd0ccd$0caf83a0$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk ----------Charlies mentioned: [...] : :IPSecond seems like the right place to explore the requirements. : :Charlie I've heard several times about an 'IPsecond place', but can someone point me on the corresponded public forum (if any)? Thank you --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- From owner-ipsec Sun Dec 21 23:15:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17290 for ipsec-outgoing; Sun, 21 Dec 1997 23:00:22 -0500 (EST) Date: Sun, 21 Dec 1997 23:11:26 -0500 Message-Id: <199712220411.XAA25874@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: [Ran Atkinson: Re: Results of the IPSEC document reading party] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran sent the following comment to me, and has given me permission to forward it on to the ipsec list. - Ted ------- Forwarded Message Date: Sat, 20 Dec 97 05:56:12 GMT Standard Time From: Ran Atkinson Subject: Re: Results of the IPSEC document reading party To: "Theodore Y. Ts'o" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199712192001.PAA25375@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ted, Regarding "Tunnel Mode" issues: IPv6 has its own protocol number assigned by IANA (41). That (41) is the number that should be in the Next-Header field when IPv6 has been encapsulated inside tunnel-mode IPsec. The note to the list seemed confused on this, but all known IPsec+IPv6 implementations do as I indicate above. When IPv4 is encapsulated inside tunnel-mode IPsec, then the Next-Header should have (4) which is the protocol number for IP-in-IP. Again, to the best of my knowledge this is how all extant IPv4+IPsec implementations work. Folks wishing to tunnel Ethernet frames within IPsec might wish to consider using a Next-Header of 97, which has been assigned as Ethernet-in-IP by IANA. Note also that Protocol number 0 has in fact been assigned by IANA to the "IPv6 Hop-by-Hop Option" and hence ought not be used by an IPsec implementation for some other (hence non-interoperable) purpose. Some folks have mumbled about using Protocol number 0 for magic purposes, hence my concern. Thanks, Ran rja@home.net ------- End Forwarded Message From owner-ipsec Mon Dec 22 08:14:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20824 for ipsec-outgoing; Mon, 22 Dec 1997 08:11:24 -0500 (EST) Date: Sun, 21 Dec 1997 22:19:18 -0500 Message-Id: <199712220319.WAA25849@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Help solicited for IPSEC minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, Bob and I neglected to appoint a scribe at the Washington IETF meeting. (I think we both assumed the other would find one or was taking notes. Oops.) So I am therefore soliciting help in reconstructing a set of minutes for the Washington meeting. I am trying to reconstruct minutes from the (minimal) notes which I took, but to help me out, I would greatly appreciate it if anyone who did take more extensive notes or who gave a presentation at the meeting send to me what notes they collected. As always, if you have postscript/powerpoint/etc. of any slides which you presented, please forward them to me so I can include them as part of the minutes. Thanks to all of you for your hard work, especially those who came and participated in the document reading/review effort on Monday night. - Ted P.S. I've enclosed below the transcription of the agenda slide: Agenda Review 1545-1550 Results of the Document Reading Party 1550-1620 Next Steps on Documents 1620-1630 IPSECOND issues Multicast key management 1630-1645 Policy management 1645-1705 Tunnel Management 1705-1710 MIB 1710-1715 IANA Registration 1715-1720 IPSECOND Scoping 1720-1735 Other business 1735-1800 SSH ISAKMP test web page Next workshop SecureID Draft Convergence From owner-ipsec Mon Dec 22 16:44:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24747 for ipsec-outgoing; Mon, 22 Dec 1997 16:42:42 -0500 (EST) From: "Alexei V. Vopilov" To: "Theodore Y. Ts'o" , "IPsec MailList" Subject: Re: Results of the IPSEC document reading party Date: Tue, 23 Dec 1997 00:50:34 +0300 Message-ID: <01bd0f23$a1bafc60$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Three own observations followed by 'comments on comments' as per Theodore message. ------------------- This observation of ISAKMP-OAKLEY-05 ISAKMP-OAKLEY-05 states: > Using Quick Mode, multiple SA's and keys can be negotiated with one > exchange as follows: Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> COMMENT: If it is achieved with 'next payload == SA' inside the beginning of 'SA0' payload, it should be denoted in the ISAKMP draft sec 3.4 ------------------- This observation of Section 4.4.1 of DOI : > As a result, the protocol suites listed below > form the set of protocols that can be negotiated at the same time. . . . > Protocol ID Value > ----------- ----- > RESERVED 0 > PROTO_ISAKMP 1 > PROTO_IPSEC_AH 2 > PROTO_IPSEC_ESP 3 > PROTO_IPCOMP 4 COMMENT: The PROTO_ISAKMP and any other cannot be negotiated at the _same_ time. -------------------- This observation is of ISAKMP-08, 'Delete SA' payload definition. (I'm not sure it was already cleared at least in the list discussion) COMMENT: It is not clear what to use as SPI value when notifying on deletion of ISAKMP SA. Other comments: -------------------- Theodore wrote: : : 1. DOI of 0 in phase 1 says to use the ID semantics from the base : ISAKMP draft but the base ISAKMP draft doesn't define any semantics. : A minimal set of ID types has to be added to the base ISAKMP draft. Sorry, but the ID types are clearly defined in the DOI document. I did not find in DOI(6?) where it refers to ISAKMP for ID type. :. . . : 1. should mention that phase 2 proposals that are logically related : must be consistent and if PFS is desired the same group must be in all : proposals. That also requires to define the 'logically related proposals' term. : : 2. should mention that phase 1 SA offers consist of a single proposal : with possibly multiple transforms and not multiple proposals-- the : protocol has to be ISAKMP anyway so multiple proposals doesn't really : make sense. Sorry, but the proposal payload itself does not really make sense for an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the not best way. : . . . : Issues outside our scope that came up anyway :------------------------------------------------- : : 0. there is no way to negotiate cascaded SAs. This may be moot based on : the results of the Arch+DOI parties. SAs bundle, Multiple SAs, Multiple SA proposals, Cascaded SAs. Should they all be differentiated in some 'well-known', probably in arch draft? :. . . : 2. Arch doc seems to mandate that the "first" SA bundle be used to : protect targeted packets and not the most restrictive. E.g. if there : are SAs in the SADB currently for: : : all packets from net A to net B : all telnet packets from host a to host b : all packets from host a to host b : : (in that order) and a telnet packet from host a to host b comes along : the most restrictive SA (the one with the most exact matches vs. wild- : card matches), the one specifically for telnet packets from a to b : should be used and not "the first". : : I'm not sure I agree with this contention but the issue did arise. : As an aside, we (cisco) _always_ use the most restrictive SA as that : seems the best way to build and properly use shared SAs. Although it is possible (and reasonable) to employ 'most restrictive SA' approach for an Identifiers such as ID_IPVx_ADDR_SUBNET, an attempt to use the same for ID_IPVx_ADDR_RANGE identifiers leads to solving the problem of defining term 'most restrictive' for overlapped ranges. Don't think it is even possible. In turn, the requirement of arch draft about 'the SPD entries order' does prevent to deploy 'most restrictive SA' approach and does not solve the problem with ambiguous policy choices during creation of particular SA. Regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- From owner-ipsec Tue Dec 23 14:22:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02001 for ipsec-outgoing; Tue, 23 Dec 1997 14:13:47 -0500 (EST) Message-Id: <199712231925.LAA24343@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Alexei V. Vopilov" Cc: "Theodore Y. Ts'o" , "IPsec MailList" Subject: Re: Results of the IPSEC document reading party In-Reply-To: Your message of "Tue, 23 Dec 1997 00:50:34 +0300." <01bd0f23$a1bafc60$LocalHost@ppalx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Dec 1997 11:25:02 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Alexei, > ------------------- > This observation of ISAKMP-OAKLEY-05 > > ISAKMP-OAKLEY-05 states: > > > Using Quick Mode, multiple SA's and keys can be negotiated with one > > exchange as follows: Initiator Responder > > ----------- ----------- > > HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> > > COMMENT: If it is achieved with 'next payload == SA' inside the beginning > of 'SA0' payload, it should be denoted in the ISAKMP draft sec 3.4 > What is it exactly that you don't like about 3.4? It says if it's the last payload then its "next payload" field is zero; if it's not last then its "next payload" field is the next payload. The next payload for SA0 is SA1 and that's an "SA payload" (1). Then next payload of SA1 is Ni and that's a "nonce payload" (10). > Other comments: > -------------------- Theodore wrote: > > : > : 1. DOI of 0 in phase 1 says to use the ID semantics from the base > : ISAKMP draft but the base ISAKMP draft doesn't define any semantics. > : A minimal set of ID types has to be added to the base ISAKMP draft. > > > Sorry, but the ID types are clearly defined in the DOI document. > I did not find in DOI(6?) where it refers to ISAKMP for ID type. It won't. The DOI value specifies which document to look in for the appropriate semantics. Value 1 means look in the "IPSec DOI"; value 0 does not. If you put a zero as the DOI type in a phase I offer the ID semantics are not those of the IPSec DOI, they are those of the base ISAKMP document which, as is noted above, does not yet have them. It must. > :. . . > : 1. should mention that phase 2 proposals that are logically related > : must be consistent and if PFS is desired the same group must be in all > : proposals. > > That also requires to define the 'logically related proposals' term. We've got to put a stake in the ground somewhere otherwise we'll have an incredibly pedantic document. Is "logically related proposals" ambigouous to you? > : 2. should mention that phase 1 SA offers consist of a single proposal > : with possibly multiple transforms and not multiple proposals-- the > : protocol has to be ISAKMP anyway so multiple proposals doesn't really > : make sense. > > Sorry, but the proposal payload itself does not really make sense for > an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to > an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the > not best way. How do you negotiate ISAKMP SA parameters then? Of course the proposal payload makes sense for an ISAKMP SA. The issue is does one have a single proposal with possibly multiple transform payloads or does can one have multiple proposal payloads each with a single transform payload? It was never spelt out whether the latter is "legal". The consensus was that it is not. > :. . . > : 2. Arch doc seems to mandate that the "first" SA bundle be used to > : protect targeted packets and not the most restrictive. E.g. if there > : are SAs in the SADB currently for: > : > : all packets from net A to net B > : all telnet packets from host a to host b > : all packets from host a to host b > : > : (in that order) and a telnet packet from host a to host b comes along > : the most restrictive SA (the one with the most exact matches vs. wild- > : card matches), the one specifically for telnet packets from a to b > : should be used and not "the first". > : > : I'm not sure I agree with this contention but the issue did arise. > : As an aside, we (cisco) _always_ use the most restrictive SA as that > : seems the best way to build and properly use shared SAs. > > Although it is possible (and reasonable) to employ 'most restrictive SA' > approach for an Identifiers such as ID_IPVx_ADDR_SUBNET, an attempt > to use the same for ID_IPVx_ADDR_RANGE identifiers leads to solving > the problem of defining term 'most restrictive' for overlapped ranges. > Don't think it is even possible. > In turn, the requirement of arch draft about 'the SPD entries order' > does prevent to deploy 'most restrictive SA' approach and does not > solve the problem with ambiguous policy choices during creation of > particular SA. You're right that might not even be possible. What I was trying to capture was the general feeling at the "reading party" that the language is a bit ambiguous. "first" means different things to different implementations and that it would be better to be more explicit. If we negotiate that all communication between two particular subnets, subnet A and subnet B, uses ESP with DES and HMAC-MD5 but all communication between host a (which is on subnet A) and host b (which is on subnet B) uses ESP with 3DES and HMAC-SHA then I must protect packets from a to b with the unshared SA using 3DES and HMAC-SHA-- the "most restrictive" one-- not the shared SA using DES and HMAC-MD5. This is also an interoperability issue. If one party constructs a FIFO of SAs, the notion of "first" may be different than one that constructs a tree of SAs. Parties may (no, must) drop each other's traffic because it doesn't match their policy. But, as I noted, this issue was outside the scope of this particular clique at the party. I mentioned it only because it came up in discussion. c praznikom, Dan. From owner-ipsec Tue Dec 23 16:13:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02666 for ipsec-outgoing; Tue, 23 Dec 1997 16:10:50 -0500 (EST) Message-Id: <3.0.32.19971223132232.009c8e00@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Dec 1997 13:22:34 -0800 To: Daniel Harkins From: John Burke Subject: Re: Results of the IPSEC document reading party Cc: wdm@epoch.ncsc.mil, ipsec@tis.com, anx-sec@dot.netrex.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:25 AM 12/23/97 -0800, Daniel Harkins wrote: > Alexei, [ "Alexei V. Vopilov" wrote ] >> ------------------- >> This observation of ISAKMP-OAKLEY-05 >> [ ... ] >> : 2. should mention that phase 1 SA offers consist of a single proposal >> : with possibly multiple transforms and not multiple proposals-- the >> : protocol has to be ISAKMP anyway so multiple proposals doesn't really >> : make sense. >> >> Sorry, but the proposal payload itself does not really make sense for >> an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to >> an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the >> not best way. > >How do you negotiate ISAKMP SA parameters then? Of course the proposal payload >makes sense for an ISAKMP SA. The issue is does one have a single proposal >with possibly multiple transform payloads or does can one have multiple >proposal payloads each with a single transform payload? It was never spelt >out whether the latter is "legal". The consensus was that it is not. [ ... ] > c praznikom, > > Dan. Is this in fact consensus? I.e. that you're not allowed to use two Proposals in an ISAKMP-SA offer, but must use one with multiple Transforms. It is, as Dan says, not spelled out and it's strictly arbitrary. Did an ISAKMP author (Doug) announce his intention to include such a limitation in the next version of the draft? Our implementation accepts offers structured either way; in offers which we send, the structure can be explicitly configured either way. As things were last September (last bakeoff), doing otherwise seemed brain-dead to me; implementors shouldn't be forbidding variations allowed by the draft. I don't see why the draft should introduce limits like this at this late date, in absence of strong arguments. Best regards - John Burke From owner-ipsec Tue Dec 23 17:16:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03100 for ipsec-outgoing; Tue, 23 Dec 1997 17:13:52 -0500 (EST) From: "Alexei V. Vopilov" To: "Daniel Harkins" Cc: "Theodore Y. Ts'o" , "IPsec MailList" Subject: Re: Results of the IPSEC document reading party Date: Wed, 24 Dec 1997 01:18:19 +0300 Message-ID: <01bd0ff0$ac604580$de253ac3@ppalx> 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.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Daniel. : Alexei, : :> ------------------- :> This observation of ISAKMP-OAKLEY-05 :> :> ISAKMP-OAKLEY-05 states: :> :> > Using Quick Mode, multiple SA's and keys can be negotiated with one :> > exchange as follows: Initiator Responder :> > ----------- ----------- :> > HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> :> :> COMMENT: If it is achieved with 'next payload == SA' inside the beginning :> of 'SA0' payload, it should be denoted in the ISAKMP draft sec 3.4 :> : :What is it exactly that you don't like about 3.4? It says if it's the last :payload then its "next payload" field is zero; if it's not last then its :"next payload" field is the next payload. The next payload for SA0 is SA1 :and that's an "SA payload" (1). Then next payload of SA1 is Ni and that's a :"nonce payload" (10). If I got the right idea, a next to a SA payload is a 'Proposal payload', but the SA 'next payload' field is never filled with the 'Proposal payload' value. Probably, the name of the field should be other than 'next payload', say, 'next context-depended payloads group' ;-) Seriously, the semantic of ISAKMP goes far beyond simple parsing rules... :[. . .] : :It won't. The DOI value specifies which document to look in for the :appropriate semantics. Value 1 means look in the "IPSec DOI"; value 0 :does not. If you put a zero as the DOI type in a phase I offer the ID :semantics are not those of the IPSec DOI, they are those of the base ISAKMP :document which, as is noted above, does not yet have them. It must. OOPS, I did not even find in ISAKMP-08 that value = 0 is reserved by base ISAKMP document. For me DOI=0 is reserved by IANA, not by ISAKMP. Sorry. :[. . .] :We've got to put a stake in the ground somewhere otherwise we'll have an :incredibly pedantic document. Is "logically related proposals" ambigouous :to you? VERY! Do proposals for the same SA under same Proposal N are logically related? Do proposals from the same proposal list are logically related? Do proposals of a SA bundle are logically related? Do all proposals from the same ISAKMP message are logically related? :[. . .] : :How do you negotiate ISAKMP SA parameters then? Of course the proposal payload :makes sense for an ISAKMP SA. The issue is does one have a single proposal :with possibly multiple transform payloads or does can one have multiple :proposal payloads each with a single transform payload? It was never spelt :out whether the latter is "legal". The consensus was that it is not. If ISAKMP states that any payloads order should be supported, why not allow the latter case? BUT if there was the consensus on that - no more questions. :[. . .] :> Although it is possible (and reasonable) to employ 'most restrictive SA' :> approach for an Identifiers such as ID_IPVx_ADDR_SUBNET, an attempt :> to use the same for ID_IPVx_ADDR_RANGE identifiers leads to solving :> the problem of defining term 'most restrictive' for overlapped ranges. :> Don't think it is even possible. :> In turn, the requirement of arch draft about 'the SPD entries order' :> does prevent to deploy 'most restrictive SA' approach and does not :> solve the problem with ambiguous policy choices during creation of :> particular SA. : :You're right that might not even be possible. What I was trying to capture :was the general feeling at the "reading party" that the language is a bit :ambiguous. "first" means different things to different implementations and :that it would be better to be more explicit. If we negotiate that all :communication between two particular subnets, subnet A and subnet B, uses :ESP with DES and HMAC-MD5 but all communication between host a (which is on :subnet A) and host b (which is on subnet B) uses ESP with 3DES and HMAC-SHA :then I must protect packets from a to b with the unshared SA using 3DES and :HMAC-SHA-- the "most restrictive" one-- not the shared SA using DES and :HMAC-MD5. : :This is also an interoperability issue. If one party constructs a FIFO of :SAs, the notion of "first" may be different than one that constructs a tree :of SAs. Parties may (no, must) drop each other's traffic because it doesn't :match their policy. : :But, as I noted, this issue was outside the scope of this particular clique :at the party. I mentioned it only because it came up in discussion. I agree with you since did the same. IMO, what could keep IPsec from interoperability troubles is either of two approaches: (I like first but vote for latter as less-complicated for now) 1. - Remove mention about RANGES from ID payload - Keep the notion of port the same and never introduce a ranges in future - Employ 'most restrictive approach' whenever it is possible. 2. - Remove everything that implies a wildcard for addresses, protocols and ports to make traffic discrimination the straightforward operation. - Add to ISAKMP support of two negotiation types (actually should be done in any case) a) Join particular TCP/UDP/ connection to a specified SA b) Remove particular connection from a specified SA AND work hard on the definitions of Security Policy Management scope and functionality (in IPsecond)! I will return to FIFO and TREE problem sometime later, you are right again: it's not in the scope of current job, unfortunately. : c praznikom, : : Dan. Thank you and Merry Xmass to you all! (Here we have Xmass celebration at Jan 7, but a new year comes in the same date ;-) --Alexei From owner-ipsec Tue Dec 23 18:30:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03554 for ipsec-outgoing; Tue, 23 Dec 1997 18:27:51 -0500 (EST) Date: Tue, 23 Dec 1997 18:39:29 -0500 (EST) Message-Id: <199712232339.SAA25495@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Results of the IPSEC document reading party In-Reply-To: <199712192001.PAA25375@dcl.MIT.EDU> References: <199712192001.PAA25375@dcl.MIT.EDU> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes (quoting Dan Harkins' minutes): > 2. Arch doc seems to mandate that the "first" SA bundle be used to > protect targeted packets and not the most restrictive. E.g. if there > are SAs in the SADB currently for: > > all packets from net A to net B > all telnet packets from host a to host b > all packets from host a to host b > > (in that order) and a telnet packet from host a to host b comes along > the most restrictive SA (the one with the most exact matches vs. wild- > card matches), the one specifically for telnet packets from a to b > should be used and not "the first". > > I'm not sure I agree with this contention but the issue did arise. > As an aside, we (cisco) _always_ use the most restrictive SA as that > seems the best way to build and properly use shared SAs. Sorry to jump into this particular conversation a bit belatedly, but I was waiting on a response from Bob to an issue I had wanted resolved before bringing this to the group. But, he's evidently too busy to respond, so here we go: I'm a bit more concerned about the larger issue here, which is the idea that one SA selector set might be "better" than another, even when they both provide matches on a given packet. For the moment I'll concede the above point to Dan (for the case he mentions) while I stir up a little trouble elsewhere. I'm mostly concerned about the following situation: net A and net B are connected via two security gateways (call them Ga and Gb). These gateways agree on the following SADB entries: all packets from net A to host b all packets from host a to net B Now, Ga receives a packet from host a to host b. He cannot decide which SA selector is more restrictive because neither are. (I think this is how we got started on the original conversation, no?) So, we'd have to figure out a way to make one of these "better" than the other. One approach was to say that the first is the one that we'd always choose (in the case that they are otherwise of equal preference). However, I would claim that both of the SA's are perfectly valid for this type of traffic, and either should be perfectly acceptable. More to the point, I'd argue that if we support this selector scheme, then we should never have conflicting selectors. Rescinding the original concession, I look at the SADB that Dan proposes. Regardless of the interpretation, if we want to claim that only one SA matches a telnet packet from host a to host b (whether it be first, or most restrictive), what we are essentially saying is that we are working with the following set of SA's (order rearanged to simply notation): Ht = { all telnet packets from host a to host b } Hp = { all packets from host a to host b } - Ht Np = { all packets from net A to net B } - Ht - Hp which is nice and non-ambiguous, but it assumes that we have some way to do these sorts of set operations on the implicit sets defined by a given set of selectors. Moreover, it also assumes that we could deal with the situation where we first negotiate: Np = { all packets from net A to net B } and then want to negotiate a more restrictive rule for all packets from host a to host b. This looks to me to require an implicit renegotiation of the selector set for Np. I would suggest that if we were to stick with the concept of selectors, then we use them literally. If a given packet matches the selectors of more than one SA, then it can be en/de-capsulated by any of them. I am very uncomfortable with the implication that a second ISAKMP negotiation can change the meaning of an earlier negotiation. If you elect to prefer one SA over another for encapsulation, that is your business. But you cannot require that I do the same. If that is your intent, then I would require that you negotiate a deletion of the less restrictive rules, and renegotiate them as non-overlapping sets. ben PS- Before anyone takes this message as my tacit approval of the selector concept in general, I want to note that I am merely pointing out what I see to be one weakness. The rest will follow as a response to the notes on the discussion I had with Stephen Kent, Cheryl Madson and a number of others near the end of the document reading. If this is not posted (was anyone taking notes at that time?), then my comments will come unsolicited... :) From owner-ipsec Wed Dec 24 09:36:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09345 for ipsec-outgoing; Wed, 24 Dec 1997 09:33:08 -0500 (EST) From: "Alexei V. Vopilov" To: "Indermohan Singh Monga" Cc: "IPsec MailList" Subject: Re: a drop/bypass action negotiation issue Date: Wed, 24 Dec 1997 16:52:51 +0300 Message-ID: <01bd1073$39f54260$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Inder. -------From Inder: :I disagree with policy negotiation, this can become :a considerable security hole which a network :administrator configuring policy cannot comprehend. Does this :negotiation mean, secure when you can, not-so-secure when you :can't? (borrowing very common phrase..). :Can you give me an example where such negotiation would help :security? : :Thanks, :Inder Easily. Just consider the way an administrator will manage your personal laptop when you are working with office from home. He/She has to provide you with the list of (let's call it) SPD entries, which will much the Corporate Security Policy. There is no problem with that, except the list has to be somehow delivered on your machine and updated there. The problem is how the list will coexist with _your_ intention to visit a favorite WEB or protect _your_ system from a friend you are playing 'in hackers' with? What should be the order in which the Corporate SPD entries are inserted into your local SPD file? How long they should be there? Now consider the following way. Since you have to traverse a Corporate firewall whenever accessing your mail/ftp/nfs server, an administrator can just provide you with one Certificate (the firewall's one). You _always_ do a SA negotiation either with a gateway or directly with a server. You may get one of the: secure, bypass, or sorry replies. For you at home does it make any sense what the policy the remote peer is dictating, if you do need _get access_ to information rather than _protect_ the laptop resources? In turn, even working from inside a Corporate LAN, why you don't consider ISAKMP as the proven carrier to distribute Security Policy on the network terminals? Sure you might want to have this kind of negotiations disabled, but, probably, not as the statement in the IPsec standard. Did I answered your question? Sorry for the reply-delay, ---Alexei From owner-ipsec Wed Dec 24 09:36:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09344 for ipsec-outgoing; Wed, 24 Dec 1997 09:33:02 -0500 (EST) From: "Alexei V. Vopilov" To: "Charles Lynn" Cc: "IPsec MailList" Subject: Re: a drop/bypass action negotiation issue Date: Wed, 24 Dec 1997 17:39:46 +0300 Message-ID: <01bd1079$c7f43700$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, : :You have raised an interesting point. I have been thinking about the :drop and bypass functions as mechanisms used by the security :administrator to specify policy. From that perspective, I would not :want any one else to be able to _negotiate_ any changes to the local :policy. However, if the local policy is to permit some trusted :parties to poke holes in the firewall, then I can see your view. :However, it could still be argued that the local policy is not being :negotiated, only the use of a different preexisting policy entry. : :IPSecond seems like the right place to explore the requirements. : :Charlie The policy is whatever that protects your system (resources). The question is whenever you surf the net do you really want such protection at the cost of _access_ to information? IMO, very few systems (or people) can dictate the policy, others just have a choice either accept it or loose the chance to conduct business. Sorry for the reply-delay. regards, --Alexei From owner-ipsec Wed Dec 24 09:43:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09393 for ipsec-outgoing; Wed, 24 Dec 1997 09:42:01 -0500 (EST) Message-Id: <199712241454.JAA28725@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-01.txt Date: Wed, 24 Dec 1997 09:54:06 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Mode for ISAKMP/Oakley Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-01.txt Pages : 8 Date : 23-Dec-97 This document describes an alternate authentication method for ISAKMP/Oakley which makes use of GSS-API to authenticate the Diffie- Hellman exchange. The mechanism described here extends the authentication modes defined in [Harkins97] without introducing any modifications to the ISAKMP/Oakley key exchange protocol. This constraint however, necessarily restricts the number of GSS-API exchanges and may limit the broader applicability of this method. Additional work is needed to provide a fully generalized solution. Such a solution will require ISAKMP/Oakley protocol modifications. For a list of changes since the previous version of this document, please see Section 5. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-gss-auth-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971223172523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971223172523.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Dec 24 12:44:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10345 for ipsec-outgoing; Wed, 24 Dec 1997 12:42:01 -0500 (EST) Message-Id: <199712241753.JAA24759@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: Results of the IPSEC document reading party In-Reply-To: Your message of "Tue, 23 Dec 1997 18:39:29 EST." <199712232339.SAA25495@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Dec 1997 09:53:09 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, (I flipped your post, 2nd issue 1st, 1st issue 2nd) > Rescinding the > original concession, I look at the SADB that Dan proposes. Regardless > of the interpretation, if we want to claim that only one SA matches a > telnet packet from host a to host b (whether it be first, or most > restrictive), what we are essentially saying is that we are working with > the following set of SA's (order rearanged to simply notation): > > Ht = { all telnet packets from host a to host b } > Hp = { all packets from host a to host b } - Ht > Np = { all packets from net A to net B } - Ht - Hp > > which is nice and non-ambiguous, but it assumes that we have some way to > do these sorts of set operations on the implicit sets defined by a given > set of selectors. Yes, that's my point exactly. We should decide on "some way to do these sorts" otherwise we will not have interoperability. > Moreover, it also assumes that we could deal with the > situation where we first negotiate: > > Np = { all packets from net A to net B } > > and then want to negotiate a more restrictive rule for all packets from > host a to host b. This looks to me to require an implicit renegotiation > of the selector set for Np. Why can't we deal with that situation? I know of vendors whose implementations can deal with this situation just fine. I think we have to deal with this situation. In my opinion it is a Good Thing to have shared and unshared SAs exist simultaneously in the SADB and to enforce the policy that created them. I can envision real world situations where people want certain protection for all resources on a subnet _except_ for a particular one (or two...) which will have different protection. If we don't decide on "some way to do these sorts" then you'll use any old SA that you happen to have (because it is valid in your opinion since we did negotiate it) and I'm going to throw it on the ground because it doesn't match my local policy. Now back to your first example: > I'm mostly concerned about the following situation: > > net A and net B are connected via two security gateways (call > them Ga and Gb). These gateways agree on the following SADB > entries: > > all packets from net A to host b > all packets from host a to net B > > Now, Ga receives a packet from host a to host b. He cannot > decide which SA selector is more restrictive because neither > are. (I think this is how we got started on the original > conversation, no?) > > So, we'd have to figure out a way to make one of these "better" than the > other. One approach was to say that the first is the one that we'd > always choose (in the case that they are otherwise of equal > preference). However, I would claim that both of the SA's are > perfectly valid for this type of traffic, and either should be perfectly > acceptable. That policy is ambiguous so the resulting SADB will be similarly ambiguous. Can we prevent an administrator from implementing ambiguous policy? Should we? I don't think so. If such policy was configured and 2 sets of SAs ended up being negotiated then there is no "better" one. In that case I guess you'd have to accept a packet from host b to host a using either of your 2 inbound SAs. You (the administrator) made that bed, now lie in it. We should follow the example set my other developers of munitions: "point away from foot when firing". But it seems to me that for unambiguous policy we can have a standard, unambiguous, way to do those sorts-- to decide which is "better". If my unambiguous policy says: "all traffic from net A to net B is protected by FOO except traffic from host a to host b which is protected by BAR" then why can't we decide that receipt of a packet from host b for host a that is not protected by BAR MUST be dropped? Is this not a Good Thing? We could define the sorting to be "most restrictive" and then say that "Specific selector entries are always more restrictive than wildcard entries." This would be nice and unambiguous except in this situation: address service --------- ------- wildcard telnet specific host wildcard which we could unambiguously agree to say that specific services are always more restrictive than specific addresses. And in the situations where you have ambiguous policy then your sort is done ambiguously and you live with the results, or lack thereof. Perhaps this isn't the best way to define the sorting. I'm not claiming it is, only that it's something for the WG to consider and I really really really believe that the WG should consider a standard, unambiguous way to define sorting. Just saying, "take the first one" doesn't work. Dan. P.S. Dynamically changing policy-- where the administrator on one side adds more restrictive policy to his gateway or host and packets start to be silently dropped-- should be an IPSecond issue. From owner-ipsec Mon Dec 29 08:54:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13433 for ipsec-outgoing; Mon, 29 Dec 1997 08:44:04 -0500 (EST) Message-ID: <34A1D2BE.3E42@ukiahsoft.com> Date: Wed, 24 Dec 1997 19:27:58 -0800 From: sanjay Reply-To: sanjay@ukiahsoft.com Organization: Ukiah Software Inc., X-Mailer: Mozilla 3.04Gold (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: User Authentication for home-office scenario Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk My question (below) relates to an IPSEC implementation of a VPN between a mobile/home user's PC and a corporate VPN gateway/firewall protecting a secured network. Is there a standard for authenticating the user with the VPN server? The idea is that once the mobile user authenticates with the authentication service at the VPN server, he can be allowed into the secured network. I am more interested in a standard protocol/message exchange sequence (based on some standard) as opposed to different schemes such as user/password, one-time-passwords, token cards etc. What do most commercial remote-user/corporate-VPN-server implementations do for user authentication? Do they use proprietary protocols? Any help would be greatly appreciated. (Please reply directly to me) Sanjay Sawhney (sanjay@ukiahsoft.com) From owner-ipsec Mon Dec 29 09:57:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13925 for ipsec-outgoing; Mon, 29 Dec 1997 09:55:04 -0500 (EST) Date: Mon, 29 Dec 1997 10:31:30 -0300 From: Gordon Oliver Subject: Re: Results of the IPSEC document reading party To: Daniel Harkins Cc: ipsec@tis.com Message-Id: X-Mailer: TkMail 4.0beta9 In-Reply-To: <199712241753.JAA24759@dharkins-ss20.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk ... Daniel Harkins said ... [snip] >But it seems to me that for unambiguous policy we can have a standard, >unambiguous, way to do those sorts-- to decide which is "better". >If my unambiguous policy says: "all traffic from net A to net B is >protected by FOO except traffic from host a to host b which is protected >by BAR" then why can't we decide that receipt of a packet from host b >for host a that is not protected by BAR MUST be dropped? [snip] >Perhaps this isn't the best way to define the sorting. I'm not claiming it >is, only that it's something for the WG to consider and I really really >really believe that the WG should consider a standard, unambiguous way to >define sorting. Just saying, "take the first one" doesn't work. If it is "take the first one, from an ordered set defined by the administrator" it is much less ambiguous than any other set of sorting rules that you could define... admitedly this is giving the administrator a gun that is easy to point at the foot, but tools could warn when it looked like he was about to shoot it... We seem to have two separate issues here: 1) How does one portably specify rule sets for IPSec/IPSecond. If we want to define portable rule sets (A good thing) We need to have standards to specify what they _mean_. Personally I would prefer the ordered set approach to this, as it will often generate smaller rule sets. An implementation is free to convert this rule set into whatever internal representation it wants... 2) The sorting/search algorithm used by an implementation to find the appropriate rule. This has no need to be defined here... In fact the note about searching the rules in order should probably be amended so that it is more clearly stated that an implementation doesn't need to _actually_ search in order... -gordo -- --------------------------------------------------------------- Gordon Oliver (gordo@telsur.cl) Independent Consultant From owner-ipsec Mon Dec 29 12:05:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14853 for ipsec-outgoing; Mon, 29 Dec 1997 12:04:08 -0500 (EST) Date: Mon, 29 Dec 1997 12:09:21 -0500 (EST) From: Dave Mason Message-Id: <199712291709.MAA05805@rubicon.rv.tis.com> To: anx-sec@dot.netrex.net, ipsec@tis.com Subject: Breaks compatablity Sender: owner-ipsec@ex.tis.com Precedence: bulk Most of the changes to the ipsec drafts since the last bakeoff don't appear to break compatablity with the implementations that were tested there, except the following. I just thought that this item should REALLY be EMPHASIZED. As Tero Kivinen points out: >Did you add any clarification of the calculation of authentication >hash? Most of the vendors in interop used only IP address instead of >full ID payload (without generic headers, but with protocol and port >number). I had to add compat option for that in interop... > > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) > ^^^^ > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) ^^^^ And as Daniel Harkins responds concerning the correction to the resolution doc incorporated into version 5: >Thank you! I forgot to mention that. It says: > "The entire ID payload (including ID type, port, and protocol > but excluding the generic header) is hashed into both HASH_I > and HASH_R." I know that everybody we tested with at the last bakeoff did NOT include the type, port, protocol as part of the HASH, and since the three postings to the mailing list that mention this change, mention this item amidst many other items, many people may have overlooked it AND WILL NEED to correct there implementations to bring them inline with the latest resolution draft. Does anyone know of any other changes to the drafts that outright break compatability with what was tested at the last bakeoff? -dave From owner-ipsec Mon Dec 29 12:18:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14917 for ipsec-outgoing; Mon, 29 Dec 1997 12:18:09 -0500 (EST) Date: Mon, 29 Dec 1997 12:23:37 -0500 (EST) From: Dave Mason Message-Id: <199712291723.MAA06419@rubicon.rv.tis.com> To: ipsec@tis.com Subject: AH handling of options Sender: owner-ipsec@ex.tis.com Precedence: bulk For IPv4 options, the total packet space for the options is a multiple of four bytes. If an "End of Options List" is encountered, but there are more bytes in the options part of the packet due to the four byte alignment, how are the remaining bytes dealt with concerning the ICV computation? 1) remaining bytes are ignored/skipped (ala NRL July 96 reference port) 2) remaining bytes are included as is (treated as immutable) 3) remaining bytes are included but set to zero for the computation I would think that number 2 would be the case. -dave From owner-ipsec Mon Dec 29 13:13:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15303 for ipsec-outgoing; Mon, 29 Dec 1997 13:12:09 -0500 (EST) Date: Mon, 29 Dec 1997 20:21:56 +0200 (EET) Message-Id: <199712291821.UAA21833@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: anx-sec@dot.netrex.net Cc: Daniel Harkins , wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: Results of the IPSEC document reading party In-Reply-To: <3.0.32.19971223132232.009c8e00@192.43.161.2> References: <3.0.32.19971223132232.009c8e00@192.43.161.2> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 9 min Sender: owner-ipsec@ex.tis.com Precedence: bulk John Burke writes: > Is this in fact consensus? I.e. that you're not allowed to use two > Proposals in an ISAKMP-SA offer, but must use one with multiple Transforms. If you have to use only one proposal that have one protocol (isakmp) inside it, then you cannot make interoperable extension to isakmp and add new protocol that can be used in combination or instead of isakmp protocol. I think it would be good idea to leave the protocol so that it can be extended later easily in such way that new and old implementations can still interoperate without knowning whether the other end supports that new extension. If old version gets proposal that has any other protocol than isakmp it rejects that proposal and if we allow multiple proposals then it can try to check if the next proposal is for backward compatibility (only isakmp protocol). > Our implementation accepts offers structured either way; in offers which we > send, the structure can be explicitly configured either way. As things So does our implementation. -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Mon Dec 29 22:00:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18336 for ipsec-outgoing; Mon, 29 Dec 1997 21:57:11 -0500 (EST) Date: Tue, 30 Dec 97 02:39:02 GMT Standard Time From: Ran Atkinson Subject: Re: User Authentication for home-office scenario To: ipsec@tis.com, sanjay X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <34A1D2BE.3E42@ukiahsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 24 Dec 1997 19:27:58 -0800 sanjay wrote: > My question (below) relates to an IPSEC implementation of > a VPN between a mobile/home user's PC and a corporate VPN > gateway/firewall protecting a secured network. > > Is there a standard for authenticating the user with the > VPN server? The idea is that once the mobile user > authenticates with the authentication service at the > VPN server, he can be allowed into the secured network. > > I am more interested in a standard protocol/message exchange > sequence (based on some standard) as opposed to different > schemes such as user/password, one-time-passwords, token cards > etc. > > What do most commercial remote-user/corporate-VPN-server > implementations do for user authentication? Do they use > proprietary protocols? ---------------End of Original Message----------------- There are a number of possible approaches. One reasonable approach is to use RADIUS Authentication and the RADIUS Mandatory Tunneling Attribute to specify the IPsec tunnel endpoint relative to the dialup TAC. Ran From owner-ipsec Tue Dec 30 02:41:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA19593 for ipsec-outgoing; Tue, 30 Dec 1997 02:40:11 -0500 (EST) From: "Alexei V. Vopilov" To: "Borovoy, Noam" , "IPsec MailList" Subject: Re: a drop/bypass action negotiation issue Date: Tue, 30 Dec 1997 10:47:48 +0300 Message-ID: <01bd14f7$3982e840$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id CAA19590 Sender: owner-ipsec@ex.tis.com Precedence: bulk Noam, The first issue (as you defined it) implies also a case when the port for service-traffic might be just randomly selected. Consider an example where you have IPsec enabled FTP client. If ftp-data are to be secured, your ftp-client _can_ _negotiate_ corresponded association with a remote peer. But the case when ftp-data are to be passed in clear, the only thing you can perform is set such SPD entry _locally_ (and dynamically?) with no guaranties the channel will be really established. You cannot track potential problem because the way for remote peer to tell you about it is not defined. As about second issue, denoted in your response. The problem is not only with policy distribution and management, but also with the definition what Security Policy means and how it works. Unfortunately, the mention about security policy is in the current arch draft, but is so less developed that it might be better just remove some of the draft statements. >From the other hand, the Pass/Drop actions support, the wildcards for IP address, protocol, port - all this requires explanation of the IPsec _logic_ when doing such things under real network environments. Though, I do not say that this logic, even if detailed, will completely clarify Security Policy issues for IPsec. Trying to compose some proposal for Security Policy requirements, I meet with difficulties to understand the logic of IPsec under particular operational environments. Restrictions for the IPsec logic means (beside functionality) the same for the scope of Security Policy. By the way, do the potential customers of IPsec, who are on this list, just throw examples below as being rare cases? The following cases are first addressed to the logic and then to the policy issues. 1. How an application can be aware that the requested IPsec service will be definitely performed even it is allowed by an administrator, policy, etc.? (Like, upon system start the default policy was activated, so the standalone host did negotiate a fat secured channel through a firewall to internal network. Now an application on that host wants to negotiate particular connection to internal network under _dedicated_ crypto context. It might be done even with the same certificates, but prove me that drafts allow such service to be provided?) 2. How an implementation has to react, when a remote peer responses with SPI value already in effect for a past negotiated SA even the policy implies such behavior? (Like, a remote peer has negotiated a telnet connection through a gateway. Now it tries negotiate ftp connection. If the gateway policy says:'do the same SA context for all traffic with the same remote address', there is nothing extraordinary here. But a remote host did not know that telnet connection will be followed by ftp one, so it did negotiated only the first one to be the scope of first SA. May be the draft states that the same SPI must never be used for different SA requests? 3. How an IPsec implementation can restrict a remote user (read certificate) to access only from known IP addresses? (Like an ISP wants to allow secured access for it customers, but only from ISP dial-in facilities? Note: IP address here acts as a SA restraint rather than as a key ID selector.) Other environments can be highlighted as well. I agree that many IPsec functions and services can be just cut off in IPsec-first, but how to make continuity for IPsecond? Another word, how to do development of new functions for IPsecond without redevelopment of base IPsec drafts? I would be happy if everything can be done with just new DOI, as it was probably intended, but not sure this will work. regards, --Alexei -----Original Message----- From: Borovoy, Noam To: 'Alexei V. Vopilov' ; IPsec MailList Date: 19 декабря 1997 г. 23:42 Subject: RE: a drop/bypass action negotiation issue :You're raising two very different issues: :the first: securing some "control" communication while allowing the :resulting service trafic to go in the clear, there are basically two :possible situations: :-the control trafic uses different protocols or ports from the service :trafic - in this case the currently defined selectors should be enough. :- the control trafic uses the same protocol and port as the service :trafic, in this case the overhead to change the control application to :negotiate a 'clear' connection for the service trafic would be probably :greater than simply changing it to use a different protocol or port that :would be defined by policy to be in the clear. : :On the second issue - policy management and distribution - there needs :to be a lot of work done in IPsecond to enable future interoperability. :I'll second you on policy negotiation and management being key to any :wide deployment, there certainly should be more discussion on this :topic. : :Regards, :Noam Borovoy : From owner-ipsec Tue Dec 30 13:30:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23041 for ipsec-outgoing; Tue, 30 Dec 1997 13:19:16 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199712291723.MAA06419@rubicon.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Dec 1997 13:23:00 -0500 To: Dave Mason From: Stephen Kent Subject: Re: AH handling of options Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, I believe the IPv4 End of Options option is supposed to be used to cause the list of options to be an integral multiple of 4 bytes. If so, there ought not be any bytes after it and thus the situation you cite should not arise. Steve From owner-ipsec Tue Dec 30 17:42:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24353 for ipsec-outgoing; Tue, 30 Dec 1997 17:39:23 -0500 (EST) Message-Id: <199712302250.OAA28059@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Burke Cc: anx-sec@dot.netrex.net, wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: Results of the IPSEC document reading party In-Reply-To: Your message of "Tue, 23 Dec 1997 13:22:34 PST." <3.0.32.19971223132232.009c8e00@192.43.161.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Dec 1997 14:50:31 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk At 13:22:34 PST on Tues, 23 Dec 1997 John Burke wrote: > At 11:25 AM 12/23/97 -0800, Daniel Harkins wrote: > > Alexei, > [ "Alexei V. Vopilov" wrote ] > >> ------------------- > >> This observation of ISAKMP-OAKLEY-05 > >> > [ ... ] > >> : 2. should mention that phase 1 SA offers consist of a single proposal > >> : with possibly multiple transforms and not multiple proposals-- the > >> : protocol has to be ISAKMP anyway so multiple proposals doesn't really > >> : make sense. > >> > >> Sorry, but the proposal payload itself does not really make sense for > >> an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to > >> an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the > >> not best way. > > > >How do you negotiate ISAKMP SA parameters then? Of course the proposal > payload > >makes sense for an ISAKMP SA. The issue is does one have a single proposal > >with possibly multiple transform payloads or does can one have multiple > >proposal payloads each with a single transform payload? It was never spelt > >out whether the latter is "legal". The consensus was that it is not. > [ ... ] > > c praznikom, > > > > Dan. > > Is this in fact consensus? I.e. that you're not allowed to use two > Proposals in an ISAKMP-SA offer, but must use one with multiple Transforms. > It is, as Dan says, not spelled out and it's strictly arbitrary. Did an > ISAKMP author (Doug) announce his intention to include such a limitation in > the next version of the draft? I'll leave it up to the co-chairs of the IPSec Working Group to define what constitutes concensus on a particular issue. No, "an ISAKMP author (Doug)" did not announce this but an ISAKMP/Oakley author (me) did. Is that unacceptable to you? > Our implementation accepts offers structured either way; in offers which we > send, the structure can be explicitly configured either way. As things > were last September (last bakeoff), doing otherwise seemed brain-dead to > me; implementors shouldn't be forbidding variations allowed by the draft. > I don't see why the draft should introduce limits like this at this late > date, in absence of strong arguments. What seems brain-dead is to have another configurable option to give to the administrator which will ultimately have absolutely no impact on the system. That's a recipe for confusion and frustration. The motivation for doing this was to prevent confusing but legal offers like: SA, prop1, trans1, trans2, prop2, trans1, prop3, trans1, trans2, trans3 What is the sender of this trying to convey? It is arbitrary and confusing. We decided that not allowing people to be arbitrary and confusing when negotiating security parameters is good and this was declared illegal. It also has the potential (depending on specific implementations your mileage may vary) to simplify what are already very confusing parsing rules. Phase 1 negotiation can only result in a single SA (unlike phase 2 negot- iation); that single SA can only be one possible protocol (unlike IPSec SAs); the logical relationships possible with IPSec-- eg ((X AND Y) OR Z)-- are not possible with the single ISAKMP SA; and, there is no "SPI" for this proposal. So the only thing possible with multiple proposals for an ISAKMP SA is to have them all be identical except their proposal numbers which are monotonically increasing which means logical "OR". By making this limitation we are in no way limiting the things that can be expressed, only limiting the way they are expressed; we are forcing people to be clear and consise. This simplifies security parameter negotiation and does not limit the things that can be described in offers. Aside from easing your UI and documentation burden what impact does this have on you? Dan. From owner-ipsec Wed Dec 31 00:01:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26277 for ipsec-outgoing; Tue, 30 Dec 1997 23:58:18 -0500 (EST) Date: Wed, 31 Dec 97 04:51:22 GMT Standard Time From: Ran Atkinson Subject: Re: a drop/bypass action negotiation issue To: IPsec MailList X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <01bd14f7$3982e840$LocalHost@ppalx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Tue, 30 Dec 1997 10:47:48 +0300 "Alexei V. Vopilov" wrote: > By the way, do the potential customers of IPsec, > who are on this list, just throw examples below as > being rare cases? > > The following cases are first addressed > to the logic and then to the policy issues. > > 1. How an application can be aware that the requested > IPsec service will be definitely performed > even it is allowed by an administrator, policy, etc.? > (Like, upon system start the default policy was > activated, so the standalone host did negotiate > a fat secured channel through a firewall to internal > network. Now an application on that host wants to > negotiate particular connection to internal network > under _dedicated_ crypto context. > It might be done even with the same certificates, > but prove me that drafts allow such service > to be provided?) People are sick of hearing this, but the fact is that the original NRL code included a (simplistic) API for IPsec. With such an API, it is trivial to inform the application when some security has been requested but is not available. That seems like an existence proof to me... Details of such an API are beyond the scope of the IPsec protocol specifications, though it would be useful (IMHO) if IPsecond wrote an Informational RFC describing extensions to POSIX.1g for IPsec. > 2. How an implementation has to react, when a remote > peer responses with SPI value already in effect for > a past negotiated SA even the policy implies such > behavior? > (Like, a remote peer has negotiated a telnet connection > through a gateway. Now it tries negotiate ftp connection. > If the gateway policy says:'do the same SA context > for all traffic with the same remote address', > there is nothing extraordinary here. > But a remote host did not know that telnet connection > will be followed by ftp one, so it did negotiated only > the first one to be the scope of first SA. > May be the draft states that the same SPI must never > be used for different SA requests? I don't see this as an issue. It is possible for different devices to have conflicting policies. Depending on the extent of the policy conflict, those devices might or might not even communicate with each other. > 3. How an IPsec implementation can restrict a remote user > (read certificate) to access only from known IP addresses? > (Like an ISP wants to allow secured access for it > customers, but only from ISP dial-in facilities? > Note: IP address here acts as a SA restraint rather than > as a key ID selector.) Add a knob to one's KM daemon configuration that permits the system admin to restrict the range of Source Identities that are considered acceptable to one's own KM entity. See also the preceding paragraph. Also, note that this knob is NOT a protocol issue, but the knob's existence is instead a quality-of-implementation issue. > I agree that many IPsec functions and services can be > just cut off in IPsec-first, but how to make continuity > for IPsecond? Another word, how to do development > of new functions for IPsecond without redevelopment > of base IPsec drafts? I would be happy if everything > can be done with just new DOI, as it was probably > intended, but not sure this will work. I don't think you have found any insurmountable problems in the current DOI in the above note. In short, I'm not persuaded there is a real problem here. Ran rja@inet.org From owner-ipsec Wed Dec 31 10:09:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29492 for ipsec-outgoing; Wed, 31 Dec 1997 10:03:19 -0500 (EST) Message-Id: <199712311508.KAA26474@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-04.txt Date: Wed, 31 Dec 1997 10:08:58 -0500 Sender: owner-ipsec@ex.tis.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 Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol (IPComp) Author(s) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-04.txt Pages : 8 Date : 30-Dec-97 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. Internet-Drafts are 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-ippcp-protocol-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-protocol-04.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971230113232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971230113232.I-D@ietf.org> --OtherAccess-- --NextPart--