From owner-ipsec Mon Jun 1 08:10:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10263 for ipsec-outgoing; Mon, 1 Jun 1998 08:06:53 -0400 (EDT) Date: Sat, 30 May 1998 17:15:32 -0400 (EDT) From: Eric Dean To: Stephen Waters cc: Avram Shacham , ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and IPSEC In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I've worked full-time from home for a few years now - using a > direct dial ISDN link over which the > average compression seems to stay stubbornly on 2:1. I'll load > up the IPPCP image and share the results > once I have a decent sample. Not a bad case study considering > the use of IPPCP in the short term - > i.e. remote-access for laptops/SOHOs. > For reasons stated in my previous message, as you move closer to the core of the Internet where traffic is highly uncorrelated, you will find relatively poor cases for stateful compression. (I am aware that stateless compression is the proposed method for IPPCP.) As you move far to the edge of the Internet, at the modem layer, you find that packets are highly correlated and tend to benefit from current stateful compression methodologies. -eric From owner-ipsec Mon Jun 1 08:11:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10292 for ipsec-outgoing; Mon, 1 Jun 1998 08:07:52 -0400 (EDT) Date: Sat, 30 May 1998 17:09:50 -0400 (EDT) From: Eric Dean To: Avram Shacham cc: Stephen Waters , ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and IPSEC In-Reply-To: <3.0.2.32.19980529133701.006b1dd8@airedale.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > >comparing different compression algorithms in a stateful environment; > ^^^^^^^^ how comes? Looking at the queue state of a typical Internet router, there is next to no correlation of any packets within the queue. Therefore, maintaining a state (or history) is not of significant value because the patterns are random. For instance, I rarely have two packets belonging to the same flow (or session) in my queue at the same time. Now, if one were to FTP some files, one at a time, and have no other concurrent activity, then the queue serving the local segment would contain only packets from the single session. These packets would be highly correlated and therefore should compress relatively well (assuming that they are not already compressed). >From a packet compression perspective, the Internet is a stateless environment. Now if one were to build VPN's with IPSEC, then one might achieve better compression ratios. -eric From owner-ipsec Mon Jun 1 22:42:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA12997 for ipsec-outgoing; Mon, 1 Jun 1998 22:33:17 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01959165@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 30 May 1998 14:31:05 -0400 To: Stephen Waters From: Stephen Kent Subject: Re: IPCOMP and IPSEC Cc: ippcp@external.cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, >e.g. > >Original host packet [IP1][TCP][data] > >After passing through a security gateway/IP tunnel: > >[IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > >If this is supported, is it detailed anywhere? For example, if an >Explicit IV is used, would it come after the ESP header or after the >IPCOMP header? The IV appears at the beginning of the ciphertext, which would place it in front of the IPCOMP header, by definition. However, we have not been explicit abouit mentioning the option of IPCOMP coming directly after ESP (in tunnel mode) in the arch doc. It complicates matters a bit in that this requires IPCOMP to be performed before the inner IP header check is performed. That check is part of IPSEC tunnel mode processing, so inserting IPCOMP here requires some care. I see from later messages that there is good reason to layer it here, rather than after the inner IP header; this definately makes IPCOMP an integral part of the IPsec processing, not just a modular compression protocol. To the extent that IPcomp use is specified as part of the SA negotiation, that seems fine. Steve From owner-ipsec Tue Jun 2 06:23:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA14807 for ipsec-outgoing; Tue, 2 Jun 1998 06:19:03 -0400 (EDT) Message-Id: <3573D6A4.D4142C2D@cclk400.ccl.itri.org.tw> Date: Tue, 02 Jun 1998 18:40:37 +0800 From: Jen-Chi Liu X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ipsec@tis.com Subject: Socket level have implemented interface for IPSEC???? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id GAA14804 Sender: owner-ipsec@ex.tis.com Precedence: bulk Everybody, I find out there is a draft "draft-mcdonald-simple-ipsec-api-01.txt". This draft describes a socket interface to setup IPSEC operation. However, this draft is expired. Now where has documents or drafts to discuss about the development of this socket interface supporting IPSEC?? In Winsocket 2.0 specification, I do not find out any paraments (enable ESP or AH) used to setup IPSEC. What is the current status about API used to setup IPSEC parament. Thanks a lot!! Best Regards -- ¼B«Ø§Ó/Jen-Chi, Liu Ph.D. Engineer, Multimedia System Dept. Computer & Communications Research Laboratories, Industrial Technology Research Institute, Taiwan (tel) 886-3-5914663 (fax) 886-3-5820310 e-mail: ccliu@cclk400.ccl.itri.org.tw From owner-ipsec Tue Jun 2 13:41:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16575 for ipsec-outgoing; Tue, 2 Jun 1998 13:37:25 -0400 (EDT) From: "GuApo" To: "pcalhoun@eng.sun.com" , "Robert Moskowitz" Cc: Subject: Me tirem daqui!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Date: Tue, 2 Jun 1998 14:33:53 -0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1132 MIME-Version: 1.0 Content-Type: text/plain; charset=Default Message-ID: <19980602175207327.AAA148@cprot> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA16572 Sender: owner-ipsec@ex.tis.com Precedence: bulk COMO EU FAÇO PARA SAIR DESTA DROGA DE LISTA???????????????? ---------- > De: Robert Moskowitz > Para: pcalhoun@eng.sun.com > Cc: ipsec@tis.com > Assunto: Re: Items for new charter > Data: Quarta-feira, 27 de Maio de 1998 21:18 > > At 08:05 AM 5/27/98 -0700, pcalhoun@eng.sun.com wrote: > >How about external Policy Server Support? This could be used to "download" > >policies as well as for Extended Authentication. > > > Part of IPsecond. > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Jun 2 19:01:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17464 for ipsec-outgoing; Tue, 2 Jun 1998 18:59:35 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806022314.QAA15346@server.livingston.com> Subject: Re: Comments on the latest Security architecture draft To: matt@ljo.dec.com (Matt Thomas) Date: Tue, 2 Jun 1998 16:19:11 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <199805311757.NAA06983@tecumseh.altavista-software.com> from "Matt Thomas" at May 31, 98 01:55:39 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > 2. Secion 4.1. Defintion of an SA > > > > A Security Association(SA) is a triple of (Dest_Addr, SPI, > > security_protocol). Yet, the SPI number is fixed by the initiator > > and selected by the responder (refer ISAKMP and IKE documents). > > There is a problem with the above two statements to work together. > > No there isn't. > > > Suppose there are 2 secure gateways (called SGW1 and SGW2) talking > > to the same target dest. Address (hereafter called target), using > > the same SPI number and same security protocol (say ESP). Surely, > > the target node should maintain 2 SAs with different sets of > > attributes (such as keys, SA lifetime etc..), one for traffic from > > SGW1 and another for traffic from SGW2. Yet, the triple of both > > these SAs on target is identical. > > Only if the target is broken. It should have generated a different > SPI for each of the security gateways. If it did not, it's implementation > of IPsec is broken. > -- > Matt Thomas Internet: matt@ljo.dec.com > Internet Locksmith WWW URL: > AltaVista Internet Software Disclaimer: This message reflects my own > Littleton, MA warped views, etc. > So, I assume, you are saying that the target should pick the SPI number; And, not the initiating gateways (SGW1, SGW2 in the above example). Makes sense. But, as far as I can tell, this was left unspecified in ISAKMP and IKE drafts. In particular, in section 4.1 of the latest ISAKMP draft should have specified who sets the SPI number and who uses it. The most obvious assumption to make is that the initiator sets the SPI number along with the proposals and transforms in SA payload and the responder selects one that suits the best. The draft SHOULD document the roles of who sets the number and who uses the number very clearly. It doesnt do that. Neither does the IKE draft. Thanks. cheers, suresh From owner-ipsec Tue Jun 2 19:47:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17535 for ipsec-outgoing; Tue, 2 Jun 1998 19:46:35 -0400 (EDT) Message-Id: <98Jun2.200254edt.11649@janus.tor.securecomputing.com> To: Pyda Srisuresh Cc: ipsec@tis.com Subject: Re: Comments on the latest Security architecture draft References: <199806022314.QAA15346@server.livingston.com> In-reply-to: Your message of "Tue, 02 Jun 1998 19:19:11 -0400". <199806022314.QAA15346@server.livingston.com> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21127.896832094.1@gamera.tornd.securecomputing.com> Date: Tue, 2 Jun 1998 20:01:35 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199806022314.QAA15346@server.livingston.com>, Pyda Srisuresh writes: > > Makes sense. But, as far as I can tell, this was left unspecified in > ISAKMP and IKE drafts. In particular, in section 4.1 of the latest > ISAKMP draft should have specified who sets the SPI number and > who uses it. The most obvious assumption to make is that the initiator > sets the SPI number along with the proposals and transforms in SA > payload and the responder selects one that suits the best. The IKE negotiation sets up SAs in BOTH directions. The Initiator sends an SPI along with a series of SA proposals; that is the initiator's SPI; the one that will be used for Receiving traffic at the initiator. The Responder, when it selects a single SA proposal and sends that back, fills in the SPI field with the Responder's SPI; this is the one that will be used for receiving traffic at the responder. This is (unfortunately) only spelled out in a paragraph in section 5.5 of IKE, which says: A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. But, nonetheless, it's pretty obvious that this is the only way to get different SPIs, and thus different keys, at each end of the negotiation. -- Harald Koch From owner-ipsec Tue Jun 2 20:02:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA17602 for ipsec-outgoing; Tue, 2 Jun 1998 20:00:33 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806030015.RAA19772@server.livingston.com> Subject: Re: Comments on the latest Security architecture draft To: chk@utcc.utoronto.ca (C. Harald Koch) Date: Tue, 2 Jun 1998 17:20:01 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <98Jun2.200254edt.11649@janus.tor.securecomputing.com> from "C. Harald Koch" at Jun 2, 98 08:01:35 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > In message <199806022314.QAA15346@server.livingston.com>, Pyda Srisuresh writes: > > > > Makes sense. But, as far as I can tell, this was left unspecified in > > ISAKMP and IKE drafts. In particular, in section 4.1 of the latest > > ISAKMP draft should have specified who sets the SPI number and > > who uses it. The most obvious assumption to make is that the initiator > > sets the SPI number along with the proposals and transforms in SA > > payload and the responder selects one that suits the best. > > The IKE negotiation sets up SAs in BOTH directions. > > The Initiator sends an SPI along with a series of SA proposals; that is the > initiator's SPI; the one that will be used for Receiving traffic at the > initiator. > > The Responder, when it selects a single SA proposal and sends that back, fills > in the SPI field with the Responder's SPI; this is the one that will be used > for receiving traffic at the responder. > > This is (unfortunately) only spelled out in a paragraph in section 5.5 of IKE, > which says: > > > A single SA negotiation results in two security assocations-- one > inbound and one outbound. Different SPIs for each SA (one chosen by > the initiator, the other by the responder) guarantee a different key > for each direction. The SPI chosen by the destination of the SA is > used to derive KEYMAT for that SA. > > But, nonetheless, it's pretty obvious that this is the only way to get > different SPIs, and thus different keys, at each end of the negotiation. > > -- > Harald Koch > That's clear. I would recommend adding the above text or something like that to the IKE and ISAKMP drafts. Thanks. cheers, suresh From owner-ipsec Tue Jun 2 23:01:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA17923 for ipsec-outgoing; Tue, 2 Jun 1998 22:55:32 -0400 (EDT) Message-ID: <71F9F43682B7D011BDA20020C5E2CCB3145737@FTP> From: Titus Peedikayil To: "'ipsec@tis.com'" Subject: DOD vs Cisco ISAKMP reference implementation Date: Tue, 2 Jun 1998 20:10:25 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > Can someone compare the two reference implementations out there? I > want to pick one to base my implementation upon. > > Thanks, > > Biao Wang > RouterWare Inc. > Biao@RouterWare.COM > From owner-ipsec Thu Jun 4 10:17:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24908 for ipsec-outgoing; Thu, 4 Jun 1998 10:07:30 -0400 (EDT) Message-Id: <199806041412.KAA13997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-06.txt Date: Thu, 04 Jun 1998 10:12:42 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, B. Phan, C. Metz Filename : draft-mcdonald-pf-key-v2-06.txt Pages : 72 Date : 03-Jun-98 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-mcdonald-pf-key-v2-06.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980603142644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980603142644.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jun 4 11:52:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25411 for ipsec-outgoing; Thu, 4 Jun 1998 11:50:32 -0400 (EDT) Message-Id: <3.0.5.32.19980604120133.00a58c50@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 12:01:33 -0400 To: Stephen Waters , Avram Shacham From: Robert Moskowitz Subject: RE: IPCOMP and IPSEC Cc: ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:38 AM 5/30/98 +0100, Stephen Waters wrote: Sorry I have been out of the loop for a while. I am back for a bit. First off, gateways will REALLY NEED to implement IPCOMP. After all, what will MOST remotes be maintaining a tunnel too? Hmm? In fact this points to an advantage of IPCOMP over V.42bis and PPP compression. The later only benefit the dialup link. The former will tend to reduce bandwidth over the net (that is if we get some of those 1.7:1 reductions). Also, as Avram pointed out, where there is a compression gain, there will be and encryption savings. Given the 'right' hardware this might be a total processing gain (time will tell), and this could benefit heavily loaded gateways. > > I guess time will tell. For remote-access VPN stuff (over the >Internet), there is no doubt that > stateless compression is what you use. For some of the newer >VNP-focused providers offering > QOS for LAN-to-LAN, it may be possible to use a history - even >for IPPCP. Remember one of the design problems in IPsec: you do not want IPsec dealing with lost packets. That is an upper layer problem. If you use history, will lost packets be an issue? There was also some concern of security weakening with history, but that was never really nailed down. The general concensus was that IPCOMP was yet another hack, and really TCPng needs to add intelligent compression (that is interact with the application). There is could have history. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Jun 5 01:34:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA27485 for ipsec-outgoing; Fri, 5 Jun 1998 01:30:50 -0400 (EDT) Message-Id: <3.0.2.32.19980604224547.006a18ec@airedale.cisco.com> X-Sender: shacham@airedale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 04 Jun 1998 22:45:47 -0700 To: Robert Moskowitz From: Avram Shacham Subject: RE: IPCOMP and IPSEC Cc: ipsec@tis.com, ippcp@external.cisco.com, Stephen Waters In-Reply-To: <3.0.5.32.19980604120133.00a58c50@homebase.htt-consult.com> References: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:01 PM 6/4/98 -0400, Robert Moskowitz wrote: >TCPng needs to add intelligent compression (that is interact with the >application). There is could have history. In previous discussions of compression at level 4, several people correctly pointed that TCP-compression may reduce the number of IP packets while IP compression can only reduce the size of each packet. Fewer IP packets may enhance performance even more than utilizing compression history. But - and this may be a BIG implementation obstacle - the current compression algorithms require ~16KB of compression and decompression context for _each_ connection. In other words, 16KB per socket... Also, UDP is still a useful L4 protocol and no stateful compression is possible here either. Regards, avram From owner-ipsec Fri Jun 5 06:15:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA28593 for ipsec-outgoing; Fri, 5 Jun 1998 06:12:51 -0400 (EDT) Date: Fri, 5 Jun 1998 06:27:54 -0400 Message-Id: <199806051027.GAA00454@rsts-11.mit.edu> To: suresh@livingston.com CC: matt@ljo.dec.com, suresh@livingston.com, ipsec@tis.com In-reply-to: <199806022314.QAA15346@server.livingston.com> (message from Pyda Srisuresh on Tue, 2 Jun 1998 16:19:11 -0700 (PDT)) Subject: Re: Comments on the latest Security architecture draft From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <199806022314.QAA15346@server.livingston.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Harold Koch cited where it is listed in the IKE document. The Architecture Security document also has this to say: SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. So it is there in the documents. - Ted From owner-ipsec Fri Jun 5 10:33:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29829 for ipsec-outgoing; Fri, 5 Jun 1998 10:26:00 -0400 (EDT) Date: Fri, 5 Jun 1998 10:39:51 -0400 Message-Id: <199806051439.KAA00557@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: shacham@cisco.com Cc: rgm-sec@htt-consult.com, ipsec@tis.com, ippcp@external.cisco.com, Stephen.Waters@digital.com Subject: RE: IPCOMP and IPSEC References: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com> <3.0.5.32.19980604120133.00a58c50@homebase.htt-consult.com> <3.0.2.32.19980604224547.006a18ec@airedale.cisco.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Avram" == Avram Shacham writes: Avram> At 12:01 PM 6/4/98 -0400, Robert Moskowitz wrote: >> TCPng needs to add intelligent compression (that is interact with >> the application). There is could have history. Avram> In previous discussions of compression at level 4, several Avram> people correctly pointed that TCP-compression may reduce the Avram> number of IP packets while IP compression can only reduce the Avram> size of each packet. Fewer IP packets may enhance performance Avram> even more than utilizing compression history. That's a very good point. Certainly sending the same number of bytes in a smaller number of packets is always a win. Avram> But - and this may be a BIG implementation obstacle - the Avram> current compression algorithms require ~16KB of compression Avram> and decompression context for _each_ connection. In other Avram> words, 16KB per socket... That's only a few millicents per socket. Avram> Also, UDP is still a useful L4 protocol and no stateful Avram> compression is possible here either. True, but for UDP packets that are larger than the MTU, the same IP packet reduction benefit applies. From owner-ipsec Fri Jun 5 15:36:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01030 for ipsec-outgoing; Fri, 5 Jun 1998 15:34:41 -0400 (EDT) Date: Fri, 5 Jun 98 15:32:46 EDT From: rct@epoch.ncsc.mil (Ruth C. Taylor) Message-Id: <9806051932.AA00265@gareb.epoch.ncsc.mil> To: ipsec@tis.com, isakmp-oakley@cisco.com Subject: ISAKMP Implementation Analysis Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I am interested in comparing current freely available ISAKMP- Oakley implementations for BSD platforms, such as Cisco's ISAKMP code and "Pluto" by Angelos Keromytis. Does anyone know of information sources for the following, for these or other BSD ISAKMP implementations? - the degree of policy flexibility (is the security proposal requested/accepted hard-coded, or can it be configured?) - the subset of ISAKMP implemented (which, if any, optional features are implemented?) - the interface from the ISAKMP code to the IPSec code (known for Cisco's release). - Is the ISAKMP code separated from the cryptographic code? If so, does ISAKMP use a standardized CAPI (e.g. Cryptoki)? How much access does the ISAKMP code have to raw cryptographic key data? - robustness of code - How well structured and understandable is the code? How easily could a new DOI or policy engine be integrated? - performance Thank you in advance, Ruth Taylor From owner-ipsec Fri Jun 5 15:58:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01106 for ipsec-outgoing; Fri, 5 Jun 1998 15:57:40 -0400 (EDT) Message-Id: <199806052010.QAA19926@adk.gr> To: rct@epoch.ncsc.mil (Ruth C. Taylor) Cc: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: ISAKMP Implementation Analysis In-reply-to: Your message of "Fri, 05 Jun 1998 15:32:46 EDT." <9806051932.AA00265@gareb.epoch.ncsc.mil> Date: Fri, 05 Jun 1998 16:10:30 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: rct@epoch.ncsc.mil (Ruth C. Taylor) Subject: Re: ISAKMP Implementation Analysis Cc: ipsec@tis.com, isakmp-oakley@cisco.com Date: 06/05/98, 16:10:27 > I am interested in comparing current freely available ISAKMP- > Oakley implementations for BSD platforms, such as Cisco's ISAKMP > code and "Pluto" by Angelos Keromytis. I don't think there's any kind of comparison to be made here. The pluto code was written in 3 weeks' time, trying to meet a deadline. As such, it looks (looked) more like a prototype implementation than something that could/should be deployed. The FreeSWAN people are maintaining it (since June '97), and I'll let them answer your questions, since things are likely to have changed. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNXhQtL0pBjh2h1kFAQHOnwP7BDLNTOn3kfEXVPXxUgIeRXTigZd3IOrO cnRnwcEvW0yyE2Tseq9Dxm89PITbKytjmLuuu2m22OnoqshzGNgmYoFTFhrsD0xt nYwgE2OvoY1DxYgs4/YI53Yp6M189PbjcMrpLeZQReHvIN/FiV0ggQurOru68XXZ Vvx9d6penVQ= =zA0i -----END PGP SIGNATURE----- From owner-ipsec Fri Jun 5 16:20:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01186 for ipsec-outgoing; Fri, 5 Jun 1998 16:20:40 -0400 (EDT) From: John Ioannidis Date: Fri, 5 Jun 1998 16:34:59 -0400 (EDT) Message-Id: <199806052034.QAA08792@bual.research.att.com> To: ipsec@tis.com Subject: commercial IPSEC in Europe? Sender: owner-ipsec@ex.tis.com Precedence: bulk Are there any commercially available/supported IPSEC implementations in Europe? If the answer is "yes," which ones, and does anyone have experience with them? Thanks, /ji From owner-ipsec Fri Jun 5 19:18:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01468 for ipsec-outgoing; Fri, 5 Jun 1998 19:16:47 -0400 (EDT) Message-Id: <199806052331.TAA09200@jekyll.piermont.com> To: John Ioannidis cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? In-reply-to: Your message of "Fri, 05 Jun 1998 16:34:59 EDT." <199806052034.QAA08792@bual.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 05 Jun 1998 19:31:15 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk John Ioannidis writes: > Are there any commercially available/supported IPSEC implementations > in Europe? SSH Comsec's implementation is commercially available and supported, but it is targeted at manufacturers, not end users. Perry From owner-ipsec Sat Jun 6 17:41:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03319 for ipsec-outgoing; Sat, 6 Jun 1998 17:35:51 -0400 (EDT) Date: Sun, 7 Jun 1998 00:48:46 +0300 (IDT) From: Dan Frommer To: John Ioannidis Cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? In-Reply-To: <199806052034.QAA08792@bual.research.att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Are there any commercially available/supported IPSEC implementations > in Europe? If the answer is "yes," which ones, and does anyone have > experience with them? RADGUARD's IPsec gateways are available wordlwide. They demonstrated interoperability in the ANX and ICSA environments. See www.radguard.com for more details. Dan From owner-ipsec Sun Jun 7 06:23:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04183 for ipsec-outgoing; Sun, 7 Jun 1998 06:17:48 -0400 (EDT) Date: Sun, 7 Jun 1998 06:31:48 -0400 (EDT) From: Dave Mason Message-Id: <199806071031.GAA22660@rubicon.rv.tis.com> To: dan@radguard.com, ji@research.att.com Cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Are there any commercially available/supported IPSEC implementations >> in Europe? If the answer is "yes," which ones, and does anyone have >> experience with them? > >RADGUARD's IPsec gateways are available wordlwide. They demonstrated >interoperability in the ANX and ICSA environments. See www.radguard.com >for more details. Ditto for Network Associates GVPN Firewalls. -dmason From owner-ipsec Sun Jun 7 16:36:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05155 for ipsec-outgoing; Sun, 7 Jun 1998 16:32:00 -0400 (EDT) Message-Id: <4.0.1.19980607164429.0109e1b0@vpnet.com> X-Sender: jehorton@pop.erols.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 07 Jun 1998 16:45:41 -0400 To: ji@research.att.com From: "John E. Horton" Subject: Re: commercial IPSEC in Europe? Cc: ipsec@tis.com In-Reply-To: <199806071031.GAA22660@rubicon.rv.tis.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ditto for VPNet's VSU-1010. Check out www.vpnet.com. At 06:31 AM 6/7/98 -0400, Dave Mason wrote: >>> Are there any commercially available/supported IPSEC implementations >>> in Europe? If the answer is "yes," which ones, and does anyone have >>> experience with them? >> >>RADGUARD's IPsec gateways are available wordlwide. They demonstrated >>interoperability in the ANX and ICSA environments. See www.radguard.com >>for more details. > >Ditto for Network Associates GVPN Firewalls. > >-dmason > Regards, John Horton -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.2 iQA/AwUBNXr79NQXWH2P/o+pEQLJEwCffDEB2kThgZC8jvioJktmPDFJnKAAoLjx P7Qd4XohWeceS+59aB9Q9Lp9 =7EiV -----END PGP SIGNATURE----- From owner-ipsec Sun Jun 7 17:10:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05221 for ipsec-outgoing; Sun, 7 Jun 1998 17:08:59 -0400 (EDT) From: John Ioannidis Date: Sun, 7 Jun 1998 17:21:48 -0400 (EDT) Message-Id: <199806072121.RAA13826@bual.research.att.com> To: jehorton@erols.com, ji@research.att.com Cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? Sender: owner-ipsec@ex.tis.com Precedence: bulk > Ditto for VPNet's VSU-1010. Check out www.vpnet.com. You do not appear to have a european distributor. Do you have export licences for european countries? I somehow doubt that you have gotten an export licence for 3DES, and I am not going to advise anyone to use anything lesser! The same comment applies to the Network Associates firewalls (which dmason@tis.com suggested, but gave no URL pointing to them). To avoid turning this into a "we too" forum, please only respond to the query if your product is manufactured outside the USA and/or has no export restrictions whatsoever. Toy systems using single-des (or worse) need not apply! Thanks again, /ji PS: I know that my IPSEC code, ported by Angelos Keromytis, is available under OpenBSD, which does not suffer from export restrictions. However, noone seems to be supporting it commercially, and the intended audience needs a number they can call if something goes wrong. From owner-ipsec Mon Jun 8 03:56:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA06503 for ipsec-outgoing; Mon, 8 Jun 1998 03:49:59 -0400 (EDT) Date: Mon, 8 Jun 1998 04:03:49 -0400 (EDT) From: Dave Mason Message-Id: <199806080803.EAA12217@rubicon.rv.tis.com> To: jehorton@erols.com, ji@research.att.com Cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? Sender: owner-ipsec@ex.tis.com Precedence: bulk >The same comment applies to the Network Associates firewalls (which >dmason@tis.com suggested, but gave no URL pointing to them). www.tis.com -> tis -> gauntlet -> vpns [ -> sales for contacts in UK and Germany ] -dmason From owner-ipsec Mon Jun 8 05:47:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA06727 for ipsec-outgoing; Mon, 8 Jun 1998 05:44:59 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A23EB8@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: Rest of World encryption hardware products? Date: Mon, 8 Jun 1998 10:56:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Since it is not possible to ship worth-while encryption products from the US (40-bit restriction), are there any rest-of-world companies building hardware encryption? Thanks, Steve. Stephen Waters Devon, UK Tel: National 01548 551012 / 550474 International 44 1548 " " Stephen.Waters@Digital.com From owner-ipsec Mon Jun 8 10:10:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07981 for ipsec-outgoing; Mon, 8 Jun 1998 10:06:00 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199806081420.HAA27526@kc.livingston.com> Subject: Re: Comments on the latest Security architecture draft To: tytso@MIT.EDU Date: Mon, 8 Jun 1998 07:20:29 -0700 (PDT) Cc: suresh@livingston.com, matt@ljo.dec.com, ipsec@tis.com In-Reply-To: <199806051027.GAA00454@rsts-11.mit.edu> from "tytso@MIT.EDU" at Jun 5, 98 06:27:54 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Harold Koch cited where it is listed in the IKE document. The > Architecture Security document also has this to say: > > SPI > Acronym for "Security Parameters Index". The combination of a > destination address, a security protocol, and an SPI uniquely > identifies a security association (SA, see above). The SPI is > carried in AH and ESP protocols to enable the receiving system to > select the SA under which a received packet will be processed. An > SPI has only local significance, as defined by the creator of the > SA (usually the receiver of the packet carrying the SPI); thus an > SPI is generally viewed as an opaque bit string. However, the > creator of an SA may choose to interpret the bits in an SPI to > facilitate local processing. > > So it is there in the documents. > > - Ted > OK, you have the material in the Glosary section (Apendix A, page 47) of the Architecture document. I was looking to find this in the main portion of this document. Perhaps, more so in IKE/ISAKMP documents. Anyways, I would still recommend adding clarity to the text in IKE/ISAKMP drafts. One more thing: It seems, IKE negotiated ISAKMP/IPsec SA parameters must be symmetric in both directions. Is this true? If not, can you give me an example of how an asymmetric SA negotiation takes place, where the initiator proposes NULL ESP and the responder accepts with MD-5 AH . (i.e., initiator will receive NULL ESP packets and the responder will receive MD-5 AH packets). Thanks. cheers, suresh From owner-ipsec Mon Jun 8 10:46:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08097 for ipsec-outgoing; Mon, 8 Jun 1998 10:40:03 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199806081456.HAA28182@kc.livingston.com> Subject: Multi-homed nodes and SAs for incoming packets To: ipsec@tis.com Date: Mon, 8 Jun 1998 07:56:00 -0700 (PDT) Cc: suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Question on multi-homed nodes. This may have been previously hashed in the mailing list already. If so, I would appreciate if you could refer me to a mail archival. Thanks. Say, a VPN node X is multi-homed (i.e., has multiple network interfaces and IP addresses); and is using IKE application to negotiate IPsec SAs. X is supposed to use the tuple of (, SPI, ) to find the SA the incoming packet belongs to. In reality, the destination IP address doesnt matter so long as it matches one of the addresses used by X. Most nodes are likely to have a single SPI index table (per protocol, may be) for the box, not one for each address of the box. So, is it fair to assume that an SPI, once nogitiated using one address of the box, is equally valid for all addresses pertaining to the same box? If not, what are the logistics against this? Thanks. cheers, suresh From owner-ipsec Mon Jun 8 11:59:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08434 for ipsec-outgoing; Mon, 8 Jun 1998 11:53:11 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A23ECF@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Cc: Stephen Waters Subject: IKE implementation issues Date: Mon, 8 Jun 1998 17:04:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk 1) Processing of INBOUND Quick mode processing seems to have a problem. The SPD is searched to find an appropriate policy, but given the information available at the time, this has to be a guess, at best. The consequences are that data packets arriving on the resulting INBOUND SA may need to search the SPD for the correct match. This is not optimal. What is needed is a way to exchange (securely) the selectors used on the initiators policy. 2) Is it mandatory to respond to an Inbound SA request (responder) with an Outbound SA establishment (in a single Quick mode)? I would prefer not to set up the Outbound SA until outbound traffic presents itself. This allows me to use separate keys for inbound and outbound processes as well. As for question 1, if I am forced to setup an Outbound SA as a responder to an inbound request, I am likely to end up with a bad matching inbound policy AND a bad matching outbound policy (i.e. one that may never get used). 3) Why does Phase1 SA (IKE SA) need to be deleted when pfs is selected? Since DH is used in Phase-2, doesn't that remove the need to trash the Phase1 SA? Regards, Steve. From owner-ipsec Mon Jun 8 11:59:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08445 for ipsec-outgoing; Mon, 8 Jun 1998 11:56:01 -0400 (EDT) Message-Id: <199806081610.MAA06436@istari.sandelman.ottawa.on.ca> To: suresh@livingston.com (Pyda Srisuresh) CC: ipsec@tis.com Subject: Re: Multi-homed nodes and SAs for incoming packets In-reply-to: Your message of "Mon, 08 Jun 1998 07:56:00 PDT." <199806081456.HAA28182@kc.livingston.com> Date: Mon, 08 Jun 1998 12:10:43 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Let me turn it around: Since it is up to the destination node to allocate the SPI, and it can therefore make sure that its SPI, is unique, can you give a reason why anyone should care about whether or not a node considers its interfaces to be equivalent? There are serious security issues if the machine considers its interfaces equivalent for all operations, btw. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNXwNAdiXVu0RiA21AQGL4gMArRCXm/Djfcl/osgek62RJwjGjuMIZtak SLCBkr3pWjHGHxkRF4mEkVnyE5+w8AIbWsVynt9IFiecSA0sOntq/KgC6+xMYW96 c7O66OwEQ5YJ+Y69kci0JcASYVkY/TF/ =xWnn -----END PGP SIGNATURE----- From owner-ipsec Mon Jun 8 12:54:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08583 for ipsec-outgoing; Mon, 8 Jun 1998 12:49:03 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199806081703.KAA01705@kc.livingston.com> Subject: Re: Multi-homed nodes and SAs for incoming packets To: mcr@sandelman.ottawa.on.ca (Michael C. Richardson) Date: Mon, 8 Jun 1998 10:03:13 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <199806081610.MAA06436@istari.sandelman.ottawa.on.ca> from "Michael C. Richardson" at Jun 8, 98 12:10:43 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > Let me turn it around: > Since it is up to the destination node to allocate the SPI, > and it can therefore make sure that its SPI, is > unique, can you give a reason why anyone should care about > whether or not a node considers its interfaces to be equivalent? One reason would be to have fewer SAs. Say, my security policies allow VPNs to be established with peer nodes (identified by DNS FQDN name or address) on a policy based selection criteria. If I determine that an SA already exists to one of the addresses of a peer node, i would rather reuse the same outgoing SA for all of its addresses than establish one for each address. > > There are serious security issues if the machine considers > its interfaces equivalent for all operations, btw. > So long as all addresses are valid and equally accessible, what security issues are you concerned about? cheers, suresh From owner-ipsec Mon Jun 8 16:18:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09251 for ipsec-outgoing; Mon, 8 Jun 1998 16:10:31 -0400 (EDT) Message-Id: <199806082025.NAA07117@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Waters Cc: ipsec@tis.com Subject: Re: IKE implementation issues In-Reply-To: Your message of "Mon, 08 Jun 1998 17:04:56 BST." <250F9C8DEB9ED011A14D08002BE4F64C01A23ECF@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 Jun 1998 13:25:39 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 08 Jun 1998 17:04:56 BST you wrote > > 1) Processing of INBOUND Quick mode processing seems to > have a problem. > The SPD is searched to find an appropriate policy, but > given the information available at the time, > this has to be a guess, at best. What information is missing? > The consequences are that data packets arriving on the > resulting INBOUND SA may need to > search the SPD for the correct match. This is not > optimal. What is needed is a way to > exchange (securely) the selectors used on the initiators > policy. It's done in the ID payloads passed as part of the Quick Mode exchange. > 2) Is it mandatory to respond to an Inbound SA request > (responder) with an Outbound SA > establishment (in a single Quick mode)? I would prefer > not to set up the Outbound SA until > outbound traffic presents itself. This allows me to use > separate keys for inbound and outbound > processes as well. You'll have different keys if your SPIs are different (see recent post from D. Hugh Redelmeier on this subject). But to answer your question, yes, you have to respond with the outbound SA info complete with your SPI. > As for question 1, if I am forced to setup an Outbound > SA as a responder to an inbound request, > I am likely to end up with a bad matching inbound policy > AND a bad matching outbound policy > (i.e. one that may never get used). It is possible that you can set up an outbound SA that never gets used but that doesn't mean that you get bad matching inbound and outbound policy. If it's bad then don't accept it and don't set up any SAs. > 3) Why does Phase1 SA (IKE SA) need to be deleted when > pfs is selected? Since DH is used in > Phase-2, doesn't that remove the need to trash the > Phase1 SA? That's only if you want PFS for the identities as well as the keys. If you just want PFS for the phase 2 keys then you don't have to delete the phase 1 SA. Dan. From owner-ipsec Tue Jun 9 01:37:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA10705 for ipsec-outgoing; Tue, 9 Jun 1998 01:19:08 -0400 (EDT) Date: Tue, 9 Jun 1998 01:28:12 -0400 From: Ran Canetti Message-Id: <9806090528.AA32190@ornavella.watson.ibm.com> To: benny@watson.ibm.com, canetti@watson.ibm.com, ipsec@tis.com Subject: Multicast security issues I-D Sender: owner-ipsec@ex.tis.com Precedence: bulk Benny Pinkas and me have written an I-D that discusses multicast security issues, and contains a short mini-survey on some existing works on the topic. (Most of these issues were telegraphically mentioned in my talk at the LA meeting.) Hopefully, this will be a first step towards good solutions to this problem. The current version (to be made available by the I-D secretariat soon) is tentative. I would like to encourage and ask those who are intrested in the topic to take a look and give us their comments. We will do our best to incorporate these remarks in the next version. Ran From owner-ipsec Tue Jun 9 03:28:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA11134 for ipsec-outgoing; Tue, 9 Jun 1998 03:10:17 -0400 (EDT) Message-Id: <3.0.3.32.19980609002519.009c0d80@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 09 Jun 1998 00:25:19 -0700 To: Stephen Waters , ipsec@tis.com From: Alex Alten Subject: Re: Rest of World encryption hardware products? In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23EB8@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:56 AM 6/8/98 +0100, Stephen Waters wrote: > > Since it is not possible to ship worth-while encryption products >from the US (40-bit restriction), Actually that is not true anymore. TriStrata Security just announced a fully exportable, unlimited key strength encryption product. Here's their URL. http://www.tristrata.com You may want to call the Price Waterhouse ISRM consultants over there in London, they are a TriStrata sales partner. Try Alastair MacWillson at 44-171-939-2199. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Tue Jun 9 05:28:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA11686 for ipsec-outgoing; Tue, 9 Jun 1998 05:21:20 -0400 (EDT) From: John Ioannidis Date: Tue, 9 Jun 1998 05:33:49 -0400 (EDT) Message-Id: <199806090933.FAA22007@bual.research.att.com> To: Andrade@ix.netcom.com, Stephen.Waters@digital.com, ipsec@tis.com Subject: Re: Rest of World encryption hardware products? Sender: owner-ipsec@ex.tis.com Precedence: bulk > Actually that is not true anymore. TriStrata Security just announced > a fully exportable, unlimited key strength encryption product. Here's > their URL. > > http://www.tristrata.com Don't bother -- it's snake oil. This is the first paragraph of text in their home page: Based on the only theoretically unbreakable encryption - the Vernam Cipher. Over the past 5 years, TriStrata has perfected Random KeyStream[tm] (RKS[tm]) Technology, a new fundamental technology to secure the Internet, based on the Vernam Cipher one-time pad, which was invented in 1917. I hope y'all had a good laugh. /ji From owner-ipsec Tue Jun 9 07:23:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12109 for ipsec-outgoing; Tue, 9 Jun 1998 07:16:20 -0400 (EDT) Message-Id: <3.0.1.32.19980609163900.0069ac44@172.16.1.10> X-Sender: ramana@172.16.1.10 (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 09 Jun 1998 16:39:00 +0500 To: ipsec@tis.com From: Ramana Yarlagadda Subject: independent SAs linking Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Sumit from:draft-ietf-ipsec-arch-sec-05.txt (page 27) Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine(H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall(SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway". ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server Only tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case2. The choices for the SA between H1 and H2 would be one of the ones in case 1. Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configu- -ration of the SPD and SAD to ensure this ordering of IPsec header application. As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. *****I need some clarification at these points***** Let us assume that from H1 to SG2 we have ESP in tunnel mode and from H1 to H2 we have AH in transport mode. 1) How do we negotiate SA's ? Suppose H1 starts negotiation then it will end up in creating two SA's, one from H1 to SG2 and another from H1 to H2. In such case since the proposal are sent from the same SPD entry both the SA's negotiated will form a single bundle on H1's SPD. ButSG2 and H2 will have only one SA created on their end. So when the packet is sent out from H1 both the SA's will be app- -lied, and correspondingly SG2 will decrypt and then it will be passed to H2 that is our final destination. The matching SPD entry in H1 would have two protocols to be applied out of which one is to SG2 and the other is to H2. But ...when H2 initiates SA negotioation for the above case. H2 has an SPD entry that says that AH has to be applied in transport mode.This creates the ISAKMP SA between H1 and H2 and then the AH SA. H2 applies it and sends it out. Now, this comes to SG2 which now negotiates the ESP SA in tunnel mode with H1. Since these SAs form independently and match the same SPD entry (will they?) in H1, how are these linked together to be a single SA bundle for any data that will be sent out from H1? If these are independent SAs linked to the outbound SPD entry, we will have to search through the list of bundles looking for those that match and applying them in the sequence that is determined by the policy. But, this is not how IPSEC architecture outlines the processing of a datagram. So, what does happen in this case? How do we link two SAs that are negotiated independently together? -thanks -ramana * Ramana Yarlagadda * Rendezvous On Chip Pvt Ltd. * NewVasaviNagar, Kharkhana, * SECUNDERABAD - 500015. * INDIA * Tele Phone : (040) 7742606, 7740406 * Email : ramana@trinc.com * http://www.trinc.com ****************************************************************** From owner-ipsec Tue Jun 9 09:44:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13169 for ipsec-outgoing; Tue, 9 Jun 1998 09:42:19 -0400 (EDT) Date: Tue, 9 Jun 1998 16:48:23 +0300 (EET DST) From: Jani Hursti To: John Ioannidis cc: ipsec@tis.com Subject: Re: commercial IPSEC in Europe? In-Reply-To: <199806052034.QAA08792@bual.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 5 Jun 1998, John Ioannidis wrote: > Are there any commercially available/supported IPSEC implementations > in Europe? If the answer is "yes," which ones, and does anyone have > experience with them? > Yes, there are. SSH Communications Security produces an easy-to-use, military grade encryption toolkit targeted especially for router, access router, VPN, and firewall vendors. The toolkit has been fully tested to be interoperable at ANX, provides strong, lightning fast crypto without any export restrictions, and if that is not enough, it is easy to plug-in hardware crypto (either European or non-European), too. For more details see http://www.ipsec.com Cheers, Jani Hursti -- Jani Hursti Tel: +358-40-521 9281 SSH Communications Security Ltd. Fax: +358-9-4354 3206 [SSH IPSEC Express http://www.ssh.fi - hands-on security toolkit] Tekniikantie 12, FIN-02150 Espoo, Finland From owner-ipsec Tue Jun 9 09:52:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13256 for ipsec-outgoing; Tue, 9 Jun 1998 09:52:19 -0400 (EDT) Message-Id: <199806091402.KAA22305@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-canetti-secure-multicast-taxonomy-00.txt Date: Tue, 09 Jun 1998 10:02:55 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: The document is related to work to be done at a secure multicast working group, that is currently being formed in the IRTF. This working group is an offspring of the IPSEC working group. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A taxonomy of multicast security issues (temporary version) Author(s) : B. Pinkas, R. Canetti Filename : draft-canetti-secure-multicast-taxonomy-00.txt Pages : 13 Date : 08-Jun-98 With the growth and commercialization of the Internet, the need for secure IP multicast is growing. In this draft we present a taxonomy of multicast security issues. We first sketch some multicast group parameters that are relevant to security, and outline the basic security issues concerning multicast in general, with emphasis on IP multicast. Next we suggest two `benchmark' scenarios for secure multicast solutions. Lastly we review some previous works. This is a temporary version of the document. The authors will be grateful for remarks, and will update and revise this document accordingly. 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-canetti-secure-multicast-taxonomy-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-canetti-secure-multicast-taxonomy-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-canetti-secure-multicast-taxonomy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980608154316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-canetti-secure-multicast-taxonomy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-canetti-secure-multicast-taxonomy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980608154316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Jun 9 11:38:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13939 for ipsec-outgoing; Tue, 9 Jun 1998 11:37:21 -0400 (EDT) Message-Id: <199806091548.LAA01720@thunk.epilogue.com> From: Bill Sommerfeld To: Alex Alten cc: Stephen Waters , ipsec@tis.com Subject: Re: Rest of World encryption hardware products? In-reply-to: Your message of "Tue, 09 Jun 1998 00:25:19 PDT." <3.0.3.32.19980609002519.009c0d80@netcom.com> Date: Tue, 09 Jun 1998 11:48:05 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Since it is not possible to ship worth-while encryption products > >from the US (40-bit restriction), > > Actually that is not true anymore. TriStrata Security just announced > a fully exportable, unlimited key strength encryption product. Here's > their URL. > > http://www.tristrata.com I read the whitepaper on the site. It contains a number of phrases which should set off any crypto expert's snake-oil detectors, the most crucial being "virtual one time pad". It also has built-in key recovery, and appears to require interaction with a centralized network service for all encryption and decryption. As described, it also has good potential to have severe scaling problems. My advice is "run away screaming". - Bill From owner-ipsec Tue Jun 9 14:49:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15102 for ipsec-outgoing; Tue, 9 Jun 1998 14:47:22 -0400 (EDT) Message-Id: <98Jun9.150314edt.11651@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: DSS support? From: "C. Harald Koch" Date: Tue, 9 Jun 1998 15:02:30 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk Anyone out there got an ISAKMP implementation that implements DSS/DSA (pick your favourite acronym), and would be willing to to some over-the-net interop testing? Thanks, -- C. Harald Koch "Madness takes its toll. Please have exact change." -Karen Murphy From owner-ipsec Tue Jun 9 17:25:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15740 for ipsec-outgoing; Tue, 9 Jun 1998 17:24:39 -0400 (EDT) Message-Id: <357DAB99.39BB@xedia.com> Date: Tue, 09 Jun 1998 17:39:37 -0400 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: ietf-lsd@listserv.umu.se, ipsec@tis.com, spki@c2.net Subject: DNS and X.501 DistinguishedName Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk A network entity such as a router may require an X.501 DistinguishedName to utilize LDAP directory serices or generate PKCS certificate requests. It's possible that the network entity can use it's domain name to create an X.500 Distinguished Name as specified in RFC2247. However, I'm concerned that this might be too inflexible since many organizations may implement an internal X.500 naming convention unrelated to their Internet domain naming. Has any MIB work been done to support distinguished name configuration? Thanks in advance, Eric Bomarsi From owner-ipsec Tue Jun 9 17:25:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15739 for ipsec-outgoing; Tue, 9 Jun 1998 17:24:38 -0400 (EDT) From: Cliff Wang To: Subject: cert request or cert repository? Message-ID: <5040200015968756000002L062*@MHS> Date: Tue, 9 Jun 1998 17:46:27 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk When an ISAKMP received a signature payload without the optional certificate payload, in order to get the peer's public key for signature verfication, shall the ISAKMP send a certificate request to the peer or try to retrieve it through certificate repository? Seems that sending a certificate request makes more sense. Thanks! Cliff Wang cxwang@us.ibm.com From owner-ipsec Tue Jun 9 20:35:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16302 for ipsec-outgoing; Tue, 9 Jun 1998 20:33:52 -0400 (EDT) Message-ID: <70C20C1647EBD11183F800805FA67B4308B62C@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: RE: cert request or cert repository? Date: Tue, 9 Jun 1998 17:48:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Cliff, Requesting a cert on receiving a signature payload won't work for either main mode or for aggressive mode. By the time the signature payload is received, its too late. Consider main mode. The responder will receive the signature payload in message 5. So he would have to request a cert in message 6. That's the last message of the exchange, so the initiator cannot send its cert. Similarly, the initiator sees a signature payload only in message 6. So, for them to exchange certs, main mode would have to be extended beyond 6 messages and that's not allowed. From section 5 of IKE, Exchanges in IKE are not open ended and have a fixed number of messages. Receipt of a Certificate Request payload MUST NOT extend the number of messages transmitted or expected. This topic came up on the list some time back. You may want to check the archives. Sumit A. Vakil VPNet Technologies, Inc. > -----Original Message----- > From: Cliff Wang [SMTP:cxwang@us.ibm.com] > Sent: Tuesday, June 09, 1998 2:46 PM > To: ipsec@tis.com > Subject: cert request or cert repository? > > When an ISAKMP received a signature payload > without the optional certificate payload, in order to > get the peer's public key for signature verfication, > shall the ISAKMP send a certificate request to the > peer or try to retrieve it through certificate repository? > Seems that sending a certificate request makes > more sense. Thanks! > > Cliff Wang > cxwang@us.ibm.com From owner-ipsec Wed Jun 10 02:13:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA17337 for ipsec-outgoing; Wed, 10 Jun 1998 02:09:54 -0400 (EDT) Message-Id: <3.0.5.32.19980610092559.009eed90@127.0.0.1> X-Sender: ilkka@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Jun 1998 09:25:59 +0300 To: John Ioannidis (by way of Juha =?iso-8859-1?Q?K=E4ki?= ) From: Ilkka Ranta Subject: Re: commercial IPSEC in Europe? Cc: ipsec@tis.com, f-secure-marketing@datafellows.com In-Reply-To: <3.0.5.32.19980609135513.00b3ea70@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk John, Data Fellows does also have an own IPSec implementation under the product family F-Secure VPN+. As a Finnish company we are not restricted by the US ITAR laws, and thus we can provide strong uncompromised cryptography worldwide. For more information please check http://www.DataFellows.com/f-secure/vpn-plus/ Regards, Ilkka Ranta Data Fellows Ltd. http://www.DataFellows.com At 13:55 9.6.1998 +0300, you wrote: >Are there any commercially available/supported IPSEC implementations >in Europe? If the answer is "yes," which ones, and does anyone have >experience with them? > >Thanks, > >/ji > From owner-ipsec Wed Jun 10 03:33:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA17657 for ipsec-outgoing; Wed, 10 Jun 1998 03:32:59 -0400 (EDT) Message-Id: <3.0.3.32.19980610004741.009af1a0@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 10 Jun 1998 00:47:41 -0700 To: Bill Sommerfeld From: Alex Alten Subject: Re: Rest of World encryption hardware products? Cc: Stephen Waters , ipsec@tis.com In-Reply-To: <199806091548.LAA01720@thunk.epilogue.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id DAA17652 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:48 AM 6/9/98 -0400, Bill Sommerfeld wrote: >> > Since it is not possible to ship worth-while encryption products >> >from the US (40-bit restriction), >> >> Actually that is not true anymore. TriStrata Security just announced >> a fully exportable, unlimited key strength encryption product. Here's >> their URL. >> >> http://www.tristrata.com > >I read the whitepaper on the site. It contains a number of phrases >which should set off any crypto expert's snake-oil detectors, the most >crucial being "virtual one time pad". > I don't think you need to take quotes out of context and change their wording. Here's exactly what was written. "With RKS, a Random KeyStream derived from a physical random number generator is used as the cipher key. Conforming to the requirements for a practical Vernam Cipher, the Random KeyStream is the same length as the message and will not repeat with a small statistical probability. The secret is the effective management of a virtual keystream over 10³º bytes long." It is not claiming to be perfect, there is a small statistical probability of a repetition. Obviously you can't store a 10^30 byte 1-time pad. So it has to be generated from a smaller amount of random data. However the solution is elegant and has been reviewed by some top cryptographers, like Bart Preneel and Fred Piper. So far it has held up under tough analysis, including by some cryptographers over at Bell Labs. It's effective key strength is 128 bits. >It also has built-in key recovery, and appears to require interaction >with a centralized network service for all encryption and decryption. >As described, it also has good potential to have severe scaling >problems. > The built in key recovery is why the unrestricted export license was granted. No keys are escrowed with the government or third party agencies (unlike TIS's solution). This is very powerful stuff. Any company in the world, except for places like Iraq, can buy the system and keep their keys to themselves. Key recovery is at their own discretion, not forced upon them by the US government. As for scaling, I guess if you can exceed 2 thousand requests per server per second, then you've got a problem. It ships as a dual server system. This sure beats the hell out of Public Key implementations which can't do more than 10 per sec. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Wed Jun 10 07:36:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18262 for ipsec-outgoing; Wed, 10 Jun 1998 07:32:00 -0400 (EDT) Message-Id: <199806101142.HAA06129@postal.research.att.com> To: Alex Alten cc: Bill Sommerfeld , Stephen Waters , ipsec@tis.com Subject: Re: Rest of World encryption hardware products? Date: Wed, 10 Jun 1998 07:42:08 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > >I read the whitepaper on the site. It contains a number of phrases >which should set off any crypto expert's snake-oil detectors, the mos t >crucial being "virtual one time pad". > I don't think you need to take quotes out of context and change their wording. Here's exactly what was written. "With RKS, a Random KeyStream derived from a physical random number generator is used as the cipher key. Conforming to the requirements for a practical Vernam Cipher, the Random KeyStream is the same length as the message and will not repeat with a small statistical probability. The secret is the effective management of a virtual keystream over 10³º bytes long." It is not claiming to be perfect, there is a small statistical probability of a repetition. Obviously you can't store a 10^30 byte 1-time pad. So it has to be generated from a smaller amount of random data. However the solution is elegant and has been reviewed by some top cryptographers, like Bart Preneel and Fred Piper. So far it has held up under tough analysis, including by some cryptographers over at Bell Labs. It's effective key strength is 128 bits. Your own excerpts prove Bill's point. The web page is full of statements about how the Vernam cipher is theoretically unbreakable. But a Vernam cipher requires a *true* random key stream as long as the message. It is *not* a cipher where you XOR the message with a pseudo-random key stream. But that's precisely what this cipher is doing -- you say so, in about those words. This is an ordinary stream cipher, not a one-time pad. I have no intrinsic objection to stream ciphers, though using them properly requires a great deal of care. I have serious objections to misleading advertising. >It also has built-in key recovery, and appears to require interaction >with a centralized network service for all encryption and decryption. >As described, it also has good potential to have severe scaling >problems. > The built in key recovery is why the unrestricted export license was granted. No keys are escrowed with the government or third party agencies (unlike TIS's solution). This is very powerful stuff. Any company in the world, except for places like Iraq, can buy the system and keep their keys to themselves. Key recovery is at their own discretion, not forced upon them by the US government. I'm not certain how this works. But let me shoot down a strawman. Suppose that this system did indeed use a true one-time pad. A customer would be shipped N copies of a CD-ROM of true-random bits -- about 4800M of them. The purpose of the server, then, would be to allocate chunks of the bitstream to clients, ensuring that no portion was ever reused (remember Venona?). Such a system would be a theoretician's delight and a practical nightmare. The problem is that you have to maintain perfect security on *every* copy of the CD-ROM. If one of the N is stolen (or the machine with it hacked), all past, present, and future conversations are compromised. And the probability of that happening is exponential in N. In other words, it doesn't scale at all. It's also obvious that 4800 Mbits doesn't last very long -- less than an hour at T-1 speeds. So you'd have to switch CD-ROMs -- simultaneously; everyone needs to be playing off the same score -- and safeguard all of the old CD-ROMs as well. Key recovery, of course, is simple in such a scheme: you turn over the CD-ROM to the government on demand. In all seriousness, DES in OFB mode is likely to be more secure in practice. IDEA or CAST-128 in OFB mode would be even better; they have a key size of 128 bits. Of course, this scheme is clearly not a true one-time-pad. The real question is how the key stream is generated from the keying material. Is it a published algorithm? If not, I'm very unlikely to trust it even if the Web page were not misleading. As for scaling, I guess if you can exceed 2 thousand requests per serv er per second, then you've got a problem. It ships as a dual server system. This sure beats the hell out of Public Key implementations which can't do more than 10 per sec. 10 per second *per machine communicating*. And public key systems can set up a secure channel even if the KDC is unreachable; this scheme can't. From owner-ipsec Wed Jun 10 09:06:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19057 for ipsec-outgoing; Wed, 10 Jun 1998 09:04:00 -0400 (EDT) Message-ID: From: Greg Carter To: ietf-lsd@listserv.umu.se, ipsec@tis.com, "'Eric Bomarsi'" Subject: RE: DNS and X.501 DistinguishedName Date: Wed, 10 Jun 1998 09:16:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Eric, For X.509 (PKCS10 requests or PKIX requests) you should look at the subjectAltName extension. It allows the certification authority to list a number of alternative names which the entity is associated with. This list can include name types such as IP Address, DNS, and rfc822 names. Therefore the network device can have it's DNS and/or IP Address stored in the certificate, while having an X.500 DN that fits the organizations directory structure. >From X.509 12.3.2.1 Subject alternative name field This field contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the CA to the certified public key. This field is defined as follows: subjectAltName EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName } GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OTHER-NAME ::= TYPE-IDENTIFIER EDIPartyName ::= SEQUENCE { nameAssigner [0] DirectoryString {ub-name} OPTIONAL, partyName [1] DirectoryString {ub-name} } The values in the alternatives of the GeneralName type are names of various forms as follows: - otherName is a name of any form defined as an instance of the OTHER-NAME information object class; - rfc822Name is an Internet electronic mail address defined in accordance with Internet RFC 822; - dNSName is an Internet domain name defined in accordance with Internet RFC 1035; - x400Address is an O/R address defined in accordance with ITU-T Rec. X.411 | ISO/IEC 10021-4; - directoryName is a directory name defined in accordance with ITU-T Rec. X.501 | ISO/IEC 9594-2; - ediPartyName is a name of a form agreed between communicating Electronic Data Interchange partners; the nameAssigner component identifies an authority that assigns unique values of names in the partyName component; - uniformResourceIdentifier is a Uniform Resource Identifier for the World-Wide Web defined in accordance with Internet RFC 1630; - iPAddress is an Internet Protocol address defined in accordance with Internet RFC 791, represented as a binary string. - registeredID is an identifier of any registered object assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1. For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users. This extension may, at the option of the certificate issuer, be either critical or non-critical. An implementation which supports this extension is not required to be able to process all name forms. If the extension is flagged critical, at least one of the name forms that is present shall be recognized and processed, otherwise the certificate shall be considered invalid. Apart from the preceding restriction, a certificate-using system is permitted to ignore any name with an unrecognized or unsupported name form. It is recommended that, provided the subject field of the certificate contains a directory name that unambiguously identifies the subject, this field be flagged non-critical. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Eric Bomarsi[SMTP:ebomarsi@xedia.com] > Sent: Tuesday, June 09, 1998 5:39 PM > To: ietf-lsd@listserv.umu.se; ipsec@tis.com; spki@c2.net > Subject: DNS and X.501 DistinguishedName > > A network entity such as a router may require > an X.501 DistinguishedName to utilize LDAP > directory serices or generate PKCS certificate > requests. > > It's possible that the network entity can > use it's domain name to create an X.500 > Distinguished Name as specified in RFC2247. > However, I'm concerned that this might be too > inflexible since many organizations may > implement an internal X.500 naming convention > unrelated to their Internet domain naming. > > Has any MIB work been done to support > distinguished name configuration? > > Thanks in advance, > Eric Bomarsi > From owner-ipsec Wed Jun 10 10:05:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA19424 for ipsec-outgoing; Wed, 10 Jun 1998 10:03:05 -0400 (EDT) Date: Wed, 10 Jun 1998 10:17:24 -0400 Message-Id: <199806101417.KAA01797@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: Andrade@ix.netcom.com Cc: sommerfeld@orchard.arlington.ma.us, Stephen.Waters@digital.com, ipsec@tis.com Subject: Re: Rest of World encryption hardware products? References: <199806091548.LAA01720@thunk.epilogue.com> <3.0.3.32.19980610004741.009af1a0@netcom.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA19421 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Alex" == Alex Alten writes: Alex> At 11:48 AM 6/9/98 -0400, Bill Sommerfeld wrote: >>> > Since it is not possible to ship worth-while encryption >>> products >from the US (40-bit restriction), >>> >>> Actually that is not true anymore. TriStrata Security just >>> announced a fully exportable, unlimited key strength encryption >>> product. Here's their URL. >>> >>> http://www.tristrata.com >> I read the whitepaper on the site. It contains a number of >> phrases which should set off any crypto expert's snake-oil >> detectors, the most crucial being "virtual one time pad". >> Alex> I don't think you need to take quotes out of context and change Alex> their wording. Here's exactly what was written. Alex> "With RKS, a Random KeyStream derived from a physical random Alex> number generator is used as the cipher key. Conforming to the Alex> requirements for a practical Vernam Cipher, the Random Alex> KeyStream is the same length as the message and will not repeat Alex> with a small statistical probability. The secret is the Alex> effective management of a virtual keystream over 10³º bytes Alex> long." Alex> It is not claiming to be perfect, there is a small statistical Alex> probability of a repetition. Obviously you can't store a 10^30 Alex> byte 1-time pad. So it has to be generated from a smaller Alex> amount of random data. However the solution is elegant and has Alex> been reviewed by some top cryptographers, like Bart Preneel and Alex> Fred Piper. So far it has held up under tough analysis, Alex> including by some cryptographers over at Bell Labs. It's Alex> effective key strength is 128 bits. So what you're saying is that Bill and others were EXACTLY right. If the effective key strength is 128 bits, it may be a decent cryptosystem. (It doesn't follow that it will be, since key length is necessary but not sufficient.) However, the reason the comment "snake oil detectors" is valid is that such a system, by your own statement, is NOT a Vernam cypher, is not related to the Vernam cypher, and has NONE of the properties of a Vernam cypher. Any claim to the contrary IS snake oil and is likely to be interpreted as an attempt to mislead the gullible. A Vernam cypher has a random key of length equal to the plaintext. Period. Full stop. Then and only then will it have the "provably unbreakable" property that makes it unique among cryptosystems. paul From owner-ipsec Wed Jun 10 10:06:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA19441 for ipsec-outgoing; Wed, 10 Jun 1998 10:04:05 -0400 (EDT) Message-Id: <199806101414.KAA24707@jekyll.piermont.com> To: Alex Alten cc: Bill Sommerfeld , Stephen Waters , ipsec@tis.com Subject: Re: Rest of World encryption hardware products? In-reply-to: Your message of "Wed, 10 Jun 1998 00:47:41 PDT." <3.0.3.32.19980610004741.009af1a0@netcom.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 10 Jun 1998 10:14:37 -0400 From: "Perry E. Metzger" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA19438 Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > At 11:48 AM 6/9/98 -0400, Bill Sommerfeld wrote: > >> > Since it is not possible to ship worth-while encryption products > >> >from the US (40-bit restriction), > >> > >> Actually that is not true anymore. TriStrata Security just announced > >> a fully exportable, unlimited key strength encryption product. Here's > >> their URL. > >> > >> http://www.tristrata.com > > > >I read the whitepaper on the site. It contains a number of phrases > >which should set off any crypto expert's snake-oil detectors, the most > >crucial being "virtual one time pad". > > > > I don't think you need to take quotes out of context and change > their wording. Here's exactly what was written. The term "Vernam Cipher" is a bell ringer. I agree with Mr. Sommerfeld on this. It doesn't smell very good. .pm > > "With RKS, a Random KeyStream derived from a physical random > number generator is used as the cipher key. Conforming to the > requirements for a practical Vernam Cipher, the Random KeyStream > is the same length as the message and will not repeat with a > small statistical probability. The secret is the effective > management of a virtual keystream over 10³º bytes long." > > It is not claiming to be perfect, there is a small statistical > probability of a repetition. Obviously you can't store a 10^30 > byte 1-time pad. So it has to be generated from a smaller > amount of random data. However the solution is elegant and > has been reviewed by some top cryptographers, like Bart Preneel > and Fred Piper. So far it has held up under tough analysis, > including by some cryptographers over at Bell Labs. It's > effective key strength is 128 bits. > > >It also has built-in key recovery, and appears to require interaction > >with a centralized network service for all encryption and decryption. > >As described, it also has good potential to have severe scaling > >problems. > > > > The built in key recovery is why the unrestricted export license was > granted. No keys are escrowed with the government or third party > agencies (unlike TIS's solution). This is very powerful stuff. Any > company in the world, except for places like Iraq, can buy the system > and keep their keys to themselves. Key recovery is at their own > discretion, not forced upon them by the US government. > > As for scaling, I guess if you can exceed 2 thousand requests per server > per second, then you've got a problem. It ships as a dual server > system. This sure beats the hell out of Public Key implementations > which can't do more than 10 per sec. > > - Alex > -- > Alex Alten > Andrade@Netcom.Com > P.O. Box 11406 > Pleasanton, CA 94588 USA > (510) 417-0159 > From owner-ipsec Wed Jun 10 13:46:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20329 for ipsec-outgoing; Wed, 10 Jun 1998 13:42:15 -0400 (EDT) Date: Wed, 10 Jun 1998 09:36:04 -0400 From: yjj@mci.net (Yuan John Jiang) Message-Id: <199806101336.JAA07593@cletus.> To: Andrade@ix.netcom.com, sommerfeld@orchard.arlington.ma.us Cc: Stephen.Waters@digital.com, ipsec@tis.com Subject: Re: Rest of World encryption hardware products? Sender: owner-ipsec@ex.tis.com Precedence: bulk >"With RKS, a Random KeyStream derived from a physical random >number generator is used as the cipher key. Conforming to the >requirements for a practical Vernam Cipher, the Random KeyStream >is the same length as the message and will not repeat with a >small statistical probability. The secret is the effective >management of a virtual keystream over 10³º bytes long." Forgive me if I'm wrong. But doesn't "will not repeat with a small statistical probability" mean "will repeat with a high probability"? John From owner-ipsec Wed Jun 10 14:02:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20381 for ipsec-outgoing; Wed, 10 Jun 1998 14:02:19 -0400 (EDT) Message-Id: <357ECD51.6DB@xedia.com> Date: Wed, 10 Jun 1998 14:15:45 -0400 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: Greg Carter Cc: ietf-lsd@listserv.umu.se, ipsec@tis.com, ietf-pkix@imc.org Subject: Re: DNS and X.501 DistinguishedName References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks Greg, I see. So I can generate an X.509 certificate request from the system's domain name or one of it's IP addresses, (and I should make that user selectable.) However, the subjectAltName is specific to an X.509 certificate request and so I believe I still need a way to enter an X.500 distinguished name into the system for LDAP services, unless there is a similar alternate name construct for LDAP? /Eric Bomarsi Greg Carter wrote: > > Hi Eric, > > For X.509 (PKCS10 requests or PKIX requests) you should look at the > subjectAltName extension. It allows the certification authority to list a > number of alternative names which the entity is associated with. This list > can include name types such as IP Address, DNS, and rfc822 names. Therefore > the network device can have it's DNS and/or IP Address stored in the > certificate, while having an X.500 DN that fits the organizations directory > structure. > > >From X.509 > 12.3.2.1 Subject alternative name field > This field contains one or more alternative names, using any of a variety of > name forms, for the entity that is bound by the CA to the certified public > key. This field is defined as follows: > subjectAltName EXTENSION ::= { > SYNTAX GeneralNames > IDENTIFIED BY id-ce-subjectAltName } > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > GeneralName ::= CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER } > > OTHER-NAME ::= TYPE-IDENTIFIER > > EDIPartyName ::= SEQUENCE { > nameAssigner [0] DirectoryString {ub-name} OPTIONAL, > partyName [1] DirectoryString {ub-name} } > The values in the alternatives of the GeneralName type are names of various > forms as follows: > - otherName is a name of any form defined as an instance of > the OTHER-NAME information object class; > - rfc822Name is an Internet electronic mail address defined in > accordance with Internet RFC 822; > - dNSName is an Internet domain name defined in accordance > with Internet RFC 1035; > - x400Address is an O/R address defined in accordance with > ITU-T Rec. X.411 | ISO/IEC 10021-4; > - directoryName is a directory name defined in accordance with > ITU-T Rec. X.501 | ISO/IEC 9594-2; > - ediPartyName is a name of a form agreed between > communicating Electronic Data Interchange partners; the nameAssigner > component identifies an authority that assigns unique values of names in the > partyName component; > - uniformResourceIdentifier is a Uniform Resource Identifier > for the World-Wide Web defined in accordance with Internet RFC 1630; > - iPAddress is an Internet Protocol address defined in > accordance with Internet RFC 791, represented as a binary string. > - registeredID is an identifier of any registered object > assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1. > For every name form used in the GeneralName type, there shall be a name > registration system that ensures that any name used unambiguously identifies > one entity to both certificate issuer and certificate users. > This extension may, at the option of the certificate issuer, be either > critical or non-critical. An implementation which supports this extension is > not required to be able to process all name forms. If the extension is > flagged critical, at least one of the name forms that is present shall be > recognized and processed, otherwise the certificate shall be considered > invalid. Apart from the preceding restriction, a certificate-using system is > permitted to ignore any name with an unrecognized or unsupported name form. > It is recommended that, provided the subject field of the certificate > contains a directory name that unambiguously identifies the subject, this > field be flagged non-critical. > > ---- > Greg Carter, Entrust Technologies > greg.carter@entrust.com > > > ---------- > > From: Eric Bomarsi[SMTP:ebomarsi@xedia.com] > > Sent: Tuesday, June 09, 1998 5:39 PM > > To: ietf-lsd@listserv.umu.se; ipsec@tis.com; spki@c2.net > > Subject: DNS and X.501 DistinguishedName > > > > A network entity such as a router may require > > an X.501 DistinguishedName to utilize LDAP > > directory serices or generate PKCS certificate > > requests. > > > > It's possible that the network entity can > > use it's domain name to create an X.500 > > Distinguished Name as specified in RFC2247. > > However, I'm concerned that this might be too > > inflexible since many organizations may > > implement an internal X.500 naming convention > > unrelated to their Internet domain naming. > > > > Has any MIB work been done to support > > distinguished name configuration? > > > > Thanks in advance, > > Eric Bomarsi > > From owner-ipsec Wed Jun 10 17:04:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20921 for ipsec-outgoing; Wed, 10 Jun 1998 17:01:16 -0400 (EDT) Message-ID: <59726335C162D111B2CF00805FA7205DC1BB07@csifiapp621.wepex.net> From: "Burden, James" To: "'ipsec@tis.com'" Subject: FW: Rest of World encryption hardware products? Date: Wed, 10 Jun 1998 14:16:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA20918 Sender: owner-ipsec@ex.tis.com Precedence: bulk Providing proxy for.... > -----Original Message----- > From: Litney, Tom > Sent: Wednesday, June 10, 1998 1:21 PM > To: Burden, James > Subject: RE: Rest of World encryption hardware products? > > Alex, > > Not sure what you meant by taking the quote out of context and > changing the wording. When I visited the site using the URL that Bill > provided, I found his quote listed as the first bullet point on the > page. The quote that you are suppling come from another page which > was apparently intended to provided more product detail. I won't go > into the cryptographic issues as they have already been so eloquently > voiced by others. > > > Tom > > > -----Original Message----- > From: Alex Alten [SMTP:Andrade@ix.netcom.com] > Sent: Wednesday, June 10, 1998 12:48 AM > To: Bill Sommerfeld > Cc: Stephen Waters; ipsec@tis.com > Subject: Re: Rest of World encryption hardware products? > > At 11:48 AM 6/9/98 -0400, Bill Sommerfeld wrote: > >> > Since it is not possible to ship worth-while encryption products > >> >from the US (40-bit restriction), > >> > >> Actually that is not true anymore. TriStrata Security just > announced > >> a fully exportable, unlimited key strength encryption product. > Here's > >> their URL. > >> > >> http://www.tristrata.com > > > >I read the whitepaper on the site. It contains a number of phrases > >which should set off any crypto expert's snake-oil detectors, the > most > >crucial being "virtual one time pad". > > > > I don't think you need to take quotes out of context and change > their wording. Here's exactly what was written. > > "With RKS, a Random KeyStream derived from a physical random > number generator is used as the cipher key. Conforming to the > requirements for a practical Vernam Cipher, the Random KeyStream > is the same length as the message and will not repeat with a > small statistical probability. The secret is the effective > management of a virtual keystream over 10³º bytes long." > > It is not claiming to be perfect, there is a small statistical > probability of a repetition. Obviously you can't store a 10^30 > byte 1-time pad. So it has to be generated from a smaller > amount of random data. However the solution is elegant and > has been reviewed by some top cryptographers, like Bart Preneel > and Fred Piper. So far it has held up under tough analysis, > including by some cryptographers over at Bell Labs. It's > effective key strength is 128 bits. > > >It also has built-in key recovery, and appears to require interaction > >with a centralized network service for all encryption and decryption. > >As described, it also has good potential to have severe scaling > >problems. > > > > The built in key recovery is why the unrestricted export license was > granted. No keys are escrowed with the government or third party > agencies (unlike TIS's solution). This is very powerful stuff. Any > company in the world, except for places like Iraq, can buy the system > and keep their keys to themselves. Key recovery is at their own > discretion, not forced upon them by the US government. > > As for scaling, I guess if you can exceed 2 thousand requests per > server > per second, then you've got a problem. It ships as a dual server > system. This sure beats the hell out of Public Key implementations > which can't do more than 10 per sec. > > - Alex > -- > Alex Alten > Andrade@Netcom.Com > P.O. Box 11406 > Pleasanton, CA 94588 USA > (510) 417-0159 From owner-ipsec Wed Jun 10 17:07:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20939 for ipsec-outgoing; Wed, 10 Jun 1998 17:05:20 -0400 (EDT) Date: Wed, 10 Jun 1998 17:19:12 -0400 From: yjj@mci.net (Yuan John Jiang) Message-Id: <199806102119.RAA07850@cletus.> To: ebomarsi@xedia.com, greg.carter@entrust.com Cc: ietf-lsd@listserv.umu.se, ietf-pkix@imc.org, ipsec@tis.com Subject: Re: DNS and X.501 DistinguishedName Sender: owner-ipsec@ex.tis.com Precedence: bulk >So I can generate an X.509 certificate request from >the system's domain name or one of it's IP addresses, >(and I should make that user selectable.) > >However, the subjectAltName is specific to an X.509 >certificate request and so I believe I still need >a way to enter an X.500 distinguished name into the >system for LDAP services, unless there is a similar >alternate name construct for LDAP? > >/Eric Bomarsi There is an I-D or RFC by the LDAP working group specifying using domain names as DNs. John > >Greg Carter wrote: >> >> Hi Eric, >> >> For X.509 (PKCS10 requests or PKIX requests) you should look at the >> subjectAltName extension. It allows the certification authority to list a >> number of alternative names which the entity is associated with. This list >> can include name types such as IP Address, DNS, and rfc822 names. Therefore >> the network device can have it's DNS and/or IP Address stored in the >> certificate, while having an X.500 DN that fits the organizations directory >> structure. >> >> >From X.509 >> 12.3.2.1 Subject alternative name field >> This field contains one or more alternative names, using any of a variety of >> name forms, for the entity that is bound by the CA to the certified public >> key. This field is defined as follows: >> subjectAltName EXTENSION ::= { >> SYNTAX GeneralNames >> IDENTIFIED BY id-ce-subjectAltName } >> >> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName >> >> GeneralName ::= CHOICE { >> otherName [0] INSTANCE OF OTHER-NAME, >> rfc822Name [1] IA5String, >> dNSName [2] IA5String, >> x400Address [3] ORAddress, >> directoryName [4] Name, >> ediPartyName [5] EDIPartyName, >> uniformResourceIdentifier [6] IA5String, >> iPAddress [7] OCTET STRING, >> registeredID [8] OBJECT IDENTIFIER } >> >> OTHER-NAME ::= TYPE-IDENTIFIER >> >> EDIPartyName ::= SEQUENCE { >> nameAssigner [0] DirectoryString {ub-name} OPTIONAL, >> partyName [1] DirectoryString {ub-name} } >> The values in the alternatives of the GeneralName type are names of various >> forms as follows: >> - otherName is a name of any form defined as an instance of >> the OTHER-NAME information object class; >> - rfc822Name is an Internet electronic mail address defined in >> accordance with Internet RFC 822; >> - dNSName is an Internet domain name defined in accordance >> with Internet RFC 1035; >> - x400Address is an O/R address defined in accordance with >> ITU-T Rec. X.411 | ISO/IEC 10021-4; >> - directoryName is a directory name defined in accordance with >> ITU-T Rec. X.501 | ISO/IEC 9594-2; >> - ediPartyName is a name of a form agreed between >> communicating Electronic Data Interchange partners; the nameAssigner >> component identifies an authority that assigns unique values of names in the >> partyName component; >> - uniformResourceIdentifier is a Uniform Resource Identifier >> for the World-Wide Web defined in accordance with Internet RFC 1630; >> - iPAddress is an Internet Protocol address defined in >> accordance with Internet RFC 791, represented as a binary string. >> - registeredID is an identifier of any registered object >> assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1. >> For every name form used in the GeneralName type, there shall be a name >> registration system that ensures that any name used unambiguously identifies >> one entity to both certificate issuer and certificate users. >> This extension may, at the option of the certificate issuer, be either >> critical or non-critical. An implementation which supports this extension is >> not required to be able to process all name forms. If the extension is >> flagged critical, at least one of the name forms that is present shall be >> recognized and processed, otherwise the certificate shall be considered >> invalid. Apart from the preceding restriction, a certificate-using system is >> permitted to ignore any name with an unrecognized or unsupported name form. >> It is recommended that, provided the subject field of the certificate >> contains a directory name that unambiguously identifies the subject, this >> field be flagged non-critical. >> >> ---- >> Greg Carter, Entrust Technologies >> greg.carter@entrust.com >> >> > ---------- >> > From: Eric Bomarsi[SMTP:ebomarsi@xedia.com] >> > Sent: Tuesday, June 09, 1998 5:39 PM >> > To: ietf-lsd@listserv.umu.se; ipsec@tis.com; spki@c2.net >> > Subject: DNS and X.501 DistinguishedName >> > >> > A network entity such as a router may require >> > an X.501 DistinguishedName to utilize LDAP >> > directory serices or generate PKCS certificate >> > requests. >> > >> > It's possible that the network entity can >> > use it's domain name to create an X.500 >> > Distinguished Name as specified in RFC2247. >> > However, I'm concerned that this might be too >> > inflexible since many organizations may >> > implement an internal X.500 naming convention >> > unrelated to their Internet domain naming. >> > >> > Has any MIB work been done to support >> > distinguished name configuration? >> > >> > Thanks in advance, >> > Eric Bomarsi >> > > From owner-ipsec Wed Jun 10 18:47:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21291 for ipsec-outgoing; Wed, 10 Jun 1998 18:44:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 10 Jun 1998 16:59:08 -0600 From: "Umesh Muniyappa" To: ipsec@tis.com Subject: Where can I find the latest drafts? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id SAA21281 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Could any of you please let me know where I can find the latest drafts for ISAKMP/OAKLEY and if any implementation available in the public domain. BTW, I could not find the latest "The resolution of ISAKMP with OAKLEY" draft. thanks umesh From owner-ipsec Wed Jun 10 19:01:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21333 for ipsec-outgoing; Wed, 10 Jun 1998 18:59:47 -0400 (EDT) Message-Id: <199806102312.QAA01183@greatdane.cisco.com> To: "Umesh Muniyappa" cc: ipsec@tis.com Subject: Re: Where can I find the latest drafts? In-reply-to: Your message of "Wed, 10 Jun 1998 16:59:08 MDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jun 1998 16:12:23 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk http://www.ietf.org/html.charters/ipsec-charter.html and scroll down a tad. "The Resolution of ISAKMP with Oakley" is dead, long live IKE! (It's the same protocol with a different name). There's a freeware IKE available at http://www.cisco.com/public/library/isakmp/disclaimer.html Read the disclaimer, follow the hotlinks, answer the questions and it's yours. Actually, if you wait a few days I'll put the updated version there. The one on the page is dated. Dan. On Wed, 10 Jun 1998 16:59:08 MDT you wrote > Hi, > Could any of you please let me know where I can find the latest drafts for IS >AKMP/OAKLEY and if any implementation available in the public domain. > > BTW, I could not find the latest "The resolution of ISAKMP with OAKLEY" draft >. > > thanks > > umesh > From owner-ipsec Thu Jun 11 04:00:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA22764 for ipsec-outgoing; Thu, 11 Jun 1998 03:54:17 -0400 (EDT) Date: Thu, 11 Jun 1998 10:03:05 +0200 From: Holger.Reif@PrakInf.TU-Ilmenau.DE (Holger Reif) Message-Id: <199806110803.KAA07843@remus.Prakinf.tu-ilmenau.de> To: Stephen.Waters@digital.com Subject: Re: Rest of World encryption hardware products? Cc: ipsec@tis.com X-Sun-Charset: US-ASCII X-Mailer: Mail Tool V3 plus JoesMailtool 1.1.3b Organization: TU Ilmenau, Fak. IA, FG Telematik Sender: owner-ipsec@ex.tis.com Precedence: bulk > Since it is not possible to ship worth-while encryption products > from the US (40-bit restriction), > are there any rest-of-world companies building hardware > encryption? www.ncipher.com, based in cambridge, UK with office in US, has a hardware accelerator. -- read you later - Holger Reif ------------------------------------ Signaturprojekt Deutsche Einheit TU Ilmenau - Informatik - Telematik (Verdamp lang her) Reif@PrakInf.TU-Ilmenau.DE Alt wie ein Baum werden, um ueber Remus.PrakInf.TU-Ilmenau.DE/Reif/ alle 7 Bruecken gehen zu koennen From owner-ipsec Thu Jun 11 04:42:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA22871 for ipsec-outgoing; Thu, 11 Jun 1998 04:41:19 -0400 (EDT) Message-Id: <355C4C5517A5D111A25800805FEA72A119409F@nmpies02tr.nmp.nokia.com> From: "Lehtonen Erkko (NMP)" To: "'ipsec@tis.com'" Subject: RE: Rest of World encryption hardware products? Date: Thu, 11 Jun 1998 11:54:41 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul Koning writes: > A Vernam cypher has a random key of length equal to the plaintext. > Period. Full stop. Then and only then will it have the "provably > unbreakable" property that makes it unique among cryptosystems. Handbook of Applied Cryptography by Menezes, van Oorschot and Vanstone defines Vernam cipher as follows: The Vernam Cipher is a stream cipher defined on the alphabet A = {0, 1}. A binary message m1 m2 ... mt is operated on by a binary key string k1 k2 ... kt of the same length to produce a ciphertext string c1 c2 ... ct where ci = mi XOR ki, 1 <= i <= t. If the key string is randomly chosen and never used again, the Vernam cipher is called a one-time system or a one-time pad. The definition of stream cipher does not require that the keystream be random. - Erkko Lehtonen From owner-ipsec Thu Jun 11 09:41:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23621 for ipsec-outgoing; Thu, 11 Jun 1998 09:33:37 -0400 (EDT) Date: Thu, 11 Jun 1998 09:49:05 -0400 Message-Id: <199806111349.JAA09327@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Erkko.Lehtonen@nmp.nokia.com Cc: ipsec@tis.com Subject: RE: Rest of World encryption hardware products? References: <355C4C5517A5D111A25800805FEA72A119409F@nmpies02tr.nmp.nokia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "NMP" == NMP writes: NMP> Paul Koning writes: >> A Vernam cypher has a random key of length equal to the plaintext. >> Period. Full stop. Then and only then will it have the "provably >> unbreakable" property that makes it unique among cryptosystems. NMP> Handbook of Applied Cryptography by Menezes, van Oorschot and NMP> Vanstone defines Vernam cipher as follows: NMP> The Vernam Cipher is a stream cipher defined on the alphabet A = NMP> {0, 1}. A binary message m1 m2 ... mt is operated on by a binary NMP> key string k1 k2 ... kt of the same length to produce a NMP> ciphertext string c1 c2 ... ct where ci = mi XOR ki, 1 <= i <= NMP> t. If the key string is randomly chosen and never used again, NMP> the Vernam cipher is called a one-time system or a one-time pad. NMP> The definition of stream cipher does not require that the NMP> keystream be random. Hm, that's very interesting. Up to now I've only seen the term "Vernam cypher" used as a synonym of "One time pad". (If my memory of Kahn's book serves, Vernam himself was using it that way.) I was using it in that sense, and the snake oil I was commenting on was doing likewise. Of course it's only the one time pad (random stream, not reused) that has the provably secure property. paul From owner-ipsec Fri Jun 12 09:11:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27388 for ipsec-outgoing; Fri, 12 Jun 1998 09:03:55 -0400 (EDT) Message-Id: <199806041412.KAA13997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-06.txt Date: Thu, 04 Jun 1998 10:12:42 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, B. Phan, C. Metz Filename : draft-mcdonald-pf-key-v2-06.txt Pages : 72 Date : 03-Jun-98 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-mcdonald-pf-key-v2-06.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980603142644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980603142644.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jun 12 10:12:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27737 for ipsec-outgoing; Fri, 12 Jun 1998 10:05:52 -0400 (EDT) Message-Id: <199806121414.KAA15528@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-08.txt Date: Fri, 12 Jun 1998 10:14:40 -0400 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 Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-08.txt Pages : 38 Date : 10-Jun-98 This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. 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-oakley-08.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-08.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980611093935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980611093935.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Sat Jun 13 01:04:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA00254 for ipsec-outgoing; Sat, 13 Jun 1998 01:01:01 -0400 (EDT) Message-Id: <3.0.3.32.19980612221536.009c5850@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 12 Jun 1998 22:15:36 -0700 To: Steve Bellovin From: Alex Alten Subject: Re: Rest of World encryption hardware products? Cc: Bill Sommerfeld , Stephen Waters , ipsec@tis.com In-Reply-To: <199806101142.HAA06129@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id BAA00251 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:42 AM 6/10/98 -0400, Steve Bellovin wrote: > > > >I read the whitepaper on the site. It contains a number of phrases > >which should set off any crypto expert's snake-oil detectors, the most > >crucial being "virtual one time pad". > > > > I don't think you need to take quotes out of context and change > their wording. Here's exactly what was written. > > "With RKS, a Random KeyStream derived from a physical random > number generator is used as the cipher key. Conforming to the > requirements for a practical Vernam Cipher, the Random KeyStream > is the same length as the message and will not repeat with a > small statistical probability. The secret is the effective > management of a virtual keystream over 10³º bytes long." > > It is not claiming to be perfect, there is a small statistical > probability of a repetition. Obviously you can't store a 10^30 > byte 1-time pad. So it has to be generated from a smaller > amount of random data. However the solution is elegant and > has been reviewed by some top cryptographers, like Bart Preneel > and Fred Piper. So far it has held up under tough analysis, > including by some cryptographers over at Bell Labs. It's > effective key strength is 128 bits. > >Your own excerpts prove Bill's point. The web page is full of statements >about how the Vernam cipher is theoretically unbreakable. But a Vernam >cipher requires a *true* random key stream as long as the message. It >is *not* a cipher where you XOR the message with a pseudo-random key stream. >But that's precisely what this cipher is doing -- you say so, in about >those words. This is an ordinary stream cipher, not a one-time pad. > There is no PRNG involved. Every bit, and I mean every bit, used to create the final pad is ultimately generated from a Fortezza card RNG. This is one of the reasons why it is not a normal stream cipher. As you point out below, it is impractical to manage large amounts of 1-time pads throughout a system. So a compromise is made. A finite pad has to be generated on demand by using a unique random key and a large finite amount of pre-generated random data (of which there is one per security server). Each new pad is the size of a text block to be encrypted. So to encipher a message of several blocks, a series of keys, one per block, *must* be generated randomly. This is why there is a small probability of repetition. In effect each unique pad is created from both static and dynamic random data. If the pre-generated random data is public, then all the strength resides in the bit length of the random key (128 bits here). The work factor can be easily modified by adjusting the amount of pre-generated random data and by the number of simple operations needed to generate a single finite pad--increase either and the number of bits needed in a key then increases. (Sorry, I can't give you more details.) It is possible to come arbitrarily close to the infinite unicity of a true Vernam 1-tape system. However it is a asymptotic limit, it can not be reached. The beauty of this system is that it is very easy to increase its strength to any level one desires, or that is practical given the technology of the moment. The same is true of speed, one can make time-memory tradeoffs to come arbitrarily close to a true single pad speed (a single XOR operation). The distribution of the single chunk of pre-generated random data to all users is easy compared to the impossible chore in a true Vernam system. The drawback is that the large number of random keys being generated on the fly and distributed makes key management more difficult than in typical public or symmetric key cipher systems. >I have no intrinsic objection to stream ciphers, though using them >properly requires a great deal of care. I have serious objections to >misleading advertising. > I don't think there was any attempt to mislead. I talked with the author of the white paper. He was trying hard to be accurate without giving away the store. > >It also has built-in key recovery, and appears to require interaction > >with a centralized network service for all encryption and decryption. > >As described, it also has good potential to have severe scaling > >problems. > > > First the dual server system can handle about 2-4000 transactions per second. Each transaction allows a authorized user to encrypt/decrypt up to about 4 GB of data. Second the scaling problem for server bottle necks has been solved by others. Novell has done it with their replication service for NDS. Something similar, but more concious of security, is applied here. > The built in key recovery is why the unrestricted export license was > granted. No keys are escrowed with the government or third party > agencies (unlike TIS's solution). This is very powerful stuff. Any > company in the world, except for places like Iraq, can buy the system > and keep their keys to themselves. Key recovery is at their own > discretion, not forced upon them by the US government. > >I'm not certain how this works. But let me shoot down a strawman. > >Suppose that this system did indeed use a true one-time pad. A customer >would be shipped N copies of a CD-ROM of true-random bits -- about 4800M >of them. The purpose of the server, then, would be to allocate chunks >of the bitstream to clients, ensuring that no portion was ever reused >(remember Venona?). > >Such a system would be a theoretician's delight and a practical nightmare. > >The problem is that you have to maintain perfect security on *every* >copy of the CD-ROM. If one of the N is stolen (or the machine with it >hacked), all past, present, and future conversations are compromised. >And the probability of that happening is exponential in N. In other >words, it doesn't scale at all. > >It's also obvious that 4800 Mbits doesn't last very long -- less than >an hour at T-1 speeds. So you'd have to switch CD-ROMs -- simultaneously; >everyone needs to be playing off the same score -- and safeguard all of >the old CD-ROMs as well. > These problems are solved. The use of a central secure server and attaching a seal, containing all information necessary to allow access, to a document (or to a communications stream) has made it possible. >Key recovery, of course, is simple in such a scheme: you turn over >the CD-ROM to the government on demand. > Unfortunately it can be too simple. Efforts have to be made to ensure that this cannot be done on a whim. This system requires two or more authorized key recovery officials to decrypt an encrypted document or communications stream. >In all seriousness, DES in OFB mode is likely to be more secure in >practice. IDEA or CAST-128 in OFB mode would be even better; they >have a key size of 128 bits. > >Of course, this scheme is clearly not a true one-time-pad. The real >question is how the key stream is generated from the keying material. >Is it a published algorithm? If not, I'm very unlikely to trust it >even if the Web page were not misleading. I don't blame you at all for this healthy skepticism. However think carefully. Given that memory is plentiful, that you can have lots of microprocessors, and that good network connections are everywhere. Now, how would you design a brand new cipher? > > As for scaling, I guess if you can exceed 2 thousand requests per server > per second, then you've got a problem. It ships as a dual server > system. This sure beats the hell out of Public Key implementations > which can't do more than 10 per sec. > >10 per second *per machine communicating*. And public key systems can >set up a secure channel even if the KDC is unreachable; this scheme can't. > To date every public key system fielded has proven impractical, witness the struggles of the SET system or the SNMP security efforts. We've have been over this ground before, so let's not reiterate old arguements. I would hope that you, as one of the leading members of the Internet community, will seriously investigate this new security possibility and see if it can be of any use in solving our problems with Internet security. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sat Jun 13 04:50:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00556 for ipsec-outgoing; Sat, 13 Jun 1998 04:48:00 -0400 (EDT) Message-ID: <3582405C.4487@cs.umass.edu> Date: Sat, 13 Jun 1998 05:03:24 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Alex Alten , IP Security List Subject: Re: Rest of World encryption hardware products? References: <3.0.3.32.19980612221536.009c5850@netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > There is no PRNG involved. Every bit, and I mean every bit, used > to create the final pad is ultimately generated from a Fortezza > card RNG. This is one of the reasons why it is not a normal > stream cipher. [...elided...] > A finite pad has to be generated on demand by using a unique random > key and a large finite amount of pre-generated random data [...elided...] > In effect each unique pad is created from both static > and dynamic random data. If the pre-generated random data is > public, then all the strength resides in the bit length of the > random key (128 bits here). Suppose the pre-generated random data _is_ public. Then the TriStrata system includes some function F that takes the 128-bit unique random key as input and produces (block-by-block) a keystream of more than 128 bits. For *any given encryption*, the large finite amount of pre-generated random data can be treated as part of F. So each encryption uses some deterministic F to generate the keystream, but (it is claimed that) the same F will almost never be used twice. I'd call each one of those F's a PRNG. Thus it appears that the system uses a long sequence of different PRNGs over time. An attacker can use the public randomly-generated data to determine which PRNG was used for any particular encryption. (I'm assuming the static algorithm underlying the sequence of F's is available to the attacker, perhaps at a price.) -Lewis From owner-ipsec Sat Jun 13 11:35:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00962 for ipsec-outgoing; Sat, 13 Jun 1998 11:26:02 -0400 (EDT) Message-Id: <199806131539.PAA05632@orchard.arlington.ma.us> To: Alex Alten Cc: ipsec@tis.com Subject: Re: Rest of World encryption hardware products? In-Reply-To: Your message of "Fri, 12 Jun 1998 22:15:36 PDT." <3.0.3.32.19980612221536.009c5850@netcom.com> Date: Sat, 13 Jun 1998 11:39:32 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk While I'd love to continue taking pot-shots at the crypto side, this discussion is taking place in the context of an IETF working group, and your last message contained two rather telling points which indicate that the products you're advocating for have no chance whatsoever of becoming an internet standard. > He was trying hard to be accurate without giving away the store. Serious investigation requires revealing enough detail to allow a cryptographer to reimplement the system. If this constitutes `giving away the store', you've come to the wrong place. > (Sorry, I can't give you more details.) One of the basic ground rules in the IETF is that trade secrets and NDA's have no place here. If you can't publish your algorithms and protocols, then you're not making a good faith effort to offer your *technology* to the working group Instead, it seems like you're trying to market your *products* to the subscribers of the list. That's an abuse of the purpose of the working group list. - Bill From owner-ipsec Sat Jun 13 14:22:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01191 for ipsec-outgoing; Sat, 13 Jun 1998 14:21:05 -0400 (EDT) Message-Id: <199806131836.LAA06838@gallium.network-alchemy.com> To: ipsec@tis.com Subject: IKE COMMIT/CONNECTED processing Date: Sat, 13 Jun 1998 11:36:37 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bitheads, In implementing support for the ISAKMP COMMIT bit and associated CONNECTED notify message, I uncovered an ambiguity in the ISAKMP draft that I don't recall reading on this list. The draft says that a Phase 2 informational exchange should generate its own message id (Section 4.8, pg. 56). ISAKMP also defines how a CONNECTED Notify is sent under an ISAKMP Informational Exchange as a result of the COMMIT bit (Section 3.1, pp. 24-25). The ambiguity is whether the ISAKMP Informational with the CONNECTED message is sent under its own unique message id, per Section 4.8, or whether it's sent under the associated QM message id. If the former, there's no way to associated the message with the particular QM exchange. If the latter, we're in violation of section 4.8's guidelines. Two solutions spring to mind: o ammend the ISAKMP COMMIT description to state that the message id for the CONNECTED Notify MUST be the associated QM message id o ammend the ISAKMP COMMIT description to state that the Notify payload for a CONNECTED message MUST contain the associated QM message id I implemented the first solution because the CONNECTED message is intricately tied to a previous QM exchange. Derrell From owner-ipsec Mon Jun 15 08:55:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA05838 for ipsec-outgoing; Mon, 15 Jun 1998 08:47:07 -0400 (EDT) Message-ID: From: Greg Carter To: ipsec@tis.com, "'Derrell D. Piper'" Subject: RE: IKE COMMIT/CONNECTED processing Date: Mon, 15 Jun 1998 08:55:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I am with Derrell on this, my processing of the COMMIT bit requires the message ID in the ISAKMP header to be the same as the QM exchange. I assume it is the final message of the exchange. ---- Bithead Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Derrell D. Piper[SMTP:ddp@network-alchemy.com] > Sent: Saturday, June 13, 1998 2:36 PM > To: ipsec@tis.com > Subject: IKE COMMIT/CONNECTED processing > > Bitheads, > .... > Two solutions spring to mind: > > o ammend the ISAKMP COMMIT description to state that the message id > for > the CONNECTED Notify MUST be the associated QM message id > > o ammend the ISAKMP COMMIT description to state that the Notify > payload > for a CONNECTED message MUST contain the associated QM message id > > I implemented the first solution because the CONNECTED message is > intricately > tied to a previous QM exchange. > > Derrell > From owner-ipsec Mon Jun 15 19:45:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08083 for ipsec-outgoing; Mon, 15 Jun 1998 19:41:11 -0400 (EDT) Date: Tue, 16 Jun 1998 02:55:57 +0300 (EET DST) Message-Id: <199806152355.CAA29026@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "C. Harald Koch" Cc: ipsec@tis.com Subject: DSS support? In-Reply-To: <98Jun9.150314edt.11651@janus.tor.securecomputing.com> References: <98Jun9.150314edt.11651@janus.tor.securecomputing.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Anyone out there got an ISAKMP implementation that implements DSS/DSA (pick > your favourite acronym), and would be willing to to some over-the-net interop > testing? Our test site (http://isakmp-test.ssh.fi/) have also the DSS support so you can use that to test against our toolkit. You have to configure your site to accept our ca-key, and you can either send me PKCS#10 request of your key that I can send you back signed by our key, or you have to check the "trust any certificate" flag on in the first page (this will disable the check that the key is signed by correct ca, but it still does other validity checks (validity period etc)). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Jun 17 08:54:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01893 for ipsec-outgoing; Wed, 17 Jun 1998 08:43:53 -0400 (EDT) Message-Id: <3.0.5.32.19980616083031.009d1e80@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Jun 1998 08:30:31 -0400 To: Bill Sommerfeld , Alex Alten From: Robert Moskowitz Subject: Re: Rest of World encryption hardware products? Cc: ipsec@tis.com In-Reply-To: <199806131539.PAA05632@orchard.arlington.ma.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:39 AM 6/13/98 -0400, Bill Sommerfeld wrote: > >Instead, it seems like you're trying to market your *products* to the >subscribers of the list. That's an abuse of the purpose of the >working group list. Yes. Let's close this discussion down. For those interested in this technology, they have there points. Otherwise it is out of scope for this list. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Jun 18 00:30:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA07417 for ipsec-outgoing; Thu, 18 Jun 1998 00:28:32 -0400 (EDT) Date: Wed, 17 Jun 1998 21:44:16 -0700 (PDT) From: Bryan Gleeson Message-Id: <199806180444.VAA22848@shasta-nms.shastanets.com> To: ipsec@tis.com Subject: use of client IDs Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm new to the list and am unclear on when client IDs in a Quick Mode exchange initiated by a security gateway are mandatory and when they are optional, when establishing an IPSEC SA. >From reading some of the specs it seems that for a security gateway, the ID payload has been pressed into service as a way of identifying the type of traffic that the gateway intends to pump down an SA that it initiates (e.g. identifying the source IP addresses of the traffic that will use the SA) and so is in effect being used to convey selector information between IPSEC nodes. This can then be used by the responder to dynamically create an SPD entry corresponding to the new SA. Is this the case or am I way off in the weeds here ? If it is the case and a security gateway has multiple disjoint IP subnets behind it, all of which could source packets to be sent on the IPSEC SA, how should the client ID be set - use multiple ID payloads, a different SA for each disjoint subnet, or something else ? Another question is how optional the use of client IDs is for a security gateway doing an IPSEC SA establishment. Is it ever necessary to be able to use client IDs in order to interoperate with another security gateway ? Put another way is a security gateway acting as a client negotiator an optional feature, or is "security gateway = client negotiator" always true ? Lastly the architecture draft models both an SPD entry and an SAD entry as having a selector field. I'm a bit unclear on the need for this. If an SPD entry points to a list of SADs (and the SADs have backpointers to SPDs) wouldn't one selector associated with the SPD do the job ? Under what circumstances would the SAD selectors be different from their linked SPD selectors ? Thanks in advance for any clarifications ... Bryan Gleeson Shasta Networks. From owner-ipsec Thu Jun 18 12:55:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10937 for ipsec-outgoing; Thu, 18 Jun 1998 12:49:32 -0400 (EDT) Message-ID: <358948B7.606A226F@redcreek.com> Date: Thu, 18 Jun 1998 10:04:55 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson CC: ipsec@tis.com Subject: Re: use of client IDs References: <199806180444.VAA22848@shasta-nms.shastanets.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson wrote: > > I'm new to the list and am unclear on when client IDs in a > Quick Mode exchange initiated by a security gateway are > mandatory and when they are optional, when establishing > an IPSEC SA. The ID payload is optional when the sender and receiver are to be considered to be the conversation endpoints. In that case, the IDs are implicit. > From reading some of the specs it seems that for a security > gateway, the ID payload has been pressed into service as a > way of identifying the type of traffic that the gateway > intends to pump down an SA that it initiates (e.g. identifying > the source IP addresses of the traffic that will use the SA) > and so is in effect being used to convey selector information > between IPSEC nodes. This can then be used by the responder to > dynamically create an SPD entry corresponding to the new SA. I guess it's a matter of semantics, but personally, I would say that the responder would use the selector information to select an *existing* SPD policy entry from which to derive(i.e. dynamically create) the SA > If it is the > case and a security gateway has multiple disjoint IP subnets > behind it, all of which could source packets to be sent on the > IPSEC SA, how should the client ID be set - use multiple ID > payloads, a different SA for each disjoint subnet, or something > else ? This isn't currently supported, but it has been discussed off the list. That was during last call for the current document set, so it wasn't proposed to the list. I will continue to hold off on posting the suggested mechanism to this list until the chairs release the finalized agenda for ipsecond. > Another question is how optional the use of client IDs is for a > security gateway doing an IPSEC SA establishment. Is it ever > necessary to be able to use client IDs in order to interoperate > with another security gateway ? Put another way is a security > gateway acting as a client negotiator an optional feature, or > is "security gateway = client negotiator" always true ? It depends on the granularity of policy you would like to exercise, and on the policy configuration of the remote gateway. If you (and the other gateway) don't mind having all the traffic from one net to the other being funneled into one tunnel (using the same keys, etc), then you don't need to use client IDs. If you want finer control, with different policies applied to different hosts/protocols/ports, then you need client IDs. > Lastly the architecture draft models both an SPD entry and an SAD > entry as having a selector field. I'm a bit unclear on the need > for this. If an SPD entry points to a list of SADs (and the SADs > have backpointers to SPDs) wouldn't one selector associated with > the SPD do the job ? Under what circumstances would the SAD > selectors be different from their linked SPD selectors ? The line between the SPD/SAD is a bit blurred in this respect, and I personally would say this is an implementation detail. However, there are others here who might disagree... From owner-ipsec Thu Jun 18 13:12:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11095 for ipsec-outgoing; Thu, 18 Jun 1998 13:11:33 -0400 (EDT) Message-ID: <35894E1F.5016AA2A@redcreek.com> Date: Thu, 18 Jun 1998 10:27:59 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson , ipsec@tis.com Subject: Re: use of client IDs References: <199806180444.VAA22848@shasta-nms.shastanets.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson wrote: > Lastly the architecture draft models both an SPD entry and an SAD > entry as having a selector field. I'm a bit unclear on the need > for this. If an SPD entry points to a list of SADs (and the SADs > have backpointers to SPDs) wouldn't one selector associated with > the SPD do the job ? Under what circumstances would the SAD > selectors be different from their linked SPD selectors ? After giving this a bit more thought, I believe my previous reply on this particular item was incorrect. I said that having selectors in both places is an implementation detail. What I should have said is that the ARCH doc calls for the SPD to be searched for all outgoing packets, (i.e. the selectors are in the SPD), and that for inbound packets, the selectors are associated with the SAD (section 4.4.2). I have previously asserted that you can avoid the SPD lookup for outgoing packets by associating *exact* selectors with the outbound SAD entries (and also inbound ones, but that's another issue), but there are those who disagree. Sorry for the confusion. > > Thanks in advance for any clarifications ... > > Bryan Gleeson > Shasta Networks. From owner-ipsec Thu Jun 18 13:52:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11315 for ipsec-outgoing; Thu, 18 Jun 1998 13:51:34 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB441002C9@scc-server3.semaphorecom.com> From: CJ Gibson To: "Scott G. Kelly" , Bryan Gleeson Cc: ipsec@tis.com Subject: RE: use of client IDs Date: Thu, 18 Jun 1998 11:13:41 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, could you please be a little clearer (or give examples) about your statement: " The ID payload is optional when the sender and receiver are to be considered to be the conversation endpoints. In that case, the IDs are implicit." The question is about a gateway so the key neg has to be for tunnel mode. -CJ -----Original Message----- From: Scott G. Kelly [SMTP:skelly@redcreek.com] Sent: Thursday, June 18, 1998 10:05 AM To: Bryan Gleeson Cc: ipsec@tis.com Subject: Re: use of client IDs Bryan Gleeson wrote: > > I'm new to the list and am unclear on when client IDs in a > Quick Mode exchange initiated by a security gateway are > mandatory and when they are optional, when establishing > an IPSEC SA. The ID payload is optional when the sender and receiver are to be considered to be the conversation endpoints. In that case, the IDs are implicit. > From reading some of the specs it seems that for a security > gateway, the ID payload has been pressed into service as a > way of identifying the type of traffic that the gateway > intends to pump down an SA that it initiates (e.g. identifying > the source IP addresses of the traffic that will use the SA) > and so is in effect being used to convey selector information > between IPSEC nodes. This can then be used by the responder to > dynamically create an SPD entry corresponding to the new SA. I guess it's a matter of semantics, but personally, I would say that the responder would use the selector information to select an *existing* SPD policy entry from which to derive(i.e. dynamically create) the SA > If it is the > case and a security gateway has multiple disjoint IP subnets > behind it, all of which could source packets to be sent on the > IPSEC SA, how should the client ID be set - use multiple ID > payloads, a different SA for each disjoint subnet, or something > else ? This isn't currently supported, but it has been discussed off the list. That was during last call for the current document set, so it wasn't proposed to the list. I will continue to hold off on posting the suggested mechanism to this list until the chairs release the finalized agenda for ipsecond. > Another question is how optional the use of client IDs is for a > security gateway doing an IPSEC SA establishment. Is it ever > necessary to be able to use client IDs in order to interoperate > with another security gateway ? Put another way is a security > gateway acting as a client negotiator an optional feature, or > is "security gateway = client negotiator" always true ? It depends on the granularity of policy you would like to exercise, and on the policy configuration of the remote gateway. If you (and the other gateway) don't mind having all the traffic from one net to the other being funneled into one tunnel (using the same keys, etc), then you don't need to use client IDs. If you want finer control, with different policies applied to different hosts/protocols/ports, then you need client IDs. > Lastly the architecture draft models both an SPD entry and an SAD > entry as having a selector field. I'm a bit unclear on the need > for this. If an SPD entry points to a list of SADs (and the SADs > have backpointers to SPDs) wouldn't one selector associated with > the SPD do the job ? Under what circumstances would the SAD > selectors be different from their linked SPD selectors ? The line between the SPD/SAD is a bit blurred in this respect, and I personally would say this is an implementation detail. However, there are others here who might disagree... From owner-ipsec Thu Jun 18 14:02:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11379 for ipsec-outgoing; Thu, 18 Jun 1998 14:01:34 -0400 (EDT) Message-ID: <358959C0.B27854DB@redcreek.com> Date: Thu, 18 Jun 1998 11:17:36 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: CJ Gibson CC: Bryan Gleeson , ipsec@tis.com Subject: Re: use of client IDs References: <0171F2F8F9E5D011A4D10060B03CFB441002C9@scc-server3.semaphorecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk CJ Gibson wrote: > > Scott, > could you please be a little clearer (or give examples) about > your statement: > > " The ID payload is optional when the sender and receiver are to > be > considered to be the conversation endpoints. In that case, the > IDs are > implicit." > > The question is about a gateway so the key neg has to be for tunnel > mode. > I mean that in the case of a single tunnel between gateways which is used to support all traffic between the networks behind the gateways, the gateways are the conversation endpoints. See section 5.5 of the IKE doc, where it says "The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode." From owner-ipsec Thu Jun 18 17:33:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12173 for ipsec-outgoing; Thu, 18 Jun 1998 17:32:48 -0400 (EDT) Message-ID: From: Bryan Gleeson To: "Scott G. Kelly" , Bryan Gleeson Cc: ipsec@tis.com Subject: RE: use of client IDs Date: Thu, 18 Jun 1998 14:48:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, Thanks for the detailed reply. > > If it is the > > case and a security gateway has multiple disjoint IP subnets > > behind it, all of which could source packets to be sent on the > > IPSEC SA, how should the client ID be set - use multiple ID > > payloads, a different SA for each disjoint subnet, or something > > else ? > > This isn't currently supported, but it has been discussed off > the list. > That was during last call for the current document set, so it wasn't > proposed to the list. I will continue to hold off on posting the > suggested mechanism to this list until the chairs release the > finalized > agenda for ipsecond. I think that attempting to define a general purpose selector protocol, which tells a responder exactly what packets the initiator intends to send on an SA, is going to prove quite difficult. For example I might want to encode in a message that the SA was used to carry all traffic from subnets 1,2 & 3 to subnet 100, except ftp and telnet traffic (which receive different treatment). In the absence of a fully general purpose protocol whatever is defined will at best be a half-way house, as it is today. It will always be a subset of the selector rules that people wish to use. > It depends on the granularity of policy you would like to > exercise, and > on the policy configuration of the remote gateway. If you (and the > other gateway) don't mind having all the traffic from one net to the > other being funneled into one tunnel (using the same keys, etc), then > you don't need to use client IDs. If you want finer control, with > different policies applied to different > hosts/protocols/ports, then you > need client IDs. I think that applying a fine level of control about what packets get transmitted onto an SA, is separate from conveying the filtering information to the other end of the SA. A gateway could be separating traffic out using an arbitrary amount of information from a packet (e.g. looking at embedded URLs) and applying different security policies. I'm assuming that there is no need for the receiver side of an SA to view the allowed traffic on an SA with the same granularity as the sender does. It may the same, or it may be coarser, all the way down to allowing "any". Is this correct, or do both sides have to share exactly the same view? To remove any ambiguity would anyone object to adding the following to the IKE spec (section 5.5) - "The use of client identities is optional for both hosts and security gateways" ? Bryan Gleeson Shasta Networks. From owner-ipsec Thu Jun 18 17:43:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12197 for ipsec-outgoing; Thu, 18 Jun 1998 17:42:47 -0400 (EDT) Message-ID: <35898DA5.CF6A206F@redcreek.com> Date: Thu, 18 Jun 1998 14:59:01 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson CC: ipsec@tis.com Subject: Re: use of client IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson wrote: > > I think that attempting to define a general purpose selector > protocol, which tells a responder exactly what packets the > initiator intends to send on an SA, is going to prove quite > difficult. For example I might want to encode in a message that > the SA was used to carry all traffic from subnets 1,2 & 3 > to subnet 100, except ftp and telnet traffic (which receive > different treatment). In the absence of a fully general purpose > protocol whatever is defined will at best be a half-way house, > as it is today. It will always be a subset of the selector rules > that people wish to use. Yes, this is one of the remaining challenges for IPsec. Hopefully, it will be on the agenda. > I think that applying a fine level of control about what packets get > transmitted onto an SA, is separate from conveying the filtering > information to the other end of the SA. A gateway could be separating > traffic out using an arbitrary amount of information from a packet > (e.g. looking at embedded URLs) and applying different security > policies. I'm assuming that there is no need for the receiver side > of an SA to view the allowed traffic on an SA with the same granularity > as the sender does. It may the same, or it may be coarser, all the way > down to allowing "any". Is this correct, or do both sides have to share > exactly the same view? Policy is a local matter. Gateways with differing policies may or may not communicate, depending upon the intersection of their policy sets. From owner-ipsec Thu Jun 18 18:30:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12421 for ipsec-outgoing; Thu, 18 Jun 1998 18:29:48 -0400 (EDT) Message-ID: From: Bryan Gleeson To: "Scott G. Kelly" , Bryan Gleeson Cc: ipsec@tis.com Subject: RE: use of client IDs Date: Thu, 18 Jun 1998 15:45:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, > Policy is a local matter. Gateways with differing policies may or may > not communicate, depending upon the intersection of their policy sets. Agreed. What I want to make sure of is that two boxes that claim IPSEC conformance are not fundamentally uninteroperable if a security gateway is serving multiple disjoint subnets. Either the transmitting gateway must be able to set up multiple SAs to the same peer, one for each subnet, or a receiving gateway must be precluded from assuming that the source IP address of packets received on an SA will always either fall under the range of the client ID if included, or the ID of the ISAKMP peer, if not. Bryan Gleeson Shasta Networks. From owner-ipsec Thu Jun 18 19:35:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12575 for ipsec-outgoing; Thu, 18 Jun 1998 19:34:49 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806182349.QAA23370@server.livingston.com> Subject: Re: use of client IDs To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 18 Jun 1998 16:54:17 -0700 (PDT) Cc: bgleeson@shastanets.com, ipsec@tis.com In-Reply-To: <358948B7.606A226F@redcreek.com> from "Scott G. Kelly" at Jun 18, 98 10:04:55 am Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Bryan Gleeson wrote: > > > > I'm new to the list and am unclear on when client IDs in a > > Quick Mode exchange initiated by a security gateway are > > mandatory and when they are optional, when establishing > > an IPSEC SA. > > The ID payload is optional when the sender and receiver are to be > considered to be the conversation endpoints. In that case, the IDs are > implicit. I believe, Client ID is mandatory when IKE key negotiator and the client node for which it is negotiating are not the same. Given that the ID payload serves the dual role of providing identification as well as policy, this would become a requirement when the policy specification is expanded to include trasport level and other types of services. > > > From reading some of the specs it seems that for a security > > gateway, the ID payload has been pressed into service as a > > way of identifying the type of traffic that the gateway > > intends to pump down an SA that it initiates (e.g. identifying > > the source IP addresses of the traffic that will use the SA) > > and so is in effect being used to convey selector information > > between IPSEC nodes. This can then be used by the responder to > > dynamically create an SPD entry corresponding to the new SA. > > I guess it's a matter of semantics, but personally, I would say that the > responder would use the selector information to select an *existing* SPD > policy entry from which to derive(i.e. dynamically create) the SA > I agree with what Bryan is saying here. But, SPD entries on a node cannot be allowed to be dictated by the peering external node. I would state that the responder would be expected to choose one of an existing matching SPD entries or a subset of a matching SPD entry to correspond to the new SA. Ideally, when the two parties have exact SPD entries (as far as traffic between the two parties are concerned) on either side, there is no problem. But, in the case where the SPDs do not match, the ID payload is supposed to automate the policy selection criteria. > > If it is the > > case and a security gateway has multiple disjoint IP subnets > > behind it, all of which could source packets to be sent on the > > IPSEC SA, how should the client ID be set - use multiple ID > > payloads, a different SA for each disjoint subnet, or something > > else ? > > This isn't currently supported, but it has been discussed off the list. > That was during last call for the current document set, so it wasn't > proposed to the list. I will continue to hold off on posting the > suggested mechanism to this list until the chairs release the finalized > agenda for ipsecond. > Fair enough. I agree, it is important to have the drafts progressed into RFC status. When a secure gateway has multiple disjoint subnet or discrete hosts in the policy, you could setup multiple SAs to accomodate them. In the future, we need a way to clearly state the security policies; I.e., one that would allow you to specify discrete hosts, range of hosts, protocols, TCP/UDP ports etc. Otherwise, packets could get black-holed. > > Another question is how optional the use of client IDs is for a > > security gateway doing an IPSEC SA establishment. Is it ever > > necessary to be able to use client IDs in order to interoperate > > with another security gateway ? Put another way is a security > > gateway acting as a client negotiator an optional feature, or > > is "security gateway = client negotiator" always true ? > > It depends on the granularity of policy you would like to exercise, and > on the policy configuration of the remote gateway. If you (and the > other gateway) don't mind having all the traffic from one net to the > other being funneled into one tunnel (using the same keys, etc), then > you don't need to use client IDs. If you want finer control, with > different policies applied to different hosts/protocols/ports, then you > need client IDs. > Here is my thinking on this. An IKE negotiator is an entity by itself, independent of whether it is negotiating on behalf of a transport mode client (i.e., end host) or a tunnel mode client(say, VPN gateway). The IKE negotiator entity could be on the same node as the client for which it is negotiating or it could be on an entirely different node. So, it is important for the negotiator to identify the client for which it is negotiating, especially when the client is different node/address from that of the negotiator. The ID payload semantics seems overloaded to carry both the client ID and the security policy applicable to client. > > Lastly the architecture draft models both an SPD entry and an SAD > > entry as having a selector field. I'm a bit unclear on the need > > for this. If an SPD entry points to a list of SADs (and the SADs > > have backpointers to SPDs) wouldn't one selector associated with > > the SPD do the job ? Under what circumstances would the SAD > > selectors be different from their linked SPD selectors ? > > The line between the SPD/SAD is a bit blurred in this respect, and I > personally would say this is an implementation detail. However, there > are others here who might disagree... > Well, there are many cases where an SPD selector could differ from an SAD selector. If the selection criteria is set to be based on packet (as opposed to policy), every new packet matching the same policy but differing in one regard(say, IP address or TCP/UDP port) would require a new SA. In the case where selection criteria is set to be based on policy, the SA selection would match the selection of an SP. It is also possible for an SA to match multiple policies. Hope this helps. cheers, suresh From owner-ipsec Thu Jun 18 19:55:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12617 for ipsec-outgoing; Thu, 18 Jun 1998 19:54:48 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806190009.RAA25021@server.livingston.com> Subject: Re: use of client IDs To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 18 Jun 1998 17:15:06 -0700 (PDT) Cc: BGleeson@shastanets.com, ipsec@tis.com In-Reply-To: <35898DA5.CF6A206F@redcreek.com> from "Scott G. Kelly" at Jun 18, 98 02:59:01 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Bryan Gleeson wrote: > > > > > I think that attempting to define a general purpose selector > > protocol, which tells a responder exactly what packets the > > initiator intends to send on an SA, is going to prove quite > > difficult. For example I might want to encode in a message that > > the SA was used to carry all traffic from subnets 1,2 & 3 > > to subnet 100, except ftp and telnet traffic (which receive > > different treatment). In the absence of a fully general purpose > > protocol whatever is defined will at best be a half-way house, > > as it is today. It will always be a subset of the selector rules > > that people wish to use. > > Yes, this is one of the remaining challenges for IPsec. Hopefully, it > will be on the agenda. I agree. Developing a specification format for SPD, as described in the architecture document shouldnt be that hard, I suspect. > > > I think that applying a fine level of control about what packets get > > transmitted onto an SA, is separate from conveying the filtering > > information to the other end of the SA. A gateway could be separating > > traffic out using an arbitrary amount of information from a packet > > (e.g. looking at embedded URLs) and applying different security > > policies. I'm assuming that there is no need for the receiver side > > of an SA to view the allowed traffic on an SA with the same granularity > > as the sender does. It may the same, or it may be coarser, all the way > > down to allowing "any". Is this correct, or do both sides have to share > > exactly the same view? > > Policy is a local matter. Gateways with differing policies may or may > not communicate, depending upon the intersection of their policy sets. > Well, not really. A VPN node has to use policies to determine which SA to send a packet out on. When a packet is received on an SA (say, SAin), it will detunnel the packet and send to the appropriate target host. When a response comes back from the target host, the VPN node has to figure out which of the many SAs to use for sending the packet back to peer-VPN node (There may be multiple SAs between the same peering nodes). If there is no policy mismatch between the peering nodes, this would be no problem in selecting the right SA. Otherwise, there is a potential for you to send the packets on the wrong SA. I believe, the intent of exchanging policies is so that a VPN node could use the policy to correctly determine which SA to use on the way out. This would ensure that the SAin and SAout that were negotiated using IKE are indeed used the way they are supposed to. Otherwise, tunneled packets could be received on SAin, but sent out on SAout~, different from SAout. cheers, suresh From owner-ipsec Thu Jun 18 20:34:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12769 for ipsec-outgoing; Thu, 18 Jun 1998 20:33:48 -0400 (EDT) Message-ID: <3589B5A6.7207E47D@redcreek.com> Date: Thu, 18 Jun 1998 17:49:42 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: bgleeson@shastanets.com, ipsec@tis.com Subject: Re: use of client IDs References: <199806182349.QAA23370@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > I believe, Client ID is mandatory when IKE key negotiator and the > client node for which it is negotiating are not the same. I don't think this is true. That's not to say that it shouldn't be, but I don't think that as things currently stand, it is right. See the related post to see what the IKE doc says about this. Consider the following scenario: 192.168.1.2 10.0.0.2 +----+ | 192.168.1.3 10.0.0.1 | +----+ | U1 +-| +-----+ +-----+ |--| U2 | +----+ +===+ SG1 +===================+ SG2 +==+ +----+ | +---- + +-----+ | SG2's SPD: --------------------------------- 192.168.1.0/12 (some SA spec) (other SPD entries) ... Now, SG1 negotiates a SA, and neglects to send a ID payload. SG2 selects rule 1. Subsequently, SG1 encapsulates packets from 192.168.1.2, and SG2 uses the SA to decrypt/decapsulate the packets. Then, SG2 looks in its SPD to ensure the resulting packet selectors match the SPD entry. Guess what? They do... > Given that the ID payload serves the dual role of providing > identification as well as policy, this would become a requirement > when the policy specification is expanded to include trasport level > and other types of services. The ID payload provides *identification*, not policy. Policy may be selected based upon the provided identification, or perhaps based upon some other criteria. > I agree with what Bryan is saying here. But, SPD entries on a node cannot > be allowed to be dictated by the peering external node. I would state that > the responder would be expected to choose one of an existing matching SPD > entries or a subset of a matching SPD entry to correspond to the new SA. Yes, that's what I said, I think. > Ideally, when the two parties have exact SPD entries (as far as traffic > between the two parties are concerned) on either side, there is no problem. > But, in the case where the SPDs do not match, the ID payload is supposed > to automate the policy selection criteria. > I'm very confused by your terminology here. The parties may have an exact match for the selectors in a SPD entry, and I think that's what you mean here. However, whether they do or not, they will do the same amount of work to look up a matching policy entry (using the packet source IP or the ID payload content) either way, unless the ID payload contains a FQDN or something, and they have to do additional protocol backflips to get the info. Either way, the policy selection is automated. > When a secure gateway has multiple disjoint subnet or discrete hosts in > the policy, you could setup multiple SAs to accomodate them. In the > future, we need a way to clearly state the security policies; I.e., one > that would allow you to specify discrete hosts, range of hosts, protocols, > TCP/UDP ports etc. Otherwise, packets could get black-holed. Yes, and it would also be nice to have a method for specifying 'all but this one', i.e. a notch filter. > Here is my thinking on this. > > An IKE negotiator is an entity by itself, independent of whether it > is negotiating on behalf of a transport mode client (i.e., end host) > or a tunnel mode client(say, VPN gateway). The IKE negotiator entity > could be on the same node as the client for which it is negotiating > or it could be on an entirely different node. > > So, it is important for the negotiator to identify the client for which > it is negotiating, especially when the client is different node/address > from that of the negotiator. I never meant to imply that the negotiator should try to hide its client, only to clarify the behavior when no ID payload is present, which is well-defined. > The ID payload semantics seems overloaded to carry both the client ID and > the security policy applicable to client. In the current design, the security policy is selected based upon the identity of the client. This is based upon a typical identity-based security policy model. If you want to use some other sort of model (e.g. rule-based), then I suppose the identity isn't so important, and you might need some other 'privilege-level' payload or something. I guess I don't understand what you mean by 'overloaded' here, as it seems to me to be serving one purpose: to identify. > Well, there are many cases where an SPD selector could differ from an > SAD selector. Bingo - this is correct (and I missed it in my previous response), but I don't think you fleshed it out properly below. It's when the SPD selector is *not an address*, i.e. if it's a FQDN, or DN, or some certificate field, then that selector (the one which matched the SPD entry) won't be in subsequent packets, and hence cannot be used to select the correct SAD entry. Additional issues arise when the SPD selectors are address wildcards, which also can't be used to select the SAD entry due to the possibility of unintended collisions with earlier more precise SPD entries. One way to clarify this distinction for purposes of discussion is to differentiate between SPD selectors (which might be things other than addresses, protocols, etc), and packet selectors (SAD selectors), which are *always* addresses, protocols, and SPIs. > If the selection criteria is set to be based on packet > (as opposed to policy), every new packet matching the same policy but > differing in one regard(say, IP address or TCP/UDP port) would require > a new SA. > > In the case where selection criteria is set to be based on policy, > the SA selection would match the selection of an SP. It is also > possible for an SA to match multiple policies. > Again, your terminology confuses me. When you say 'the selection criteria is set to be based on packet (as opposed to policy)', what do you mean? From owner-ipsec Thu Jun 18 20:42:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12792 for ipsec-outgoing; Thu, 18 Jun 1998 20:39:48 -0400 (EDT) Message-ID: <3589B707.1F2363E1@redcreek.com> Date: Thu, 18 Jun 1998 17:55:35 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: BGleeson@shastanets.com, ipsec@tis.com Subject: Re: use of client IDs References: <199806190009.RAA25021@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > Policy is a local matter. Gateways with differing policies may or may > > not communicate, depending upon the intersection of their policy sets. > > > > Well, not really. > > A VPN node has to use policies to determine which SA to send a packet out > on. When a packet is received on an SA (say, SAin), it will detunnel the > packet and send to the appropriate target host. When a response comes back > from the target host, the VPN node has to figure out which of the many SAs > to use for sending the packet back to peer-VPN node (There may be multiple > SAs between the same peering nodes). If there is no policy mismatch between > the peering nodes, this would be no problem in selecting the right SA. > Otherwise, there is a potential for you to send the packets on the wrong > SA. You missed the point: if their policies don't intersect, *there won't be a SA*. > I believe, the intent of exchanging policies is so that a VPN node could > use the policy to correctly determine which SA to use on the way out. Policies are not exchanged, at least not in the current implementations, as far as I know. Proposals which result from policy are exchanged. From owner-ipsec Thu Jun 18 22:38:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA13141 for ipsec-outgoing; Thu, 18 Jun 1998 22:34:48 -0400 (EDT) Message-ID: From: Bryan Gleeson To: "Scott G. Kelly" , Pyda Srisuresh Cc: Bryan Gleeson , ipsec@tis.com Subject: RE: use of client IDs Date: Thu, 18 Jun 1998 19:50:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, Pyda > Pyda Srisuresh wrote: > > > > > I believe, Client ID is mandatory when IKE key negotiator and the > > client node for which it is negotiating are not the same. > > I don't think this is true. That's not to say that it > shouldn't be, but > I don't think that as things currently stand, it is right. I think the current draft is sufficiently ambiguous that it does not rule out either conclusion. There is definitely a need for a statement that "for a security gateway the use of the client ID is foobar", where foobar is either "mandatory" or "optional". > > Given that the ID payload serves the dual role of providing > > identification as well as policy, this would become a requirement > > when the policy specification is expanded to include trasport level > > and other types of services. > > The ID payload provides *identification*, not policy. Policy may be > selected based upon the provided identification, or perhaps based upon > some other criteria. With the concept of client/proxy negotiation I think the ID payload is overloaded with the concept of policy. If this field is extended to include multiple subnets, and TCP/UDP port info and whatever, I think it becomes clearer that it is overloaded, as then there would be a need to talk about an IKE negotiation on behalf of a client flow, or on behalf of a flow aggregate which included many clients, for example. Right now I view it as being a poor man's policy descriptor - which is capable of only representing a limited set of policies, and cannot deal with the case of a router that is serving multiple disjoint subnets. I don't think that the capability of including policy info in an IKE exchange is a bad idea, but I think overloading the ID payload with policy semantics is a bad idea. Instead I think a separate policy (or selector) payload should be added, and that the ID payload should be left to identify the thing that is initiating or terminating the SA. The model that a security gateway is always "negotiating on behalf of" a client may be intuitive in some scenarios, but I believe is not in others, and that this model should not drive mandatory protocol behaviours. For example if there are two hosts communicating over the Internet, and somewhere in the middle two routers, over which the host to host traffic travels, decide to set up an MPLS label switched path between themselves to provide for some traffic engineering, I wouldn't view the setting up of the label switched path as being "on behalf of the client that was ultimately sourcing the IP packets". It is rather a policy decision made by the domain administrator, and is completely transparent to any hosts, who probably have no idea of what an MPLS label switched path was or why they would ever want someone to get one on their behalf. Also you wouldn't want to force a separate label switched path for every client or client address range (subnet) since that may be irrelevant to the policy aims of the administrator. I think exactly the same situation arises with setting up an IPSEC tunnel between two routers / gateways. In both cases there is a "connection" (label switched path or SA) and there is a filtering / selector policy which determines which packets get what label or get transmitted on what SA. Now if the client ID were mandatory for a security gateway, then a separate SA *would* be required for disjoint subnets, because the ID payload, in its duty as a poor man's policy descriptor, was not capable of representing this and this would be true even when the source addresses of the packets to be sent on an SA are irrelevant to the policy that an administrator wishes to implement. Bryan Gleeson Shasta Networks. From owner-ipsec Thu Jun 18 23:59:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA13386 for ipsec-outgoing; Thu, 18 Jun 1998 23:57:48 -0400 (EDT) Message-Id: <199806190412.VAA14976@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Bryan Gleeson Cc: "Scott G. Kelly" , Pyda Srisuresh , ipsec@tis.com Subject: Re: use of client IDs In-Reply-To: Your message of "Thu, 18 Jun 1998 19:50:12 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jun 1998 21:12:48 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, On Thu, 18 Jun 1998 19:50:12 PDT you wrote > Scott, Pyda > > > Pyda Srisuresh wrote: > > > > > > > > I believe, Client ID is mandatory when IKE key negotiator and the > > > client node for which it is negotiating are not the same. > > > > I don't think this is true. That's not to say that it > > shouldn't be, but > > I don't think that as things currently stand, it is right. > > I think the current draft is sufficiently ambiguous that it does not > rule out either conclusion. There is definitely a need for a statement > that "for a security gateway the use of the client ID is foobar", where > foobar is either "mandatory" or "optional". What does a security gateway do? If it provides security services on behalf of other networked entites then I think the draft is decidedly unambiguous. When some box is operating as a security gateway-- when "[it] is acting as a client negotiator on behalf of another party"-- it must use client IDs in the phase 2 exchange to identify the traffic to be protected. This is, of course, based upon my view of what a security gateway is. If your view is different please tell me how. > > > Given that the ID payload serves the dual role of providing > > > identification as well as policy, this would become a requirement > > > when the policy specification is expanded to include trasport level > > > and other types of services. > > > > The ID payload provides *identification*, not policy. Policy may be > > selected based upon the provided identification, or perhaps based upon > > some other criteria. > > With the concept of client/proxy negotiation I think the ID payload > is overloaded with the concept of policy. If this field is extended to > include multiple subnets, and TCP/UDP port info and whatever, I think > it becomes clearer that it is overloaded, as then there would be a need > to talk about an IKE negotiation on behalf of a client flow, or on > behalf > of a flow aggregate which included many clients, for example. Right now > I view it as being a poor man's policy descriptor - which is capable > of only representing a limited set of policies, and cannot deal with > the case of a router that is serving multiple disjoint subnets. I don't > think that the capability of including policy info in an IKE exchange is > a bad idea, but I think overloading the ID payload with policy semantics > is a bad idea. It already allows TCP/UDP port info and subnets and ranges. No, it can't express multiple disjoint subnets as a single entity. You need as many SAs as you have subnets in that case. This limitation (and also the inability to express the "everything except..." construct) is acknowledged. > Instead I think a separate policy (or selector) payload > should be added, and that the ID payload should be left to identify the > thing that is initiating or terminating the SA. This is an "IPSecond" issue and a draft on how to do this is needed (hint). > The model that a security gateway is always "negotiating on behalf > of" a client may be intuitive in some scenarios, but I believe is not > in others, and that this model should not drive mandatory protocol > behaviours. What is it doing then? Note that that client can be an entire class-B network if you like; client != host. > For example if there are two hosts communicating over the > Internet, and somewhere in the middle two routers, over which the host > to host traffic travels, decide to set up an MPLS label switched path > between themselves to provide for some traffic engineering, I wouldn't > view the setting up of the label switched path as being "on behalf of > the client that was ultimately sourcing the IP packets". It is rather > a policy decision made by the domain administrator, and is completely > transparent to any hosts, who probably have no idea of what > an MPLS label switched path was or why they would ever want someone > to get one on their behalf. Also you wouldn't want to force a separate > label switched path for every client or client address range (subnet) > since that may be irrelevant to the policy aims of the administrator. > > I think exactly the same situation arises with setting up an IPSEC > tunnel between two routers / gateways. In both cases there is a > "connection" (label switched path or SA) and there is a > filtering / selector policy which determines which packets get what > label or get transmitted on what SA. Now if the client ID were > mandatory for a security gateway, then a separate SA *would* be required > for disjoint subnets, because the ID payload, in its duty as a poor > man's policy descriptor, was not capable of representing this and > this would be true even when the source addresses of the packets > to be sent on an SA are irrelevant to the policy that an administrator > wishes to implement. Bad example. MPLS switching is not done "on behalf" of hosts any more than routing protocols are. If we were talking about link encryption it might be more accurate, but who is your peer? You want a single SA to protect multiple disjoint networks. This SA has a single destination address. In the absense of security do all packets from these multiple disjoint networks get routed to this destination? I doubt it. But if they do then send all that traffic through a GRE tunnel and protect it with IPSec. Dan. From owner-ipsec Fri Jun 19 00:13:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA13469 for ipsec-outgoing; Fri, 19 Jun 1998 00:13:01 -0400 (EDT) Message-Id: <3.0.1.32.19980619094828.006dbdd4@172.16.1.10> X-Sender: padma@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 19 Jun 1998 09:48:28 +0500 To: ipsec@ex.tis.com From: Padma Goli Subject: In tunnel mode why options are not copied to outer IP header Cc: kseo@bnn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Karen, I have a pending ( I wanted to ask this question long before) question ( rather a clarification ) in draft-ietf-ipsec-arch-sec-04.txt : In section 5.1.2 Header Construction for Tunnel Mode: 1) It is said that options are never copied to outer IP header from the inner IP header. Why is it so ? 2) According to that a user cannot have tunnel mode security between two endpoints along with strict routing( or any options ). Is it so. But having Strict routing along with security ( I am speaking in the context of tunnel mode ) provided, makes a lot of sense because we can avoid the datagram traversal along a previously known insecured route or a rival's router. 3) We are doing options processing after IpsecOutbound processing. In case of tunnel mode even though the hidden inner IP header had Options set as they are not visible from outer IP header, we are just processing as if no options was present in the inner IP header. Is this way correct. Even if option processing is done before Ipsecoutbound processing, options of the inner IP header will be processed before encapsulation by the IPSEC only at the sender, but the intermediate security gateways acting as just routers will not be doing any options processing at all. If this what is thought of? Hoping an immediate reply. Thanks, Padma Goli. *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| *Padma Goli | *Rendzevous Onchip Pvt Ltd. | *Secunderbad | *Phone No : (040)7742606 | (040)7740406 | *email address : padma@trinc.com | *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| From owner-ipsec Fri Jun 19 12:36:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15898 for ipsec-outgoing; Fri, 19 Jun 1998 12:30:52 -0400 (EDT) Message-ID: <358A960D.1F1139F3@redcreek.com> Date: Fri, 19 Jun 1998 09:47:09 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson , ipsec@tis.com Subject: Re: use of client IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson wrote: > > I think the current draft is sufficiently ambiguous that it does not > rule out either conclusion. There is definitely a need for a statement > that "for a security gateway the use of the client ID is foobar", where > foobar is either "mandatory" or "optional". I think the draft is clear: specifying the ID of the client is a local policy decision, and the meaning of a missing ID payload is implied. > With the concept of client/proxy negotiation I think the ID payload > is overloaded with the concept of policy. Again, I don't see the issue here. The current policy model is identity-based, and that requires some basis of identification. The ID payload serves to provide this basis. How is this overloading the ID payload? It is serving one, and only one purpose, which is to identify the endpoint for which security services are being negotiated. Sometimes that endpoint is the system doing the negotiating, and sometimes it is not. Regarding extending the ID payload to represent disjoint subnets, this is a DOI issue which has been discussed offline. There are a few other related items which were also discussed. As I said, I've been waiting for the new agenda before presenting it to the list. I agree that there are numerous remaining issues regarding policy, negotiation, etc. I'm sure we'll be seeing the new agenda soon... From owner-ipsec Fri Jun 19 13:56:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16166 for ipsec-outgoing; Fri, 19 Jun 1998 13:50:21 -0400 (EDT) Message-Id: <199806191750.NAA16162@portal.ex.tis.com> Date: Fri, 19 Jun 98 13:59:21 EDT From: Charles Lynn To: Padma Goli cc: ipsec@ex.tis.com, kseo@bnn.com Subject: Re: In tunnel mode why options are not copied to outer IP header Sender: owner-ipsec@ex.tis.com Precedence: bulk Padma, Karen is away at a class, so I'll try to address your questions. I think that the issues you are raising do not in general have a simple, easy to describe and implement answer, so they were set aside in the interest of getting the current version of the specifications standardized. I hope that they will be addressed in IPSecond :-). > 1) It is said that options are never copied to outer IP header from > the inner IP header. Why is it so ? Options have semantics, and in general, simply copying may not preserve those semantics. One might need an option by option specification of how it should be transformed when included in an encapsulating header. Your next questions illustrate some of these issues. > 2) According to that a user cannot have tunnel mode security between > two endpoints along with strict routing (or any options). Is it so. I say no, that is not the way I read the documents (but others may not agree :-). Your question 1 is about copying options from an inner header to an outer header -- something that a security gateway would do. As I read question 2, it is about an end-to-end tunnel. In the end-to-end case, any options would not be "copied", they would be inserted as part of whatever IP layer processing is used to create the tunnel header. Note that a source route in the inner header would accomplish nothing, as the packet would already be delivered to the endpoint by the outer header and source route. > But having Strict routing along with security ( I am speaking in the > context of tunnel mode ) provided, makes a lot of sense because we > can avoid the datagram traversal along a previously known insecured > route or a rival's router. In the case of a security gateway to security gateway tunnel, there is nothing prohibiting the inclusion of a source route in the outer header, when the inner header does not include a source route. An implementation may provide additional functionality in its policy database that allows an administrator to specify parameters of tunnels that it creates (whether the receiving security gateway would associate such a source route with the tunnel for return traffic has not been standardized -- but a return tunnel is a separate issue). Traditionally, source routes have been viewed as dangerous since they can be used to implement spoofing attacks. Now that we have IPSec to protect the integrity of source routes implemented via a Routing Header (but not the IPv4 option), maybe folks will view them as less dangerous. Note however, that neither integrity nor any other IPSec services or mechanisms provides any assurance that the routers actually forwarded the packet along the intended route -- one or more of the routers may be untrustworthy or have been compromised. You would have to trust each router in the strict source route -- maybe that is acceptable. > 3) We are doing options processing after IpsecOutbound processing. > In case of tunnel mode even though the hidden inner IP header had > Options set as they are not visible from outer IP header, we are > just processing as if no options was present in the inner IP > header. Is this way correct. I do not think so. First, a security gateway that is going to tunnel a packet (with or without a source route) has to figure out where the tunnel will end. This is the security gateway discovery problem. The discovery mechanism would need to place (at least the unused portion of) a source route into the discovery packet so that it would be routed according to the source route. (Note that the security gateway that is discovered using the source routed packet may not be the same as would have been discovered were the source route not present -- that is to be expected.) The reply packet should include the source route option / routing extension header as it was received at the discovered gateway. Using that information, the encapsulator can identify the remaining portion of the original source route, and can partition it into the segment before the tunnel endpoints and the portion beyond the decapsulator. We might have to legislate whether the tunnel encapsulator or decapsulator is responsible for making the inner destination IP address and source route look right. I suspect that the most deployable solution would be to assume the decapsulator does not do anything special, so that the encapsulator must do the transform -- especially since it is the box that wants to use a source route. Given that decision, when tunneling a packet, the inner source route and destination IP address needs to be adjusted by the encapsulator to appear as it would at the tunnel decapsulator: the inner source route needs to be adjusted for all the hops that were processed by the tunnel -- this is the motivation for having the source route returned in the discovery packet. The IP address needs to updated accordingly. The encapsulating IP header would need to include as its source route the segment (if any) discovered to be between the security gateways (end of tunnel). I think it would actually be better better, for IPv4, if the decapsulator updated the inner IP header and source route, as it can more easily maintain the IPv4 source route semantics. Recall that for IPv4, IPSec cannot even provide integrity for a source route - it is mutable and cannot be predicted. The routing header is easier to handle. > Even if option processing is done before Ipsecoutbound processing, > options of the inner IP header will be processed before > encapsulation by the IPSEC only at the sender, but the intermediate > security gateways acting as just routers will not be doing any > options processing at all. If this what is thought of? This would work for the "copy inner source route to outer source route" portion of the problem, but someone would still have to adjust the inner source route and IP destination address to skip over the portion of the source route between the tunnel encapsulator and decapsulator. Its is all doable, but there are lots of details to get correct. Let me know if I have skipped over too many details to make the above clear. Other options might need their own analysis and processing rules. Charlie From owner-ipsec Fri Jun 19 14:12:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16250 for ipsec-outgoing; Fri, 19 Jun 1998 14:11:51 -0400 (EDT) Date: Fri, 19 Jun 1998 11:27:56 -0700 (PDT) From: Bryan Gleeson Message-Id: <199806191827.LAA16927@shasta-nms.shastanets.com> To: BGleeson@shastanets.com, dharkins@cisco.com Subject: Re: use of client IDs Cc: ipsec@tis.com, skelly@redcreek.com, suresh@livingston.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda said: >I believe, Client ID is mandatory when IKE key negotiator and the >client node for which it is negotiating are not the same. Scott replied: >I don't think this is true. Dan said: >I think the draft is decidedly unambiguous. When some box is operating as >a security gateway [...] it must use client IDs Scott said: >I think the draft is clear: specifying the ID of the client is a local >policy decision ... Bryan: Some other comments .... >This is, of course, based upon my view of what a security >gateway is. If your view is different please tell me how. My view of a security gateway is that it is a router, that is applying security services to some of the packets flowing through it. >> The model that a security gateway is always "negotiating on behalf >> of" a client may be intuitive in some scenarios, but I believe is not >> in others, and that this model should not drive mandatory protocol >> behaviours. > >What is it doing then? Forwarding packets and applying security services to some of them. >Bad example. MPLS switching is not done "on behalf" of hosts any more than >routing protocols are. If we were talking about link encryption it might >be more accurate, but who is your peer? You want a single SA to protect >multiple disjoint networks. This SA has a single destination address. In >the absense of security do all packets from these multiple disjoint networks >get routed to this destination? I doubt it. But if they do then send all >that traffic through a GRE tunnel and protect it with IPSec. Still don't see the fundamental difference. SAs and label switched paths are set up between routers. The packets that are fed into the path/SA may be sourced from an arbitrary number of hosts, and destined for an arbitrary number of hosts. In the absence of security and mpls the packets still get to their destination, but the route taken could be different, and the services applied along the way could be different. Bryan From owner-ipsec Fri Jun 19 14:54:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16343 for ipsec-outgoing; Fri, 19 Jun 1998 14:53:53 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806191908.MAA04035@server.livingston.com> Subject: Re: use of client IDs To: dharkins@cisco.com (Daniel Harkins) Date: Fri, 19 Jun 1998 12:13:33 -0700 (PDT) Cc: BGleeson@shastanets.com, skelly@redcreek.com, suresh@livingston.com, ipsec@tis.com In-Reply-To: <199806190412.VAA14976@dharkins-ss20.cisco.com> from "Daniel Harkins" at Jun 18, 98 09:12:48 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Bryan, > > On Thu, 18 Jun 1998 19:50:12 PDT you wrote > > Scott, Pyda > > > > > Pyda Srisuresh wrote: > > > > > > > > > > > I believe, Client ID is mandatory when IKE key negotiator and the > > > > client node for which it is negotiating are not the same. > > > > > > I don't think this is true. That's not to say that it > > > shouldn't be, but > > > I don't think that as things currently stand, it is right. > > > > I think the current draft is sufficiently ambiguous that it does not > > rule out either conclusion. There is definitely a need for a statement > > that "for a security gateway the use of the client ID is foobar", where > > foobar is either "mandatory" or "optional". > > What does a security gateway do? If it provides security services on > behalf of other networked entites then I think the draft is decidedly > unambiguous. When some box is operating as a security gateway-- when "[it] > is acting as a client negotiator on behalf of another party"-- it must > use client IDs in the phase 2 exchange to identify the traffic to be > protected. This is, of course, based upon my view of what a security > gateway is. If your view is different please tell me how. > Yes, a security gateway does provide security services for networked entites. As far as client negotiator is concerned, it is providing security negotiation service to a client (which in this happens to be a VPN node), not the clients supported by the client. I think, it would be the job of VPN GW client to interface with the negotiator such that its ID and its secure policies are communicated to the negotiator. That way, the negotiator in turn can pass on the information in turn, as part of SA negotiation between GW clients. > > > > Given that the ID payload serves the dual role of providing > > > > identification as well as policy, this would become a requirement > > > > when the policy specification is expanded to include trasport level > > > > and other types of services. > > > > > > The ID payload provides *identification*, not policy. Policy may be > > > selected based upon the provided identification, or perhaps based upon > > > some other criteria. > > > > With the concept of client/proxy negotiation I think the ID payload > > is overloaded with the concept of policy. If this field is extended to > > include multiple subnets, and TCP/UDP port info and whatever, I think > > it becomes clearer that it is overloaded, as then there would be a need > > to talk about an IKE negotiation on behalf of a client flow, or on > > behalf > > of a flow aggregate which included many clients, for example. Right now > > I view it as being a poor man's policy descriptor - which is capable > > of only representing a limited set of policies, and cannot deal with > > the case of a router that is serving multiple disjoint subnets. I don't > > think that the capability of including policy info in an IKE exchange is > > a bad idea, but I think overloading the ID payload with policy semantics > > is a bad idea. > > It already allows TCP/UDP port info and subnets and ranges. No, it can't > express multiple disjoint subnets as a single entity. You need as many SAs > as you have subnets in that case. This limitation (and also the inability > to express the "everything except..." construct) is acknowledged. > Thanks for the clarification. How does it allow TCP/UDP port info? Can you point me to a section that describes this. Thanks. > > Instead I think a separate policy (or selector) payload > > should be added, and that the ID payload should be left to identify the > > thing that is initiating or terminating the SA. > > This is an "IPSecond" issue and a draft on how to do this is needed (hint). > Thanks for the clarification. I do think, it is a good idea to have a seperate policy payload. Doing this in IPsecond sounds good. > > The model that a security gateway is always "negotiating on behalf > > of" a client may be intuitive in some scenarios, but I believe is not > > in others, and that this model should not drive mandatory protocol > > behaviours. > > What is it doing then? Note that that client can be an entire class-B network > if you like; client != host. > The IKE document throughout refers IKE as a process. I dont believe this process is required to be on the same node as VPN, right. If an enterprise has multiple VPN nodes (for load balancing, or whatever), there could be a single IKE negotiator process supporting all the VPN nodes. And, this process can be residing on a stand-alone machine with significant hardware and disk space capacity. I think, we need a clarification on what an IKE client is. Here is what I think IKE does and who its clients are. IKE is providing SA establishment, maintenance and termination services to clients. The clients are SA end-points. So, if a client happens to be a VPN GW node, and has multiple other clients (i.e., end hosts) that it supports, the clients supported by the VPN are NOT the clients of IKE. It is up to the VPN to notify its policies to IKE. Does this make sense? > > For example if there are two hosts communicating over the > > Internet, and somewhere in the middle two routers, over which the host > > to host traffic travels, decide to set up an MPLS label switched path > > between themselves to provide for some traffic engineering, I wouldn't > > view the setting up of the label switched path as being "on behalf of > > the client that was ultimately sourcing the IP packets". It is rather > > a policy decision made by the domain administrator, and is completely > > transparent to any hosts, who probably have no idea of what > > an MPLS label switched path was or why they would ever want someone > > to get one on their behalf. Also you wouldn't want to force a separate > > label switched path for every client or client address range (subnet) > > since that may be irrelevant to the policy aims of the administrator. > > > > I think exactly the same situation arises with setting up an IPSEC > > tunnel between two routers / gateways. In both cases there is a > > "connection" (label switched path or SA) and there is a > > filtering / selector policy which determines which packets get what > > label or get transmitted on what SA. Now if the client ID were > > mandatory for a security gateway, then a separate SA *would* be required > > for disjoint subnets, because the ID payload, in its duty as a poor > > man's policy descriptor, was not capable of representing this and > > this would be true even when the source addresses of the packets > > to be sent on an SA are irrelevant to the policy that an administrator > > wishes to implement. > > Bad example. MPLS switching is not done "on behalf" of hosts any more than > routing protocols are. If we were talking about link encryption it might > be more accurate, but who is your peer? You want a single SA to protect > multiple disjoint networks. This SA has a single destination address. In > the absense of security do all packets from these multiple disjoint networks > get routed to this destination? I doubt it. But if they do then send all > that traffic through a GRE tunnel and protect it with IPSec. > I think, Bryan is arguing for making ID payload (which in its current state is the poor man's policy descriptor) mandatory. > Dan. > > cheers, suresh From owner-ipsec Fri Jun 19 14:58:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16366 for ipsec-outgoing; Fri, 19 Jun 1998 14:57:53 -0400 (EDT) Message-ID: <358AB89C.2F0A3BD5@redcreek.com> Date: Fri, 19 Jun 1998 12:14:36 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: use of client IDs References: <199806191908.MAA04035@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > > It already allows TCP/UDP port info and subnets and ranges. No, it can't > > express multiple disjoint subnets as a single entity. You need as many SAs > > as you have subnets in that case. This limitation (and also the inability > > to express the "everything except..." construct) is acknowledged. > > > > Thanks for the clarification. How does it allow TCP/UDP port info? Can you > point me to a section that describes this. Thanks. > ID payload description, DOI document. From owner-ipsec Fri Jun 19 15:31:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16474 for ipsec-outgoing; Fri, 19 Jun 1998 15:30:53 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806191945.MAA07307@server.livingston.com> Subject: Re: use of client IDs To: skelly@redcreek.com (Scott G. Kelly) Date: Fri, 19 Jun 1998 12:50:50 -0700 (PDT) Cc: suresh@livingston.com, bgleeson@shastanets.com, ipsec@tis.com In-Reply-To: <3589B5A6.7207E47D@redcreek.com> from "Scott G. Kelly" at Jun 18, 98 05:49:42 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk <... snip> > > > Well, there are many cases where an SPD selector could differ from an > > SAD selector. > > Bingo - this is correct (and I missed it in my previous response), but I > don't think you fleshed it out properly below. It's when the SPD > selector is *not an address*, i.e. if it's a FQDN, or DN, or some > certificate field, then that selector (the one which matched the SPD > entry) won't be in subsequent packets, and hence cannot be used to > select the correct SAD entry. > > Additional issues arise when the SPD selectors are address wildcards, > which also can't be used to select the SAD entry due to the possibility > of unintended collisions with earlier more precise SPD entries. One way > to clarify this distinction for purposes of discussion is to > differentiate between SPD selectors (which might be things other than > addresses, protocols, etc), and packet selectors (SAD selectors), which > are *always* addresses, protocols, and SPIs. > > > If the selection criteria is set to be based on packet > > (as opposed to policy), every new packet matching the same policy but > > differing in one regard(say, IP address or TCP/UDP port) would require > > a new SA. > > > > In the case where selection criteria is set to be based on policy, > > the SA selection would match the selection of an SP. It is also > > possible for an SA to match multiple policies. > > > > Again, your terminology confuses me. When you say 'the selection > criteria is set to be based on packet (as opposed to policy)', what do > you mean? > My terminology is based on the IP architecture draft, , section 4.4.1, pg 17 below. For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value: source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) From owner-ipsec Fri Jun 19 15:50:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16590 for ipsec-outgoing; Fri, 19 Jun 1998 15:49:56 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Pyda Srisuresh , dharkins@cisco.com Cc: Bryan Gleeson , skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Fri, 19 Jun 1998 13:05:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, [...] > I think, Bryan is arguing for making ID payload (which in its > current state > is the poor man's policy descriptor) mandatory. Actually I'm proposing that it should be optional, since to make it mandatory would preclude simple cases like "on interface X use security association Y for all traffic sent to destination Z". In general I think things would be much clearer if the discussion was in terms of hosts and routers, and hosts running X, and routers running Y etc. Instead there is a rather confusing array of clients (IKE, GW etc), (but interestingly there are no servers), gateways, nodes, VPNs, processes etc. BTW whats the definition of "client" (a host, host interface, group of hosts, flow, aggregate flow or all of the above) and where is it defined ? I have noticed that the word client does not appear in either the architecture document, the DOI spec, or the ISAKMP spec (except in a reference to Kerberos). Bryan From owner-ipsec Fri Jun 19 16:09:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16688 for ipsec-outgoing; Fri, 19 Jun 1998 16:07:53 -0400 (EDT) Message-ID: <358AC8F7.9D8FABC9@redcreek.com> Date: Fri, 19 Jun 1998 13:24:24 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson CC: Pyda Srisuresh , ipsec@tis.com Subject: Re: use of client IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson wrote: > > Actually I'm proposing that it should be optional, since to make it > mandatory would preclude simple cases like "on interface X use > security association Y for all traffic sent to destination Z". > It *is* optional. We're right back where we started. If the ID payload is not included, the appropriate ID for policy selection is, by definition, that associated with the sender. From owner-ipsec Fri Jun 19 16:23:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16758 for ipsec-outgoing; Fri, 19 Jun 1998 16:22:57 -0400 (EDT) Message-ID: <358ACC91.AAA96377@redcreek.com> Date: Fri, 19 Jun 1998 13:39:45 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh , ipsec@tis.com Subject: Re: use of client IDs References: <199806191945.MAA07307@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > > > If the selection criteria is set to be based on packet > > > (as opposed to policy), every new packet matching the same policy but > > > differing in one regard(say, IP address or TCP/UDP port) would require > > > a new SA. > > > > > > In the case where selection criteria is set to be based on policy, > > > the SA selection would match the selection of an SP. It is also > > > possible for an SA to match multiple policies. > > > > > > > Again, your terminology confuses me. When you say 'the selection > > criteria is set to be based on packet (as opposed to policy)', what do > > you mean? > > > > My terminology is based on the IP architecture draft, > , section 4.4.1, pg 17 below. > Okay, now I think I understand what you are trying to say. Still, if you read a little further in the same draft, you'll find that your assertion that every packet differing in one or another regard would require a new SA is incorrect. In section 4.4.3, page 22, you'll find the text which explains why this is not so. I won't include it here, but it's in the paragraph which begins with For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to... From owner-ipsec Fri Jun 19 16:59:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16866 for ipsec-outgoing; Fri, 19 Jun 1998 16:58:52 -0400 (EDT) Message-Id: <199806192114.OAA15348@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Pyda Srisuresh Cc: BGleeson@shastanets.com, skelly@redcreek.com, ipsec@tis.com Subject: Re: use of client IDs In-Reply-To: Your message of "Fri, 19 Jun 1998 12:13:33 PDT." <199806191908.MAA04035@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jun 1998 14:14:13 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 19 Jun 1998 12:13:33 PDT you wrote [snip] > > It already allows TCP/UDP port info and subnets and ranges. No, it can't > > express multiple disjoint subnets as a single entity. You need as many SAs > > as you have subnets in that case. This limitation (and also the inability > > to express the "everything except..." construct) is acknowledged. > > > > Thanks for the clarification. How does it allow TCP/UDP port info? Can you > point me to a section that describes this. Thanks. It's in section 4.6.2 of the DOI. [snip] > > > For example if there are two hosts communicating over the > > > Internet, and somewhere in the middle two routers, over which the host > > > to host traffic travels, decide to set up an MPLS label switched path > > > between themselves to provide for some traffic engineering, I wouldn't > > > view the setting up of the label switched path as being "on behalf of > > > the client that was ultimately sourcing the IP packets". It is rather > > > a policy decision made by the domain administrator, and is completely > > > transparent to any hosts, who probably have no idea of what > > > an MPLS label switched path was or why they would ever want someone > > > to get one on their behalf. Also you wouldn't want to force a separate > > > label switched path for every client or client address range (subnet) > > > since that may be irrelevant to the policy aims of the administrator. > > > > > > I think exactly the same situation arises with setting up an IPSEC > > > tunnel between two routers / gateways. In both cases there is a > > > "connection" (label switched path or SA) and there is a > > > filtering / selector policy which determines which packets get what > > > label or get transmitted on what SA. Now if the client ID were > > > mandatory for a security gateway, then a separate SA *would* be required > > > for disjoint subnets, because the ID payload, in its duty as a poor > > > man's policy descriptor, was not capable of representing this and > > > this would be true even when the source addresses of the packets > > > to be sent on an SA are irrelevant to the policy that an administrator > > > wishes to implement. > > > > Bad example. MPLS switching is not done "on behalf" of hosts any more than > > routing protocols are. If we were talking about link encryption it might > > be more accurate, but who is your peer? You want a single SA to protect > > multiple disjoint networks. This SA has a single destination address. In > > the absense of security do all packets from these multiple disjoint network >s > > get routed to this destination? I doubt it. But if they do then send all > > that traffic through a GRE tunnel and protect it with IPSec. > > > > I think, Bryan is arguing for making ID payload (which in its current state > is the poor man's policy descriptor) mandatory. For the case that he's describing it already is! Dan. From owner-ipsec Fri Jun 19 17:22:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16916 for ipsec-outgoing; Fri, 19 Jun 1998 17:19:53 -0400 (EDT) Message-Id: <199806192135.OAA15395@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Bryan Gleeson Cc: Pyda Srisuresh , skelly@redcreek.com, ipsec@tis.com Subject: Re: use of client IDs In-Reply-To: Your message of "Fri, 19 Jun 1998 13:05:46 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jun 1998 14:35:21 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 19 Jun 1998 13:05:46 PDT you wrote > Pyda, > > [...] > > I think, Bryan is arguing for making ID payload (which in its > > current state > > is the poor man's policy descriptor) mandatory. > > Actually I'm proposing that it should be optional, since to make it > mandatory would preclude simple cases like "on interface X use > security association Y for all traffic sent to destination Z". (I'm assuming that the box to which this policy is being applied is not sourcing the traffic sent to Z and that Z is the traffic endpoint as well as the IPSec endpoint). IDci= IPv4 subnet, 0.0.0.0/0.0.0.0, protocol=0, port=0 IDcr= IPv4 address, Z, protocol=0, port=0 In my opinion it would be bad for Z to have related policy (which would allow it to accept this negotiation) since it would require every single packet sent to it and sent from it to go through this box. And that is not realistic. If my assumption that the box was not sourcing the traffic is wrong then this is the trivial host-to-host example and it doesn't matter that your "host" was in fact a router because it's acting like a host in this case and passing client identities is not required. If my assumption that Z is not the traffic endpoint was wrong (and that Z is a router) then it is even more bad for Z to have this policy because he's saying that every single packet sent to him (through the particular interface to which this policy is applied) must come from the box in question. This includes all routing updates etc. And if that's the case then I'll ask you why you want to do link encryption with IPSec? If the box in question and Z are more than 1 hop from each other you don't want to do what you think you want to do. Dan. Dan. From owner-ipsec Fri Jun 19 17:55:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16979 for ipsec-outgoing; Fri, 19 Jun 1998 17:54:53 -0400 (EDT) Message-ID: <358AE1E4.877E8179@redcreek.com> Date: Fri, 19 Jun 1998 15:10:44 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Bryan Gleeson , Pyda Srisuresh , ipsec@tis.com Subject: Re: use of client IDs References: <358AC8F7.9D8FABC9@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I just realized I've been fueling this round-and-round due to a misinterpretation on my part. From IKE, ... 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. This is clearly what everyone is referring to, and I had forgotten this. My apologies for the error on my part. From owner-ipsec Fri Jun 19 18:15:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17055 for ipsec-outgoing; Fri, 19 Jun 1998 18:14:52 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806192229.PAA22587@server.livingston.com> Subject: Re: use of client IDs To: dharkins@cisco.com (Daniel Harkins) Date: Fri, 19 Jun 1998 15:35:06 -0700 (PDT) Cc: suresh@livingston.com, BGleeson@shastanets.com, skelly@redcreek.com, ipsec@tis.com In-Reply-To: <199806192114.OAA15348@dharkins-ss20.cisco.com> from "Daniel Harkins" at Jun 19, 98 02:14:13 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > On Fri, 19 Jun 1998 12:13:33 PDT you wrote > [snip] > > > It already allows TCP/UDP port info and subnets and ranges. No, it can't > > > express multiple disjoint subnets as a single entity. You need as many SAs > > > as you have subnets in that case. This limitation (and also the inability > > > to express the "everything except..." construct) is acknowledged. > > > > > > > Thanks for the clarification. How does it allow TCP/UDP port info? Can you > > point me to a section that describes this. Thanks. > > It's in section 4.6.2 of the DOI. > Thanks. I missed that... While we are on the subject of IDs, here is an issue with ID payload format: Say, the negotiator (IKEi) and its client VPN (GWi) are 2 different nodes. The negotiator (IKEi) initiates a quick mode exchange. Say, the ID type used was a range of addresses (i.e., end nodes supported by GWi). How can the gateway on the responder side know the address of its peer gateway node (GWi), using this ID payload? You need the peer's address to have a unique SA identification. Note, the address used by IKEi cannot be assumed to be the address of the client (GWi) it is negotiating for. cheers, suresh From owner-ipsec Fri Jun 19 19:58:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17255 for ipsec-outgoing; Fri, 19 Jun 1998 19:56:53 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , Bryan Gleeson Cc: Pyda Srisuresh , skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Fri, 19 Jun 1998 17:12:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > In my opinion it would be bad for Z to have related policy > (which would > allow it to accept this negotiation) since it would require > every single > packet sent to it and sent from it to go through this box. > And that is not > realistic. An SA is a simplex connection, and assymetric routes are not uncommon. If a box accepts packets from a source IP address of "any", that arrive over an SA, it should not imply that the box has only one default route for sending packets, which all packets must follow, and which has a nexthop IP address of the other end of the SA. I think I now see where some of the confusion lies however. If I have two routers, and a GRE or L2TP tunnel between them, and I want to secure the GRE or L2TP tunnel with IPSEC, then the Quick Mode exchange needed to set up the SA does not need to include the client ID, because in this case the router is acting as a virtual host, and is not proxying for anyone. Is this correct ? Bryan From owner-ipsec Sat Jun 20 11:07:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18654 for ipsec-outgoing; Sat, 20 Jun 1998 11:02:54 -0400 (EDT) Message-Id: <199806201517.IAA24039@greatdane.cisco.com> To: Bryan Gleeson cc: Pyda Srisuresh , skelly@redcreek.com, ipsec@tis.com Subject: Re: use of client IDs In-reply-to: Your message of "Fri, 19 Jun 1998 17:12:44 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 20 Jun 1998 08:17:46 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, On: Fri, 19 Jun 1998 17:12:44 PDT you wrote > An SA is a simplex connection, and assymetric routes are not > uncommon. If a box accepts packets from a source IP address of > "any", that arrive over an SA, it should not imply that the > box has only one default route for sending packets, which all > packets must follow, and which has a nexthop IP address of the > other end of the SA. Under what circumstances would you use the outbound SA that was created with this inbound SA? Your inbound SA is "anyone to me"; your outbound is "me to anyone". If what you mean by "it should not imply a single route" is that under some circumstances you would not apply this SA to outbound traffic then why did you negotiate such policy? The client identities identify traffic to which security is applied. What you seem to want is to protect everything that's routed through some particular route. I don't see the point and that's real ugly. Routing updates would have to modify your security policy. Hmmm. Not too secure considering routing protocols aren't secure (yet). > I think I now see where some of the confusion lies however. > If I have two routers, and a GRE or L2TP tunnel between them, > and I want to secure the GRE or L2TP tunnel with IPSEC, then > the Quick Mode exchange needed to set up the SA does not need > to include the client ID, because in this case the router is > acting as a virtual host, and is not proxying for anyone. > Is this correct ? Yes, that's correct. One way to look at it is that if you *could* use transport mode client IDs aren't necessary; if you must use tunnel mode then they are. Unless you want to specify some particular port/protocol then you need client IDs regardless. Dan. From owner-ipsec Sun Jun 21 23:49:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA21257 for ipsec-outgoing; Sun, 21 Jun 1998 23:37:01 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , Bryan Gleeson Cc: Pyda Srisuresh , skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Sun, 21 Jun 1998 20:52:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > Under what circumstances would you use the outbound SA that was > created with this inbound SA? Your inbound SA is "anyone to me"; your > outbound is "me to anyone". If what you mean by "it should not imply > a single route" is that under some circumstances you would not apply > this SA to outbound traffic then why did you negotiate such policy? A Quick Mode exchange to set up an IPSEC SA does not exist in isolation, but is relative to a previously negotiated ISAKMP SA. Thus the semantics of an absent client ID are "anyone behind this trusted gateway", not "anyone". You seem to be implying that the security policy must be symmetric, which I did not think to be the case, given that as SA is explicitly defined to be simplex. > The client identities identify traffic to which security is applied. > What you seem to want is to protect everything that's routed through > some particular route. I don't see the point and that's real ugly. > Routing updates would have to modify your security policy. Hmmm. Not > too secure considering routing protocols aren't secure (yet). I think that forcing the inclusion of the client ID actually ties the security policy more tightly to routing than otherwise. If I have a site which is multihomed to the Internet via a number (n) of security gateways, and internally uses m subnets, then I need to cater for a host on any subnet being reachable via any gateway, leading to a total of M*N SAs, between this site another remote gateway. As routing changed, a host could "move" from being behind one gateway to another, so the security policy has to take that into account. I still haven't seen a convincing reason for precluding the semantics of "any host reachable via this trusted gateway" to be conveyed in an IPSEC SA establishment. I would think that this would be a common part of many security policies, and that the identity of the trusted gateway would be sufficient to determine the matching SPD entries at a gateway that received an incoming establishment request. Bryan From owner-ipsec Mon Jun 22 02:26:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA21507 for ipsec-outgoing; Mon, 22 Jun 1998 02:21:54 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Bryan Gleeson , Daniel Harkins Cc: Pyda Srisuresh , skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Sun, 21 Jun 1998 23:37:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk correcting my previous post ... > ... Thus the semantics of an absent client ID are "anyone > behind this trusted gateway", not "anyone". Dan pointed out that this is completely wrong. What I meant to say was "the semantics of an absent client ID *should be* anyone behind this trusted gatway ..." Bryan From owner-ipsec Mon Jun 22 08:31:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA22468 for ipsec-outgoing; Mon, 22 Jun 1998 08:27:57 -0400 (EDT) From: Charles Kunzinger To: Subject: Multiple Certificate Request Payloads Message-ID: <5040300017387232000002L022*@MHS> Date: Fri, 19 Jun 1998 21:33:28 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk In cases where a machine can accept certificates issued by two or more different CAs, we are considering using multiple instances of the Certificate Request Payload to indicate to an IKE negotiating partner which CAs are acceptable to machine making the request. When multiple Certificate Request Paylaods are present in a given IKE message, the semantics would be that the recipient should respond with a certifciate issued by at least one of the named CAs. The recipient would not be required to respond with a certificate issued by every named CA, but could return certificates issued by multiple CAs if it so desired. The description in ISAKMP section 5.10 on Certifcate Payload Request processing didn't talk about a case where multiple request occur in a single IKE message, so we are looking for feedback from the group on the use we're considering. In particular, is it legitimate to include multiple Certificate Request Payloads in a single IKE message? Regards, Charlie ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Mon Jun 22 10:29:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23438 for ipsec-outgoing; Mon, 22 Jun 1998 10:16:55 -0400 (EDT) Message-ID: From: Greg Carter To: ipsec@tis.com, "'Charles Kunzinger'" Subject: RE: Multiple Certificate Request Payloads Date: Mon, 22 Jun 1998 10:28:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > ---------- > From: Charles Kunzinger[SMTP:kunzinge@us.ibm.com] > Sent: Friday, June 19, 1998 9:33 PM > To: ipsec@tis.com > Subject: Multiple Certificate Request Payloads > > In cases where a machine can accept certificates issued by two or more > different CAs, we are considering using multiple instances of the > Certificate > Request Payload to indicate to an IKE negotiating partner which CAs are > acceptable to machine making the request. When multiple Certificate > Request > Paylaods are present in a given IKE message, the semantics would be that > the > recipient should respond with a certifciate issued by at least one of the > named > CAs. The recipient would not be required to respond with a certificate > issued > by every named CA, but could return certificates issued by multiple CAs if > it > so desired. > > I think you have to respond with only one, which has the public key needed to verify the signature payload. Unless you are having the same public key signed by multiple Certification Authorities. Which in general is not a good thing. > The description in ISAKMP section 5.10 on Certifcate Payload Request > processing > didn't talk about a case where multiple request occur in a single IKE > message, > so we are looking for feedback from the group on the use we're > considering. In > particular, is it legitimate to include multiple Certificate Request > Payloads > in a single IKE message? > Multiple certificate request payloads are OK. In previous versions of the protocol only a single CRP was used which had a list of acceptable CAs. To make processing easier the payload format changed and now multiple CRP are used. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Mon Jun 22 17:45:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25752 for ipsec-outgoing; Mon, 22 Jun 1998 17:42:09 -0400 (EDT) Date: Mon, 22 Jun 1998 14:55:02 -0700 Message-Id: <199806222155.OAA08903@spire.inside.sealabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Chris Boscolo To: ipsec@tis.com Subject: RE: use of client IDs In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk This seems reasonable. But, I would like to add the following. It seems like there is a disconnect between IPSEC policies, and IKE IDs. Here is what I see. The IPSEC Arch draft specifies selectors which should be used in policy lookup, and says that policies should be ordered and searched in order. Also, the policy determines what action to take: apply IPSEC (using an SA), discard, or bypass. In IKE the IDs try to determine which IPSEC packets should be protected by the SA being negotiated. But, the mapping between these IDs and the policies seems to be muddled. It seems to me that the ID should be a special Policy ID which is negotiated. But, since there isn't currently a current way to negotiate policies or even inform the other side about our policies, this wouldn't work. In the mean time, for the ID, why not use as many of the selector values as are needed to match your local policy for which you are trying to build an SA. Of course this implies the policies are similar on both sides. This way, the responder of the IKE negotiation would use the ID to do a policy lookup. The SA negotiated would be used for that policy. One outcome of this approach is that address ranges and subnets as IDs would lead to ambiguous policy to ID mappings. But, if you ask me, ranges and subnets seem an attempt to accomplish partial policy negotiation anyway. Does this make sense, or am I missing something fundamental here? - chrisb On Sun 21-June, Bryan Gleeson wrote (id ): % %correcting my previous post ... % %> ... Thus the semantics of an absent client ID are "anyone %> behind this trusted gateway", not "anyone". % %Dan pointed out that this is completely wrong. What I meant %to say was "the semantics of an absent client ID *should be* %anyone behind this trusted gatway ..." % %Bryan % From owner-ipsec Mon Jun 22 20:23:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA26308 for ipsec-outgoing; Mon, 22 Jun 1998 20:19:12 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806230034.RAA22508@server.livingston.com> Subject: Re: use of client IDs To: BGleeson@shastanets.com (Bryan Gleeson) Date: Mon, 22 Jun 1998 17:39:19 -0700 (PDT) Cc: BGleeson@shastanets.com, dharkins@cisco.com, suresh@livingston.com, skelly@redcreek.com, ipsec@tis.com In-Reply-To: from "Bryan Gleeson" at Jun 21, 98 11:37:47 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > correcting my previous post ... > > > ... Thus the semantics of an absent client ID are "anyone > > behind this trusted gateway", not "anyone". > > Dan pointed out that this is completely wrong. What I meant > to say was "the semantics of an absent client ID *should be* > anyone behind this trusted gatway ..." > > Bryan > It is very confusing to have such semantics. How is the peer node to know all the subnets behind a VPN node? I would much rather have the subnet (requiring security service) listed explicitly in the ID payload. Let me try and summarize the issues with the client ID payload. I believe, the ID payload as it exists has the following limitations. Transport mode: IKE can negotiate for a client, irrespective of whether the client is the same node as IKE or not. ID type and identification data truly represent client identification. Note, the ID type cannot be a subnet or range! Policy can be communicated in a limited way, using the byte field for protocol and 2-byte field for transport identifier. Tunnel mode: IKE and the tunnel end point (i.e., a VPN node) must be running on the same node. ID type and identification data, in reality, are meant to identify the clients supported by the VPN node, and not the VPN node itself. I.e., the ID type and Identification data is being used to communicate the VPN client policy. In other words, policy is communicated in a limited way using ID type, Identification data, protocol ID and transport port ID. Clearly, the ID payload as it exists is overloaded to carry the semantics of ID and policy. But, it is workable with the above limitations. We need an unambiguous ID payload and a distinct policy payload. These are slated to be discussed in IPsecond. Dan, if you would confirm or deny the above assertions, I would very much appreciate. Thanks. cheers, suresh From owner-ipsec Mon Jun 22 21:14:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26501 for ipsec-outgoing; Mon, 22 Jun 1998 21:11:11 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806230126.SAA24935@server.livingston.com> Subject: Re: use of client IDs To: skelly@redcreek.com (Scott G. Kelly) Date: Mon, 22 Jun 1998 18:31:31 -0700 (PDT) Cc: suresh@livingston.com, BGleeson@shastanets.com, ipsec@tis.com In-Reply-To: <3589B707.1F2363E1@redcreek.com> from "Scott G. Kelly" at Jun 18, 98 05:55:35 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pyda Srisuresh wrote: > > > > Policy is a local matter. Gateways with differing policies may or may > > > not communicate, depending upon the intersection of their policy sets. > > > > > > > Well, not really. > > > > A VPN node has to use policies to determine which SA to send a packet out > > on. When a packet is received on an SA (say, SAin), it will detunnel the > > packet and send to the appropriate target host. When a response comes back > > from the target host, the VPN node has to figure out which of the many SAs > > to use for sending the packet back to peer-VPN node (There may be multiple > > SAs between the same peering nodes). If there is no policy mismatch between > > the peering nodes, this would be no problem in selecting the right SA. > > Otherwise, there is a potential for you to send the packets on the wrong > > SA. > > You missed the point: if their policies don't intersect, *there won't be > a SA*. Let me expand a bit on what I am trying to say here. It is not good enough for policies to intersect. They must match. Alternately, where only a subset of a policy matches, the receiving node must be prepared to split the original policy into one that has a match and one that doesnt have match. That could get messy. Another subtle item is the sequencing of policies on either end. It is quite possible to have SAs established with matching policies and still have the packets blackholed, because the policy ordering is not the same on both ends. When a data packet that must be tunneled securely, arrives on a VPN node; the VPN node will simply search through its policies and will apply the first policy (and its outbound SA) that matches. The receiving peer could be receiving the data packet on a lesser desirable policy than was intended at the time of negotiation. A simple example would be when VPNa and VPN b have the following ordering of policies. VPNa: 1. Send and receive TCP packets with VPNb using 3DES encryption. 2. Send and receive UDP packets with VPNb using DES encryption. 3. Send and receive all IP packets with VPNb using NULL encryption. VPNb: 1. Send and receive all IP packets with VPNb using NULL encryption. 2. Send and receive TCP packets with VPNb using 3DES encryption. 3. Send and receive UDP packets with VPNb using DES encryption. In summary, what I am trying to say is that the current scheme of things require the peer nodes to have matching policies in exactly the same order. Otherwise, bad things could happen. > > > I believe, the intent of exchanging policies is so that a VPN node could > > use the policy to correctly determine which SA to use on the way out. > > Policies are not exchanged, at least not in the current implementations, > as far as I know. Proposals which result from policy are exchanged. > As far as I can tell, policies are exchanged between peer nodes. Without that, you cannot be certain peer nodes will utlize the right SAs for secure data transmission. While policies may be determined locally, they need to be exchanged with the appropriate peer nodes. Hope this helps. cheers, suresh From owner-ipsec Mon Jun 22 22:27:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26760 for ipsec-outgoing; Mon, 22 Jun 1998 22:23:12 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Pyda Srisuresh , Bryan Gleeson Cc: Bryan Gleeson , dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Mon, 22 Jun 1998 19:39:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, > > Dan pointed out that this is completely wrong. What I meant > > to say was "the semantics of an absent client ID *should be* > > anyone behind this trusted gatway ..." > > > > Bryan > > > It is very confusing to have such semantics. How is the peer node > to know all the subnets behind a VPN node? I would much rather > have the subnet (requiring security service) listed explicitly in > the ID payload. The peer node will have an SPD policy for outbound traffic, which will list the subnets. The current use of client ID by a receiving party, as I understand it, is to verify that the SA is suitable, and therefore there needs to be something to verify against - which is the SPD. I do not think that the client ID is intended to dynamically create an SPD entry. Now if you have already verified that your peer negotiator is trusted, as a result of an ISAKMP SA being established, further verification on each IPSEC SA may be redundant in many cases. > Clearly, the ID payload as it exists is overloaded to carry > the semantics > of ID and policy. I agree. > But, it is workable with the above > limitations. We need > an unambiguous ID payload and a distinct policy payload. I think that would be a definite improvement. Bryan From owner-ipsec Mon Jun 22 22:39:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26790 for ipsec-outgoing; Mon, 22 Jun 1998 22:36:12 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806230250.TAA00398@server.livingston.com> Subject: Re: use of client IDs To: BGleeson@shastanets.com (Bryan Gleeson) Date: Mon, 22 Jun 1998 19:56:06 -0700 (PDT) Cc: suresh@livingston.com, BGleeson@shastanets.com, dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com In-Reply-To: from "Bryan Gleeson" at Jun 22, 98 07:39:04 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > Pyda, > > > > Dan pointed out that this is completely wrong. What I meant > > > to say was "the semantics of an absent client ID *should be* > > > anyone behind this trusted gatway ..." > > > > > > Bryan > > > > > It is very confusing to have such semantics. How is the peer node > > to know all the subnets behind a VPN node? I would much rather > > have the subnet (requiring security service) listed explicitly in > > the ID payload. > > The peer node will have an SPD policy for outbound traffic, which > will list the subnets. The current use of client ID by a receiving > party, as I understand it, is to verify that the SA is suitable, > and therefore there needs to be something to verify against - > which is the SPD. I do not think that the client ID is intended to > dynamically create an SPD entry. Now if you have already verified > that your peer negotiator is trusted, as a result of an ISAKMP SA > being established, further verification on each IPSEC SA may be > redundant in many cases. > Trusting a peer node is different from figuring out whether a packet should be tunneled to the peer or not. You cannot make the assumption that your routing table will tell you whether or not a packet should be tunneled to a peer, because you may not be running routing protocols on top of the tunnels. Hope this helps. cheers, suresh From owner-ipsec Mon Jun 22 23:12:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26877 for ipsec-outgoing; Mon, 22 Jun 1998 23:10:11 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Pyda Srisuresh , Bryan Gleeson Cc: Bryan Gleeson , dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Mon, 22 Jun 1998 20:25:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, > Trusting a peer node is different from figuring out whether a > packet should be tunneled to the peer or not. You cannot make > the assumption that your routing table will tell you whether or > not a packet should be tunneled to a peer, because you may not > be running routing protocols on top of the tunnels. I think it is important to note that, as the architecture doc describes, there are logically separate SPDs for inbound and outbound traffic. If A is establishing an IPSEC SA to B, then B could have a policy that says "accept (source IP address) 0.0.0.0 on an SA from A" because it has already established a trust relationship with A and can rely on A to apply its own outbound policy on the SA. Now B could have an outbound policy which says, for example, "send packets destined to 1.1.1.0/24 and 1.1.2.0/24 to A ", but this is separate from the inbound policy. Having a finer granularity inbound policy on B, which explicitly lists the subnets allowed to source traffic is something that I think should be allowed, but not required, because to do this requires, in effect, a policy exchange protocol, so that B can verify the policy defined in the incoming protocol message, with the policy defined in its SPD. Bryan From owner-ipsec Mon Jun 22 23:12:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26883 for ipsec-outgoing; Mon, 22 Jun 1998 23:11:10 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Chris Boscolo , ipsec@tis.com Subject: RE: use of client IDs Date: Mon, 22 Jun 1998 20:26:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Chris, > In the mean time, for the ID, why not use as many of the selector > values as are needed to match your local policy for which you are > trying to build an SA. Of course this implies the policies are > similar on both sides. This way, the responder of the IKE negotiation > would use the ID to do a policy lookup. The SA negotiated would be > used for that policy. > > One outcome of this approach is that address ranges and subnets as > IDs would lead to ambiguous policy to ID mappings. But, if you ask > me, ranges and subnets seem an attempt to accomplish partial policy > negotiation anyway. Yes, and I think a general purpose policy exchange protocol, which is capable of representing the set of IP packets that will be transmitted onto an SA, is a difficult problem to solve. Because an SPD is an ordered list of selectors, you need to able to represent "the set of packets selected by entry 10, except for those selected by entries 1 to 9". Bryan From owner-ipsec Tue Jun 23 07:54:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28647 for ipsec-outgoing; Tue, 23 Jun 1998 07:48:11 -0400 (EDT) Message-ID: <358FC48E.7BFB@phase2net.com> Date: Tue, 23 Jun 1998 08:06:55 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp notify MID values Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The IKE document (5.7) states that the MID used when sending a notify should be unique to the info exchange. The ISAKMP doc says it should be the MID associated with the current negotiation. It seems there are reasons for both: - You probably need the MID from the negotiation to identify the negotiation if you cant extract spi,doi from the offending packet, eg. payload validation doesnt pass. - If you use the MID from the negotiation, encryption IV material can get unsynchronized. Is there a concensus on this issue? jeff From owner-ipsec Tue Jun 23 14:36:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00835 for ipsec-outgoing; Tue, 23 Jun 1998 14:31:53 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806231846.LAA22391@server.livingston.com> Subject: Re: use of client IDs To: BGleeson@shastanets.com (Bryan Gleeson) Date: Tue, 23 Jun 1998 11:52:13 -0700 (PDT) Cc: suresh@livingston.com, BGleeson@shastanets.com, dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com In-Reply-To: from "Bryan Gleeson" at Jun 22, 98 08:25:42 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pyda, > > > Trusting a peer node is different from figuring out whether a > > packet should be tunneled to the peer or not. You cannot make > > the assumption that your routing table will tell you whether or > > not a packet should be tunneled to a peer, because you may not > > be running routing protocols on top of the tunnels. > > I think it is important to note that, as the architecture doc > describes, there are logically separate SPDs for inbound and > outbound traffic. > > If A is establishing an IPSEC SA to B, then B could have a policy > that says "accept (source IP address) 0.0.0.0 on an SA from A" > because it has already established a trust relationship with A and > can rely on A to apply its own outbound policy on the SA. Now B > could have an outbound policy which says, for example, "send packets > destined to 1.1.1.0/24 and 1.1.2.0/24 to A ", but this is separate > from the inbound policy. Having a finer granularity inbound policy > on B, which explicitly lists the subnets allowed to source > traffic is something that I think should be allowed, but not > required, because to do this requires, in effect, a policy exchange > protocol, so that B can verify the policy defined in the incoming > protocol message, with the policy defined in its SPD. > > Bryan > Bryan, A couple of clarifications (at least for myself) to note: 1. In a quick mode, SA proposals and optional ID/policy payload are exchanged in one swoop. So, there is no question of trust relationship being established ahead of policy exchange. However, I do believe, that in the current documentation, the unstated assumption is that for a tunnel mode, the ID of IKE is same as the ID of the VPN node for which SA negotiation is in progress. Hence, the ID payload accompanying SA proposal is actually the policy. In that context, what you say about trust being established prior to policy exchange is correct. 2. Next, the issue of policy direction. During SA negotiation, IKE client for A sends proposals to B. The SA that is represented by these proposals are for inbound data packets to A. Shouldnt the policy that accompanies SA also be in the same direction as the SA? I.e., I believ, the policy description sent by A should in fact be applicable for the inbound packets to A. (and, not the outbound as your message above seems to imply). 3. Lastly, the policy (the description of which may be relegated to IPsecond) cannot be limited to just the source side or the destination side. It has to be a combination of both. Ex: It may not be sufficent to say, a certain SA should be applied to packets directed to an address (say, 172.168.1.1). Rather, it may be desirable to be able to state that a certain SA should be applied to packets from a set of addresses (say, 175.18/16) to an address (say, 172.168.1.1). Have a nice day. cheers, suresh From owner-ipsec Tue Jun 23 14:36:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00856 for ipsec-outgoing; Tue, 23 Jun 1998 14:35:54 -0400 (EDT) Date: Tue, 23 Jun 1998 11:48:13 -0700 Message-Id: <199806231848.LAA12353@spire.inside.sealabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Chris Boscolo To: Bryan Gleeson Cc: ipsec@tis.com Subject: RE: use of client IDs In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon 22-June, Bryan Gleeson wrote (id ): %Chris, % %> In the mean time, for the ID, why not use as many of the selector %> values as are needed to match your local policy for which you are %> trying to build an SA. Of course this implies the policies are %> similar on both sides. This way, the responder of the IKE negotiation %> would use the ID to do a policy lookup. The SA negotiated would be %> used for that policy. %> %> One outcome of this approach is that address ranges and subnets as %> IDs would lead to ambiguous policy to ID mappings. But, if you ask %> me, ranges and subnets seem an attempt to accomplish partial policy %> negotiation anyway. % %Yes, and I think a general purpose policy exchange protocol, which is %capable of representing the set of IP packets that will be transmitted %onto an SA, is a difficult problem to solve. Because an SPD is an %ordered list of selectors, you need to able to represent "the set %of packets selected by entry 10, except for those selected by entries %1 to 9". I don't think this is a concern as long as the src outgoing policies match one for one to the destinations incoming policy. The fact that they match implies the ordering is correct. If a packet I send matches my local policy which is different than the policy on the receiving end the packet will not be accepted anyway. (Assuming the two different policies are using different SA's.) My main point is that in the absence of a complete policy exchanges protocol, we should not try to convey policy information in IKE. In the absence of policy exchange, it is up the people configuring the devices to ensure outgoing policies on one end match incoming policies on the other. Given his, IKE IDs should only contain the information necessary to find that policy. - chrisb From owner-ipsec Tue Jun 23 15:07:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01032 for ipsec-outgoing; Tue, 23 Jun 1998 15:06:54 -0400 (EDT) Message-Id: <199806231922.MAA06633@greatdane.cisco.com> To: ipsec@tis.com Subject: KEA and SKIPJACK declassified MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jun 1998 12:22:24 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Read all about it: http://www.defenselink.mil/news/Jun1998/b06231998_bt316-98.html I called the number at the bottom (NSA Public Affairs) to request a copy of the specs and was told to call the InfoSec 800 number who then told me to call NSA Public Affairs. Sigh, some things never change. Dan. --------------------------------------------------------------------------- ENCRYPTION FORMULAS DECLASSIFIED The Department of Defense today announced the decision by the National Security Agency to declassify both the Key Exchange Algorithm and the SKIPJACK encryption algorithm used in the FORTEZZA(tm) personal computer card. FORTEZZA(tm) provides security at the desktop in the Defense Message System and other DoD applications. This marks the first time that the NSA has declassified such information and made it commercially available. This declassification is an essential part of the Department of Defense's efforts to work with commercial industry in developing reasonably priced computer protection products. This declassification decision will enable industry to develop software and smartcard based security products, which are interoperable with FORTEZZA(tm). The availability of such products will enhance the protection of DoD's sensitive but unclassified and critical non-mission communications. The decision to release SKIPJACK (an 80 bit encryption algorithm that is not extensible to higher key lengths) and KEA (a 1024 bit key exchange algorithm) is restricted to these particular algorithms, and does not apply to other classified NSA algorithms. The SKIPJACK and KEA algorithms and their source codes have been declassified pursuant to Executive Order 12958. Vendors interested in obtaining more information on this matter should contact the National Security Agency Public Affairs Office at 301-688-6524. From owner-ipsec Tue Jun 23 19:46:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02003 for ipsec-outgoing; Tue, 23 Jun 1998 19:44:37 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Pyda Srisuresh , Bryan Gleeson Cc: Bryan Gleeson , dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com Subject: RE: use of client IDs Date: Tue, 23 Jun 1998 17:00:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, > 1. In a quick mode, SA proposals and optional ID/policy payload > are exchanged in one swoop. So, there is no question of trust > relationship being established ahead of policy exchange. What I had in mind was the ISAKMP SA establishment that must occur before the IPSEC SA establishment, thus the remote negotiating peer has already been successfully authenticated before the Quick Mode exchange starts. > 2. Next, the issue of policy direction. > > During SA negotiation, IKE client for A sends proposals to B. > The SA that is represented by these proposals are for inbound > data packets to A. > > Shouldnt the policy that accompanies SA also be in the same > direction as the SA? I.e., I believ, the policy > description sent > by A should in fact be applicable for the inbound packets to A. > (and, not the outbound as your message above seems to imply). Hmm.. I had read it such that the {IDci, IDcr} pair identified the traffic that A was going to send on the SA, and that B used this to key into its SPD in order to verify that it had a matching policy, so I thought it applied to the outbound traffic at A. Bryan From owner-ipsec Tue Jun 23 21:20:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA02229 for ipsec-outgoing; Tue, 23 Jun 1998 21:17:38 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199806240132.SAA29917@server.livingston.com> Subject: Re: use of client IDs To: BGleeson@shastanets.com (Bryan Gleeson) Date: Tue, 23 Jun 1998 18:37:31 -0700 (PDT) Cc: suresh@livingston.com, BGleeson@shastanets.com, dharkins@cisco.com, skelly@redcreek.com, ipsec@tis.com In-Reply-To: from "Bryan Gleeson" at Jun 23, 98 05:00:54 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pyda, > > > 1. In a quick mode, SA proposals and optional ID/policy payload > > are exchanged in one swoop. So, there is no question of trust > > relationship being established ahead of policy exchange. > > What I had in mind was the ISAKMP SA establishment that must occur > before the IPSEC SA establishment, thus the remote negotiating peer > has already been successfully authenticated before the Quick Mode > exchange starts. > I understand. > > 2. Next, the issue of policy direction. > > > > During SA negotiation, IKE client for A sends proposals to B. > > The SA that is represented by these proposals are for inbound > > data packets to A. > > > > Shouldnt the policy that accompanies SA also be in the same > > direction as the SA? I.e., I believ, the policy > > description sent > > by A should in fact be applicable for the inbound packets to A. > > (and, not the outbound as your message above seems to imply). > > Hmm.. I had read it such that the {IDci, IDcr} pair identified the > traffic that A was going to send on the SA, and that B used this to > key into its SPD in order to verify that it had a matching policy, > so I thought it applied to the outbound traffic at A. > Well, one could have interpreted it either way. What I wrote was my interpretation. Lot of the ambiguity is apparantly due to overloading of the ID payload semantics. cheers, suresh From owner-ipsec Wed Jun 24 12:34:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05582 for ipsec-outgoing; Wed, 24 Jun 1998 12:29:59 -0400 (EDT) Message-ID: <35912D55.8F1EF6F0@redcreek.com> Date: Wed, 24 Jun 1998 09:46:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh , ipsec@tis.com Subject: Re: use of client IDs References: <199806231846.LAA22391@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > A couple of clarifications (at least for myself) to note: > > 1. In a quick mode, SA proposals and optional ID/policy payload > are exchanged in one swoop. So, there is no question of trust > relationship being established ahead of policy exchange. This is one portion of this discussion that confuses me, i.e. the references to 'policy exchange'. Somebody help me out here: when is policy *ever* exchanged? My understanding is this: my policy is a local matter, completely defined at my discretion. I *never* send you my policy. Rather, I offer proposals to which you respond. I really don't understand when I hear the ID payload called a 'policy' payload. I reiterate from an earlier post: the policy implementation for the current ipsec suite assumes an identity-based policy model, as opposed to a rule-based policy model. Inherent in such a model is the need for some sort of identification, and the ID payload serves this purpose. So far as I can tell, that is precisely its reason for existence. If I'm missing something, somebody please correct me. From owner-ipsec Wed Jun 24 12:36:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05623 for ipsec-outgoing; Wed, 24 Jun 1998 12:35:56 -0400 (EDT) Message-ID: <35912EEF.1A7ECA1C@redcreek.com> Date: Wed, 24 Jun 1998 09:53:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: use of client IDs References: <199806230126.SAA24935@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > > > Policy is a local matter. Gateways with differing policies may or may > > > > not communicate, depending upon the intersection of their policy sets. > > > > > Let me expand a bit on what I am trying to say here. > > It is not good enough for policies to intersect. They must match. > Alternately, where only a subset of a policy matches, the receiving > node must be prepared to split the original policy into one that > has a match and one that doesnt have match. That could get messy. Re-read the post: the policy sets must intersect. If they don't, the negotiations will fail. Think about it. > > Another subtle item is the sequencing of policies on either end. > It is quite possible to have SAs established with matching policies > and still have the packets blackholed, because the policy ordering > is not the same on both ends. No. The architecture document specifically prescribes the methodology for avoiding this pitfall. > As far as I can tell, policies are exchanged between peer nodes. Without > that, you cannot be certain peer nodes will utlize the right SAs for > secure data transmission. While policies may be determined locally, they > need to be exchanged with the appropriate peer nodes. As stated in the previous post, policies are not exchanged - identities may be, and proposals always are. From owner-ipsec Wed Jun 24 18:18:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07155 for ipsec-outgoing; Wed, 24 Jun 1998 18:11:07 -0400 (EDT) Message-ID: From: Bryan Gleeson To: "Scott G. Kelly" , Pyda Srisuresh , ipsec@tis.com Subject: RE: use of client IDs Date: Wed, 24 Jun 1998 15:27:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, > This is one portion of this discussion that confuses me, i.e. the > references to 'policy exchange'. Somebody help me out here: when is > policy *ever* exchanged? > > My understanding is this: my policy is a local matter, completely > defined at my discretion. I *never* send you my policy. > Rather, I offer > proposals to which you respond. I really don't understand when I hear > the ID payload called a 'policy' payload. > > I reiterate from an earlier post: the policy implementation for the > current ipsec suite assumes an identity-based policy model, as opposed > to a rule-based policy model. Inherent in such a model is the need for > some sort of identification, and the ID payload serves this > purpose. So > far as I can tell, that is precisely its reason for existence. > > If I'm missing something, somebody please correct me. I previously posed a question about what is the definition of the "thing" that client/proxy negotiation is done on behalf of - is it a host, host interface, flow, aggregate flow, group of hosts that share a common address prefix, a group of hosts that may share more than one address prefix, all of the above, or something else ? Given that the payload with the name "Identity" can represent many of these things, and in the future may be able to represent an even richer set of things, the issue is that in practice the payload with the name "Identity" does in fact semantically represent something that in many people's view is "Policy", e.g. the set of packets that are allowed on a particular SA. Bryan From owner-ipsec Thu Jun 25 11:25:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10524 for ipsec-outgoing; Thu, 25 Jun 1998 11:21:42 -0400 (EDT) Message-ID: <7F1A88CDF4D1D0118C8C0000929B54AD2FDC78@spock.timpo.ha.osd.mil> From: "Perry, David" To: "'ipsec@tis.com'" Subject: Does IPsec undermine PKI? Date: Thu, 25 Jun 1998 10:36:47 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk BACKGROUND I am a DOD contractor who is very interested in the potential that IPsec may have for supporting privacy of patient information in the DOD military medical information environment. Since the DOD medical community must interface with commercial healthcare providers, the use of IPsec VPNs (initially in a gateway-to-gateway configuration between commercial sites and military sites) is appealing. I have recently read the ARCH, AH, ESP, and ISAKMP drafts and I am still digesting the concepts. I have recently started following the mailing list. The questions I have below, come from an IPsec end-user perspective, rather than from an implementation perspective, so I hope that this message is appropriate to the mailing list, and appreciate any responses. ISSUE The DOD is currently in the process of standing up a PKI. Some DOD applications are being planned to use the PKI for using X.509 certificates for authentication and encryption purposes. One DOD group is planning a particular application which requires user authentication and data encryption. Two paragraphs, presented below, are excerpts of a point paper providing recommendations for implementation of this particular application. The paragraphs make some statements that don't seem to be quite accurate to me. I was wondering if someone could comment on these statements and on my questions that follow. EXCERPTS FROM THE POINT PAPER 2.2 IPSec can create a Virtual Private Network (VPN) between any interoperable routers or firewalls on an internet. This process takes place in the end location routers and is transparent to the intermediate routers in the internet. Authentication of the sites taking part in the session is inherent in that they share a secret key. Manually keyed IPSec has been implemented in industry in both routers and firewalls. The DMC is currently testing this capability using [brand-name] routers. Encryption is supported in hardware in the larger routers and in software in the smaller routers. IPSec uses IETF Requests for Comments (RFCs) as standards. Automatic symmetric key exchange protocols for IPSec will be standardized later this year to support the encryption process. However, with the limited number of current users the manual method is acceptable and manageable. The [brand-name firewall] at the [central site] is also capable of manual key IPSec encryption. The [other brand name firewall] also supports manual IPSec and will be adding the automatic key exchange this year. We can expect a number of vendor firewalls and routers to come out with standard automatic key exchange IPSec capabilities in 1998. Interoperability is a key issue in that the solution must be vendor neutral and therefore be standards based and tested for interoperability. The interoperability issue is always difficult and costly to test. 2.2.1 The IPSec methods used to establish sessions between end points differ from those that are used in PKI. PKI operates at the application level and IPSec operates at the IP level. The automatic key exchange algorithms use different hash algorithms (MD5 in IPSec and Secure Hash Algorithm in PKI) to sign the certificates containing the public and private keys. This would become an issue if a large number of sites had to access the [application] server and manual keys became unmanageable. There are industry certificate issuers that would fulfill this role for IPSec. Use of IPSec would have the effect of under minding the PKI initiative. MY QUESTIONS AND COMMENTS 1. I don't have much problem with para 2.2, above. 2. In generic terms, does a PKI really provide the capability to establish sessions between end points? 3. Isn't IKE (ISAKMP) the IPsec component that is responsible for establishing sessions between end points, and doesn't IKE operate at the application layer?...I just read para 2.5.1 in the ISAKMP draft, it states that ISAKMP can be implemented over any transport protocol or over IP itself...and MUST include send and receive capability for ISAKMP using UDP on port 500. So, it looks to me like it could be an application layer service? What's the correct answer? 4. I know that AH and ESP operate at Layer 3. The ISAKMP Draft (drafts-ipsec-isakmp-09.txt) shows a picture in section 2.2 of the draft as to the placement of ISAKMP in a network architecture, however the text does not really seem to point out what layer it operates in. 5. Para 2.2.1 above eludes that IPsec supports only MD5 in automatic key exchange algorithms. My understanding is that IPsec compliant implementations must support MD5, SHA-1 and Null authentication algorithms and for encryption DES and Null encryption. So I would assume that the automatic key exchange algorithms would support attributes for these as well. 6. The statement, above, about IPsec "undermining the [DOD] PKI initiative" seems to stem from the author's implied belief that PKI also provides the underlying security algorithms responsible performing the authentication and encryption. My question is simply how do IPsec and PKI coexist and what is the demarcation of functionality between the two? 7. My observation is that a public key infrastructure is a "utility" that serves certificates. This utility is independently linked to the functions of IPsec. In fact, isn't PKI a utility that is independently linked to any security-based application? I would restate the above statement as, "The choice of PKI implementation may have the effect of undermining a security initiative because there is relatively little standardization among various PKI implemenations." It seems the challenge is to the vendor community to make industry standards work. Therefore it is my hopes that vendors implementing IPsec will make their products at least compatible to mainstream PKI implementations...there is nothing in the IPsec specifications that is stopping them from doing so...is there? Thanks. David W. Perry SRA International TriService Infrastructure Management Program Office From owner-ipsec Thu Jun 25 18:39:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12161 for ipsec-outgoing; Thu, 25 Jun 1998 18:33:34 -0400 (EDT) Date: Thu, 25 Jun 1998 16:16:30 -0400 From: yjj@mci.net (Yuan John Jiang) Message-Id: <199806252016.QAA04116@cletus.> To: ipsec@tis.com, perry@timpo.osd.mil Subject: Re: Does IPsec undermine PKI? Sender: owner-ipsec@ex.tis.com Precedence: bulk David, You are absolutely right. The point paper is full of rubbish. 1. VPNs using firewalls with AH, ESP and ISAKMP (IPsec) plus PKI authentication are available. I tested Checkpoint's Firewall-1 4.0 beta a few months ago. It worked quite well among Firewall-1 gateways. It uses Entrust PKI, which was rather combersome to install and manage. I'm not sure about the inter-operability of gateways among different vendors. 2. The IPsec protocols use H-MD5 or H-SHA for MAC. They are more secure than straight MD5 or SHA. 3. PKI is on a different layer from the IPsec protocols IPsec does not care about the details of of the PKI, be it X.509 or PGP. Take my tested Firewall-1 as an example, when comes to PKI stuff, it always calls the Entrust library to deal with it. Y. John Jiang, Internet Engineer, Internet Security, MCI 703-715-7480, v272-7480, 2100 Reston Parkway, Reston, VA 20191 From owner-ipsec Thu Jun 25 20:51:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12548 for ipsec-outgoing; Thu, 25 Jun 1998 20:49:35 -0400 (EDT) Date: Thu, 25 Jun 1998 17:59:43 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Question about ID types in IPSEC DOI To: ddp@network-alchemy.com Cc: ipsec@tis.com, vipul.gupta@Eng.Sun.Com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8dToRSMbU2cTq1fFzBcpHw== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 4.6.2.12 of the IPSec DOI draft states: 4.6.2.12 ID_KEY_ID The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre- shared key should be used to authenticate Aggressive mode negotiations. Am I correct in assuming that this does not preclude the use of ID_KEY_ID type identification when Main mode (rather than aggressive mode) is used in phase I. Amongst the following ID types mentioned in Section 4.6.2.1, are all of them valid for use in phase II as well? ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 Thanks for your time, vipul From owner-ipsec Thu Jun 25 21:13:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12577 for ipsec-outgoing; Thu, 25 Jun 1998 21:11:39 -0400 (EDT) Message-Id: <199806260127.SAA14483@gallium.network-alchemy.com> To: Vipul Gupta cc: ipsec@tis.com, vipul.gupta@Eng.Sun.Com Subject: Re: Question about ID types in IPSEC DOI In-reply-to: Your message of "Thu, 25 Jun 1998 17:59:43 PDT." Date: Thu, 25 Jun 1998 18:27:28 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Vipul, The is a actually a bug in the current DOI. Since the last draft of ISAKMP, the IPSEC DOI ID types apply only to Phase 2 negotiations. The valid Phase 1 types are now listed in the ISAKMP draft (and are much more limited). The ID_KEY_ID type predates the ISAKMP Vendor ID payload and should probably be deprecated in favor of that, since it's essentially a private extension. Who's using this type in Phase 1? Derrell From owner-ipsec Fri Jun 26 12:14:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15060 for ipsec-outgoing; Fri, 26 Jun 1998 12:11:50 -0400 (EDT) Message-Id: <199806251520.LAA17089@ghostwheel.ncsl.nist.gov> Date: Thu, 25 Jun 1998 11:20:42 -0400 (EDT) To: dharkins@cisco.com Cc: ipsec@tis.com From: rob.glenn@nist.gov Subject: Re: KEA and SKIPJACK declassified X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, NIST now has those specifications online in PDF format. See http://csrc.nist.gov/encryption/skipjack-kea.htm for more details. Rob G. rob.glenn@nist.gov > Read all about it: > > http://www.defenselink.mil/news/Jun1998/b06231998_bt316-98.html > > I called the number at the bottom (NSA Public Affairs) to request a >copy of the specs and was told to call the InfoSec 800 number who then >told me to call NSA Public Affairs. Sigh, some things never change. > > Dan. From owner-ipsec Fri Jun 26 12:56:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15339 for ipsec-outgoing; Fri, 26 Jun 1998 12:55:52 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Fri, 26 Jun 1998 20:21:05 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: rob.glenn@nist.gov cc: ipsec@tis.com Subject: Re: KEA and SKIPJACK declassified In-Reply-To: <199806251520.LAA17089@ghostwheel.ncsl.nist.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 25 Jun 1998 rob.glenn@nist.gov wrote: > NIST now has those specifications online in PDF format. > See http://csrc.nist.gov/encryption/skipjack-kea.htm for > more details. > > Rob G. > rob.glenn@nist.gov Rob, you just must enjoy the fuss on sci.crypt that has lasted for two last days :). Don't you? On the more serious side, http://www.cs.technion.ac.il/~biham/Reports/SkipJack/ shows that even the big boys came to play. Helger Lipmaa http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Fri Jun 26 13:50:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15864 for ipsec-outgoing; Fri, 26 Jun 1998 13:49:02 -0400 (EDT) Message-Id: <199806261804.OAA05311@jekyll.piermont.com> To: rob.glenn@nist.gov cc: dharkins@cisco.com, ipsec@tis.com Subject: Re: KEA and SKIPJACK declassified In-reply-to: Your message of "Thu, 25 Jun 1998 11:20:42 EDT." <199806251520.LAA17089@ghostwheel.ncsl.nist.gov> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Jun 1998 14:04:03 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk There are several implementations already available (the one from Finland appeared about 1hr after the news release; I didn't finish mine until later that day), and Biham has already made some progress in attacking a reduced (16 round) version of the cipher. Unfortunately, the document available on the NIST site is rather difficult to read in some critical places, notably in the F() table, because it is a PDF of a scan. The version of the document on http://www.jya.com/skipjack-spec.htm in HTML is more readable, and includes a cleaned up version of the F() table data (which took some work for most of us to figure out.) Some people I know are working on converting the whole thing into TeX for archival documentary purposes. .pm rob.glenn@nist.gov writes: > > Dan, > > NIST now has those specifications online in PDF format. > See http://csrc.nist.gov/encryption/skipjack-kea.htm for > more details. > > Rob G. > rob.glenn@nist.gov > > > Read all about it: > > > > http://www.defenselink.mil/news/Jun1998/b06231998_bt316-98.html > > > > I called the number at the bottom (NSA Public Affairs) to request a > >copy of the specs and was told to call the InfoSec 800 number who then > >told me to call NSA Public Affairs. Sigh, some things never change. > > > > Dan. > > > From owner-ipsec Fri Jun 26 14:47:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16012 for ipsec-outgoing; Fri, 26 Jun 1998 14:47:03 -0400 (EDT) Date: Fri, 26 Jun 1998 15:01:56 -0400 Message-Id: <199806261901.PAA11007@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Perry, David" Cc: "'ipsec@tis.com'" In-Reply-To: Perry, David's message of Thu, 25 Jun 1998 10:36:47 -0500, <7F1A88CDF4D1D0118C8C0000929B54AD2FDC78@spock.timpo.ha.osd.mil> Subject: Re: Does IPsec undermine PKI? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Perry, David" Date: Thu, 25 Jun 1998 10:36:47 -0500 2.2.1 The IPSec methods used to establish sessions between end points differ from those that are used in PKI. PKI operates at the application level and IPSec operates at the IP level. It's clear that whoever wrote this point paper doesn't know what the heck they are talking about. At a guess, they are equating "PKI" with something like SSL (the Secure Sockets Layer, used by secure http), when in fact IPSEC and SSL both take advantage of a Public Key Infrastructure (PKI) --- namely certificates and some kind of hierarchy of Certification Authorities (CA's). - Ted From owner-ipsec Fri Jun 26 15:29:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16145 for ipsec-outgoing; Fri, 26 Jun 1998 15:28:09 -0400 (EDT) Date: Fri, 26 Jun 1998 12:38:23 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: More questions on ID types To: ipsec@tis.com, ddp@network-alchemy.com Cc: vgupta@nobel.Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JR00qEFEo9jNyytSdmUEWw== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk I thought I understood the role of IDs but I am not so sure any more. I hope some one on this list can help. I used to think that the (mandatory) IDs in phase I identify ISAKMP participants (the initiator and responder) and (optional) phase II IDs identify clients, such as subnets, for which the ISAKMP participants negotiate tunnel-mode IPSec SAs. A typical scenario might be two firewalls that use ISAKMP to negotiate IPSec SAs for two subnets -- each subnet represents a branch office and hosts on these subnets wish to communicate across the Internet using a secure tunnel. According to the latest ISAKMP draft, the only ID types allowed in phase I are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET. With the reasoning above, I can see how the first two make sense as IDs for phase I. However, the latter two ID types seem more appropriate for use in phase II. I have some concerns about limiting phase I IDs to these four types. I am interested in the use of IPSec in remote access scenarios (details in draft-gupta-ipsec-remote-access-00.txt). In particular, I'd like to use IPSec to securely connect a road warrior (attached to the Internet using a dynamic, ISP-allocated address) to his corporate Intranet. In order to minimize the changes required within the Intranet, I'd like to use IPSec in "end-to-edge" mode i.e. from the remote computer (R) to an IPSec gateway (G) on the Intranet's periphery. Most Intranets assume mutual trust between internal hosts and use addresses that are not advertised on the Internet (even when they are globally unique). Private addresses on the Intranet can be handled by using NAT (network address and port translation) or dynamically assigning the remote host an internal address (as described in the ISAKMP configuration draft). However, before anything else, R must set up an ISAKMP SA with G. Assuming that preshared keys are used for phase I authentication, R needs to convey an identity that G can use to look up its preshared secret associated with R (or the employee authorized to use R). Since R communicates with G using a dynamic ISP address, what identity type should it use in phase I -- ID_IPV4_ADDR doesn't help because there is no "fixed" address associated with the portable that could be used to look up the preshared secret. If ID_USER_FQDN or ID_KEY_ID were allowed as valid phase I ID types, they could be used effectively in this situation. Am I missing something here? Thanks for your time. vipul > To: Vipul Gupta > cc: ipsec@tis.com, vipul.gupta@Eng > Subject: Re: Question about ID types in IPSEC DOI > Date: Thu, 25 Jun 1998 18:27:28 -0700 > From: "Derrell D. Piper" > > Vipul, > > The is a actually a bug in the current DOI. Since the last draft of ISAKMP, > the IPSEC DOI ID types apply only to Phase 2 negotiations. The valid Phase 1 > types are now listed in the ISAKMP draft (and are much more limited). > > The ID_KEY_ID type predates the ISAKMP Vendor ID payload and should probably > be deprecated in favor of that, since it's essentially a private extension. > > Who's using this type in Phase 1? > > Derrell > From owner-ipsec Fri Jun 26 16:03:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16325 for ipsec-outgoing; Fri, 26 Jun 1998 16:03:13 -0400 (EDT) Date: Fri, 26 Jun 1998 16:15:26 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199806262015.QAA05310@earth.hpc.org> To: ddp@network-alchemy.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199806260134.SAA20843@baskerville.CS.Arizona.EDU> Subject: Re: Question about ID types in IPSEC DOI Sender: owner-ipsec@ex.tis.com Precedence: bulk > Since the last draft of ISAKMP, > the IPSEC DOI ID types apply only to Phase 2 negotiations. The valid Phase 1 > types are now listed in the ISAKMP draft (and are much more limited). > The ID_KEY_ID type predates the ISAKMP Vendor ID payload and should probably > be deprecated in favor of that, since it's essentially a private extension. Why should the ID types in Phase 1 be limited? I'd gotten the very strong impression that there was no intent to do this --- it has policy implications that are really unnecessary. Hilarie From owner-ipsec Fri Jun 26 16:04:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16324 for ipsec-outgoing; Fri, 26 Jun 1998 16:03:11 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF1D93B0@exchange.timestep.com> From: Roy Pereira To: "Derrell D. Piper" , Vipul Gupta Cc: ipsec@tis.com, vipul.gupta@Eng.Sun.Com Subject: RE: Question about ID types in IPSEC DOI Date: Fri, 26 Jun 1998 16:17:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDA13F.7D6CDF20" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDA13F.7D6CDF20 Content-Type: text/plain Why wouldn't you be able to use ID_KEY_ID in phase 1? It is just an identity 'blob' that can have any format, so instead of using an email address with a specific format as an identifier (user@site) you could also use a non-formated identifier like "Bob's Laptop" if you use ID_KEY_ID. > -----Original Message----- > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > Sent: Thursday, June 25, 1998 9:27 PM > To: Vipul Gupta > Cc: ipsec@tis.com; vipul.gupta@Eng.Sun.Com > Subject: Re: Question about ID types in IPSEC DOI > > > Vipul, > > The is a actually a bug in the current DOI. Since the last > draft of ISAKMP, > the IPSEC DOI ID types apply only to Phase 2 negotiations. > The valid Phase 1 > types are now listed in the ISAKMP draft (and are much more > limited). > > The ID_KEY_ID type predates the ISAKMP Vendor ID payload and > should probably > be deprecated in favor of that, since it's essentially a > private extension. > > Who's using this type in Phase 1? > > Derrell > ------ =_NextPart_001_01BDA13F.7D6CDF20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Question about ID types in IPSEC DOI

Why wouldn't you be able to use ID_KEY_ID in phase = 1? 

It is just an identity 'blob' that can have any = format, so instead of using an email address with a specific format as = an identifier (user@site) you could also use a non-formated identifier = like "Bob's Laptop" if you use ID_KEY_ID.

> -----Original Message-----
> From: Derrell D. Piper [mailto:ddp@network-alchemy.com]
> Sent: Thursday, June 25, 1998 9:27 PM
> To: Vipul Gupta
> Cc: ipsec@tis.com; = vipul.gupta@Eng.Sun.Com
> Subject: Re: Question about ID types in IPSEC = DOI
>
>
> Vipul,
>
> The is a actually a bug in the current = DOI.  Since the last
> draft of ISAKMP,
> the IPSEC DOI ID types apply only to Phase 2 = negotiations. 
> The valid Phase 1
> types are now listed in the ISAKMP draft (and = are much more
> limited). 
>
> The ID_KEY_ID type predates the ISAKMP Vendor = ID payload and
> should probably
> be deprecated in favor of that, since it's = essentially a
> private extension.
>
> Who's using this type in Phase 1?
>
> Derrell
>

------ =_NextPart_001_01BDA13F.7D6CDF20-- From owner-ipsec Fri Jun 26 21:36:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA17423 for ipsec-outgoing; Fri, 26 Jun 1998 21:31:12 -0400 (EDT) From: Dan McDonald Message-Id: <199806270146.SAA14958@kebe.eng.sun.com> Subject: Byte-count lifetime enforcement? To: ipsec@tis.com Date: Fri, 26 Jun 1998 18:46:54 -0700 (PDT) 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 As I was chasing bugs in lifetime counts, particularly that my _outbound_ number of bytes wasn't consistent with the _inbound_ number of bytes, the thought occurred to me that, while I am self-consistent (after fixing said bug, of course), I might not be consistent with others. This _may_ be an interoperability issue in that one side's byte-count will expire before the other side's, leaving one side using an SA that is expired on the other side. If I'm missing something here (an ISAKMP Notification of some kind?), please let me know. If I'm not missing anything, read on for more details. ... The Architecture document touches upon this issue with the following text: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. But for ESP, _WHICH_ algororithm? The number of bytes applied with encryption will be different than authentication. We have several options for "number of bytes" counts: * Number of bytes in the "protected" portion of the datagram, before any security is applied. This means the transport payload length or the inner datagram total length. * Number of bytes that get crunched through the _primary_ algorithm. For ESP, this is encryption (and null encryption counts here), and for AH, it would be authentication. This would include pad bytes, etc. * Some other method of byte count, TBD. Any "accepted" method? It's nice to be consistent with your implementation, but we ARE in the interoperability business; it would be nice to be consistent with others too. Dan From owner-ipsec Fri Jun 26 21:42:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA17441 for ipsec-outgoing; Fri, 26 Jun 1998 21:41:12 -0400 (EDT) Message-Id: <199806270156.VAA03124@adk.gr> To: Dan McDonald Cc: ipsec@tis.com Subject: Re: Byte-count lifetime enforcement? In-reply-to: Your message of "Fri, 26 Jun 1998 18:46:54 PDT." <199806270146.SAA14958@kebe.eng.sun.com> Date: Fri, 26 Jun 1998 21:56:47 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: Dan McDonald Subject: Re: Byte-count lifetime enforcement? Cc: ipsec@tis.com Date: 06/26/98, 21:56:47 I don't think this is an issue; to begin with, the counters *will* get out of sync (unless you don't lose any packets at all). Whoever expires first will cause another key negotiation. So, implement whatever makes you happy (within reason, I suppose). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNZRRX70pBjh2h1kFAQFhpQP9EJZX4lLsBkiAf2MOt9imN3ZUW2gHzQOF SCb2gmsHZaoDPz4OrrTA4r5Wc+9jzEyGxk8bDPxBU/jqBXU6G4pDostGyh5Tf+qs W3JXyZkvmUQ985oxf1W4ZbmkH4ftgriRKiqwShwd5WRq7k1t1suUIKpfszev7JSB C3xSBze4jww= =US5V -----END PGP SIGNATURE----- From owner-ipsec Mon Jun 29 07:08:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA22612 for ipsec-outgoing; Mon, 29 Jun 1998 06:58:40 -0400 (EDT) Message-ID: <35977656.441E05AC@cale.checkpoint.com> Date: Mon, 29 Jun 1998 14:11:18 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: draft for a new authentication mode for IKE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk We have submitted a draft for a new authentication mode for IKE: Abstract: This document describes a new authentication mode for the Internet Key Exchange (IKE). This mode extends the authentication modes defined in [IKE]. The proposed mode assumes an asymmetry between the authenticating entities. One entity, typically an edge device (e.g. firewall), authenticates using public key techniques, while the other entity, typically a remote user, authenticates using challenge response techniques. The mode is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. The draft can be found at: http://www.ietf.org/internet-drafts/draft-litvin-ipsec-isakmp-hybrid-auth-00.txt -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Mon Jun 29 10:42:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23585 for ipsec-outgoing; Mon, 29 Jun 1998 10:40:42 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44100363@scc-server3.semaphorecom.com> From: CJ Gibson To: Dan McDonald Cc: ipsec@tis.com Subject: RE: Byte-count lifetime enforcement? Date: Mon, 29 Jun 1998 08:03:14 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I have even more questions about this issue. It seems reasonable for the receiving end of an SA to count protected bytes received and, if that number passed the limit, drop the current packet and start re-keying. (Or implement a soft limit and re-key a bit earlier). However, should the transmitting side also count protected bytes? If I am a gateway, wouldn't it be my job not to send more than the max kbytes? If I do this, the receiving side will never go over the limit (which I think is good) but it will still have to check to see if I made a mistake. If both sides implement a soft limit, hopefully one will be less than the other and re-keying will not start up on both sides at the same time (at least not too often). So now I've talked myself into checking both the receive and the xmit end of my SAs. A comment on Dan's statement about having only one SA up. This shouldn't happen because both are renegotiated at the same time. In any case, doesn't the original negotiation use the same kbyte limit for both SA's? Perhaps this is only in my implementation..? -CJ -----Original Message----- From: Dan McDonald [SMTP:danmcd@Eng.Sun.Com] Sent: Friday, June 26, 1998 6:47 PM To: ipsec@tis.com Subject: Byte-count lifetime enforcement? As I was chasing bugs in lifetime counts, particularly that my _outbound_ number of bytes wasn't consistent with the _inbound_ number of bytes, the thought occurred to me that, while I am self-consistent (after fixing said bug, of course), I might not be consistent with others. This _may_ be an interoperability issue in that one side's byte-count will expire before the other side's, leaving one side using an SA that is expired on the other side. If I'm missing something here (an ISAKMP Notification of some kind?), please let me know. If I'm not missing anything, read on for more details. ... The Architecture document touches upon this issue with the following text: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. But for ESP, _WHICH_ algororithm? The number of bytes applied with encryption will be different than authentication. We have several options for "number of bytes" counts: * Number of bytes in the "protected" portion of the datagram, before any security is applied. This means the transport payload length or the inner datagram total length. * Number of bytes that get crunched through the _primary_ algorithm. For ESP, this is encryption (and null encryption counts here), and for AH, it would be authentication. This would include pad bytes, etc. * Some other method of byte count, TBD. Any "accepted" method? It's nice to be consistent with your implementation, but we ARE in the interoperability business; it would be nice to be consistent with others too. Dan From owner-ipsec Mon Jun 29 15:53:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24834 for ipsec-outgoing; Mon, 29 Jun 1998 15:51:14 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199806270146.SAA14958@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Jun 1998 16:04:01 -0400 To: Dan McDonald From: Stephen Kent Subject: Re: Byte-count lifetime enforcement? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Good point. Sorry the arch doc was not clear enough on this point. For both AH and ESP, my intent was to count IP payload, prior to adding the ESP header and trailer. (This makes it easy to use the IP total length value that is already available to the implementation.) The text suggests more of an algorithm input approach; I don't recall who proivided that clarifying text, but I apologize for not having examined it more closely. I don't like the algorithm input approach as it seems ambiguous when we apply two algorithms, i.e., for encryption and authentication, since they cover different sets of bytes! Steve From owner-ipsec Mon Jun 29 15:57:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24864 for ipsec-outgoing; Mon, 29 Jun 1998 15:57:21 -0400 (EDT) Message-Id: <3.0.5.32.19980629161231.009b7a70@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 16:12:31 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Proposed charter Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I have floated the proposed charter among a few people that have said various things about IPsecond. I have received a few responses, but it is overdue for workgroup input and then IESG submission. Note that Ted and I are waiting for 3 IDs to get the proscribed changes. All three authors had tagged this week to get it done. They know who they are. Please just do it! IP Security Protocol (ipsec) ---------------------------- Charter Chair(s): Theodore Ts'o < Robert Moskowitz < Security Area Director(s): Jeffrey Schiller < Marcus Leech < Security Area Advisor: Jeffrey Schiller < Mailing Lists: General Discussion:ipsec@tis.com To Subscribe: ipsec-request@tis.com Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Description of Working Group: Although the IPsec main technology has been specified and is actively being implemented and deployed, the original work group deferred a number of work items. Addressing these items, plus needed minor adjustments to IPsec and IKE will be the domain of this rechartered IP Security Protocol Working Group (IPSEC). The new efforts will be broken into three catagories: Address any corrections or improvements need to either advance the IPsec/IKE documents or recycle at level. Add functionality and extend basic functions where needed, specifically: leftRemote client support. Policy/tunnel endpoint discovery. Complex tunnel management. ICMP messages, standardized error codes, and MIBs. Additional algorithms and IKE DOI options. Address reasonable recommendations from the Secure Multicasting IRTF workgroup. Goals and Milestones: Apr 1999 Planned Advance Architecture, ESP, AH, and current algorithms Apr 1999 Planned Recycle/Advance IKE, DOI, ISAKMP documents Dec 1998 Planned Publish MIBs for IPsec/IKE Dec 1998 Planned Publish Error codes and Messages for IPsec/IKE May 1998 Submitted The ISAKMP Configuration Method draft-ietf-ipsec-isakmp-mode-cfg-04.txt May 1998 Submitted Extended Authentication Within ISAKMP/Oakley draft-ietf-ipsec-isakmp-xauth-02.txt Feb 1998 Submitted The Use of HMAC-RIPEMD-160-96 within ESP and AH draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt Dec 1997 Submitted A GSS-API Authentication Mode for ISAKMP/Oakley draft-ietf-ipsec-isakmp-gss-auth-01.txt Feb 1998 Submitted IPSec Policy Data Model draft-ietf-ipsec-policy-model-00.txt Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Jun 29 16:09:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24902 for ipsec-outgoing; Mon, 29 Jun 1998 16:09:20 -0400 (EDT) Message-Id: <3.0.5.32.19980629162439.009bd340@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 16:24:39 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Next IPsec workshop Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk ICSA in conjunction with IBM are planning the next IPsec workshop. The date we have been able to get is the week of Oct 26th. The host is IBM's AS/400 Endicott group and they will be hosting it at Holiday Inn Arena, Binghamton, New York. We are working out the site details. Why YAW? CA interoperablity. leftI am working on significant CA participation. Got a couple items in the works that should be announced next month. IPPCP -- Remote clients, ya know? Remote client support. leftI hope we can set direction for remote client support and do at least some engineering level work with whatever direction gets set. Complex architecture. leftTransport within tunnels. NAT traversal. Mobile gateways. Other nasties. And of course new comers and others. Although non IPsec developers are welcome to come, They should develop a test plan to help the developers. Time for this around Chicago time. Anyway. That is the date and location. I will soon be announcing how to get in touch for reservations and workshop planning. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Jun 29 17:27:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25294 for ipsec-outgoing; Mon, 29 Jun 1998 17:26:38 -0400 (EDT) From: avs@winner.lc.lucent.com Message-ID: <359806B8.9241F055@winner.lc.lucent.com> Date: Mon, 29 Jun 1998 17:27:20 -0400 Original-From: Sashidhar V Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: A question about SPD selectors Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I am having some confusion about the selectors in SPD. For the type of IP addresses standard says that an SPD entry can be a single IP address, multicast, a range of addresses or a wildcard address. But it does not say any combinations of these types. That means comma seperated list of the above values. For example aaa.bbb.ccc.ddd-aaa.bbb.ccc.eee,aaa.bbb.fff.ggg,aaa.bbb.fff.hhh I think for the hostgroups we can give the comma seperated list of above types. Can any body explain why can't we have same thing for the SPD too. Thank you very much in advance Sashidhar Annaluru (908)-580-8014 avs@winner.lc.lucent.com From owner-ipsec Mon Jun 29 18:06:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25465 for ipsec-outgoing; Mon, 29 Jun 1998 18:05:41 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <359806B8.9241F055@winner.lc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Jun 1998 18:12:48 -0400 To: avs@winner.lc.lucent.com From: Stephen Kent Subject: Re: A question about SPD selectors Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Some time ago we agreed to simplify the selector types and removed some options, to make the SPD selectors align with the IKE payload ID types. That's why we limit the address choices, in part. In IPSecond it may be possible to remove some of these restrictions, if corresponding changes to IKE are made. Steve From owner-ipsec Tue Jun 30 13:58:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01319 for ipsec-outgoing; Tue, 30 Jun 1998 13:51:16 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Vipul Gupta , ipsec@tis.com, ddp@network-alchemy.com Subject: RE: More questions on ID types Date: Tue, 30 Jun 1998 11:07:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Vipul, > According to the latest ISAKMP draft, the only ID types allowed in > phase I are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_IPV4_ADDR_SUBNET, > ID_IPV6_ADDR_SUBNET. With the reasoning above, I can see how the > first two make sense as IDs for phase I. However, the latter two > ID types seem more appropriate for use in phase II. > > I have some concerns about limiting phase I IDs to these > four types. I agree and see no reason why the ID values should be restricted to the 4 types listed in the ISAKMP appendix. I think there is another problem however. For the mandatory case of Authentication with Pre-Shared Key & Main Mode, it seems to me that the ID payload is in the "wrong" message. The pre-shared key needs to be accessed before the message with the ID payload can be decrypted. The spec says that the key can only be identified using the (source) IP address of the incoming ISAKMP message. This doesn't work if the remote party only has a temporarily assigned IP address. Also if a host or gateway is multihomed, the source IP address may change, depending on which outgoing interface was used to reach the destination. The ISAKMP spec could specify that a single IP address be used as the source IP address of an ISAKMP UDP message, no matter what outgoing interface was used, in order to reduce the configuration burden, but it would be better to remove the need to look at source IP address at all (which is the same as IPSEC where source IP address is not used to identify SAs) Thus perhaps it would be better for the Pre-Shared key case to include the ID payload in the 3rd and 4th messages of the exchange (the ones that transfer the D-H public info and the nonces), rather than in the 5th and 6th. This removes the need to look at source IP address at all, and would be similar to the Authentication with Encryption exchange. Bryan Gleeson Shasta Networks. From owner-ipsec Tue Jun 30 14:15:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01414 for ipsec-outgoing; Tue, 30 Jun 1998 14:15:18 -0400 (EDT) Message-Id: <199806301830.LAA26441@gallium.network-alchemy.com> To: Bryan Gleeson cc: Vipul Gupta , ipsec@tis.com Subject: Re: More questions on ID types In-reply-to: Your message of "Tue, 30 Jun 1998 11:07:07 PDT." Date: Tue, 30 Jun 1998 11:30:25 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I'm sorry, I was confused when I said that the ID types in the latest ISAKMP draft were the only legal ones in Phase 1. That's true only when you don't specify the IPSEC DOI in the Phase 1 negotiation. Derrell From owner-ipsec Tue Jun 30 15:38:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01815 for ipsec-outgoing; Tue, 30 Jun 1998 15:37:14 -0400 (EDT) Date: Tue, 30 Jun 1998 12:46:43 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: ID payload in wrong msg? (was RE: More questions on ID types) To: BGleeson@shastanets.com Cc: vgupta@nobel.Eng.Sun.COM, ddp@network-alchemy.com, ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Tpp3sxvjL0A2EjboA41Spw== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk [Bryan Gleeson wrote] > > I agree and see no reason why the ID values should be > restricted to the 4 types listed in the ISAKMP appendix. Derrell's latest posting clarifies the confusion on this issue -- Phase I may use IDs other than those mentioned in the ISAKMP draft if IPSEC DOI is used. > I think there is another problem however. For the mandatory > case of Authentication with Pre-Shared Key & Main Mode, it > seems to me that the ID payload is in the "wrong" message. > The pre-shared key needs to be accessed before the message > with the ID payload can be decrypted. The spec says that the [Other stuff deleted] Is this really true? I was under the impression that the key used for decryption is derived purely from the shared secret (as in g^xy mod p) established by the key exchange in messages 3 and 4 of main mode (i.e. the second messages of the initiator and responder, respectively). This is independent of the "shared secret" (say S) used for authentication. If my interpretation is correct, then carrying the ID payload in messages 5 and 6 is ok and msg 5 is processed by the responder as follows: - responder decrypts the ID and HASH using the shared secret (g^xy mod p) obtained from the key exchange in prior messages - responder uses the ID data to lookup shared secret S associated with the initiator's identity (the ID type could be of type ID_USER_FQDN or opaque of type ID_KEY_ID i.e. key lookup need not be based on the initiator's IP address) - responder uses S to verify the HASH regards, vipul p.s. This still leaves the possibility that identities are divulged to a man-in-the-middle. However, this attacker would not be able to pass the authentication checks made when main mode msgs 5 and 6 are processed. From owner-ipsec Tue Jun 30 16:05:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01880 for ipsec-outgoing; Tue, 30 Jun 1998 16:04:16 -0400 (EDT) Message-ID: <35994854.F30B759A@cs.umass.edu> Date: Tue, 30 Jun 1998 16:19:32 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IPsec CC: Bryan Gleeson Subject: Re: More questions on ID types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson writes: > I think there is another problem however. For the mandatory > case of Authentication with Pre-Shared Key & Main Mode, it > seems to me that the ID payload is in the "wrong" message. > The pre-shared key needs to be accessed before the message > with the ID payload can be decrypted. The spec says that the > key can only be identified using the (source) IP address of > the incoming ISAKMP message. [...explanation elided...] > Thus perhaps it would be better for the Pre-Shared key case > to include the ID payload in the 3rd and 4th messages > of the exchange (the ones that transfer the D-H public info > and the nonces), rather than in the 5th and 6th. This removes > the need to look at source IP address at all, and would be > similar to the Authentication with Encryption exchange. Unfortunately Pre-Shared-Key-Auth Main Mode would no longer be an Identity Protect exchange if this change were made. Protecting the identities of the parties is a notable feature of Main Mode -- in contrast to Aggressive Mode -- for the pre-shared key case. So I don't think Main Mode should be altered to send ID payloads in the clear. I suppose there is some argument to be made for a compromise mode in the pre-shared key case that would be more "aggressive" than Main Mode, but more "reserved" than Aggressive Mode. For example (illustrative purposes only): Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA, KE, Nr HDR, KE, Ni, IDii, HASH_I --> <-- HDR, IDir, HASH_R This doesn't offer identity protection. But it allows negotiation of the DH group (unlike Aggressive Mode) and saves a full round-trip versus Main Mode. (Other variations are possible. I haven't really considered which ones might be better.) -Lewis http://www.cs.umass.edu/~lmccarth From owner-ipsec Tue Jun 30 16:33:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02022 for ipsec-outgoing; Tue, 30 Jun 1998 16:33:15 -0400 (EDT) Message-Id: <199806302047.NAA22141@greatdane.cisco.com> To: Lewis McCarthy cc: IPsec , Bryan Gleeson Subject: Re: More questions on ID types In-reply-to: Your message of "Tue, 30 Jun 1998 16:19:32 EDT." <35994854.F30B759A@cs.umass.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Jun 1998 13:47:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On: Tue, 30 Jun 1998 16:19:32 EDT you wrote > Bryan Gleeson writes: [snip] > > Thus perhaps it would be better for the Pre-Shared key case > > to include the ID payload in the 3rd and 4th messages > > of the exchange (the ones that transfer the D-H public info > > and the nonces), rather than in the 5th and 6th. This removes > > the need to look at source IP address at all, and would be > > similar to the Authentication with Encryption exchange. > > Unfortunately Pre-Shared-Key-Auth Main Mode would no longer be > an Identity Protect exchange if this change were made. > Protecting the identities of the parties is a notable feature > of Main Mode -- in contrast to Aggressive Mode -- for the > pre-shared key case. So I don't think Main Mode should be > altered to send ID payloads in the clear. > > I suppose there is some argument to be made for a compromise > mode in the pre-shared key case that would be more "aggressive" > than Main Mode, but more "reserved" than Aggressive Mode. > For example (illustrative purposes only): > > Initiator Responder > ---------- ----------- > HDR, SA --> > <-- HDR, SA, KE, Nr > HDR, KE, Ni, IDii, HASH_I --> > <-- HDR, IDir, HASH_R > > This doesn't offer identity protection. But it allows > negotiation of the DH group (unlike Aggressive Mode) and > saves a full round-trip versus Main Mode. > (Other variations are possible. I haven't really considered > which ones might be better.) It also might open the responder to a denial-of-service attack since he does an exponentiation before he's got any belief the he's talking to a genuine, honest-to-goodness IKE peer and not a program that forges thousands of "HDR, SA" messages per second from bogus source addresses. Main Mode is not immune from such attacks but before the responder does any real work he's got a strong belief that he's talking to a real entity. One of the nice things about Oakley (and also one of the things that made it so hard to implement) is that it didn't have this problem. Each side could send what it wanted when it wanted. The initiator could send an SA, KE, nonce and the responder could only send a cookie, or a cookie and an SA and a KE, or a cookie and an SA, or.... A "reserved mode" (I like that) can be written up in a draft but Main Mode is not changing at this point in time. Sorry Bryan but this point was discussed about a year ago and the resolution is what you see today. If you want to allow remote access with pre-shared keys use Aggressive Mode. If you don't want to expose a meaningful identity use ID_KEY_ID as the identity to which the pre-shared key is bound. Dan. From owner-ipsec Tue Jun 30 19:59:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03590 for ipsec-outgoing; Tue, 30 Jun 1998 19:55:28 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Vipul Gupta , BGleeson@shastanets.com Cc: ddp@network-alchemy.com, ipsec@tis.com Subject: RE: ID payload in wrong msg? (was RE: More questions on ID types) Date: Tue, 30 Jun 1998 17:10:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Vipul, > > I think there is another problem however. For the mandatory > > case of Authentication with Pre-Shared Key & Main Mode, it > > seems to me that the ID payload is in the "wrong" message. > > The pre-shared key needs to be accessed before the message > > with the ID payload can be decrypted. The spec says that the > > [Other stuff deleted] > > Is this really true? I was under the impression that the > key used for decryption is derived purely from the shared > secret (as in g^xy mod p) established by the key exchange > in messages 3 and 4 of main mode (i.e. the second messages > of the initiator and responder, respectively). This is > independent of the "shared secret" (say S) used for > authentication. For authentication with pre-shared keys, the SKEYID value seems to be a function of the pre-shared key and the nonces, and this is then used to calculate the SKEYID_e value, which is used for encryption and decryption. If it is too late to twiddle with Main Mode in the shared-key case, then perhaps Agressive mode needs to be made mandatory for hosts that don't have a fixed IP address. Bryan From owner-ipsec Tue Jun 30 22:40:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04172 for ipsec-outgoing; Tue, 30 Jun 1998 22:39:46 -0400 (EDT) Message-Id: <199807010251.WAA11301@relay.hq.tis.com> Date: Tue, 30 Jun 98 22:47:41 EDT From: Charles Lynn To: ipsec@tis.com cc: Dan McDonald , "Angelos D. Keromytis" , CLynn@bbn.com Subject: Re: Byte-count lifetime enforcement? Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I mentioned to Steve Kent that using as the byte count the "IP payload, prior to adding the ESP header and trailer" seems to imply one particular implementation, and that folks might not be implementing things that way. The manner that input processing is implemented might also make it unlikely that the suggested number would be readily available. I suspect that a number that would be available in implementations is the number of bytes fed to the algorithm. (If both ends do not agree on that number, the packet had better be discarded. :-) Steve agreed with the reasoning, but pointed out, as has Dan, that the text does not specify which algorithm should be used for ESP. Dan suggests the primary algorithm: encryption for ESP, and authentication for AH. How do folks feel about adding Dan's clarification to the Architecture document? (Note that since it is a "SHOULD", there is no reason to delay any products; those using some other count may change their code when convenient. As Angelos pointed out, things should be designed to work no matter which end is the first to exhaust its count.) Charlie From owner-ipsec Tue Jun 30 22:45:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA04187 for ipsec-outgoing; Tue, 30 Jun 1998 22:45:46 -0400 (EDT) Message-Id: <199807010259.WAA05128@adk.gr> To: Charles Lynn Cc: ipsec@tis.com, Dan McDonald Subject: Re: Byte-count lifetime enforcement? In-reply-to: Your message of "Tue, 30 Jun 1998 22:47:41 EDT." <199807010255.WAA04197@codex.cis.upenn.edu> Date: Tue, 30 Jun 1998 22:59:54 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: Charles Lynn Subject: Re: Byte-count lifetime enforcement? Cc: ipsec@tis.com, Dan McDonald Date: 06/30/98, 22:59:53 In message <199807010255.WAA04197@codex.cis.upenn.edu>, Charles Lynn writes: > >How do folks feel about adding Dan's clarification to the Architecture >document? If it goes in (I don't object), then you should probably add another sentence to the effect that implementations should expect those counters to get out of sync, either because of network failures or because other implementations aren't doing things quite the same way. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNZmmKb0pBjh2h1kFAQE/HwP8DcVcL3zAaJzf9dW/xNksnmgWyuRuEvNG bdwR/XEhT32tTKnDh0kqCeZgWCYsBnYB/yYrFaYsW7j58bqdWAehgYHHWWCvqnj+ dxASe2njLJSE6swWq/DPuv6PJCj/ocCN6OUPPriuqvKLZcxaS5AKAkt3xZMUXKbv r2cTdAlsosk= =qf8K -----END PGP SIGNATURE-----