From ipsec-request@ans.net Thu Dec 1 03:42:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26910 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 10:59:37 -0500 Received: by interlock.ans.net id AA06087 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 10:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 10:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 10:50:44 -0500 Date: Thu, 1 Dec 94 03:42:35 GMT From: "William Allen Simpson" Message-Id: <3539.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: new draft should not be written > From: Paul_Lambert-P15452@email.mot.com > There will be a draft late this week. A new editing team is scrambling to pull > it complete it. > Paul, and whoever the new team is, please don't bother to write a draft days before the meeting. We are past the deadline for submission. It will not get distributed. It will not be read. Instead, please come to the meeting with a list of unresolved issues. Let's tackle them, and THEN we should assign someone to write it up. > The draft contains a 32 bit SAID field. The top order bits will be reserved (5 > or 6 high order bits set to zero) to allow for possible Version Number, PDU > Type, and multicast bit. > That is an issue we could raise. But I will note that is not what we are doing for IPv6, so it may very well be a waste of time. Let's keep SAIDs as SAIDs, and have other fields if we can articulate a clear need for them. As for versions, we haven't gotten version 1 done in 10 years. I don't think we need to worry about version 2. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Dec 1 04:10:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20555 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 12:45:19 -0500 Received: by interlock.ans.net id AA25482 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 12:36:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 12:36:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 12:36:30 -0500 Date: Thu, 1 Dec 94 04:10:30 GMT From: "William Allen Simpson" Message-Id: <3540.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC at Dec IETF > Presentations are currently scheduled to discuss the proposals for IPSP (a new > I-D will be out next week). I propose we abandon IPSP. I propose we accept Ran Atkinson's IPv6 Authentication Header draft for IPv4 without any changes. I propose we accept Ran Atkinson's IPv6 Encapsulating Security Header draft for IPv4 with a small change, which is to move the next header, length and padding information to the trailer. This is similar to what Karn has been demonstrating for a year now, and nobody else has come out with anything better! > Several presentations and demonstrations of > experimental implementations of IKMP are scheduled. The focus of the IKMP > discussions will be on comparing the proposals and creating a consensus > approach. > Hopefully, Karn is one of the presentations. I saw his work at Qualcomm yesterday, and was impressed. He's got it to be quite fast, even compared to last meeting, folks! Any other presentation had better have running code, or we certainly shouldn't consider it. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Dec 1 18:38:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04304 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 13:51:56 -0500 Received: by interlock.ans.net id AA18562 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 13:39:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 13:39:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 13:39:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 13:39:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 13:39:00 -0500 Message-Id: <9412011838.AA03422@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: IPSEC at Dec IETF In-Reply-To: Your message of "Thu, 01 Dec 1994 04:10:30 GMT." <3540.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 01 Dec 1994 13:38:43 -0500 From: "Perry E. Metzger" "William Allen Simpson" says: > > Presentations are currently scheduled to discuss the proposals for IPSP (a new > > I-D will be out next week). > > I propose we abandon IPSP. > > I propose we accept Ran Atkinson's IPv6 Authentication Header draft for > IPv4 without any changes. I second the proposal with one modification -- there should be a short document explaining the differences in usage. Also, Ran's document needs to be cleaned up a bit. Ran's auth header was essentially what was agreed to during our deliberations. > I propose we accept Ran Atkinson's IPv6 Encapsulating Security Header > draft for IPv4 with a small change, which is to move the next header, > length and padding information to the trailer. This is similar to what > Karn has been demonstrating for a year now, and nobody else has come out > with anything better! Personally, I radically prefer what we came up with at the last IETF, which was simply [32bits of SAID] [STUFF] such that the entire package was 64 bit aligned, since after all everything on earth in the IPng world is 64 bit aligned. It seems to me that ESP as written gratuitously wastes lots of space to 64 bit align essentially 8 bits of data inside the packet. By leaving such internals up to the security transform, we allow high speed hardware to use new defined transforms that align things and we allow people operating IPv4 with software encryption over slip links to still get performance, and everyone becomes happy. However, if Ran can't be convinced that this is a Bad Thing I'd rather be compatible than noncompatible. > Any other presentation had better have running code, or we certainly > shouldn't consider it. There may be a swIPe/Ran's proposal hybrid running on v4, that is to say, swIPe hacked to do the v6 auth/encrypt headers instead of swIPe headers. No promises, though. Perry From ipsec-request@ans.net Thu Dec 1 20:04:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA36849 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 15:21:23 -0500 Received: by interlock.ans.net id AA06078 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 15:15:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 15:15:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 15:15:13 -0500 Date: Thu, 1 Dec 94 20:04:39 GMT From: "William Allen Simpson" Message-Id: <3553.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC at Dec IETF Sounds good to me! Thanks, Perry. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Dec 1 20:16:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05623 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 15:21:36 -0500 Received: by interlock.ans.net id AA13045 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 15:17:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 1 Dec 1994 15:17:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 15:17:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 15:17:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 15:17:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 15:17:13 -0500 Message-Id: <9412012017.AA16796@gimili.watson.ibm.com> To: ipsec@ans.net Subject: Internet Draft for Modular Key Management X-Mailer: exmh version 1.2 1/14/94 Date: Thu, 01 Dec 1994 15:16:55 -0500 From: " " A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Modular Key Management Protocol (MKMP) Author(s) : P. Cheng, J. Garay, A. Herzberg, H. Krawczyk Filename : draft-cheng-modular-ikmp-00.txt, .ps Pages : 22 Date : 11/28/1994 This memo describes mechanisms and introduces a protocol for the management of cryptographic keys as required for the management of security associations in IPSP and IPv6. Our key management scheme adheres to a modular approach, namely, the scheme is separated into two modules: An upper module in which a long-lived (``master'') key is exchanged between the communicating parties, and a lower module, in which the already shared (master) key is used for the derivation, sharing and/or refreshment of additional short-lived keys to be used for the cryptographic transformations applied to the data. In this draft, we concentrate on the management module for short-lived keys, and indicate how proposed variants of public key-based master key exchange protocols can be accommodated in the upper module. 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-cheng-modular-ikmp-00.txt". Or "get draft-cheng-modular-ikmp-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-cheng-modular-ikmp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-cheng-modular-ikmp-00.txt". Or "FILE /internet-drafts/draft-cheng-modular-ikmp-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941128144549.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-cheng-modular-ikmp-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-cheng-modular-ikmp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941128144549.I-D@CNRI.Reston.VA.US> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From ipsec-request@ans.net Thu Dec 1 21:51:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38467 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 18:04:43 -0500 Received: by interlock.ans.net id AA07933 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 17:56:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 1 Dec 1994 17:56:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 17:56:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 17:56:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 17:56:21 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 17:56:21 -0500 Date: 1 Dec 94 15:51:00 -0600 To: perry@imsi.com, bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re[2]: IPSEC at Dec IETF Message-Id: Bill and Perry, We will place your recommendation on the agenda. >> I propose we accept Ran Atkinson's IPv6 Encapsulating Security Header >> draft for IPv4 with a small change, which is to move the next header, >> length and padding information to the trailer. This is similar to what >> Karn has been demonstrating for a year now, and nobody else has come out >> with anything better! > >Personally, I radically prefer what we came up with at the last IETF, >which was simply > >[32bits of SAID] >[STUFF] I have a one comment on this ... if you change the header format it is no longer IPv6 pure. What you are proposing is still another protocol that we will call IPSP, but it will look much like Ran's proposal. This is fine, currently all of the proposals that have been put out look similar. The format issues always seem to be discussed out of proportion with the complete processing description. At the last meeting, we were moving towards replacing the IPv6 encapsulation with IPSP. The IPv6 authentication protocol was still required because of the header parsing requirements. This compromise was to be documented by Perry, but we seem to now be in a position of Perry proposing to use Ran's draft. Currently the rough draft has been picked up by a last minute editing team to publish. We will present this material at the meeting. It looks the group has reached a branch point in the IPSP. We need to decide if IPv6 purity is more important than efficiency. I would be very interested in learning the opinions of other implementators. We have at least a dozen lurking around. From ipsec-request@ans.net Thu Dec 1 23:01:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05596 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 18:06:30 -0500 Received: by interlock.ans.net id AA11837 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 18:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 1 Dec 1994 18:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 18:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 18:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 18:01:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 18:01:25 -0500 Message-Id: <9412012301.AA16862@gimili.watson.ibm.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz), ipsec@ans.net Subject: Re: Modular approach to key management In-Reply-To: Your message of "Tue, 29 Nov 1994 17:25:05 PST." <9411300125.AA22055@miraj.Eng.Sun.COM> X-Mailer: exmh version 1.2 1/14/94 Date: Thu, 01 Dec 1994 18:01:11 -0500 From: " " Dear IPSECers, I believe that the very reasonable arguments below by Aziz, and the very reasonable counter-arguments, make one thing clear: we should go with a modular approach that provides a common protocol for key refreshment, where the key could be obtained by a variety of mechanisms (and later we'll standardize some specific choices). The main gains are interoperability, efficiency, but over all: time to market. I suggest that the group decides to do such a modular design. In particular I suggest that to take the Modular Key Management proposal (now available as Internet-draft) and work on it together to offer the Internet QUICKLY a really useful tool for interoperable IP-layer security solutions. Please voice your opinions on the list, and let's also discuss this in the IETF. Best, Amir Herzberg > > >From ipsec-request@ans.net Mon Nov 21 15:33:39 1994 > >My suggestion is that we adopt the IEEE work, then select particular algorithms > >for use in the Internet. Of course, the IPSEC WG would also have to define the > >attributes that are part of security association negotiation. These attributes > >have to be defined regardless of the approach taken, so this is neither a plus > >nor a minus to the IEEE 802.10c approach. > > I am afraid that I, for one, am not amenable to adopting IEEE 802.10c > as something suitable for use with IPSP, for a number of reasons which I'll > describe below. > > (This is based on the IEEE 802.10c draft that was available sometime > before the last IETF meeting so if things have substantially changed > since then, I am not aware of that.) > > o IEEE 802.10c is quite a complex document. In my view, unnecessarily so. > If this groups decides to adopt it, it needs to be much clearer and > easier to understand than it currently is. > > o IEEE 802.10c utilizes OSI upper layer services and concepts like > Application Entity Titles etc. I dont think that the Internet community > needs to buy into (and implement) the OSI upper layer services, with > its associated complexities, just for the sake of IP layer key-management. > Especially since much simpler alternatives already exist. > > o IEEE 802.10c multicast design uses a single key obtained from a > Multicast KDC. Changing this key requires obtaining a new key from > the Multicast KDC. This may work for small multicast groups as may > arise on a single 802.x subnet (which is what 802.10 is intended for) > but this will not scale to the number of nodes possible in an > Internet wide multicast group. > > o Using the same key for all members of a multicast group eliminates > using some of the highest performance stream ciphers commercially available > for traffic encryption purposes. This is a major disadvantage for > high-performance multicast applications like encrypted video. > > o The fact that IEEE 802.10 was designed for subnets (and not internets, > for which scalability to a large number of nodes is criticial) shows in places > like how to determine which application entity to use in order to > negotiate session keys. In one of the appendices, it states that each > node will have a local table of mappings between 802.x MAC addresses and > AE-Titles. This might work for a single subnet. This will clearly not work > for the Internet, where it is not feasible to have a local table of > mappings between IP addresses and AE-Titles for the entire Internet. > > >In my opinion, IEEE 802.10c decreases the time to market. Protocol development > >can take alot of time, especially in an open environment like the IEEE and > >the IETF. Therefore, take advantage of the investement that has already > >been made by the IEEE 802.10 participants, and take a working solution to > >the Internet sooner. > > I think that IEEE 802.10c is the wrong solution for the Internet. > It will substantially increase time to market because of the complexities > inherent a complete OSI upper layer implementation (truly unnecessary for > the task at hand). It also does not adequately address the needs of the > Internet, because of various subnet oriented design decisions. > > Regards, > Ashar. > From ipsec-request@ans.net Thu Dec 1 23:16:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15502 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 18:22:26 -0500 Received: by interlock.ans.net id AA16170 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 18:16:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 18:16:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 18:16:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 18:16:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 18:16:49 -0500 Message-Id: <9412012316.AA03983@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Re[2]: IPSEC at Dec IETF In-Reply-To: Your message of "01 Dec 1994 15:51:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 01 Dec 1994 18:16:31 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > I have a one comment on this ... if you change the header format it is no > longer IPv6 pure. That is not really true. The AP header is identical to what we already agreed on and the ESP is identical other than the contents of the opaque portion of the packet. The opaque portion is, well, opaque, and I'm merely suggesting that it be made even more opaque by making it security transform dependant. Under that circumstance, Ran's drafts and what we were proposing as IPSP become completely identical -- so there is very little point in having two specs. > At the last meeting, we were moving towards replacing the IPv6 encapsulation > with IPSP. It would be better to say that after a couple of days we re-derived the v6 encapsulation and decided to try to have one encapsulation and call it IPSP, but it was basically just Ran's encapsulation. > It looks the group has reached a branch point in the IPSP. We need > to decide if IPv6 purity is more important than efficiency. I am not certain that this is an issue. The only way this comes up is in the question of how many bytes are used inside the opaque portion of the opaque encapsulation to define "next header" or the equivalent. If Ran is willing to let this be transform dependant the specs suddenly become absolutely identical and ther is no longer a reason to declare them to be two different protocols. Perry From ipsec-request@ans.net Thu Dec 1 18:37:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25477 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 18:37:23 -0500 Received: by interlock.ans.net id AA13282 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 18:32:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 18:32:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 18:32:41 -0500 Message-Id: Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 18:32:41 -0500 To: ipsec@ans.net From: iris!CN=Charlie_Kaufman/O=Iris@uunet.uu.net (CN=Charlie Kaufman/O=Iris@IRIS) Subject: Re: SKIP & Patent #5,081,678 Date: Thu Dec 01 16:52:01 1994 >From: uunet!eng.sun.com!Ashar.Aziz (Ashar Aziz) > >Sara, Amir and other interested parties, > >Since this issue has been raised a few times by members of this >WG, I have reviewed the claims of patent #5,081,678 (assigned >to DEC) to see if an implementation of the SKIP specification >would infringe on this patent. > >It is clear that what is described in the SKIP specification is >*not* covered by patent #5,081,678. > >I will review the essential claims of this patent to explain why. > ... With the caveats that I don't work for DEC anymore and didn't speak for them when I did, I concur with this analysis. There is ample "prior art" concerning including a short term key encrypted under a longer term key in the header of a message. Kerberos is an example - look at tickets and authenticators. --Charlie (kaufman@iris.com) From ipsec-request@ans.net Thu Dec 1 23:45:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA36724 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 19:54:52 -0500 Received: by interlock.ans.net id AA06826 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 19:49:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 1 Dec 1994 19:49:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 1 Dec 1994 19:49:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 1 Dec 1994 19:49:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 19:49:31 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 19:49:31 -0500 Date: 1 Dec 94 17:45:00 -0600 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: IPSEC at Dec IETF Message-Id: Perry, This all sounds good. Mainly because I though this is close to where we left off at the last meeting. The bundling provided by the transforms allows a simple representation of multiple algorithms and format considerations. IPv6 forces the transformations to be 64 bit aligned. This would means that one network layer security protocol can protect both IPv4 and IPv6. Different transformations would be supported for different security services, export considerations, and IPv6 alignment. The IPv6 aligned transformations are only necessary between in IPv6-to-IPv6 security encapsulations. IPv6 also has identified a requirement for a transparent authentication only encapsulation mode. This requirement was not met by IPSP and was our basis for consolidating the IPv4 versus IPv6 issues from the last meeting. IPv6 does need it's own authentication protocol to meet this requirement. I am reiterating these points because we seem to be saying the same thing now but your draft specification did not seem to reflect these ideas. Are we on the same wavelength now? Paul _______________________________________________________________________________ Subject: Re: Re[2]: IPSEC at Dec IETF Author: perry@imsi.com@INTERNET Date: 12/1/94 5:16 PM X-Reposting-Policy: redistribute only with permission Paul_Lambert-P15452@email.mot.com says: > I have a one comment on this ... if you change the header format it is no > longer IPv6 pure. That is not really true. The AP header is identical to what we already agreed on and the ESP is identical other than the contents of the opaque portion of the packet. The opaque portion is, well, opaque, and I'm merely suggesting that it be made even more opaque by making it security transform dependant. Under that circumstance, Ran's drafts and what we were proposing as IPSP become completely identical -- so there is very little point in having two specs. > At the last meeting, we were moving towards replacing the IPv6 encapsulation > with IPSP. It would be better to say that after a couple of days we re-derived the v6 encapsulation and decided to try to have one encapsulation and call it IPSP, but it was basically just Ran's encapsulation. > It looks the group has reached a branch point in the IPSP. We need > to decide if IPv6 purity is more important than efficiency. I am not certain that this is an issue. The only way this comes up is in the question of how many bytes are used inside the opaque portion of the opaque encapsulation to define "next header" or the equivalent. If Ran is willing to let this be transform dependant the specs suddenly become absolutely identical and ther is no longer a reason to declare them to be two different protocols. Perry From ipsec-request@ans.net Fri Dec 2 02:38:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23884 (5.65c/IDA-1.4.4 for ); Thu, 1 Dec 1994 22:19:13 -0500 Received: by interlock.ans.net id AA21287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 1 Dec 1994 22:11:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Dec 1994 22:11:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Dec 1994 22:11:55 -0500 Date: Fri, 2 Dec 94 02:38:01 GMT From: "William Allen Simpson" Message-Id: <3555.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: IPSEC at Dec IETF > From: "Perry E. Metzger" > Paul_Lambert-P15452@email.mot.com says: > > I have a one comment on this ... if you change the header format it is no > > longer IPv6 pure. > > That is not really true. The AP header is identical to what we already > agreed on and the ESP is identical other than the contents of the > opaque portion of the packet. The opaque portion is, well, opaque, and > I'm merely suggesting that it be made even more opaque by making it > security transform dependant. Under that circumstance, Ran's drafts > and what we were proposing as IPSP become completely identical -- so > there is very little point in having two specs. > Good. This is what I understood you to mean. Now, all we need to do is get the WG to take a hard look at these to see if there are any theoretical or practical issues not addressed in Ran's drafts. > > At the last meeting, we were moving towards replacing the IPv6 encapsulation > > with IPSP. > > It would be better to say that after a couple of days we re-derived > the v6 encapsulation and decided to try to have one encapsulation and > call it IPSP, but it was basically just Ran's encapsulation. > Yes, that's what I thought. But Perry said at the time that there were a few changes to be made for IPv4. The placement of the ISV and next header INSIDE the opaque portion were the issues I remember. > The only way this comes up is > in the question of how many bytes are used inside the opaque portion > of the opaque encapsulation to define "next header" or the > equivalent. If Ran is willing to let this be transform dependant the > specs suddenly become absolutely identical and ther is no longer a > reason to declare them to be two different protocols. > I spoke to Ran. I think he is willing. He has left for SJ already, though. We'll see next week if we have reached consensus. Everybody, please read draft-atkinson-ipng-esp-00.txt and -ah-00.txt. Bring a copy with you to mark up! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Dec 2 14:25:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14137 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 09:25:51 -0500 Received: by interlock.ans.net id AA20384 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 09:22:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 09:22:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 09:22:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 09:22:32 -0500 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9412020825.ZM3604@hughes.network.com> Date: Fri, 2 Dec 1994 08:25:03 -0600 In-Reply-To: Paul_Lambert-P15452@email.mot.com "Re[2]: IPSEC at Dec IETF" (Dec 1, 3:51pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Paul_Lambert-P15452@email.mot.com, perry@imsi.com, bsimpson@morningstar.com Subject: Re: Re[2]: IPSEC at Dec IETF Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Dec 1, 3:51pm, Paul_Lambert-P15452@email.mot.com wrote: > Subject: Re[2]: IPSEC at Dec IETF > It looks the group has reached a branch point in the IPSP. We need to decide if > IPv6 purity is more important than efficiency. > > I would be very interested in learning the opinions of other implementors. > We have at least a dozen lurking around. My opinion is that this working group has 2 responsibilities. That is, to implement something soon, and that must be IPv4 based. The next step is to implement an IPv6 version. Now, these 2 versions may be very similar, but they are not necessary to be 100% the same. There may be advantages to making them very different so that neither have to implement features that are unnecessary. In any case, the IPv4 version is time critical because, as we have all been told, the internet is dire need of security -now-. jim From ipsec-request@ans.net Fri Dec 2 14:21:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17722 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 09:25:51 -0500 Received: by interlock.ans.net id AA26514 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 09:21:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Dec 1994 09:21:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 09:21:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 09:21:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 09:21:47 -0500 Message-Id: <9412021421.AA04552@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: perry@imsi.com, ipsec@ans.net Subject: Re: Re[4]: IPSEC at Dec IETF In-Reply-To: Your message of "01 Dec 1994 17:45:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 02 Dec 1994 09:21:27 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > This all sounds good. Mainly because I though this is close to where we left > off at the last meeting. Indeed. > I am reiterating these points because we seem to be saying the same > thing now but your draft specification did not seem to reflect these > ideas. Are we on the same wavelength now? My draft (unreleased) actually was just an attempt to rephrase and clarify Ran's drafts, to specify how they should operate with IPv4, and to correct the problem with the ESP format. That was all of what I attempted. I think we have already come to consensus on our bit format and are simply having trouble coming to consensus on which text will be used to define it. :-) .pm From ipsec-request@ans.net Fri Dec 2 16:03:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38532 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 11:12:03 -0500 Received: by interlock.ans.net id AA14628 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 11:04:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Dec 1994 11:04:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 11:04:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 11:04:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 11:04:22 -0500 Message-Id: <9412021603.AA04676@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Re[2]: IPSEC at Dec IETF In-Reply-To: Your message of "Fri, 02 Dec 1994 08:25:03 CST." <9412020825.ZM3604@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 02 Dec 1994 11:03:53 -0500 From: "Perry E. Metzger" James P. Hughes says: > My opinion is that this working group has 2 responsibilities. That is, > to implement something soon, and that must be IPv4 based. The next step > is to implement an IPv6 version. Now, these 2 versions may be very > similar, but they are not necessary to be 100% the same. "The Group" isn't going to implement anything. "The Group" exists to discuss the protocol itself. In the IETF process, implementations are produced to allow the working groups to decide if they like a particular protocol. People working on actual code are, of course, out there. Implementations are already in the works on both the IPv4 and IPv6 sides. I can speak personally only of one v4 implementation based on the swIPe code that should be available Real Soon Now. > In any case, the IPv4 version is time critical because, as we have all > been told, the internet is dire need of security -now-. The bit patterns were all decided on and agreed upon at the last meeting. At this point we really are on the stage of discussing key management and the arguments are mostly about what document to use and other final polishing up. A few bits may move around but not many. I must take responsibility for the fact that we aren't already done with the document; my unreasonable delays in finishing my rough draft produced the current uncertainty. However, I think that at this point everyone agrees that what we are going to be left with is virtually indistinguishable from Ran's drafts and whats left are some minor points of contention and what document to use for the standards document qua standards document. Perry From ipsec-request@ans.net Fri Dec 2 17:03:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15490 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 13:11:16 -0500 Received: by interlock.ans.net id AA21127 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 13:07:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 2 Dec 1994 13:07:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Dec 1994 13:07:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 13:07:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 13:07:11 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 13:07:11 -0500 Date: 2 Dec 94 11:03:00 -0600 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: IPSEC at Dec IETF Message-Id: >However, I think that at this point >everyone agrees that what we are going to be left with is virtually >indistinguishable from Ran's drafts .... I do not fully agree. It is true that the basic format was fairly well determined at the last meeting short of a few bytes here or there. Beyond the format there are issue areas that need to be expanded in a document. Error handling, management information, decryptor discovery, and multicast SAID usage are areas that now need description. Hopefully putting the format issues to rest will allow the group to move forward on these other areas. Paul _______________________________________________________________________________ Subject: Re: Re[2]: IPSEC at Dec IETF Author: perry@imsi.com@INTERNET Date: 12/2/94 10:03 AM X-Reposting-Policy: redistribute only with permission James P. Hughes says: > My opinion is that this working group has 2 responsibilities. That is, > to implement something soon, and that must be IPv4 based. The next step > is to implement an IPv6 version. Now, these 2 versions may be very > similar, but they are not necessary to be 100% the same. "The Group" isn't going to implement anything. "The Group" exists to discuss the protocol itself. In the IETF process, implementations are produced to allow the working groups to decide if they like a particular protocol. People working on actual code are, of course, out there. Implementations are already in the works on both the IPv4 and IPv6 sides. I can speak personally only of one v4 implementation based on the swIPe code that should be available Real Soon Now. > In any case, the IPv4 version is time critical because, as we have all > been told, the internet is dire need of security -now-. The bit patterns were all decided on and agreed upon at the last meeting. At this point we really are on the stage of discussing key management and the arguments are mostly about what document to use and other final polishing up. A few bits may move around but not many. I must take responsibility for the fact that we aren't already done with the document; my unreasonable delays in finishing my rough draft produced the current uncertainty. However, I think that at this point everyone agrees that what we are going to be left with is virtually indistinguishable from Ran's drafts and whats left are some minor points of contention and what document to use for the standards document qua standards document. Perry From ipsec-request@ans.net Fri Dec 2 18:15:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15545 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 13:17:18 -0500 Received: by interlock.ans.net id AA12797 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 13:15:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Dec 1994 13:15:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 13:15:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 13:15:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 13:15:32 -0500 Message-Id: <9412021815.AA04845@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[4]: IPSEC at Dec IETF In-Reply-To: Your message of "02 Dec 1994 11:03:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 02 Dec 1994 13:15:00 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > >However, I think that at this point > >everyone agrees that what we are going to be left with is virtually > >indistinguishable from Ran's drafts .... > > I do not fully agree. It is true that the basic format was fairly > well determined at the last meeting short of a few bytes here or > there. Beyond the format there are issue areas that need to be > expanded in a document. Error handling, management information, > decryptor discovery, and multicast SAID usage are areas that now > need description. Hopefully putting the format issues to rest will > allow the group to move forward on these other areas. I fully agree that there are deficits in areas such as these in the current documents that need repair, but I would rather have these added on as supplements to a single set of documents or modifications to those documents than end up with two sets. The IPng need to solve all the same problems, and as with the formats it would be nice to have just one set of defining documents. Perry From ipsec-request@ans.net Fri Dec 2 22:31:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23635 (5.65c/IDA-1.4.4 for ); Fri, 2 Dec 1994 18:48:58 -0500 Received: by interlock.ans.net id AA28486 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 2 Dec 1994 18:34:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 2 Dec 1994 18:34:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 2 Dec 1994 18:34:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 2 Dec 1994 18:34:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 2 Dec 1994 18:34:56 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Dec 1994 18:34:56 -0500 Date: 2 Dec 94 16:31:00 -0600 To: ipsec@ans.net Subject: IPSEC Agenda for Dec IETF Message-Id: Agenda of the IP Security (IPSEC) WG as of 12/1/94 at the Thirty-First IETF (December 5 & 7 1994) IPSEC working group sessions are scheduled for the 31st Internet Engineering Task Force meeting (December in San Jose). Working group sessions will be held on the IP Security Protocol (IPSP) and on the Internet Key Management Protocol (IKMP - key management for IPSP). The following days and times are scheduled for IPSEC: Mon. Dec.5, 1600-1800 SEC IP Security WG Mon. Dec 5, 1930-2200 SEC IP Security WG Wed. Dec 7, 1930-2200 SEC IP Security WG Following are the detailed agendas for the IPSEC WG meetings. ------------- IPSEC Agenda for Monday, December 5, 1994 16:00 Introduction o Review and Approve Agenda o Minutes of Toronto (July 1994) Meeting 16:15 IPSP Status Reports o Introduction o IPSP Draft (draft-ietf-ipsp-00.txt) o IPv6 Security (Randall Atkinson) (draft-atkinson-ipng-esp-00.txt) o IPv6 Security and IPSP o Implementors Reports/Discussion (J.H., others) 17:00 IPSP and IPv6 Interworking Discussion 17:30 Summary of IPSP Discussions o Review of Documentation Plan o Review of Open Issues o Action Items 18:00 Break for Dinner ------------- ------------- IPSEC Agenda for Monday, December 5, 1994 19:30 Internet Key Management Protocol (IKMP) Introduction o Background and Identification of Relevant Work o Requirements and Criteria Review o Brief Patent Position Discussion o Issues to Resolve o Issues to Defer Review of Experimental Implementations and Proposals 20:00 "Interoperable Symmetric and Asymmetric Key Management" P V McMahon (ICL Enterprises) SESAME V3 20:30 "IEEE Standard 802.10C - Key Management" Russ Housley IEEE 802.10C 21:00 "Modular Key Management Protocol" P. Cheng, J.A. Garay, A. Herzberg, H. Krawczyk (draft-cheng-modular-ikmp-00.txt) 21:40 Preliminary Discussion of Presentations 22:00 Adjourn till Wednesday ------------- IPSEC Agenda for Wednesday, December 7, 1994 19:30 IKMP Introduction Again 19:35 "Simple Key-Management For Internet Protocols (SKIP)" Ashar Aziz (Sun Microsystems, Inc.) (draft-ietf-ipsec-aziz-skip-00.txt) 20:05 "Photuris and IKMP Requirements" Phil Karn 20:25 "Group Key Management Protocol (GKMP)" Hugh Harney (Sparta) (draft-harney-gkmp-spec-00.txt, draft-harney-gkmp-arch-00.txt) 21:15 "A Key Management Proposal" Jim Hughes (Network Systems Corporation) (http://www.network.com/external/ news_releases/security.shtml) 21:30 Discussion of Presentations 21:45 Summary of IKMP Discussions o Review of Documentation Plan o Review of Group Decisions and Requirements o Review of Open Issues o Action Items 22:00 Adjourn From ipsec-request@ans.net Sun Dec 4 20:24:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25575 (5.65c/IDA-1.4.4 for ); Sun, 4 Dec 1994 15:52:00 -0500 Received: by interlock.ans.net id AA13448 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Dec 1994 15:23:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Dec 1994 15:23:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Dec 1994 15:23:12 -0500 Date: Sun, 4 Dec 1994 12:24:48 -0800 From: Phil Karn Message-Id: <199412042024.MAA15041@servo.qualcomm.com> To: ipsec@ans.net Subject: Photuris KMP draft Network Working Group Phil Karn Internet Draft Qualcomm expires in six months December 1994 The Photuris Key Management Protocol draft-karn-photuris-00.txt Status of this Memo This document is a submission to the IP-Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Photuris [1] is an experimental key management protocol intended for use with the IP Security Protocol (IPSP) in a point-to-point mode. Photoris is still in the early design stages and has not yet been completely implemented. Detailed packet formats are not yet specified, but it is hoped that this draft will stimulate discussion about the merits of the design philosphy. Karn expires in six months [Page i] DRAFT Photuris December 1994 1. Introduction Users must have confidence in every Internet Security component, including key management. Users will rely on Internet Security to protect the confidentiality of the traffic they send across the Internet, and they depend on it to block unauthorized external access to their internal hosts and networks. Otherwise, they will either erect barriers that impede legitimate use of the Internet, or they will forego the Internet entirely. Photuris combines Diffie-Hellman key exchange with RSA authentication to provide perfect forward secrecy, as defined by Diffie [2]. The protocol is also designed to thwart certain types of active denial of service attacks on host resources. This draft assumes familiarity with both the Diffie-Hellman and RSA public-key algorithms. Good descriptions can be found in [5]. 1.1. Use of Public-Key Cryptography Widespread deployment and use of an Internet Security protocol is possible without public-key cryptography. For example, Kerberos [6] can generate host-pair keys for use in Internet Security much as it now generates session keys for use by encrypted telnet and other kerberized applications. The Kerberos model has some widely recognized drawbacks. Foremost is the requirement for a highly available on-line key distribution center with a database containing every principal's secret key. This carries significant security risks. Public-key cryptography decentralizes things considerably. Entities authenticate themselves to each other, and generate shared session keys, without real-time communication with any other party. Photuris is based on public-key cryptography, specifically Diffie- Hellman and RSA. Photuris uses RSA only for signature purposes, so in principle it could be replaced by the Digital Signature Standard (DSS). 1.2. Defense against Sabotage The ultimate goal of Internet Security is to facilitate direct IP connectivity between sensitive internal hosts and the external Karn expires in six months [Page 1] DRAFT Photuris December 1994 Internet. Protecting sensitive data on these hosts against compromise -- either by interception or by unauthorized access -- is necessary, but not sufficient. The computing resources themselves must also be protected against malicious attack or sabotage. This is accomplished mainly by the authentication facilities in Internet Security. If a packet does not pass an authentication check, it can be immediately discarded at relatively little cost, given the speed of fast cryptographic hash functions (such as MD5). Internet Security does not place any significance on easily forged IP source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. But there is a potential Achilles heel in the key management protocol. If we are to grant access to authorized users regardless of location, we must be able to cheaply detect and discard bogus packets. Otherwise, an attacker intent on sabotage might rapidly send them to exhaust the host's CPU or memory resources. This is easily done with manual (null) key management, since each packet encounters only the fast crypto-hash functions just mentioned. But key management schemes based on public-key cryptography are potentially vulnerable because of their use of CPU-intensive operations, such as modular exponentiation. Although a complete defense against such attacks is impossible, a simple feature makes them much more difficult. Photuris exchanges a "cookie" before initiating public-key operations, thwarting the saboteur from using random IP source addresses. He must then either: 1) use his own IP address, 2) gain access to a transmission link to a subnet whose addresses he appropriates, or 3) subvert Internet routing for the same purpose. The first option allows the target to detect and filter out such attacks, and significantly increases the likelihood of identifying the attacker. The latter two options are much more difficult than merely sending large numbers of datagrams with randomly chosen IP source addresses from an arbitrary point on the Internet. Karn expires in six months [Page 2] DRAFT Photuris December 1994 1.3. Perfect Forward Secrecy As Diffie points out, many security breaches in government cryptographic systems have been facilitated by designs that generate traffic-encrypting keys (or their equivalents) well before they are needed, and then keep them around longer than necessary. This creates many opportunities for compromise, especially by insiders. A carefully designed public-key system can avoid this problem. The rule is to avoid using any long-lived keys (such as an RSA key pair) to encrypt session keys or actual traffic. Such keys should be used solely for authentication purposes. All keys for traffic encryption should be randomly generated immediately before use, and then destroyed immediately after use, so that they cannot be recovered. Photuris uses a combination of Diffie-Hellman (for key exchange) and RSA (for authentication), as follows: 1. Agree on a session key using the Diffie-Hellman algorithm. 2. Authenticate the Diffie-Hellman exchanges with a digital signature algorithm, such as RSA or DSS. This authenticates the parties to each other, and thwarts the "man in the middle" active attack against Diffie-Hellman. When the session key generated in step 1 is eventually destroyed, it is gone for good. The generating information is not based on any other stored information. Theft of the secret key used to sign the exchanges in step 2 would allow the thief to impersonate the party in future conversations, but it would not allow him to decode any past traffic that he might have recorded. 1.4. Mobile Traffic Anonymity A fundamental role of a key management protocol is to verify the identities of the communicating parties to each other. But one would often like to deny this information to an eavesdropper, especially when this would reveal the location of a mobile user. Although each packet carries a cleartext IP destination address, the ultimate destination could be hidden by "laundering" it through an encrypted tunnel. A mobile user's IP source address could be hidden in the same manner. Karn expires in six months [Page 3] DRAFT Photuris December 1994 If the address has been dynamically allocated, it provides no useful information to an eavesdropper. This leaves the identifying information that the mobile user sends during key exchange. This identification can be easily protected in the two-step DH/RSA protocol by encrypting the RSA signature exchanges with the key just established with Diffie-Hellman. This keeps a passive eavesdropper from learning the identities of the parties, either by checking the signatures against a known database of public keys, or by intercepting possible exchanges of public keys and certificates. The scheme is not foolproof. By posing as the home system, an active attacker could trick the mobile user into revealing his identity. But an active attack is considerably more difficult than passive vacuum-cleaner monitoring. And unless the attacker can steal the RSA secret key belonging to the user's home system, the mobile user will discover the deception when checking the RSA signature in the home system's key exchange message. 1.5. Multicast Support Key management is much more difficult in a multicast environment. The author is not convinced that it is possible to provide all the features just described in a multicast key management protocol. Since the most common use of Internet Security will be in conventional point-to-point IP communications, the author feels that the lack of multicast support in Photuris is acceptable. Nothing in this proposal is meant to discourage the development of other key management protocols with multicast support. If such a protocol can also provide all of the design features of Photuris with reasonable complexity, this author is willing to withdraw this proposal. The author is also open to suggestions on how multicast capability might be added to Photuris, without compromising its fundamental features. Karn expires in six months [Page 4] DRAFT Photuris December 1994 2. Protocol Description The Photuris protocol combines all these elements into a single protocol. The protocol consists of three phases: 1. A "cookie" exchange to guard against simple flooding attacks with bogus IP source addresses. 2. A Diffie-Hellman key exchange to establish a session key for conventional encryption. 3. An encrypted exchange of RSA signatures on the Diffie-Hellman messages that were sent in step 2 to verify their integrity and the identities of the two parties. Regular operation of the Internet Security protocol (encryption and/or authentication of user packets) then begins. Either party may initiate a key exchange. This party is the initiator, while the other party is the responder. The initiator is responsible for recovering from all packet losses by retransmission. 3. Cookie Exchange 3.1. Cookie Request The initiator initializes local state, and sends a COOKIE_REQUEST message to the responder containing the initiator's cookie. The initiator starts a retransmission timer. If no response is obtained within the time limit, the same COOKIE_REQUEST is retransmitted. 3.2. Cookie Response On receipt of the COOKIE_REQUEST, the responder generates a cookie for the incoming IP source address, and returns it in a COOKIE_RESPONSE message, along with the initiator's cookie. Note that the responder creates no state at this time. 3.3. Cookie Generation The exact method in which a Photuris entity generates a cookie is Karn expires in six months [Page 5] DRAFT Photuris December 1994 implementation dependent. The function chosen must satisfy some basic requirements: 1. The cookie must depend on the remote IP address. This prevents an attacker from obtaining a cookie with his real IP address, and then using it to swamp the victim with Diffie-Hellman requests from randomly chosen IP addresses. 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie, and it must not be possible to deduce this secret information from any particular cookie. 3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources. A recommended method is to run a cryptographic one-way hash function (such as MD5) over the remote IP address and a locally generated random value. An incoming cookie can be verified at any time by regenerating it locally from the incoming IP address and the local random value. The random value may be generated once at boot time and remain static until the next reboot. It is kept secret. 4. Diffie-Hellman Exchange 4.1. Diffie-Hellman Request On receipt of a valid COOKIE_RESPONSE, the initiator sends a DH_REQUEST message containing the following items: a) The initiator's cookie. b) The responder's cookie. c) The public part of the initiator's Diffie-Hellman exchange. d) The prime modulus used to compute (c). e) A list of transport protocols supported by the initiator f) A list of Internet Security encapsulation modes (encryption and authentication algorithms) supported by the initiator. g) A policy indicator showing whether the initiator requires the use Karn expires in six months [Page 6] DRAFT Photuris December 1994 of authentication on incoming Internet Security protected packets. The initiator then starts a timer that runs until it receives a DH_RESPONSE message. If the timer expires, the same DH_REQUEST is retransmitted. 4.2. Diffie-Hellman Response On receipt of a valid DH_REQUEST message, the responder returns a DH_RESPONSE message with the following items: a) The initiator's cookie. b) The responder's cookie. c) The public part of the initiator's Diffie-Hellman exchange, computed using the prime modulus received in the DH_REQUEST message. d) A list of transport protocols supported by the responder. e) A list of Internet Security encapsulation modes (encryption and authentication algorithms) supported by the responder. f) A policy indicator showing whether the responder requires the use of authentication on incoming Internet Security protected packets. At this time, the responder begins execution of the final modular exponentiation step in Diffie-Hellman that yields a shared key. The responder keeps a copy of the incoming DH_REQUEST message, and its DH_RESPONSE message. If a duplicate DH_REQUEST is received, it merely resends the previous DH_RESPONSE message, and takes no further action. 4.3. Session Key Computation On receipt of the DH_RESPONSE message, the initiator begins execution of the final modular exponentiation step in Diffie-Hellman that yields a shared key. This final step is executed in parallel with the responder's computation, minimizing delay. Karn expires in six months [Page 7] DRAFT Photuris December 1994 Both the initiator and responder use the resulting shared key to encrypt all subsequent exchanges, with the exception of any DH_RESPONSE retransmissions. Each party selects an encryption mode (if any) according to its own local policy database, and the list of encryption functions supported by the other party. Each party additionally selects an authentication function according to the requirements and facilities of the other party. Note that the encryption and authentication modes, as well as the IP-IP encapsulation mode (if any), need not be the same in both directions. 4.4. Random Number Generation The security of Diffie-Hellman depends critically on the quality of the secret random numbers generated by each party. A poor random number generator at either end will compromise the shared key produced by the algorithm. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hash function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [4]. 4.5. Moduli It is envisioned that a small set of recommended strong primes for use as Diffie-Hellman moduli will be specified in the Photuris standard. The preferred modulus will be 1024 bits long. The modulus indicated in the "Diffie-Hellman Request" may then take the form of a one-byte index into a well-known table, with a reserved escape value allowing an arbitrary modulus. Use of a very limited number of moduli (preferably one) has one minor and one very significant advantage: Minor advantage: Avoiding the overhead of sending the full modulus in every DH_REQUEST packet. Karn expires in six months [Page 8] DRAFT Photuris December 1994 Major advantage: Allowing each party to precompute the public DH part in the DH_REQUEST and DH_RESPONSE, and for the RSA signatures (described later). A background process can periodically destroy the old values, generate a new random secret, and recalculate the public DH part and the RSA signature. This limits the exposure of the secret, as past secrets are not kept for possible discovery by a future intrusion, protecting earlier communications. Also, the secret currently in use is less likely to be anticipated, as the element of random timing is introduced. Since these operations involve several time-consuming modular exponentiations, moving them to the "background" substantially speeds up the apparent execution speed of the Photuris protocol. It also allows a single DH key pair and associated RSA signature to be used in several closely spaced Photuris executions, when setting up security associations with several different hosts over a short period of time, thus reducing total CPU loading. 4.6. Size of Secret DH Components There is surprisingly little guidance in the literature about how large the randomly chosen secret exponent in Diffie-Hellman should be. The size of this exponent dramatically affects the speed of both modular exponentiations involved in Diffie-Hellman. For example, a single modular exponentiation on a 486-66DX2 processor using RSAREF and Borland C under MS-DOS took 20 seconds with a 1024- bit prime modulus and a 1024-bit random exponent. This dropped to about 1 to 1.5 seconds when the random exponent was shortened to 256 bits, with the same 1024-bit modulus. Therefore, it is desirable to use the smallest random exponent that is consistent with good security. The most conservative advice received to date [3] is to make the random exponent twice as long as the intended session key. This ensures that any space/time "meet in the middle" attack on the discrete logarithm problem will be at least as complex as a brute-force search on the resulting session key space. Karn expires in six months [Page 9] DRAFT Photuris December 1994 5. Signature Exchange 5.1. Signature Transmission When each party completes its parallel computation of the Diffie- Hellman key agreement, and encryption has begun, each party sends the other a RSA_SIG message containing the following items: a) The initiator's cookie. b) The responder's cookie. c) An RSA signature on the public part of the sender's Diffie-Hellman exchange. d) The corresponding RSA public key, or an indicator of same. e) Certificates on the RSA public key (optional). Each party keeps a copy of its RSA_SIG message and starts a timer. When it receives the other party's RSA_SIG message, it stops the timer. If it does not receive the other party's RSA_SIG message before the timer expires, it retransmits its own RSA_SIG message and restarts the timer. If it receives a duplicate of the other party's RSA_SIG message (after its timer has been stopped), it retransmits its own RSA_SIG message without restarting the timer. 5.2. Signature Verification The two parties now verify the RSA signatures just received. If they fail, the users are notified, and the security association is destroyed. If they succeed, normal operation begins with the encryption and/or authentication of user packets. Each party implements local policy that determines what access, if any, is granted to the holder of a particular RSA key pair. Exchange of RSA public key certificates is optional; early implementations may wish to keep their own trusted public key databases, and accept only those users found there. Any encrypted and/or authenticated user packets received before the completion of RSA signature verification are placed on a queue pending completion of this step. If the RSA verification succeeds, the queue is processed as though the packets had arrived subsequent Karn expires in six months [Page 10] DRAFT Photuris December 1994 to the verification. If the verification fails, the queue is discarded. Karn expires in six months [Page 11] DRAFT Photuris December 1994 A. Strong Primes This 1024-bit prime p, expressed in hex, has the property that both p and (p-1)/2 are prime: 1 a4788e2184b8d68bfe02690e4dbe485b17a80bc5f21d680f1a8413139734f7f2b0db4e253750018a ad9e86d49b6004bbbcf051f52fcb66d0c5fca63fbfe634173485bbbf7642e9df9c74b85b6855e942 13b8c2d89162abeff43424350e96be41edd42de99a6961638c1dac598bc90da069b50c414d8eb865 2adcff4a270d567f The recommended generator g for this prime is 5. Although this prime is suggested for use in this protocol, cooperating installations might use additional primes. Karn expires in six months [Page 12] DRAFT Photuris December 1994 Security Considerations Security issues are the topic of this memo. References [1] "Photuris" is the latin name for the firefly. "Firefly" is in turn the name for NSA's (classified) key exchange protocol for the STU- III secure telephone. Informed speculation has it that Firefly is based on very similar design principles. [2] Whitfield Diffie, "Authenticated Key Exchange and Secure Interactive Communication", Northern Telecom, Securicom '90, Paris France, 16 March 1990. [3] Martin Hellman, personal communication. [4] Eastlake, Crocker & Schiller, "Randomness Requirements for Security", work in progress. [5] Bruce Schneier, "Applied Cryptography", ISBN 0- 471-59756-2. [6] Kerberos? Acknowledgements Thanks go to Bill Simpson for his protocol suggestions, editorial changes and NROFF formatting. Author's Address Questions about this memo can also be directed to: Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779 Karn expires in six months [Page 13] DRAFT Photuris December 1994 karn@qualcomm.com karn@unix.ka9q.ampr.org Karn expires in six months [Page 14] DRAFT Photuris December 1994 Table of Contents 1. Introduction .......................................... 1 1.1 Use of Public-Key Cryptography .................. 1 1.2 Defense against Sabotage ........................ 1 1.3 Perfect Forward Secrecy ......................... 3 1.4 Mobile Traffic Anonymity ........................ 3 1.5 Multicast Support ............................... 4 2. Protocol Description .................................. 5 3. Cookie Exchange ....................................... 5 3.1 Cookie Request .................................. 5 3.2 Cookie Response ................................. 5 3.3 Cookie Generation ............................... 5 4. Diffie-Hellman Exchange ............................... 6 4.1 Diffie-Hellman Request .......................... 6 4.2 Diffie-Hellman Response ......................... 7 4.3 Session Key Computation ......................... 7 4.4 Random Number Generation ........................ 8 4.5 Moduli .......................................... 8 4.6 Size of Secret DH Components .................... 9 5. Signature Exchange .................................... 10 5.1 Signature Transmission .......................... 10 5.2 Signature Verification .......................... 10 APPENDICES ................................................... 12 A. Strong Primes ......................................... 12 SECURITY CONSIDERATIONS ...................................... 13 REFERENCES ................................................... 13 ACKNOWLEDGEMENTS ............................................. 13 AUTHOR'S ADDRESS ............................................. 13 From ipsec-request@ans.net Sun Dec 4 21:41:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26425 (5.65c/IDA-1.4.4 for ); Sun, 4 Dec 1994 17:02:51 -0500 Received: by interlock.ans.net id AA23568 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 4 Dec 1994 16:40:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 4 Dec 1994 16:40:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Dec 1994 16:40:02 -0500 Date: Sun, 4 Dec 1994 13:41:38 -0800 From: Phil Karn Message-Id: <199412042141.NAA15100@servo.qualcomm.com> To: ipsec@ans.net Subject: corrected Photuris draft That last draft went out a bit prematurely. Please replace it with the following. Phil Network Working Group Phil Karn Internet Draft Qualcomm expires in six months December 1994 The Photuris Key Management Protocol draft-karn-photuris-00.txt Status of this Memo This document is a submission to the IP-Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Photuris [1] is an experimental key management protocol intended for use with the IP Security Protocol (IPSP) in a point-to-point mode. Photuris is still in the early design stages and has not yet been completely implemented. Detailed packet formats are not yet specified, but it is hoped that this draft will stimulate discussion about the merits of the design philosophy. Karn expires in six months [Page i] DRAFT Photuris December 1994 1. Introduction Users must have confidence in every Internet Security component, including key management. Users will rely on Internet Security to protect the confidentiality of the traffic they send across the Internet, and they depend on it to block unauthorized external access to their internal hosts and networks. Otherwise, they will either erect barriers that impede legitimate use of the Internet, or they will forego the Internet entirely. Photuris combines Diffie-Hellman key exchange with RSA authentication to provide perfect forward secrecy, as defined by Diffie [2]. The protocol is also designed to thwart certain types of active denial of service attacks on host resources. This draft assumes familiarity with both the Diffie-Hellman and RSA public-key algorithms. Good descriptions can be found in [5]. 1.1. Use of Public-Key Cryptography Widespread deployment and use of an Internet Security protocol is possible without public-key cryptography. For example, Kerberos [6] can generate host-pair keys for use in Internet Security much as it now generates session keys for use by encrypted telnet and other kerberized applications. The Kerberos model has some widely recognized drawbacks. Foremost is the requirement for a highly available on-line key distribution center with a database containing every principal's secret key. This carries significant security risks. Public-key cryptography decentralizes things considerably. Entities authenticate themselves to each other, and generate shared session keys, without real-time communication with any other party. Photuris is based on public-key cryptography, specifically Diffie- Hellman and RSA. Photuris uses RSA only for signature purposes, so in principle it could be replaced by the Digital Signature Standard (DSS). 1.2. Defense against Sabotage The ultimate goal of Internet Security is to facilitate direct IP connectivity between sensitive internal hosts and the external Karn expires in six months [Page 1] DRAFT Photuris December 1994 Internet. Protecting sensitive data on these hosts against compromise -- either by interception or by unauthorized access -- is necessary, but not sufficient. The computing resources themselves must also be protected against malicious attack or sabotage. This is accomplished mainly by the authentication facilities in Internet Security. If a packet does not pass an authentication check, it can be immediately discarded at relatively little cost, given the speed of fast cryptographic hash functions (such as MD5). Internet Security does not place any significance on easily forged IP source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. But there is a potential Achilles heel in the key management protocol. If we are to grant access to authorized users regardless of location, we must be able to cheaply detect and discard bogus packets. Otherwise, an attacker intent on sabotage might rapidly send them to exhaust the host's CPU or memory resources. This is easily done with manual (null) key management, since each packet encounters only the fast crypto-hash functions just mentioned. But key management schemes based on public-key cryptography are potentially vulnerable because of their use of CPU-intensive operations, such as modular exponentiation. Although a complete defense against such attacks is impossible, a simple feature makes them much more difficult. Photuris exchanges a "cookie" before initiating public-key operations, thwarting the saboteur from using random IP source addresses. He must then either: 1) use his own IP address, 2) gain access to a transmission link to a subnet whose addresses he appropriates, or 3) subvert Internet routing for the same purpose. The first option allows the target to detect and filter out such attacks, and significantly increases the likelihood of identifying the attacker. The latter two options are much more difficult than merely sending large numbers of datagrams with randomly chosen IP source addresses from an arbitrary point on the Internet. Karn expires in six months [Page 2] DRAFT Photuris December 1994 1.3. Perfect Forward Secrecy As Diffie points out, many security breaches in government cryptographic systems have been facilitated by designs that generate traffic-encrypting keys (or their equivalents) well before they are needed, and then keep them around longer than necessary. This creates many opportunities for compromise, especially by insiders. A carefully designed public-key system can avoid this problem. The rule is to avoid using any long-lived keys (such as an RSA key pair) to encrypt session keys or actual traffic. Such keys should be used solely for authentication purposes. All keys for traffic encryption should be randomly generated immediately before use, and then destroyed immediately after use, so that they cannot be recovered. Photuris uses a combination of Diffie-Hellman (for key exchange) and RSA (for authentication), as follows: 1. Agree on a session key using the Diffie-Hellman algorithm. 2. Authenticate the Diffie-Hellman exchanges with a digital signature algorithm, such as RSA or DSS. This authenticates the parties to each other, and thwarts the "man in the middle" active attack against Diffie-Hellman. When the session key generated in step 1 is eventually destroyed, it is gone for good. The generating information is not based on any other stored information. Theft of the secret key used to sign the exchanges in step 2 would allow the thief to impersonate the party in future conversations, but it would not allow him to decode any past traffic that he might have recorded. 1.4. Mobile Traffic Anonymity A fundamental role of a key management protocol is to verify the identities of the communicating parties to each other. But one would often like to deny this information to an eavesdropper, especially when this would reveal the location of a mobile user. Although each packet carries a cleartext IP destination address, the ultimate destination could be hidden by "laundering" it through an encrypted tunnel. A mobile user's IP source address could be hidden in the same manner. Karn expires in six months [Page 3] DRAFT Photuris December 1994 If the address has been dynamically allocated, it provides no useful information to an eavesdropper. This leaves the identifying information that the mobile user sends during key exchange. This identification can be easily protected in the two-step DH/RSA protocol by encrypting the RSA signature exchanges with the key just established with Diffie-Hellman. This keeps a passive eavesdropper from learning the identities of the parties, either by checking the signatures against a known database of public keys, or by intercepting possible exchanges of public keys and certificates. The scheme is not foolproof. By posing as the home system, an active attacker could trick the mobile user into revealing his identity. But an active attack is considerably more difficult than passive vacuum-cleaner monitoring. And unless the attacker can steal the RSA secret key belonging to the user's home system, the mobile user will discover the deception when checking the RSA signature in the home system's key exchange message. 1.5. Multicast Support Key management is much more difficult in a multicast environment. The author is not convinced that it is possible to provide all the features just described in a multicast key management protocol. Since the most common use of Internet Security will be in conventional point-to-point IP communications, the author feels that the lack of multicast support in Photuris is acceptable. Nothing in this proposal is meant to discourage the development of other key management protocols with multicast support. If such a protocol can also provide all of the design features of Photuris with reasonable complexity, this author is willing to withdraw this proposal. The author is also open to suggestions on how multicast capability might be added to Photuris, without compromising its fundamental features. Karn expires in six months [Page 4] DRAFT Photuris December 1994 2. Protocol Description The Photuris protocol combines all these elements into a single protocol. The protocol consists of three phases: 1. A "cookie" exchange to guard against simple flooding attacks with bogus IP source addresses. 2. A Diffie-Hellman key exchange to establish a session key for conventional encryption. 3. An encrypted exchange of RSA signatures on the Diffie-Hellman messages that were sent in step 2 to verify their integrity and the identities of the two parties. Regular operation of the Internet Security protocol (encryption and/or authentication of user packets) then begins. Either party may initiate a key exchange. This party is the initiator, while the other party is the responder. The initiator is responsible for recovering from all packet losses by retransmission. 3. Cookie Exchange 3.1. Cookie Request The initiator initializes local state, and sends a COOKIE_REQUEST message to the responder containing the initiator's cookie. The initiator starts a retransmission timer. If no response is obtained within the time limit, the same COOKIE_REQUEST is retransmitted. 3.2. Cookie Response On receipt of the COOKIE_REQUEST, the responder generates a cookie for the incoming IP source address, and returns it in a COOKIE_RESPONSE message, along with the initiator's cookie. Note that the responder creates no state at this time. 3.3. Cookie Generation The exact method in which a Photuris entity generates a cookie is Karn expires in six months [Page 5] DRAFT Photuris December 1994 implementation dependent. The function chosen must satisfy some basic requirements: 1. The cookie must depend on the remote IP address. This prevents an attacker from obtaining a cookie with his real IP address, and then using it to swamp the victim with Diffie-Hellman requests from randomly chosen IP addresses. 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie, and it must not be possible to deduce this secret information from any particular cookie. 3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources. A recommended method is to run a cryptographic one-way hash function (such as MD5) over the remote IP address and a locally generated random value. An incoming cookie can be verified at any time by regenerating it locally from the incoming IP address and the local random value. The random value may be generated once at boot time and remain static until the next reboot. It is kept secret. 4. Diffie-Hellman Exchange 4.1. Diffie-Hellman Request On receipt of a valid COOKIE_RESPONSE, the initiator sends a DH_REQUEST message containing the following items: a) The initiator's cookie. b) The responder's cookie. c) The public part of the initiator's Diffie-Hellman exchange. d) The prime modulus used to compute (c). e) A list of transport protocols supported by the initiator f) A list of Internet Security encapsulation modes (encryption and authentication algorithms) supported by the initiator. g) A policy indicator showing whether the initiator requires the use Karn expires in six months [Page 6] DRAFT Photuris December 1994 of authentication on incoming Internet Security protected packets. The initiator then starts a timer that runs until it receives a DH_RESPONSE message. If the timer expires, the same DH_REQUEST is retransmitted. 4.2. Diffie-Hellman Response On receipt of a valid DH_REQUEST message, the responder returns a DH_RESPONSE message with the following items: a) The initiator's cookie. b) The responder's cookie. c) The public part of the responder's Diffie-Hellman exchange, computed using the prime modulus received in the DH_REQUEST message. d) A list of transport protocols supported by the responder. e) A list of Internet Security encapsulation modes (encryption and authentication algorithms) supported by the responder. f) A policy indicator showing whether the responder requires the use of authentication on incoming Internet Security protected packets. At this time, the responder begins execution of the final modular exponentiation step in Diffie-Hellman that yields a shared key. The responder keeps a copy of the incoming DH_REQUEST message, and its DH_RESPONSE message. If a duplicate DH_REQUEST is received, it merely resends the previous DH_RESPONSE message, and takes no further action. 4.3. Session Key Computation On receipt of the DH_RESPONSE message, the initiator begins execution of the final modular exponentiation step in Diffie-Hellman that yields a shared key. This final step is executed in parallel with the responder's computation, minimizing delay. Karn expires in six months [Page 7] DRAFT Photuris December 1994 Both the initiator and responder use the resulting shared key to encrypt all subsequent exchanges, with the exception of any DH_RESPONSE retransmissions. Each party selects an encryption mode (if any) according to its own local policy database, and the list of encryption functions supported by the other party. Each party additionally selects an authentication function according to the requirements and facilities of the other party. Note that the encryption and authentication modes, as well as the IP-IP encapsulation mode (if any), need not be the same in both directions. 4.4. Random Number Generation The security of Diffie-Hellman depends critically on the quality of the secret random numbers generated by each party. A poor random number generator at either end will compromise the shared key produced by the algorithm. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hash function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [4]. 4.5. Moduli It is envisioned that a small set of recommended strong primes for use as Diffie-Hellman moduli will be specified in the Photuris standard. The preferred modulus will be 1024 bits long. The modulus indicated in the "Diffie-Hellman Request" may then take the form of a one-byte index into a well-known table, with a reserved escape value allowing an arbitrary modulus. Use of a very limited number of moduli (preferably one) has one minor and one very significant advantage: Minor advantage: Avoiding the overhead of sending the full modulus in every DH_REQUEST packet. Karn expires in six months [Page 8] DRAFT Photuris December 1994 Major advantage: Allowing each party to precompute the public DH part in the DH_REQUEST and DH_RESPONSE, and for the RSA signatures (described later). A background process can periodically destroy the old values, generate a new random secret, and recalculate the public DH part and the RSA signature. This limits the exposure of the secret, as past secrets are not kept for possible discovery by a future intrusion, protecting earlier communications. Also, the secret currently in use is less likely to be anticipated, as the element of random timing is introduced. Since these operations involve several time-consuming modular exponentiations, moving them to the "background" substantially speeds up the apparent execution speed of the Photuris protocol. It also allows a single DH key pair and associated RSA signature to be used in several closely spaced Photuris executions, when setting up security associations with several different hosts over a short period of time, thus reducing total CPU loading. 4.6. Size of Secret DH Components There is surprisingly little guidance in the literature about how large the randomly chosen secret exponent in Diffie-Hellman should be. The size of this exponent dramatically affects the speed of both modular exponentiations involved in Diffie-Hellman. For example, a single modular exponentiation on a 486-66DX2 processor using RSAREF and Borland C under MS-DOS took 20 seconds with a 1024- bit prime modulus and a 1024-bit random exponent. This dropped to about 1 to 1.5 seconds when the random exponent was shortened to 128 bits, with the same 1024-bit modulus. Therefore, it is desirable to use the smallest random exponent that is consistent with good security. The most conservative advice received to date [3] is to make the random exponent twice as long as the intended session key. This ensures that any space/time "meet in the middle" attack on the discrete logarithm problem will be at least as complex as a brute-force search on the resulting session key space. Karn expires in six months [Page 9] DRAFT Photuris December 1994 5. Signature Exchange 5.1. Signature Transmission When each party completes its parallel computation of the Diffie- Hellman key agreement, and encryption has begun, each party sends the other a RSA_SIG message containing the following items: a) The initiator's cookie. b) The responder's cookie. c) An RSA signature on the public part of the sender's Diffie-Hellman exchange. d) The corresponding RSA public key, or an indicator of same. e) Certificates on the RSA public key (optional). Each party keeps a copy of its RSA_SIG message and starts a timer. When it receives the other party's RSA_SIG message, it stops the timer. If it does not receive the other party's RSA_SIG message before the timer expires, it retransmits its own RSA_SIG message and restarts the timer. If it receives a duplicate of the other party's RSA_SIG message (after its timer has been stopped), it retransmits its own RSA_SIG message without restarting the timer. 5.2. Signature Verification The two parties now verify the RSA signatures just received. If they fail, the users are notified, and the security association is destroyed. If they succeed, normal operation begins with the encryption and/or authentication of user packets. Each party implements local policy that determines what access, if any, is granted to the holder of a particular RSA key pair. Exchange of RSA public key certificates is optional; early implementations may wish to keep their own trusted public key databases, and accept only those users found there. Any encrypted and/or authenticated user packets received before the completion of RSA signature verification are placed on a queue pending completion of this step. If the RSA verification succeeds, the queue is processed as though the packets had arrived subsequent Karn expires in six months [Page 10] DRAFT Photuris December 1994 to the verification. If the verification fails, the queue is discarded. Karn expires in six months [Page 11] DRAFT Photuris December 1994 A. Strong Primes This 1024-bit prime p, expressed in hex, has the property that both p and (p-1)/2 are prime: 1 a4788e2184b8d68bfe02690e4dbe485b17a80bc5f21d680f1a8413139734f7f2b0 db4e253750018aad9e86d49b6004bbbcf051f52fcb66d0c5fca63fbfe634173485 bbbf7642e9df9c74b85b6855e94213b8c2d89162abeff43424350e96be41edd42d e99a6961638c1dac598bc90da069b50c414d8eb8652adcff4a270d567f The recommended generator g for this prime is 5. Although this prime is suggested for use in this protocol, cooperating installations might use additional primes. This prime was randomly generated by a freely available program written by the author. Karn expires in six months [Page 12] DRAFT Photuris December 1994 Security Considerations Security issues are the topic of this memo. References [1] "Photuris" is the latin name for the firefly. "Firefly" is in turn the name for NSA's (classified) key exchange protocol for the STU- III secure telephone. Informed speculation has it that Firefly is based on very similar design principles. [2] Whitfield Diffie, "Authenticated Key Exchange and Secure Interactive Communication", Northern Telecom, Securicom '90, Paris France, 16 March 1990. [3] Martin Hellman, personal communication. [4] Eastlake, Crocker & Schiller, "Randomness Requirements for Security", work in progress. [5] Bruce Schneier, "Applied Cryptography", ISBN 0- 471-59756-2. [6] Kerberos? Acknowledgements Thanks go to Bill Simpson for his protocol suggestions, editorial changes and NROFF formatting. Author's Address Questions about this memo can also be directed to: Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779 Karn expires in six months [Page 13] DRAFT Photuris December 1994 karn@qualcomm.com karn@unix.ka9q.ampr.org Karn expires in six months [Page 14] DRAFT Photuris December 1994 Table of Contents 1. Introduction .......................................... 1 1.1 Use of Public-Key Cryptography .................. 1 1.2 Defense against Sabotage ........................ 1 1.3 Perfect Forward Secrecy ......................... 3 1.4 Mobile Traffic Anonymity ........................ 3 1.5 Multicast Support ............................... 4 2. Protocol Description .................................. 5 3. Cookie Exchange ....................................... 5 3.1 Cookie Request .................................. 5 3.2 Cookie Response ................................. 5 3.3 Cookie Generation ............................... 5 4. Diffie-Hellman Exchange ............................... 6 4.1 Diffie-Hellman Request .......................... 6 4.2 Diffie-Hellman Response ......................... 7 4.3 Session Key Computation ......................... 7 4.4 Random Number Generation ........................ 8 4.5 Moduli .......................................... 8 4.6 Size of Secret DH Components .................... 9 5. Signature Exchange .................................... 10 5.1 Signature Transmission .......................... 10 5.2 Signature Verification .......................... 10 APPENDICES ................................................... 12 A. Strong Primes ......................................... 12 SECURITY CONSIDERATIONS ...................................... 13 REFERENCES ................................................... 13 ACKNOWLEDGEMENTS ............................................. 13 AUTHOR'S ADDRESS ............................................. 13 From ipsec-request@ans.net Mon Dec 5 04:57:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27394 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 10:10:33 -0500 Received: by interlock.ans.net id AA24002 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 09:59:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 09:59:13 -0500 Message-Id: <199412051458.AA23996@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 09:59:13 -0500 Date: Mon, 5 Dec 94 09:57:02 EST From: jwlowe@VNET.IBM.COM To: ipsec@ans.net, zmuda@spyrus.com, PAUL@LAMBERT-.IBM.COM, grwoods@VNET.IBM.COM, AMIR@yktvmv.vnet.ibm.com December 2, 1994 Mr. Phill Gross, IESG Chairman Director of Broadband Engineering MCI Data Services Division 2100 Reston Parkway, Room 6001 Reston, VA 22091 Re: IBM Proposal to Internet "Modular Approach to Key Management" Dear Mr. Gross: IBM has been working with others to make the Internet a more secure vehicle on which users can transmit messages without fear of having those messages intercepted and read by unauthorized parties. The enhancement of message security on the Internet is important to IBM and to other members of the Internet community. IBM has proposed a method which it believes, if adopted by the Internet Engineering Task Force (IETF) and implemented by the Internet community, will significantly improve the security of message traffic on the Internet between authorized users. In keeping with its view of the importance of such security, IBM is willing to make an exception to its long-standing and preferred practice of supporting industry standards by making available nonexclusive licenses under its patents, on reasonable and nondiscriminatory terms and conditions, including its then- current royalty rates. In this case, IBM will grant, to Internet users and to companies that will provide equipment for use by such users, a royalty-free right to practice inventions covered by claims of IBM patents where such claims are infringed as a necessary consequence of implementing the modular key management system of the Internet Protocol (IP), as specified in the IBM proposal. Such grants will be made if the IBM proposal is included in the final Internet standard and only to requesting parties who commit to grant IBM rights of similar scope under their patents that relate to the Internet standard in question. At this time, IBM believes that the only IBM patent relevant to the proposal is US Patent #5,148,479 and its non-US counterpart patents and patent applications. The agreement between IBM and each licensee will specifically reference, but will not be limited to, this patent. This letter will be posted on the Internet within the next few days. IBM is working on the language for the agreement and will forward it to members of the IETF when advised by the IETF that acceptance of the IBM proposal is contingent only upon the terms and conditions of the IBM agreement. Any IETF member that wishes to review the draft before that time may send a written request to me for the draft, at the address recited below. IBM will also post the agreement on the Internet and will receive acceptances of the offer and requests for the agreement electronically. However, as questions remain about the enforceability of agreements "executed" electronically, IBM will require the execution of a confirmatory printed copy of the agreement by each licensee and IBM. This should eliminate any question regarding enforceability of such agreements. IBM has not determined whether the IBM proposal is clear of infringement of any third party patents and will not undertake to clear or provide indemnification for products or services of others if its proposal is adopted. Any questions about this offer or requests for the confirmatory license may be directed to: John W. Lowe Program Manager, Licensing International Business Machines Corporation 500 Columbus Avenue Thornwood, NY 10594 United States of America Internet ID: JWLOWE@VNET.IBM.COM Telephone: (914) 742-6275 Fax: (914) 742-6729 IBM is pleased to make this offer in support of its proposal to Internet. Sincerely, John W. Lowe Program Manager, Licensing From ipsec-request@ans.net Mon Dec 5 16:23:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38675 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 11:28:30 -0500 Received: by interlock.ans.net id AA23200 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 11:24:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 5 Dec 1994 11:24:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 5 Dec 1994 11:24:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 11:24:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 11:24:21 -0500 Message-Id: <9412051623.AA06667@snark.imsi.com> To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net In-Reply-To: Your message of "Mon, 05 Dec 1994 09:57:02 EST." <199412051458.AA23996@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 05 Dec 1994 11:23:45 -0500 From: "Perry E. Metzger" jwlowe@VNET.IBM.COM says: > At this time, IBM believes that the only IBM patent relevant to > the proposal is US Patent #5,148,479 and its non-US counterpart > patents and patent applications. The agreement between IBM and > each licensee will specifically reference, but will not be > limited to, this patent. If this implies that there has to be an explicit agreement signed by each developer and user I think the terms are still not entirely acceptable. It will mean that vast amounts of paperwork will be needed to actually deploy the standard. I strongly urge you to set this up so that no interaction with IBM is needed on the part of any entity using these protocols in an internet context. .pm From ipsec-request@ans.net Mon Dec 5 17:18:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38343 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 12:26:21 -0500 Received: by interlock.ans.net id AA18338 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 12:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 5 Dec 1994 12:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 12:22:40 -0500 From: Willis Marti Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 12:22:40 -0500 Date: Mon, 5 Dec 1994 11:18:03 -0600 Message-Id: <199412051718.LAA26935@neuron.cs.tamu.edu> To: jwlowe@VNET.IBM.COM, perry@imsi.com Subject: Patents and Standards Cc: ipsec@ans.net perry@imsi.com writes: >jwlowe@VNET.IBM.COM says: >> At this time, IBM believes that the only IBM patent relevant to >> the proposal is US Patent #5,148,479 and its non-US counterpart >> patents and patent applications. The agreement between IBM and >> each licensee will specifically reference, but will not be >> limited to, this patent. > >If this implies that there has to be an explicit agreement signed by >each developer and user I think the terms are still not entirely >acceptable. It will mean that vast amounts of paperwork will be needed >to actually deploy the standard. I strongly urge you to set this up so >that no interaction with IBM is needed on the part of any entity using >these protocols in an internet context. Maybe there's some misunderstanding as to scope. If _developers_ but not users need the license, it's essentially no different than ethernet/802.3. Right? From ipsec-request@ans.net Mon Dec 5 08:49:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20684 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 13:57:48 -0500 Received: by interlock.ans.net id AA04406 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 13:51:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 13:51:15 -0500 Message-Id: <199412051851.AA04402@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 13:51:15 -0500 Date: Mon, 5 Dec 94 13:49:30 EST From: jwlowe@VNET.IBM.COM To: ipsec@ans.net ========================================================================= Date: 5 December 1994, 13:25:15 EST From: CIRCJWL at RHQVM07 To: perry at imsi.com Subject: IBM Patent Rights Offer/USP #5,148.479 I appreciate your interest in keeping the paperwork and interaction among IBM and licensees to a minimum, but I think each party is better served by assuring that each is in concert as to the terms of the agreement and that such terms are enforceable. A signed agreement accomplishes these aspectsand will not consign any single party to "vast amounts of paperwork toactually deploy the standard (accept the rights IBM has offered to grant)."We have considered your points while deciding on this offer, and are confidentthat paperwork and needless procedures will be minimized if the IBM proposal isadopted and licenses are requested and granted. We do not wish tosacrificelegal effectiveness for simple "ease-of-entry into a relationship" features,by eliminating a written confirmatory agreement based on a documentthat willbe posted on Internet for review by prospective grantees prior totheirrequesting and commiting to sign the specific agreement..cc ipsec amir gerry dick From ipsec-request@ans.net Mon Dec 5 09:00:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17113 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 14:11:15 -0500 Received: by interlock.ans.net id AA06651 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 14:02:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 14:02:15 -0500 Message-Id: <199412051902.AA29943@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 14:02:15 -0500 Date: Mon, 5 Dec 94 14:00:30 EST From: jwlowe@VNET.IBM.COM To: willis@cs.tamu.edu, ipsec@ans.net Subject: IBM Patent Rights Offer/ USP #5,148,479 Willis, thank you for your note regarding Perry Metzger's response tomy posting of the letter to IPSEC. I am not familiar with the IEEEEthernet 802.3 offer, so I don't know whether IBM's offer is similarto what was offered or granted there. However, the IBM offer appliesto developers and users who believe that they need or wish to have agrant of rights of the type setout in my letter.I hope you receive a copy of my reply to Perry, as it too is postedto IPSEC. Each party that wishes to receive the rights IBM has offeredto grant should be willing to invest a minimal amount of time to assurethat there is no misunderstanding of what is being granted or received,and that the grant is definite and legally enforceable without question..cc amir gerry dick From ipsec-request@ans.net Mon Dec 5 03:28:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23994 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 14:31:02 -0500 Received: by interlock.ans.net id AA22372 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 14:27:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 5 Dec 1994 14:27:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 5 Dec 1994 14:27:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 14:27:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 14:27:29 -0500 Date: Mon, 5 Dec 94 11:28:45 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412051928.AA25371@miraj.Eng.Sun.COM> To: ipsec@ans.net Subject: SKIP patents will be in public domain I am happy to state that Sun management has asked me to make the following statement regarding the SKIP patents. 1. The SKIP patents (when they issue) will be placed in the public domain. Anyone may use it if they wish, with no rights or dues pertaining to Sun. There will be no need to license SKIP patent rights. 2. Sun Microsystems did this to help the industry make progress in the area of security. We view this as an indication of our willingness to promote open standards. I thank all of you who publicly commented on this issue, because your comments helped bring about this change in Sun's policy. Regards, Ashar. From ipsec-request@ans.net Mon Dec 5 19:21:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23999 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 14:31:06 -0500 Received: by interlock.ans.net id AA12066 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 14:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 5 Dec 1994 14:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 5 Dec 1994 14:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 14:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 14:22:02 -0500 Message-Id: <9412051921.AA06741@snark.imsi.com> To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM Patent Rights Offer/USP #5,148.479 In-Reply-To: Your message of "Mon, 05 Dec 1994 13:45:51 EST." <199412051847.NAA24078@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 05 Dec 1994 14:21:23 -0500 From: "Perry E. Metzger" jwlowe@VNET.IBM.COM says: > I appreciate your interest in keeping the paperwork and interaction > among IBM and licensees to a minimum, but I think each party is better > served by assuring that each is in concert as to the terms of the > agreement and that such terms are enforceable. Bell Labs has repeatedly assigned inventions to segments of the public without agreements. This sort of thing is routine and easy. That leads me to believe your lawyers are simply making work for themselves and harming your work at the same time. A signed agreement is there to enforce your rights with the other party. What is it that you could possibly need to enforce? The people who are using your software owe you nothing -- no money or other consideration -- so you have no enforceable rights against them. The people who don't have the right to use your software will not have signed an agreement with you anyway. Having worked at IBM, I know what IBM's lawyers consider to be "trivial" paperwork. There is no rational legal reason to require a signed agreement of a person who is not doing anything for you that you would need to enforce. I would suggest that you eliminate the taint of licence agreements since it will not produce benefit for IBM. Perry From ipsec-request@ans.net Mon Dec 5 20:02:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38747 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 15:21:07 -0500 Received: by interlock.ans.net id AA08642 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 15:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 15:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 15:14:05 -0500 Message-Id: <199412052005.NAA21974@sass165> X-Sender: cdbrown@somnet.sandia.gov (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Dec 1994 13:02:50 -0700 To: Hugh Harney , " " From: cdbrown@somnet.sandia.gov (C. Douglas Brown) Subject: Re: Modular approach to key management Cc: "Housley, Russ" , ipsec@ans.net, hh@columbia.sparta.com Having followed the IPSEC mailing list silently, but with great interest, for a long time, I'll throw in my vote on the firewall issue: While Hugh is correct that the most secure solution is to perform the encryption at the end systems, the practicalities of implementation make that somewhat difficult to achieve in the short term, with the wide variety of operating systems running out there in the network. We already place a great deal of trust in our routers and limit access to a small group of network managers and use them to filter access into and out of our networks at Sandia. That would be one of the most secure places in our networks to implement IP encryption. We are more interested in protecting our data from outsiders in the Internet than from insiders at Sandia, although the latter is also important. We would prefer to start with encryption from the firewall out and migrate it to the hosts as software becomes available for our various platforms. - Doug Brown C. Douglas Brown cdbrown@sandia.gov Sandia National Laboratories Phone: (505) 845-8699 Albuquerque, New Mexico 87185-0811 FAX: (505) 844-2067 From ipsec-request@ans.net Mon Dec 5 20:20:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25546 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 15:22:57 -0500 Received: by interlock.ans.net id AA25645 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 15:21:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 5 Dec 1994 15:21:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 5 Dec 1994 15:21:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 15:21:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 15:21:25 -0500 Message-Id: <9412052020.AA06840@snark.imsi.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: SKIP patents will be in public domain In-Reply-To: Your message of "Mon, 05 Dec 1994 11:28:45 PST." <9412051928.AA25371@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 05 Dec 1994 15:20:25 -0500 From: "Perry E. Metzger" Ashar Aziz says: > I am happy to state that Sun management has asked me to make the following > statement regarding the SKIP patents. > > 1. The SKIP patents (when they issue) will be placed in the public domain. > Anyone may use it if they wish, with no rights or dues pertaining to Sun. > There will be no need to license SKIP patent rights. Chalk one up to Sun. We should thank the folks there for listening to and ultimately coming to an understanding our concerns. If this is really the case, the patent based impediment to using SKIP has been completely addressed. I can only hope that other firms see the wisdom of Sun's decision and decide to follow along the same lines. Perry From ipsec-request@ans.net Mon Dec 5 11:17:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24039 (5.65c/IDA-1.4.4 for ); Mon, 5 Dec 1994 16:24:56 -0500 Received: by interlock.ans.net id AA28695 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 5 Dec 1994 16:19:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 5 Dec 1994 16:19:51 -0500 Message-Id: <199412052119.AA18451@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Dec 1994 16:19:51 -0500 Date: Mon, 5 Dec 94 16:17:52 EST From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: IBM US Patent #5,148,479 IBM has decided to dedicate the above-identified patent to the public. We hope this will facilitate action by the IETF to adopt the best technical solution to address problems associated with message traffic on the Internet. .cc perry willis amir gerry lois jeff porter allan jerry marshall From ipsec-request@ans.net Tue Dec 6 10:52:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05467 (5.65c/IDA-1.4.4 for ); Tue, 6 Dec 1994 16:12:08 -0500 Received: by interlock.ans.net id AA30786 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Dec 1994 15:56:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Dec 1994 15:56:48 -0500 Message-Id: <199412062056.AA28214@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Dec 1994 15:56:48 -0500 Date: Tue, 6 Dec 94 15:52:26 EST From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: IBM US Patent #5,148,479 The decision by IBM to dedicate US Patent 5,148,479 is conditioned upon the adoption by the IETF of the IBM proposal for modular key management. If this proposal is not so adopted, IBM will not so dedicate this patent. IBM will, however, offer nonexclusive licenses to requesting parties, under its normal reasonable terms and conditions, including its then-current royalty rates. Please advise me when a decision has been made on which proposal will be included in the Internet standard. From ipsec-request@ans.net Tue Dec 6 23:01:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38436 (5.65c/IDA-1.4.4 for ); Tue, 6 Dec 1994 18:50:48 -0500 Received: by interlock.ans.net id AA20507 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Dec 1994 18:04:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Dec 1994 18:04:43 -0500 Message-Id: <199412062304.AA26903@interlock.ans.net> To: jwlowe@vnet.ibm.com Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of Tue, 06 Dec 94 15:52:26 -0500. <199412062056.AA28214@interlock.ans.net> Date: Tue, 06 Dec 94 18:01:01 -0500 From: Steve Kent As a member of the IPSEC WG who is unable to attend this IETF meeting, I'd like to suggest that adoption of any of the key management proposals on the table at this IETF would be premature and, based on the usual level of new attendees, inappropriate. It is nice that IBM and Sun have offered to make their patented technology available for use in the Internet under very reasonable terms, but the adoption of an Internet standard key management protocol is a complex undertaking and the level of traffic that has passed on this mailing list so far does not lead me to believe that concensus agreement has been reached on the requirements for such a standard, much less the details. Steve From ipsec-request@ans.net Wed Dec 7 01:10:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16759 (5.65c/IDA-1.4.4 for ); Tue, 6 Dec 1994 20:19:09 -0500 Received: by interlock.ans.net id AA06552 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Dec 1994 20:09:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Dec 1994 20:09:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Dec 1994 20:09:19 -0500 Date: Tue, 6 Dec 1994 17:10:24 -0800 From: Phil Karn Message-Id: <199412070110.RAA07616@servo.qualcomm.com> To: kent@BBN.COM Cc: jwlowe@vnet.ibm.com, ipsec@ans.net In-Reply-To: <199412062304.AA26903@interlock.ans.net> (message from Steve Kent on Tue, 06 Dec 94 18:01:01 -0500) Subject: Re: IBM US Patent #5,148,479 >As a member of the IPSEC WG who is unable to attend this IETF meeting, >I'd like to suggest that adoption of any of the key management >proposals on the table at this IETF would be premature and, based on >the usual level of new attendees, inappropriate. It is nice that IBM You can relax, Steve. The chances of us adopting *anything* at this meeting are only slightly greater than the chances of the NSA voluntarily publishing the Skipjack algorithm and abandoning all export controls on cryptography. Phil From ipsec-request@ans.net Wed Dec 7 01:42:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17270 (5.65c/IDA-1.4.4 for ); Tue, 6 Dec 1994 20:45:43 -0500 Received: by interlock.ans.net id AA10615 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Dec 1994 20:42:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Dec 1994 20:42:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Dec 1994 20:42:32 -0500 Date: Tue, 6 Dec 1994 20:42:28 -0500 From: rubin@faline.bellcore.com (Avi Rubin) Message-Id: <199412070142.UAA04179@faline.bellcore.com> To: jwlowe@vnet.ibm.com, kent@BBN.COM Subject: Re: IBM US Patent #5,148,479 Cc: ipsec@ans.net Steve, you are right. I would say that "concensus" is the last word that comes to mind from the first two IP SEC meetings so far. Avi From ipsec-request@ans.net Wed Dec 7 02:52:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20248 (5.65c/IDA-1.4.4 for ); Tue, 6 Dec 1994 21:56:09 -0500 Received: by interlock.ans.net id AA17736 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 6 Dec 1994 21:53:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 6 Dec 1994 21:53:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 6 Dec 1994 21:53:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Dec 1994 21:53:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Dec 1994 21:53:06 -0500 Message-Id: <9412070252.AA07664@snark.imsi.com> To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Tue, 06 Dec 1994 15:52:26 EST." <199412062056.AA28214@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 06 Dec 1994 21:52:27 -0500 From: "Perry E. Metzger" jwlowe@VNET.IBM.COM says: > The decision by IBM to dedicate US Patent > 5,148,479 is conditioned upon the adoption by the IETF of the IBM > proposal for modular key management. If this proposal is not so adopted, > IBM will not so dedicate this patent. IBM will, however, offer > nonexclusive licenses to requesting parties, under its normal > reasonable terms and conditions, including its then-current royalty > rates. Please advise me when a decision has been made on which > proposal will be included in the Internet standard. It might be helpful if IBM were to grant a blanket release of license for use of the patent in experimental implementations of the proposed protocol for purpose of examining the protocol for use as an IETF standard. IETF rules generally mandate that there be experience with multiple interoperable implementations before a protocol is accepted for standardization. Perry From ipsec-request@ans.net Wed Dec 7 15:32:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20751 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 10:40:32 -0500 Received: by interlock.ans.net id AA28847 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 10:32:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 7 Dec 1994 10:32:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 7 Dec 1994 10:32:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 10:32:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 10:32:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 10:32:44 -0500 Message-Id: <9412071532.AA39494@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Mon, 05 Dec 1994 16:17:52 EST." <199412052119.AA18451@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Dec 1994 10:32:33 -0500 From: " " I was travelling when the relevant discussion took place, so I can only thank John, Perry and the rest for handling and resolving this issue. Now that both SKIP and MKMP are license-free, we can look forward to a convergence on the best technical solution for Internet key management. We look forward to cooperating with the rest of the WG, and with specific proposals, to reach this goal as soon as possible. Best, Amir Herzberg p.s. John, I think you did not put the cc: list below correctly. > IBM has decided to dedicate the above-identified patent to the public. We > hope this will facilitate action by the IETF to adopt the best technical > solution to address problems associated with message traffic on the Internet. > .cc , perry willis amir gerry lois jeff porter allan jerry marshal From ipsec-request@ans.net Wed Dec 7 16:14:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20517 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 11:26:32 -0500 Received: by interlock.ans.net id AA23179 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 11:14:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 7 Dec 1994 11:14:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 7 Dec 1994 11:14:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 11:14:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 11:14:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 11:14:30 -0500 Message-Id: <9412071614.AA20562@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Steve Kent , ipsec@ans.net Subject: Re: Adopting a specific key management proposal In-Reply-To: Your message of "Tue, 06 Dec 1994 18:01:01 EST." <199412062304.AA26903@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Dec 1994 11:14:23 -0500 From: " " Steve and all, I agree we had too little discussion so far to be able to really `adopt' any scheme. We need more discussion and I'll really appreciate your input (this holds for all readers of this note). Even if the feedback is just `explain this to me', it is useful. If people are shy of asking basic questions on the mailing list, I'll do my best to respond to questions thrown my way. I'll still like us to converge, by merging some proposals and deciding on some basic questions such as the need for key refreshments, the need for a low-level mechanism which will unify public key, KDC and manual solutions, etc... Putting some stakes in the ground is necessary to focus the discussion and the efforts and get us going. Best, Amir From ipsec-request@ans.net Wed Dec 7 16:22:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20775 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 11:26:33 -0500 Received: by interlock.ans.net id AA14609 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 11:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 7 Dec 1994 11:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 7 Dec 1994 11:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 11:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 11:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 11:22:40 -0500 Message-Id: <9412071622.AA16755@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: perry@imsi.com Cc: jwlowe@VNET.IBM.COM, ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Tue, 06 Dec 1994 21:52:27 EST." <9412070252.AA07664@snark.imsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Dec 1994 11:22:19 -0500 From: " " Perry is right, thanks again. I've really slipped here. Sorry! I didn't notice we require license for experimental implementations... I'll do my best to fix this stupid mistake and I believe we'll get back soon with a statement that such experimental use is OK too. I"ll be happy to help any additional implementors. We want an interoperable, widely deployed solution. Best, Amir Herzberg Message from Perry: > > jwlowe@VNET.IBM.COM says: > > The decision by IBM to dedicate US Patent > > 5,148,479 is conditioned upon the adoption by the IETF of the IBM > > proposal for modular key management. If this proposal is not so adopted, > > IBM will not so dedicate this patent. IBM will, however, offer > > nonexclusive licenses to requesting parties, under its normal > > reasonable terms and conditions, including its then-current royalty > > rates. Please advise me when a decision has been made on which > > proposal will be included in the Internet standard. > > It might be helpful if IBM were to grant a blanket release of license > for use of the patent in experimental implementations of the proposed > protocol for purpose of examining the protocol for use as an IETF > standard. IETF rules generally mandate that there be experience with > multiple interoperable implementations before a protocol is accepted > for standardization. > > Perry From ipsec-request@ans.net Wed Dec 7 16:50:58 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12642 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 11:57:32 -0500 Received: by interlock.ans.net id AA03665 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 11:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 7 Dec 1994 11:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 7 Dec 1994 11:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 11:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 11:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 11:51:06 -0500 Date: Wed, 7 Dec 1994 11:50:58 -0500 From: amir@watson.ibm.com (A.Herzberg) Message-Id: <9412071650.AA39662@gimili.watson.ibm.com> To: ipsec@ans.net Subject: Clogging attacks on SKIP Hi Aziz and all, Here are some long over-due comments on SKIP. I'm trying to SKIP comments already made by Hugo and others. In order to be effective, in this note I'll write only two comments on one concern: the resistance of SKIP to clogging (denial of service) attacks. In the first possibility I'll continue with other comments. I am concerned about two possible clogging attacks against SKIP. First clogging attack: flooding receivers with junk packets. ============================================================ In SKIP, when a receiver $r$ receives packets from a new source $s$, then $r$ should get the public key for $s$, verify it, and then compute the master key $K_{rs}$. It is not specified what is to be done to the packet(s) in the meanwhile, but I'll assume they are cached rather than dropped unless the spec said otherwise. (Dropping the packets loses much of the SKIP-appeal). An attacker could abuse this mechanism by simply sending many packets with different source addresses. Poor $r$ would have to buffer all of these packets as well as engage in asking for master keys for all of them, verifying,... Q: doesn't this attack hold for all methods? A: Well, in any method the attacker can pretend to initiate the key exchange, that's true. But in SKIP packets are sent immediately following the key exchange, and there is no negotiation mechanism so $r$ cannot limit the number of concurrent key exchanges. Second clogging attack: re-sending old packets ----------------------------------------------- By resending an old packet between two legitimate computers $r$ and $s$ an attacker can cause $r$ and $s$ to constantly trash and replace the packet key $K_p$. This may be (only) detected by the sequencing mechanism (if used), but it is not clear what is the right response if any. This attack is less severe but could hurt performance. Well, have to run, more later... Let me mention both attacks could be dealt with, but I don't have a really wonderful solution so I'll rather see maybe Aziz will have a nicer one. Best, Amir From ipsec-request@ans.net Wed Dec 7 08:35:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05569 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 13:46:57 -0500 Received: by interlock.ans.net id AA12608 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 13:35:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 13:35:27 -0500 Message-Id: <199412071835.AA09020@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 13:35:27 -0500 Date: Wed, 7 Dec 94 13:35:31 EST From: "Juan A. Garay ((914) 784-6852)" To: karn@qualcomm.com Cc: ipsec@ans.net Subject: IBM US Patent #5,148,479 12/06/94 17:10:24 Reference: Your note of Tue, 6 Dec 1994 17:10:24 -0800 Phil, Steve and everybody: The requirements for IKMP from last year's meeting were made available by Dave Solo early this year (March?). There has been quite some activity and technical discussions on the rich variety of proposals and techniques, specially in the last few months. I hope it doesn't take too much longer to start making some basic decisions and recommendations. (Reaching agreement is a complex process - in fact, its complexity is proportional to the number of "Byzantine" players :-) ) Let's continue with the process, and move on! Regards, Juan *************** Referenced Note *************** Date: Tue, 6 Dec 1994 17:10:24 -0800 From: Phil Karn Message-Id: <199412070110.RAA07616@servo.qualcomm.com> To: kent@BBN.COM Cc: jwlowe@vnet.ibm.com, ipsec@ans.net In-Reply-To: <199412062304.AA26903@interlock.ans.net> (message from Steve Kent on Tue, 06 Dec 94 18:01:01 -0500) Subject: Re: IBM US Patent #5,148,479 >As a member of the IPSEC WG who is unable to attend this IETF meeting, >I'd like to suggest that adoption of any of the key management >proposals on the table at this IETF would be premature and, based on >the usual level of new attendees, inappropriate. It is nice that IBM You can relax, Steve. The chances of us adopting *anything* at this meeting are only slightly greater than the chances of the NSA voluntarily publishing the Skipjack algorithm and abandoning all export controls on cryptography. Phil From ipsec-request@ans.net Wed Dec 7 02:35:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04102 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 13:48:43 -0500 Received: by interlock.ans.net id AA28730 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 13:35:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 7 Dec 1994 13:35:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 13:35:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 13:35:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 13:35:15 -0500 Date: Wed, 7 Dec 94 10:35:02 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412071835.AA26391@miraj.Eng.Sun.COM> To: ipsec@ans.net, amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP >From ipsec-request@ans.net Wed Dec 7 09:05:57 1994 >First clogging attack: flooding receivers with junk packets. >============================================================ > >In SKIP, when a receiver $r$ receives packets from a new source $s$, >then $r$ should get the public key for $s$, verify it, and >then compute the master key $K_{rs}$. It is not specified >what is to be done to the packet(s) in the meanwhile, but >I'll assume they are cached rather than dropped unless the >spec said otherwise. (Dropping the packets loses much of the >SKIP-appeal). Our implementation maintains a (flow-controlled) cache, but I dont understand why dropping the packet loses the SKIP appeal? > >An attacker could abuse this mechanism by simply sending many >packets with different source addresses. Poor $r$ would have >to buffer all of these packets as well as engage in asking >for master keys for all of them, verifying,... > >Q: doesn't this attack hold for all methods? >A: Well, in any method the attacker can pretend to initiate >the key exchange, that's true. But in SKIP packets are sent >immediately following the key exchange, and there is no >negotiation mechanism so $r$ cannot limit the number of >concurrent key exchanges. This isn't true. The receiver always knows when it is computing a new DH derived key, and therefore can keep a count of the number of such concurrent activities it is willing to tolerate. Same as the case for interactive key management. >Second clogging attack: re-sending old packets >----------------------------------------------- > >By resending an old packet between two legitimate computers >$r$ and $s$ an attacker can cause $r$ and $s$ to constantly >trash and replace the packet key $K_p$. This may be (only) >detected by the sequencing mechanism (if used), but it is >not clear what is the right response if any. Two comments. First, a SKIP implementation doesn't have to trash the old key as soon as a new one appears. In fact this scenario can occur in benign ways as well, for example out of order packet arrival on key-change boundaries. The implementation can keep the old key based on some usage meter, so as long as *some* legitimate packets can come in (within the inactivity timeout) the legitimate key will not be trashed. Our implementation already does this. Second, playback of legitimate old packets can occur within a session for interactive key-management cases as well. As soon as an attacker has one legitimate packet, that packet can be repeatedly played back for the duration of the session. The only way to prevent this for the interactive case is to use sequencing as well. Ashar. From ipsec-request@ans.net Wed Dec 7 10:07:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04310 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 15:40:10 -0500 Received: by interlock.ans.net id AA13143 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 15:10:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 15:10:41 -0500 Message-Id: <199412072010.AA10061@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 15:10:41 -0500 Date: Wed, 7 Dec 94 15:07:59 EST From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: Evaluation of IBM Proposal It was not my intention to suggest that a license would be required in orderto experiment with the IBM modular key management protocol in connectionwithevaluation of it for adoption as the Internet/IETF standard. IBM acknow-ledges that such experimentation is necessary and appropriate and herebygives its permission for use of US Patent 5,148,479 in connection withsuch evaluation. Any other use of the patent prior to adoption of the IBMproposal as the Internet/IETF standard is not permitted. From ipsec-request@ans.net Wed Dec 7 20:08:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37824 (5.65c/IDA-1.4.4 for ); Wed, 7 Dec 1994 20:08:40 -0500 Received: by interlock.ans.net id AA16741 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 7 Dec 1994 19:55:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 7 Dec 1994 19:55:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 7 Dec 1994 19:55:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Dec 1994 19:55:04 -0500 Date: Wed, 07 Dec 94 16:35:56 From: "Housley, Russ" Encoding: 3723 Text Message-Id: <9411077868.AA786846956@spysouth.spyrus.com> To: Ashar.Aziz@eng.sun.com Cc: ipsec@ans.net Subject: Re: Modular approach to key management Ashar: I will be making a presentation at the Key Management IPSEC sesion at the IETF. I will try to address each of your concerns in that presentation. Thanks for the detailed list of me to focus on. Russ ______________________________ Reply Separator _________________________________ Subject: Re: Modular approach to key management Author: Ashar.Aziz@Eng.Sun.COM (Ashar Aziz) Date: 11/29/94 5:43 PM >From ipsec-request@ans.net Mon Nov 21 15:33:39 1994 >My suggestion is that we adopt the IEEE work, then select particular algorithms >for use in the Internet. Of course, the IPSEC WG would also have to define the >attributes that are part of security association negotiation. These attributes >have to be defined regardless of the approach taken, so this is neither a plus >nor a minus to the IEEE 802.10c approach. I am afraid that I, for one, am not amenable to adopting IEEE 802.10c as something suitable for use with IPSP, for a number of reasons which I'll describe below. (This is based on the IEEE 802.10c draft that was available sometime before the last IETF meeting so if things have substantially changed since then, I am not aware of that.) o IEEE 802.10c is quite a complex document. In my view, unnecessarily so. If this groups decides to adopt it, it needs to be much clearer and easier to understand than it currently is. o IEEE 802.10c utilizes OSI upper layer services and concepts like Application Entity Titles etc. I dont think that the Internet community needs to buy into (and implement) the OSI upper layer services, with its associated complexities, just for the sake of IP layer key-management. Especially since much simpler alternatives already exist. o IEEE 802.10c multicast design uses a single key obtained from a Multicast KDC. Changing this key requires obtaining a new key from the Multicast KDC. This may work for small multicast groups as may arise on a single 802.x subnet (which is what 802.10 is intended for) but this will not scale to the number of nodes possible in an Internet wide multicast group. o Using the same key for all members of a multicast group eliminates using some of the highest performance stream ciphers commercially available for traffic encryption purposes. This is a major disadvantage for high-performance multicast applications like encrypted video. o The fact that IEEE 802.10 was designed for subnets (and not internets, for which scalability to a large number of nodes is criticial) shows in places like how to determine which application entity to use in order to negotiate session keys. In one of the appendices, it states that each node will have a local table of mappings between 802.x MAC addresses and AE-Titles. This might work for a single subnet. This will clearly not work for the Internet, where it is not feasible to have a local table of mappings between IP addresses and AE-Titles for the entire Internet. >In my opinion, IEEE 802.10c decreases the time to market. Protocol development >can take alot of time, especially in an open environment like the IEEE and >the IETF. Therefore, take advantage of the investement that has already >been made by the IEEE 802.10 participants, and take a working solution to >the Internet sooner. I think that IEEE 802.10c is the wrong solution for the Internet. It will substantially increase time to market because of the complexities inherent a complete OSI upper layer implementation (truly unnecessary for the task at hand). It also does not adequately address the needs of the Internet, because of various subnet oriented design decisions. Regards, Ashar. From ipsec-request@ans.net Thu Dec 8 21:48:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16307 (5.65c/IDA-1.4.4 for ); Thu, 8 Dec 1994 17:02:10 -0500 Received: by interlock.ans.net id AA15429 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 8 Dec 1994 16:48:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 8 Dec 1994 16:48:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 8 Dec 1994 16:48:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 8 Dec 1994 16:48:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 8 Dec 1994 16:48:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 8 Dec 1994 16:48:53 -0500 Message-Id: <9412082148.AA27910@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net, amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP In-Reply-To: Your message of "Wed, 07 Dec 1994 10:35:02 PST." <9412071835.AA26391@miraj.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Dec 1994 16:48:38 -0500 From: " " Aziz and others, > >An attacker could abuse this mechanism by simply sending many > >packets with different source addresses. Poor $r$ would have > >to buffer all of these packets as well as engage in asking > >for master keys for all of them, verifying,... > > > >Q: doesn't this attack hold for all methods? > >A: Well, in any method the attacker can pretend to initiate > >the key exchange, that's true. But in SKIP packets are sent > >immediately following the key exchange, and there is no > >negotiation mechanism so $r$ cannot limit the number of > >concurrent key exchanges. > > This isn't true. The receiver always knows when it > is computing a new DH derived key, and therefore > can keep a count of the number of such concurrent > activities it is willing to tolerate. Same as > the case for interactive key management. Of course the receiver can count number of key exchanges it engages in and discard any more... You missed my point rather than finding me untrue :-) The problem is that if the receiver is deciding it is too busy, the sender is unaware of this, and continues sending messages. If the receiver is just dropping all of them, this is as severe a denial of service as any you'll get. This is not the case with the interactive scheme, where the sender is aware that the receiver has not agreed to a key and therefore would not spend resources sending the packets. Also, with the interactive schemes, esp. Photuris, the overhead for the receiver for checking the incoming request is much much less than in SKIP. And... > Second, playback of legitimate old packets can occur within > a session for interactive key-management cases as well. > As soon as an attacker has one legitimate packet, that > packet can be repeatedly played back for the duration of the > session. The only way to prevent this for the interactive > case is to use sequencing as well. > Agreed, however in the interactive scheme there is no demage except the replay of the packet. In SKIP, this makes caching more keys and reduces efficiency. Best, Amir From ipsec-request@ans.net Fri Dec 9 06:29:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14582 (5.65c/IDA-1.4.4 for ); Fri, 9 Dec 1994 11:40:06 -0500 Received: by interlock.ans.net id AA27313 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 9 Dec 1994 11:29:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 9 Dec 1994 11:29:43 -0500 Message-Id: <199412091629.AA05037@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 9 Dec 1994 11:29:43 -0500 Date: Fri, 9 Dec 94 11:29:48 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Diffie-Hellman Dear IPSEC-ers, (see questions at the bottom) It seems that if there was something agreed about key management in this IETF is that we require perfect forward secrecy (in particular, the exposure of two parties private keys should not expose past or future traffic between these two parties to passive attacks). The practical significance of this decision is that we are going to build the key exchange mechanism based on Diffie-Hellman. Since I believe that nobody wants to leave this key exchange vulnerable to active (man-in-the-middle) attacks it actually means that we are going to implement authenticated DH exchange. This is a crucial decision of this group. It means that we want to provide very high security (which is great considering that key management is the foundation of any security mechanism) and we are willing to pay the computational price. The later involves six long exponentiations, at least for parties that exchange their first key. Some careful optimizations are possible (e.g., some of the exponentiations performed off-line) but the overall computation cost is not negligible. It would be nice to close this issue over this list such that we can say that this is the IPSEC group DECISION and not just the opinion of several IETF attendees. The questions are: 1) is there any opposition to this agreement? For example, well-identified scenarios where this is infeasible? 2) if you have experimental data on the performance of DH exponentiation please share it with the group. It may help tune the protocol decisions. PLEASE SPECIFY: h/w and s/w platform, length of modulus (and length of exponent if different than modulus size) and, if possible, the software implementation used (RSAREF, PGP, etc.). Please give numbers for a SINGLE exponentiation (or otherwise specify what are the numbers for) (I heard, from people in the IETF, performance numbers that on similar platforms varied up to 10 times!) Thanks, Hugo From ipsec-request@ans.net Fri Dec 9 20:14:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27298 (5.65c/IDA-1.4.4 for ); Fri, 9 Dec 1994 16:27:26 -0500 Received: by interlock.ans.net id AA24437 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 9 Dec 1994 16:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 9 Dec 1994 16:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 9 Dec 1994 16:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 9 Dec 1994 16:17:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 9 Dec 1994 16:17:50 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 9 Dec 1994 16:17:50 -0500 Date: 9 Dec 94 14:14:00 -0600 To: hugo@watson.ibm.com, ipsec@ans.net Subject: Re: Diffie-Hellman Message-Id: Hugo, The requirement for "perfect forward secrecy" was discussed as one of many criteria for IKMP. There was no agreement on the new criteria identified at the meeting. Please do not push so hard on just one aspect of the overall design before we prioritize the criteria. Most of the proposals at this week's meeting claimed support for perfect forward secrecy so this is not a discriminating criteria. By the way, what did the "G" for good mean in our comparison matrix for your MKMP proposal? I also do not agree with your conclusion that perfect forward secrecy implies a requirement for Diffie-Hellman. Not being a cryptographer by trade it would be useful if someone would provide a better description of this requirement and it's implications. A Diffie-Hellman (D-H) key exchange is a leading contender for use as a baseline algorithm within IKMP given the number of proposals that contained D- H. Performance of D-H and any other proposed key exchange needs to be examined as part of our groups evaluation of techniques. Paul _______________________________________________________________________________ Subject: Diffie-Hellman Author: hugo@watson.ibm.com@INTERNET Date: 12/9/94 10:29 AM Dear IPSEC-ers, (see questions at the bottom) It seems that if there was something agreed about key management in this IETF is that we require perfect forward secrecy (in particular, the exposure of two parties private keys should not expose past or future traffic between these two parties to passive attacks). The practical significance of this decision is that we are going to build the key exchange mechanism based on Diffie-Hellman. Since I believe that nobody wants to leave this key exchange vulnerable to active (man-in-the-middle) attacks it actually means that we are going to implement authenticated DH exchange. This is a crucial decision of this group. It means that we want to provide very high security (which is great considering that key management is the foundation of any security mechanism) and we are willing to pay the computational price. The later involves six long exponentiations, at least for parties that exchange their first key. Some careful optimizations are possible (e.g., some of the exponentiations performed off-line) but the overall computation cost is not negligible. It would be nice to close this issue over this list such that we can say that this is the IPSEC group DECISION and not just the opinion of several IETF attendees. The questions are: 1) is there any opposition to this agreement? For example, well-identified scenarios where this is infeasible? 2) if you have experimental data on the performance of DH exponentiation please share it with the group. It may help tune the protocol decisions. PLEASE SPECIFY: h/w and s/w platform, length of modulus (and length of exponent if different than modulus size) and, if possible, the software implementation used (RSAREF, PGP, etc.). Please give numbers for a SINGLE exponentiation (or otherwise specify what are the numbers for) (I heard, from people in the IETF, performance numbers that on similar platforms varied up to 10 times!) Thanks, Hugo From ipsec-request@ans.net Fri Dec 9 13:02:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15925 (5.65c/IDA-1.4.4 for ); Fri, 9 Dec 1994 18:07:22 -0500 Received: by interlock.ans.net id AA28410 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 9 Dec 1994 18:02:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 9 Dec 1994 18:02:38 -0500 Message-Id: <199412092302.AA22262@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 9 Dec 1994 18:02:38 -0500 Date: Fri, 9 Dec 94 18:02:43 EST From: hugo@watson.ibm.com To: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net Cc: Ashar.Aziz@eng.sun.com Subject: Diffie-Hellman Ref: Your note of 9 Dec 94 14:14:00 -0600 (attached) Paul Lambert says: >> Hugo, >> >> The requirement for "perfect forward secrecy" was discussed as one of many >> criteria for IKMP. There was no agreement on the new criteria identified at >> the meeting. Please do not push so hard on just one aspect of the overall >> design before we prioritize the criteria. Most of the proposals at this week's I am not pushing but just try to make progress in the evaluation of these criteria. The particular criterium of perfect forward secrecy is a fundamental one since, in my opinion, it has the practical consequence of requiring Diffie-Hellman (see below). I see the performance issue as the only possible obstacle to use of DH. Therefore, in order to (eventually, and the sooner the better) decide on exact requirements and evaluation criteria the exact cost of DH needs to be well understood. That was the motivation of my note. I would like you, as the chair of this group, to explicitely support the request for data as I did in my note. It will not push anybody, but help us make progress. >> meeting claimed support for perfect forward secrecy so this is not a >> discriminating criteria. By the way, what did the "G" for good mean in our >> comparison matrix for your MKMP proposal? If the criterium is "forward secrecy" then you can achieve it with different levels. 'Perfect" means that even the exposure of the private keys of BOTH parties will NOT reveal the exchanged keys. "Good" means that the exposure of ONLY ONE party's private key will NOT reveal the exchanged key but the exposure of both private keys will reveal it. NO forward secrecy at all means that with one party's private key exposed then all the keys exchanged with that party are revealed. The proposals based on DH have PERFECT fwd secrecy, MKMP has GOOD fwd secrecy (here is where the 'G' comes from), and the original SKIP (w/o DH exchange enhancements) has NO fwd secrecy. BTW, as one of the authors of MKMP, the only reason we proposed good and not perfect fwd secrecy was the feeling that authenticated DH can be too expensive computationally as the universal algorithm for Internet, but if people believe it is affordable (without introducing dangerous shortcuts) we are fervent supporters of it. Whether it is affordable or not, was the question that motivated my note. >> >> >> I also do not agree with your conclusion that perfect forward secrecy implies a >> requirement for Diffie-Hellman. Not being a cryptographer by trade it would be >> useful if someone would provide a better description of this requirement and >> it's implications. The concept of perfect forward secrecy was introduced in a paper by Diffie, Van OOrschot and Wiener: W. Diffie, M. Wiener, P. Oorschot, "Authentication and Authenticated Key Exchanges.", in Designs Codes and Cryptography, Vol 2, 107-125 (1992) (Kluwer Academic Publishers) In principle it can be more general than my above "definition" but I believe that in our context this is what we mean (i.e. exposure of private keys does not imply exposure of exchanged keys - except for active attacks after the exposure). I do not know of any practical, well established technique to do this except for DH (and its variants, e.g. over elliptic curves). There can be, in principle, more efficient algorithms to achieve perfect fwd secrecy but to the best of my knowledge there are no such today. (BTW, interested readers can check the Shamir's 3-pass protocol in Schneier pg 376 or in Simmons pg. 33). (Ashar, may be you can check with Diffie on this.) >> >> A Diffie-Hellman (D-H) key exchange is a leading contender for use as a >> baseline algorithm within IKMP given the number of proposals that contained D- >> H. Performance of D-H and any other proposed key exchange needs to be examined >> as part of our groups evaluation of techniques. absolutely agreed! >> >> Paul >> From ipsec-request@ans.net Mon Dec 12 14:47:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23954 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 14:47:37 -0500 Received: by interlock.ans.net id AA34095 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 14:33:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 14:33:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 14:33:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 14:33:53 -0500 Date: Mon, 12 Dec 94 11:02:26 From: "Housley, Russ" Encoding: 191 Text Message-Id: <9411127872.AA787258946@spysouth.spyrus.com> To: ipsec@ans.net, sils@arc.nasa.gov Subject: SILS KMP Draft 6 on-line All: SILS KMP Draft 6 is available for anonymous FTP from atlas.arc.nasa.gov. It is made up of two files: /pub/sils/kmpd6.ps1 /pub/sils/kmpd6.ps2 Enjoy, Russ From ipsec-request@ans.net Mon Dec 12 19:57:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27289 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 15:08:44 -0500 Received: by interlock.ans.net id AA24287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 12 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 14:57:45 -0500 Message-Id: <9412121957.AA21591@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: hugo@watson.ibm.com Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Fri, 09 Dec 1994 18:02:43 EST." <199412092302.AA22262@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Dec 1994 14:57:34 -0500 From: " " I agree with Hugo. The requirement of `perfect forward secrecy' is non trivial and does not come for free. However, since some think it is a must, then it would be useful to decide it is a requirement - unless we have some (substantial) objections. After all, we all agree that it improves security. If we can reach such agreement, we would be making some progress. As usual, it is up to the subscribed members of the mailing list to let their voices be heard in order for us to make progress - and please, supporting is as important as objecting. Also.. Hugo says: > BTW, as one of the authors of MKMP, the only reason we proposed good and not > perfect fwd secrecy was the feeling that authenticated DH can be too expensive > computationally as the universal algorithm for Internet, but if people > believe it is affordable (without introducing dangerous shortcuts) > we are fervent supporters of it. As another author of IKMP, I feel the same. Best, Amir From ipsec-request@ans.net Mon Dec 12 20:38:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24722 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 15:49:47 -0500 Received: by interlock.ans.net id AA28891 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 15:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 15:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 15:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 15:38:21 -0500 Date: Mon, 12 Dec 1994 13:38:13 -0700 From: Hilarie Orman Message-Id: <199412122038.NAA03375@umbra.CS.Arizona.EDU> To: amir@watson.ibm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9412121957.AA21591@gimili.watson.ibm.com> Subject: Re: Diffie-Hellman (note by Hugo) With regard to the computational cost of DH, I think the use of elliptic curve systems should be considered. Our preliminary indications are that they can provide the same security with much less computation. The final word on the ratio will depend on having independent (and sophisticated) implementations on different platforms, but it is possible that the time for the computation can be brought down to something palatable. From ipsec-request@ans.net Mon Dec 12 21:16:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26453 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 16:19:48 -0500 Received: by interlock.ans.net id AA26164 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 16:10:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 16:10:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 16:10:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 16:10:44 -0500 Message-Id: <9412122116.AA04506@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Dec 1994 15:16:15 -0600 To: " " , hugo@watson.ibm.com From: hughes@hughes.network.com (James P Hughes) Subject: Re: Diffie-Hellman (note by Hugo) Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net At 2:57pm 12/12/94 -0500, wrote: >I agree with Hugo. The requirement of `perfect forward secrecy' is non >trivial and does not come for free. I agree that it is not free, but in my experience, it is not impossible to implement now and will be less costly to do so in the future. 2 cases illustrate this, I hope, without causing lotsa flames. (Be polite.) Ignoring the issue of `perfect forward secrecy', I would like to talk about D-H and RSA computing requirements. 1, Computer power is exceeds 10s of MIPs in most platforms (including routers) and is doubling every 18 months. RSA and D-H should be executable in the order of seconds in a background mode. Since creation time of SAIDs can be correlated to the length that a SAID exists, then the cost of creation can be amortized over the SAID lifetime and the delay is present only when the first connection exists. 2. -Hardware- that executes large modular arithmetic exists on security processor chips (<$20), smart cards (in the $30 to $50 range) and PCMCIA cards ($100 to $200). Each of these engines are as fast as the 25MIP RISC processors today. 3. Over the lifetime of a standard (10 years or so), something that is marginal because it is processor intensive now, and will be not at all too expensive in the future. This is better than a standard that is just fine now and not enough (compared to feasable other algorithms) in the future. In summary, I would argue that D-H can be implemented on existing platforms today and that there is no good -long term reason- not to use it. (Also, there is no reason that there can not be more than 1 key management style.) Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Dec 12 22:15:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38794 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 17:26:51 -0500 Received: by interlock.ans.net id AA25424 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 17:18:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 17:18:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 17:18:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 17:18:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 17:18:43 -0500 Message-Id: <9412122215.AA11179@snark.imsi.com> To: hughes@hughes.network.com (James P Hughes) Cc: ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Mon, 12 Dec 1994 15:16:15 CST." <9412122116.AA04506@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 12 Dec 1994 17:15:09 -0500 From: "Perry E. Metzger" James P Hughes says: > 3. Over the lifetime of a standard (10 years or so), something that is > marginal because it is processor intensive now, and will be not at all too > expensive in the future. This is better than a standard that is just fine > now and not enough (compared to feasable other algorithms) in the future. I could not agree more. What seems slow now will seem trivial in five years. Perry From ipsec-request@ans.net Mon Dec 12 12:23:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16802 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 17:28:42 -0500 Received: by interlock.ans.net id AA30344 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 17:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 12 Dec 1994 17:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 17:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 17:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 17:23:14 -0500 Date: Mon, 12 Dec 94 17:23:05 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9412122223.AA04134@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 17:23:14 -0500 To: ipsec@ans.net Subject: Eliptic Curves Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Just an aside: People have been mentioning eliptic curve analogues of D-H. I also think we might want to pay some added attention to the eliptic curve variants on D-H given the speed improvement they provide, although there is a bit of added implementation complexity. Perry From ipsec-request@ans.net Mon Dec 12 22:36:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27491 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 17:44:20 -0500 Received: by interlock.ans.net id AA26180 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 17:36:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 12 Dec 1994 17:36:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 17:36:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 17:36:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 17:36:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 17:36:47 -0500 From: uri@watson.ibm.com Message-Id: <9412122236.AA22015@buoy.watson.ibm.com> Subject: Re: Diffie-Hellman (note by Hugo) To: perry@imsi.com Date: Mon, 12 Dec 1994 17:36:40 -0500 (EST) Cc: hughes@hughes.network.com, ipsec@ans.net In-Reply-To: <9412122215.AA11179@snark.imsi.com> from "Perry E. Metzger" at Dec 12, 94 05:15:09 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 972 Perry E. Metzger says: > James P Hughes says: > > 3. Over the lifetime of a standard (10 years or so), something that is > > marginal because it is processor intensive now, and will be not at all too > > expensive in the future. This is better than a standard that is just fine > > now and not enough (compared to feasable other algorithms) in the future. > I could not agree more. What seems slow now will seem trivial in five > years. Come on, people! WHo tells you there will be IP 10 years from now? How about 5 years? Maybe we all will go ATM? Let's get back to the point of getting secure IP, and not on CPUs available after 10 years, but TODAY. Should I spell it, now? (:-) As a hint: I do suspect any standard we happen to agree upon will be absolutely useless after 10 years. [Of course unless we keep going the current pace, - then 10 years sounds quite reasonable milestone :-] -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Mon Dec 12 22:56:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20790 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 18:03:29 -0500 Received: by interlock.ans.net id AA11612 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 17:56:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 17:56:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 17:56:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 17:56:39 -0500 Date: Mon, 12 Dec 1994 15:56:25 -0700 From: Hilarie Orman Message-Id: <199412122256.PAA08531@umbra.CS.Arizona.EDU> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9412122215.AA11179@snark.imsi.com> Subject: Re: Diffie-Hellman (note by Hugo) > James P Hughes says: > > 3. Over the lifetime of a standard (10 years or so), something that is > > marginal because it is processor intensive now, and will be not at all too > > expensive in the future. This is better than a standard that is just fine > > now and not enough (compared to feasable other algorithms) in the future. > I could not agree more. What seems slow now will seem trivial in five > years. One might note a corollary that what seems secure now will probably seem less secure in 5 years. There's probably a crypto aphorism about computational cost: no pain, no security. Encrypt 'til it hurts and always leave room for larger numbers. From ipsec-request@ans.net Mon Dec 12 13:29:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06426 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 18:40:15 -0500 Received: by interlock.ans.net id AA27440 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 18:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 18:33:42 -0500 Message-Id: <199412122333.AA27436@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 18:33:42 -0500 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Eliptic Curves Date: Mon, 12 Dec 94 18:29:31 EST Just an aside: People have been mentioning eliptic curve analogues of D-H. I also think we might want to pay some added attention to the eliptic curve variants on D-H given the speed improvement they provide, although there is a bit of added implementation complexity. There may also be added patent complexity -- didn't NeXT get a patent on their elliptic curve stuff? From ipsec-request@ans.net Mon Dec 12 08:00:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20813 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 19:05:18 -0500 Received: by interlock.ans.net id AA33754 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 18:59:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 18:59:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 18:59:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 18:59:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 18:59:16 -0500 Date: Mon, 12 Dec 94 16:00:02 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412130000.AA28679@miraj.Eng.Sun.COM> To: hugo@watson.ibm.com, amir@watson.ibm.com Subject: Re: Diffie-Hellman (note by Hugo) Cc: ipsec@ans.net >From ipsec-request@ans.net Mon Dec 12 12:17:05 1994 >I agree with Hugo. The requirement of `perfect forward secrecy' is non >trivial and does not come for free. However, since some think it is a must, >then it would be useful to decide it is a requirement - unless we have some >(substantial) objections. After all, we all agree that it improves security. >If we can reach such agreement, we would be making some progress. > >As usual, it is up to the subscribed members of the mailing list to let their >voices be heard in order for us to make progress - and please, supporting >is as important as objecting. Let me both support and object. I support perfect forward secrecy for situations where secrecy is essential. I dont support perfect forward secrecy where authentication, and not secrecy, is the prime consideration. Like you said, it isn't free. If you dont want it, dont need it, you shouldn't have to pay for it. That is why I presented perfect forward secrecy as an option in my SKIP talk. There are many situations in the context of Internet applications where authentication (and not secrecy) is the prime issue. Ashar. From ipsec-request@ans.net Mon Dec 12 08:35:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16201 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 19:42:22 -0500 Received: by interlock.ans.net id AA15273 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 19:38:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 19:38:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 19:38:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 19:38:11 -0500 Date: Mon, 12 Dec 94 16:35:35 PST From: "Oliff, Phillip" Message-Id: <9411127872.AA787279440@stdntmail.lmu.edu> To: IPSEC@ans.net, hugo@watson.ibm.com Return-Receipt-To: poliff@stdntmail.lmu.edu Subject: Re: Diffie-Hellman 12 December 1994 I am a non-meeting attending member of the IETF IPSEC working group. I am personally in favor of experimenting with new Internet security protocols. My main question/quibble is that my network uses Lotus CC:MAIL. I wonder how this protocol is implemented. Is it possible to run this routine in MS-DOS/MS-Windows? We have limited use to a UNIX box and it is not connected with the real world. Regards, Phill ******************************************************************************* * PHILLIP CHARLES OLIFF | 1734 WARNALL AVENUE LL + * * ALUMNI, CLASS OF 1994 | LOS ANGELES, CA LL MM MM * * DEPARTMENT OF PSYCHOLOGY | 90024-5339 LLLLLMM MMUU UU * * LOYOLA MARYMOUNT UNIVERSITY | POLIFF@STDNTMAIL.LMU.EDU MM M MUU UU * * LOS ANGELES, CALIFORNIA 90045-2699 | Phone: (310) 915-3983 UUUUU * ******************************************************************************* ______________________________ Reply Separator _________________________________ Subject: Diffie-Hellman Author: hugo@watson.ibm.com at STDNTMAIL-LMU Date: 12/9/94 11:29 AM Dear IPSEC-ers, (see questions at the bottom) It seems that if there was something agreed about key management in this IETF is that we require perfect forward secrecy (in particular, the exposure of two parties private keys should not expose past or future traffic between these two parties to passive attacks). The practical significance of this decision is that we are going to build the key exchange mechanism based on Diffie-Hellman. Since I believe that nobody wants to leave this key exchange vulnerable to active (man-in-the-middle) attacks it actually means that we are going to implement authenticated DH exchange. This is a crucial decision of this group. It means that we want to provide very high security (which is great considering that key management is the foundation of any security mechanism) and we are willing to pay the computational price. The later involves six long exponentiations, at least for parties that exchange their first key. Some careful optimizations are possible (e.g., some of the exponentiations performed off-line) but the overall computation cost is not negligible. It would be nice to close this issue over this list such that we can say that this is the IPSEC group DECISION and not just the opinion of several IETF attendees. The questions are: 1) is there any opposition to this agreement? For example, well-identified scenarios where this is infeasible? 2) if you have experimental data on the performance of DH exponentiation please share it with the group. It may help tune the protocol decisions. PLEASE SPECIFY: h/w and s/w platform, length of modulus (and length of exponent if different than modulus size) and, if possible, the software implementation used (RSAREF, PGP, etc.). Please give numbers for a SINGLE exponentiation (or otherwise specify what are the numbers for) (I heard, from people in the IETF, performance numbers that on similar platforms varied up to 10 times!) Thanks, Hugo From ipsec-request@ans.net Mon Dec 12 14:40:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16206 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 19:43:44 -0500 Received: by interlock.ans.net id AA29908 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 19:40:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 12 Dec 1994 19:40:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 12 Dec 1994 19:40:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 19:40:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 19:40:39 -0500 Date: Mon, 12 Dec 94 19:40:32 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9412130040.AA04772@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 19:40:39 -0500 To: ipsec@ans.net Subject: key management Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission I believe that many of the given key management protocols are still deficient in so far as 1) They lack a specified method for managing separate keys for separate users; this is an articulated requirement for the IPv6 case according to the IPng Directorate. 2) All but SKIP lack clearly articulated key certificates (and SKIP's seem to be X.509 based, which is probably non-optimal) 3) All seem to lack hooks for a user level authentication system, and this deficiency makes producing user level applications difficult to write. For contrast on some, I point everyone at Kerberos. Kerberos is NOT, in my opinion, a good enough key management system for the internet -- it does not scale particularly well and uses only private keys. However, Kerberos provides name management and user level authentication as well as key management; with Kerberos in place, I can build applications like a secure telnet or a secure NFS service, which I cannot do with ANY of the thus far articulated key management systems. I would argue that any system that is not more functional than Kerberos (in the sense of providing all that kerberos does but with public keys and scalability) is not sufficient for our purposes. The key management system need not itself provide all the Kerberos functionality, but it must have clearly obvious hooks for handling naming and user level keying. This is not to say that any of the current proposals is incapable of being extended to handle this, but thus far I haven't seen the extensions, as it were. (I'm also a bit concerned that SKIP would need some alteration to handle user level keying.) Perry From ipsec-request@ans.net Tue Dec 13 00:44:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06492 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 19:47:26 -0500 Received: by interlock.ans.net id AA11267 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 19:44:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 19:44:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 19:44:36 -0500 Date: Mon, 12 Dec 1994 19:44:18 -0500 From: rubin@faline.bellcore.com (Avi Rubin) Message-Id: <199412130044.TAA21506@faline.bellcore.com> To: ho@cs.arizona.edu Subject: Re: Diffie-Hellman (note by Hugo) Cc: ipsec@ans.net, yacov@faline.bellcore.com Has anyone got any numbers on the actual computational cost of perfect forward secrecy so that we can make a more educated decision? Has anyone considered Yacobi's scheme that he published in crypto a couple of years ago? From ipsec-request@ans.net Tue Dec 13 01:07:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27472 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 20:13:04 -0500 Received: by interlock.ans.net id AA11648 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 20:08:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 20:08:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 20:08:12 -0500 Date: Mon, 12 Dec 1994 20:07:17 -0500 From: rubin@faline.bellcore.com (Avi Rubin) Message-Id: <199412130107.UAA23183@faline.bellcore.com> To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com, hugo@watson.ibm.com Subject: Re: Diffie-Hellman (note by Hugo) Cc: ipsec@ans.net Ashar, I agree that sometimes authentication is needed, and secrecy is not important, but I'm wondering how this is determined at the IP layer. When is the choice made between authentication and secrecy? Is it your idea that the applications specify this? Does this destroy transparency across layers? Avi From ipsec-request@ans.net Tue Dec 13 01:26:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34750 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 20:30:05 -0500 Received: by interlock.ans.net id AA22564 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 20:27:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 20:27:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 20:27:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 20:27:16 -0500 Message-Id: <9412130126.AA01402@skidrow.tay.dec.com> To: ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Mon, 12 Dec 94 16:00:02 PST." <9412130000.AA28679@miraj.Eng.Sun.COM> Date: Mon, 12 Dec 94 20:26:41 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Let me second Ashar. Different users need different levels of security. For those who ask for confidentiality, then I think we need to provide strong confidentiality with perfect forward secrecy. For those who ask for just authentication, we need to provide strong authentication but secrecy of any sort is not a question. And there may be many cases where only "cookie security", as included in Phil Karn's proposal, is needed. If I am on a relatively trusted local net I might be satisfied for some purposes (such as an ICMP redirect) merely to be usre it originated locally. I could establish that be merely requiring it to have a cookie without any confidentiality or further authentication. Donald From: Ashar.Aziz@eng.sun.com (Ashar Aziz) To: hugo@watson.ibm.com, amir@watson.ibm.com Cc: ipsec@ans.net > >>From ipsec-request@ans.net Mon Dec 12 12:17:05 1994 >>I agree with Hugo. The requirement of `perfect forward secrecy' is non >>trivial and does not come for free. However, since some think it is a must, >>then it would be useful to decide it is a requirement - unless we have some >>(substantial) objections. After all, we all agree that it improves security. >>If we can reach such agreement, we would be making some progress. >> >>As usual, it is up to the subscribed members of the mailing list to let their >>voices be heard in order for us to make progress - and please, supporting >>is as important as objecting. > >Let me both support and object. I support perfect forward secrecy >for situations where secrecy is essential. > >I dont support perfect forward secrecy where authentication, and >not secrecy, is the prime consideration. Like you said, it isn't >free. If you dont want it, dont need it, you shouldn't have to pay >for it. That is why I presented perfect forward secrecy as an >option in my SKIP talk. There are many situations in the context of >Internet applications where authentication (and not secrecy) is the >prime issue. > >Ashar. From ipsec-request@ans.net Tue Dec 13 02:10:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20809 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 21:13:35 -0500 Received: by interlock.ans.net id AA32212 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 21:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 21:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 21:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 21:10:55 -0500 Message-Id: <9412130210.AA03509@skidrow.tay.dec.com> To: ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Mon, 12 Dec 94 20:07:17 EST." <199412130107.UAA23183@faline.bellcore.com> Date: Mon, 12 Dec 94 21:10:43 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I think that you want the "application" and the system administrator to both be able to specify the minimum security that is acceptable and then go with the max of their requirements in each security dimension. But I don't know that the protocol for SAID set up needs to be concerned with how the security requirments of each party is established. We need things like an ICMP reject for "inadequate" security that states what security services would be required for the packet to have been accepted, etc. Donald PS: Keeping in mind that you may need multiple SAIDs even if they all provide the same services and use the same algorithms because they are authenticated with different user identities at one or both ends. From: rubin@faline.bellcore.com (Avi Rubin) To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com, hugo@watson.ibm.com Cc: ipsec@ans.net >Ashar, > >I agree that sometimes authentication is needed, and secrecy >is not important, but I'm wondering how this is determined at >the IP layer. When is the choice made between authentication >and secrecy? Is it your idea that the applications specify >this? Does this destroy transparency across layers? > >Avi From ipsec-request@ans.net Tue Dec 13 02:10:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16224 (5.65c/IDA-1.4.4 for ); Mon, 12 Dec 1994 21:15:11 -0500 Received: by interlock.ans.net id AA28096 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 12 Dec 1994 21:10:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 12 Dec 1994 21:10:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 12 Dec 1994 21:10:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 12 Dec 1994 21:10:22 -0500 Date: Mon, 12 Dec 1994 19:10:13 -0700 From: Hilarie Orman Message-Id: <199412130210.TAA15415@umbra.CS.Arizona.EDU> To: ipsec@ans.net Subject: architecture My understanding of the most general architecture is that it goes something like this: application client ... | \ \2 3| 1\ \ (SAID returned) | \ \ | \ \ (said) (set security requirements description: service, | | remote communicant id, alg (key alg)) | | . . . . . . ipsec key mgmt protocol (lookup . SAID- . key . assoc) . . . . . network In step 1, the application (or something near it) defines some security requirements (authentication, privacy, etc.) or perhaps an algorithm. The key negotiation is either specified as well, or it is implied by the algorithm. A user id or other selection criteria might be used to lookup appropriate originator public keys if needed. Anyway, all the info needed for setting/getting the service key is worked out by the key mgmt and associated with the SAID, which is returned to the caller in step 2. The SAID is given to the transport layers in step 3 as a sort of address extension when opening a connection. IPSEC then uses the SAID to get the key and run the crypto indicated by the SAID. Incoming messages are decrypted/authenticated/validated/whitewashed based on the SAID. As shown, this feels like a violation of layering to purists, and it seems to me to be rational for some sites to have steps 1 and 2 performed by ipsec itself, using only the local and remote host addresses for key related functions. I know that there is disagreement on this point, which I respect, but it doesn't seem to me that the ipsec or key mgmt protocols should try to enforce any particular architecture or policy ... they should be minimal and flexible. From ipsec-request@ans.net Tue Dec 13 14:49:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35330 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 09:55:05 -0500 Received: by interlock.ans.net id AA04430 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 09:50:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 13 Dec 1994 09:50:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 09:50:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 09:50:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 09:50:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 09:50:05 -0500 Message-Id: <9412131450.AA21547@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Hilarie Orman Cc: perry@imsi.com, ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Mon, 12 Dec 1994 15:56:25 MST." <199412122256.PAA08531@umbra.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 09:49:59 -0500 From: " " Hilarie says: > > James P Hughes says: > > > 3. Over the lifetime of a standard (10 years or so), something that is > > > marginal because it is processor intensive now, and will be not at all too > > > expensive in the future. > > I could not agree more. What seems slow now will seem trivial in five > > years. > > One might note a corollary that what seems secure now will probably > seem less secure in 5 years. There's probably a crypto aphorism about > computational cost: no pain, no security. Encrypt 'til it hurts and always > leave room for larger numbers. I agree with all of these comments, i.e.: what seems slow now may not seem slow in 5 or 10 years, and also that this similarly applies for security - to a large extent simply because of the availability of better HW also to the crackers (after all, with all cryptoanalysis of DES, the best attacks known are still basically brute force, only they now are quite realistic). However we should beware of over simplifying. In particular, we should keep in mind: 1. A cryptosystem which is more computationally intensive is not necessarily more secure. The classical example is the fact that in order to achieve security with known public key cryptosystems, one should work much harder than what is considered enough with symmetric cryptosystems. This does not mean public key is inferior, since public key buys you features which are impossible with symmetric crypto. It only means the two mechanisms should be combined as indeed we plan to do (by using symmetric techniques in IPSP, and in our proposal for using them also for the more frequent key updates in MKMP together with infrequent use of more expensive public key or DH operations). 2. While the security of cryptosystems is not proven and indeed changes with time, this should not hold for the protocol. It is possible to design protocols with modularity which would allow them to be used (with different cryptosystems) forever. For this purpose it is desirable to be able to have a reduction proof for the protocol as we know to do at least for simple protocols e.g. the short-lived module of MKMP. 3. What does one do to repair an implementation if cryptoanalysis of the cryptosystem used becomes easier? The obvious solution is to replace the cryptosystem, but this may be difficult and take long. Another potential remedy is to refresh keys more frequently. This is one of the motivations for having a highly efficient and simple mechanisms for short-lived key refresh as we propose in MKMP. Best, Amir Herzberg From ipsec-request@ans.net Tue Dec 13 10:09:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20892 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 10:09:10 -0500 Received: by interlock.ans.net id AA06920 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 10:03:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 10:03:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 10:03:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 10:03:14 -0500 Date: Tue, 13 Dec 94 06:55:50 From: "Housley, Russ" Encoding: 675 Text Message-Id: <9411137873.AA787330550@spysouth.spyrus.com> Cc: ipsec@ans.net Subject: Re[2]: Diffie-Hellman (note by Hugo) > Let me both support and object. I support perfect forward secrecy for > situations where secrecy is essential. > > I dont support perfect forward secrecy where authentication, and not > secrecy, is the prime consideration. Like you said, it isn't free. If > you dont want it, dont need it, you shouldn't have to pay for it. That > is why I presented perfect forward secrecy as an option in my SKIP talk. > There are many situations in the context of Internet applications where > authentication (and not secrecy) is the prime issue. I completely agree with Ashar. We should support forward secrecy as an option, not as a builtin feature unavoidable. Russ From ipsec-request@ans.net Tue Dec 13 11:13:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38454 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 11:13:38 -0500 Received: by interlock.ans.net id AA16568 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 11:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 11:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 11:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 11:02:37 -0500 Date: Tue, 13 Dec 94 07:57:42 From: "Housley, Russ" Encoding: 1762 Text Message-Id: <9411137873.AA787334262@spysouth.spyrus.com> To: ipsec@ans.net, perry@imsi.com Subject: Re: key management Perry: I have a real problem with your list of requirements, especially number 1. Your list is: 1) They lack a specified method for managing separate keys for separate users; this is an articulated requirement for the IPv6 case according to the IPng Directorate. 2) All but SKIP lack clearly articulated key certificates (and SKIP's seem to be X.509 based, which is probably non-optimal) 3) All seem to lack hooks for a user level authentication system, and this deficiency makes producing user level applications difficult to write. Number 1 requires the IPSP implementation to be tightly integrated with the transport layer implementation. I hope that we are desigining a solution that will work with ANY transport layer protocol, including TCP, UDP, TP4, and even TP0/RFC1006/TCP. If this is not the case, then we loose all of the advantages of a security protocol at the IP layer. Multiplexing occurs in the transport layer, and this multiplexing makes it difficult to determine which application process is involved in the communication. Human users are simply not represented at the IP layer. Hosts and routers (things with IP addresses) are represented at the IP layer. IPSP implementations will become significantly more complex if we try to represent things outside the IP layer. I strongly recommend that we leave authentication of users to the application that already has a model for representing them. Thus, I take issue with both number 1 and number 3 on your list. I agree with number 2, we need to pick a certificate format. However, I think that certificates to support IPSP should contain host names, not user names. Russ From ipsec-request@ans.net Tue Dec 13 16:13:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16795 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 11:24:32 -0500 Received: by interlock.ans.net id AA20718 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 11:16:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 11:16:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 11:16:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 11:16:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 11:16:14 -0500 Message-Id: <9412131613.AA12283@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 07:57:42." <9411137873.AA787334262@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 11:13:59 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Perry: > > I have a real problem with your list of requirements, especially number 1. > Your list is: > > 1) They lack a specified method for managing separate keys for > separate users; this is an articulated requirement for the > IPv6 case according to the IPng Directorate. > > Number 1 requires the IPSP implementation to be tightly integrated with the > transport layer implementation. No, it doesn't, although it does require that the transport layer have the ability to tell the network layer which SAID to use. > I hope that we are desigining a solution > that will work with ANY transport layer protocol, including TCP, UDP, TP4, > and even TP0/RFC1006/TCP. I see no reason why requirement 1 can't be met and permit the use of any transport. I already have a design that does this. > I strongly recommend that we leave authentication of users to the > application that already has a model for representing them. There are very good reasons that the IPng directorate made the decision they did. I wouldn't discard the recommendation without extremely serious thought. 1) The application CANNOT be trusted to represent users. Neither, for that matter, can a host -- see the documents on Kerberos for why this is the case. Although a user must trust a host for brief periods, it seems like a very bad idea to trust a random host sitting in an public area to be telling the truth when it claims a particular identity is using an application on the host. Kerberos-like systems have the advantage that they require that a user demonstrate his identity by showing that the host is in temporary posession of information known only to the user. Such information is necessarily cryptographic. Given this, why not go all the way and use just one system for cryptographic key negotiation? Why use more than one? 2) Mutually distrustful users on a single host CANNOT be trusted to know each others keys. Systems that use host keying conflate different users cryptographic keys, making all sorts of unfortunate attacks possible. Preventing seperate users from using each others keys is necessary. There are other reasons, too... Perry From ipsec-request@ans.net Tue Dec 13 06:18:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18610 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 12:34:35 -0500 Received: by interlock.ans.net id AA07431 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 11:48:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 11:48:44 -0500 Message-Id: <199412131648.AA07427@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 11:48:44 -0500 To: ipsec@ans.net Subject: patent on elliptic curve public-key cryptography Date: Tue, 13 Dec 94 11:18:31 EST I received some requests for clarification on my note that there are patents covering public-key cryptosystems based on elliptic curves. The specific patent I had in mind is (U.S.) patent number 5,159,632, issued 10/27/1992, assigned to NeXT, with Richard Crandall as the inventor. It covers some special cases of elliptic curve cryptography, and in particular those cases that can be implemented efficiently. The broadest claim is where the elliptic curve is over a finite field F_pk, where ``p is one of a class of numbers such that mod p arithmetic is performed in a processor using only shift and add operations''. The remaining claims cover various specific instances that meet those criteria, such as where p is 2^q-C where C is no more than 32 bits long. I haven't tried to see if there's an obvious D-H analog; at a guess, the answer is yes, but it would be considered ``obvious'' given this patent and the D-H patent. (Btw, there's no doubt that the D-H patent covers this scheme as well, since it's just a specific instance of a public-key cryptosystem. When an invention is covered by two patents, you need licenses from both patent-holders to practice the invention.) From ipsec-request@ans.net Tue Dec 13 17:16:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18615 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 12:34:36 -0500 Received: by interlock.ans.net id AA35876 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 12:16:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 13 Dec 1994 12:16:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 12:16:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 12:16:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 12:16:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 12:16:29 -0500 From: uri@watson.ibm.com Message-Id: <9412131716.AA23747@buoy.watson.ibm.com> Subject: Re: Eliptic Curves To: smb@research.att.com Date: Tue, 13 Dec 1994 12:16:24 -0500 (EST) Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199412122333.AA27436@interlock.ans.net> from "smb@research.att.com" at Dec 12, 94 06:29:31 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 311 smb@research.att.com says: > There may also be added patent complexity -- didn't NeXT get a patent > on their elliptic curve stuff? Well, I thought Elliptic Curves crypto was invented by Victor Miller, then IBM Research employee? -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Tue Dec 13 17:02:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38844 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 12:34:39 -0500 Received: by interlock.ans.net id AA14746 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 12:09:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 12:09:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 12:09:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 12:09:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 12:09:22 -0500 Date: Tue, 13 Dec 94 12:02:06 -0500 From: lacy@allegra.att.com (Jack Lacy) Message-Id: <9412131702.AA01482@bug.tempo.att.com> To: IPSEC@ans.net Subject: Modular Exponentiation Times All times were acquired using my library (CryptoLib): 32 bit radix Assembly implementation of 32x32 bit multiplication and squaring All else in C Montgomery Reduction in exponentiation Addition chaining Mod Len (Bits) Exp Len (Bits) Arch Times ------------- ------------- ---- ----- 512 512 Sparcs 2 430 ms 512 512 Sparcs 10 120 ms 512 512 Indigo 2 (R4400) 78 ms 512 512 486/50 (Win32) 490 ms 512 512 486/66 (Unix) 390 ms 512 160 Sparcs 2 110 ms 512 160 Indigo 2 (R4400) 25 ms 512 160 486/50 (Win32) 165 ms 1024 1024 Sparcs 2 3.0 s 1024 1024 Sparcs 10 780 ms 1024 1024 Indigo 2 (R4400) 529 ms 1024 1024 486/50 (Win32) 3.35 s 1024 160 Sparcs 2 700 ms 1024 160 Indigo 2 (R4400) 88 ms 1024 160 486/50 (Win32) 604 ms Jack Lacy lacy@research.att.com Jack Lacy lacy@research.att.com (908)582-7711 From ipsec-request@ans.net Tue Dec 13 18:15:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15987 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 13:20:56 -0500 Received: by interlock.ans.net id AA27572 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 13:16:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 13:16:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 13:16:18 -0500 Message-Id: <199412131815.NAA15827@faline.bellcore.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of Tue, 13 Dec 1994 11:13:59 -0500. <9412131613.AA12283@snark.imsi.com> Date: Tue, 13 Dec 1994 13:15:28 -0500 From: "Avi Rubin" > >2) Mutually distrustful users on a single host CANNOT be trusted to >know each others keys. Systems that use host keying conflate >different users cryptographic keys, making all sorts of unfortunate >attacks possible. Preventing seperate users from using each others >keys is necessary. How do you propose for mutually suspicious users to use the same host? *********************************************************************** Aviel D. Rubin Email: rubin@faline.bellcore.com Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html 445 South St. Morristown, NJ 07960 Voice: +1 201 829 4105 USA FAX: +1 201 829 5889 From ipsec-request@ans.net Tue Dec 13 18:41:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27440 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 13:49:22 -0500 Received: by interlock.ans.net id AA13127 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 13:42:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 13:42:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 13:42:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 13:42:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 13:42:15 -0500 Message-Id: <9412131841.AA12609@snark.imsi.com> To: "Avi Rubin" Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 13:15:28 EST." <199412131815.NAA15827@faline.bellcore.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 13:41:09 -0500 From: "Perry E. Metzger" "Avi Rubin" says: > >2) Mutually distrustful users on a single host CANNOT be trusted to > >know each others keys. Systems that use host keying conflate > >different users cryptographic keys, making all sorts of unfortunate > >attacks possible. Preventing seperate users from using each others > >keys is necessary. > > How do you propose for mutually suspicious users to use > the same host? Let them use different keys for their traffic. Thats part of the IPng spec. The key management we are developing is intended for use on both platforms. Perry From ipsec-request@ans.net Tue Dec 13 19:00:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31720 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:07:02 -0500 Received: by interlock.ans.net id AA02878 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:02:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:02:08 -0500 From: Ran Atkinson Message-Id: <9412131400.ZM11663@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 1994 14:00:30 -0500 In-Reply-To: hughes@hughes.network.com (James P Hughes) "Re: Diffie-Hellman (note by Hugo)" (Dec 12, 15:16) References: <9412122116.AA04506@hughes.network.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: James P Hughes Subject: Re: Diffie-Hellman (note by Hugo) Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil I agree with Jim Hughes (and others) that computational speed is not a major issue because processor capabilities keep improving rapidly. Ran atkinson@itd.nrl.navy.mil (speaking as an individual) From ipsec-request@ans.net Tue Dec 13 19:05:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30993 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:09:58 -0500 Received: by interlock.ans.net id AA32447 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:07:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:07:15 -0500 From: Ran Atkinson Message-Id: <9412131405.ZM11687@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 1994 14:05:49 -0500 In-Reply-To: perry@imsi.com (Perry E. Metzger) "key management" (Dec 12, 19:40) References: <9412130040.AA04772@webster.imsi.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 12, 19:40, Perry E. Metzger wrote: Subject: key management % 1) They lack a specified method for managing separate keys for % separate users; this is an articulated requirement for the IPv6 % case according to the IPng Directorate. Support for per-user keying is a requirement for IPv6. Period. Key Mgmt that does not support per-user keying does not conform to the IPv6 Security Architecture. % 2) All but SKIP lack clearly articulated key certificates (and SKIP's % seem to be X.509 based, which is probably non-optimal) IMHO, a key mgmt protocol should permit the use of DNS-supplied keys (as per Eastlake-Kaufman which is likely to appear as a Proposed Standard soon) for authentication of the key mgmt process. % 3) All seem to lack hooks for a user level authentication system, % and this deficiency makes producing user level applications % difficult to write. I don't understand what Perry means by this. A draft IPv6 API for Security Extensions to BSD Sockets is likely to appear soon as an Internet Draft. That might be a useful item in focusing discussion of how applications might use provided security services for whichever set of people happen to be concerned with that issue. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Dec 13 19:12:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16709 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:16:48 -0500 Received: by interlock.ans.net id AA31512 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:12:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 14:12:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 14:12:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 14:12:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:12:44 -0500 Message-Id: <9412131912.AA16168@pkarger.tcc> To: "Avi Rubin" Cc: perry@imsi.com, ipsec@ans.net Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 94 13:15:28 EST." <199412131815.NAA15827@faline.bellcore.com> Date: Tue, 13 Dec 94 14:12:44 -0500 From: "Paul A. Karger" > To: perry@imsi.com > Cc: ipsec@ans.net > Subject: Re: key management > In-Reply-To: Your message of Tue, 13 Dec 1994 11:13:59 -0500. > <9412131613.AA12283@snark.imsi.com> > Date: Tue, 13 Dec 1994 13:15:28 -0500 > From: "Avi Rubin" > > > > > > >2) Mutually distrustful users on a single host CANNOT be trusted to > >know each others keys. Systems that use host keying conflate > >different users cryptographic keys, making all sorts of unfortunate > >attacks possible. Preventing seperate users from using each others > >keys is necessary. > > How do you propose for mutually suspicious users to use > the same host? > Mutually suspicious users can only share the same host if you have a trusted operating system of some kind to separate them. From ipsec-request@ans.net Tue Dec 13 19:34:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35430 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:40:51 -0500 Received: by interlock.ans.net id AA11936 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:35:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 14:35:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 14:35:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 14:35:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:35:10 -0500 Message-Id: <9412131934.AA12770@snark.imsi.com> To: pkarger@gte.com Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 14:12:44 EST." <9412131912.AA16168@pkarger.tcc> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 14:34:51 -0500 From: "Perry E. Metzger" "Paul A. Karger" says: > > > From: "Avi Rubin" > > > > >2) Mutually distrustful users on a single host CANNOT be trusted to > > >know each others keys. Systems that use host keying conflate > > >different users cryptographic keys, making all sorts of unfortunate > > >attacks possible. Preventing seperate users from using each others > > >keys is necessary. > > > > How do you propose for mutually suspicious users to use > > the same host? > > Mutually suspicious users can only share the same host if you > have a trusted operating system of some kind to separate them. Many people who are interested in the use of IPSP already have compartmented mode workstations to work with. Even absent that, however, trusting your kernel is different from trusting the other users. There are also issues beyond this -- like wanting to make sure that there is a cryptographic authentication of the identity of the user in situations where you don't care about the identity of the machine per se. .pm From ipsec-request@ans.net Tue Dec 13 03:35:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14452 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:41:38 -0500 Received: by interlock.ans.net id AA37320 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:37:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 14:37:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 14:37:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 14:37:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:37:56 -0500 Date: Tue, 13 Dec 94 11:35:49 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412131935.AA29173@miraj.Eng.Sun.COM> To: amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP Cc: ipsec@ans.net >From ipsec-request@ans.net Thu Dec 8 14:10:27 1994 >Of course the receiver can count number of key exchanges it engages in and >discard any more... You missed my point rather than finding me untrue :-) >The problem is that if the receiver is deciding it is too busy, the sender >is unaware of this, and continues sending messages. If the receiver is just >dropping all of them, this is as severe a denial of service as any you'll get. >This is not the case with the interactive scheme, where the sender is aware >that the receiver has not agreed to a key and therefore would not spend >resources sending the packets. I think I did miss what you were trying to say, for which I apologize. However, there is still some confusion, and I am not sure it's all on my part. First, let me mention that the pair keys Kij always (conceptually) exist, and can be precomputed *prior* to any communication attempt. This can be done by following a prioritized list using the per node ACL (which you always need, because otherwise there is no need to authenticate). Note that this sort of precomputation cannot be performed using traditional (non-SKIP) interactive schemes, because there are no shared secrets prior to communication. This precomputation can follow usage patterns of the machine, or some administrative action. Now, if nodes on this prioritized list try to perform service access, there is no need to do computationally expensive operations (like DH). All that is needed are lightweight operations like MD5 or shared key operations. In case of clogging attacks, the end node can simply discard packets that require computation of *new* DH operations (provided the ACL was not completely covered by the precompute effort). This means that nodes on the priority list for which precomputation has been performed can *always* get access, because there is no need to engage in a computationally expensive operation to figure out if their packets are valid. The second point I would like clarification on is your comment that with interactive key-management the sender knows that there is no key, and therefore doesn't "spend resources sending the packet". This is only true if the interactive key-management protocol is embedded in a connection oriented network protocol. However, IP is most certainly *not* connection oriented. IP contains no mechanism to flow control back to the transport or application entity, which may be on a local machine or on a remote machine. If, e.g., IPSP is operating in intermediate system mode, there is no IP way for the intermediate node to tell the transmitting IP node to stop sending packets. This is not a SKIP issue, but rather an IP issue. If you have a way for addressing this issue in the context of connection oriented key-management protocols running with IP, I would be happy to learn of it. Third, I should point out that since with SKIP one can have precomputed and cached shared master keys, the master key update protocol (with perfect forward secrecy) that I presented at the San Jose meeting is far more resistant to a clogging attack than the master key negotiation protocol in your MKMP document. This is because the master key update protocol messages are protected using lightweight mechanisms like MD5. In your protocol, one has to do an RSA signature verification before one can decide what to do with the message. This is far more vulnerable to a clogging attack than the SKIP master key protocol, where one doesn't need to peform any public key operations, if one isn't happy with the result of the MD5 based authentication. >Agreed, however in the interactive scheme there is no demage except the >replay of the packet. In SKIP, this makes caching more keys and reduces >efficiency. Caching shared keys is quite a low overhead operation considering their small size, and the large amount of memory available on most machines. Regards, Ashar. From ipsec-request@ans.net Tue Dec 13 03:51:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06460 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 14:59:03 -0500 Received: by interlock.ans.net id AA33188 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 14:51:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 14:51:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 14:51:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 14:51:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 14:51:43 -0500 Date: Tue, 13 Dec 94 11:51:16 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412131951.AA29182@miraj.Eng.Sun.COM> To: rubin@faline.bellcore.com Subject: Re: Diffie-Hellman Cc: ipsec@ans.net >From ipsec-request@ans.net Mon Dec 12 16:50:16 1994 >Has anyone considered Yacobi's scheme that he published in crypto a couple >of years ago? > Avi, Are you referring to the following? Y. Yacobi: "A key distribution paradox", Crypto '90. & Y. Yacobi: "On key distribution systems", Crypto '89 If so, have you read M. Burmeister: "On the Risk of Opening Distributed Keys", Crypto '94. which performs cryptanalysis of the protocols presented in Yacobi's papers, and shows them to contain (at least theoretical) weaknesses using certain forms of known key attacks? Ashar. From ipsec-request@ans.net Tue Dec 13 20:05:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12554 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 15:15:09 -0500 Received: by interlock.ans.net id AA39145 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 15:06:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 15:06:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 15:06:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 15:06:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 15:06:14 -0500 Message-Id: <9412132006.AA12827@snark.imsi.com> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 14:05:49 EST." <9412131405.ZM11687@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 15:05:59 -0500 From: "Perry E. Metzger" Ran Atkinson says: > % 3) All seem to lack hooks for a user level authentication system, > % and this deficiency makes producing user level applications > % difficult to write. > > I don't understand what Perry means by this. Take Kerberos as a model for a moment. Kerberos lets applications determine the identity of your counterparty in communication, which is usually something of the form "user.role@realm.dom". I'm not saying that we need to adopt that particular naming or provide that capability directly in the key management layer, but if we cannot ultimately find out who our counterparty is there is no way to write things like a secure telnet or a secure distributed file system using this mechanism. IPSP and the rest remain partially useful even without such mechanisms -- you can build secure tunnels between networks -- but to make them dramatically useful you need to be able to extract information about the counterparty identity on a granularity below that of the host you are communicating with. Karn's proposal comes the closest in this regard in so far as he doesn't define the entities exchanging keys and allows the key structures themselves to contain identity information (or so he tells me). However, he'd need to be a bit more explicit about this. MKMP seems to be easily modified to handle this sort of thing currently handle it. I strongly encourage people to think in terms of providing AT LEAST as much functionality to the application writer as Kerberos provides -- without that much functionality we haven't really secured the internet. > A draft IPv6 API for Security Extensions to BSD Sockets is likely to > appear soon as an Internet Draft. That might be a useful item in > focusing discussion of how applications might use provided security > services for whichever set of people happen to be concerned with that > issue. Indeed it would. I was under the impression, actually, that this draft had already been posted but was incomplete -- am I wrong? .pm From ipsec-request@ans.net Tue Dec 13 20:12:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14356 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 15:15:33 -0500 Received: by interlock.ans.net id AA39501 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 15:12:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 15:12:30 -0500 From: Ran Atkinson Message-Id: <9412131512.ZM11826@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 1994 15:12:10 -0500 In-Reply-To: "Paul A. Karger" "Re: key management" (Dec 13, 14:12) References: <9412131912.AA16168@pkarger.tcc> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: pkarger@gte.com, Avi Rubin Subject: Re: key management Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 13, 14:12, Paul A. Karger wrote: } Subject: Re: key management % Mutually suspicious users can only share the same host if you % have a trusted operating system of some kind to separate them. It isn't clear to me what you mean by "trusted operating system". If you mean an OS with Mandatory Access Controls (e.g. B1 or better per Orange Book), then I disagree. A C2 operating system with Discretionary Access Controls permits user A to configure permissions such that user B does not have access to user A's data and resources. If user A is on such a system and does not trust user B, then user A can configure its permissions accordingly. MAC is needed when one is trying to enforce some kind of multi-level security policy, not merely to separate mutually suspicious users. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Dec 13 20:31:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38737 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 15:37:44 -0500 Received: by interlock.ans.net id AA33238 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 15:31:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 15:31:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 15:31:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 15:31:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 15:31:29 -0500 Message-Id: <9412132031.AA16359@pkarger.tcc> To: atkinson@itd.nrl.navy.mil Cc: pkarger@gte.com, Avi Rubin , ipsec@ans.net Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 94 15:12:10 EST." <9412131512.ZM11826@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 94 15:31:22 -0500 From: "Paul A. Karger" > From: Ran Atkinson > Message-Id: <9412131512.ZM11826@sundance.itd.nrl.navy.mil> > Date: Tue, 13 Dec 1994 15:12:10 -0500 > In-Reply-To: "Paul A. Karger" > "Re: key management" (Dec 13, 14:12) > Reply-To: atkinson@itd.nrl.navy.mil > To: pkarger@gte.com, Avi Rubin > Subject: Re: key management > Cc: ipsec@ans.net > > On Dec 13, 14:12, Paul A. Karger wrote: > } Subject: Re: key management > > % Mutually suspicious users can only share the same host if you > % have a trusted operating system of some kind to separate them. > > It isn't clear to me what you mean by "trusted operating system". > > If you mean an OS with Mandatory Access Controls (e.g. B1 or better > per Orange Book), then I disagree. A C2 operating system with > Discretionary Access Controls permits user A to configure permissions > such that user B does not have access to user A's data and resources. > If user A is on such a system and does not trust user B, then user A > can configure its permissions accordingly. MAC is needed when one is > trying to enforce some kind of multi-level security policy, not merely > to separate mutually suspicious users. > I did not mean to imply any particular Orange Book level. The question was how can mutually suspicious users share the same host, and my answer was intended to be very simple - they can only share the same host if there is a trusted operating system running on that host to mediate access between them. Cryptography alone cannot solve this problem. The operating system must mediate, if only to protect keys. How much sharing and how much trust and how suspicious are all issues that will determine what kind of operating system you need. Orange book ratings will be a factor, as will underlying operating system features that the Orange Book does not discuss. To really support full mutual suspicion, you need non-hierarchic protection domains as discussed in Mike Schroeder's PhD thesis from MIT back in 1973 and then another 20-odd years of research since then. The point is that mutual suspicion on a single host is an operating system issue - not a cryptographic protocol issue. Paul From ipsec-request@ans.net Tue Dec 13 20:34:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14709 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 15:40:36 -0500 Received: by interlock.ans.net id AA37498 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 15:37:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 15:37:49 -0500 From: Ran Atkinson Message-Id: <9412131534.ZM11890@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 1994 15:34:53 -0500 In-Reply-To: "Paul A. Karger" "Re: key management" (Dec 13, 15:31) References: <9412132031.AA16359@pkarger.tcc> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: pkarger@gte.com Subject: Re: key management Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 13, 15:31, Paul A. Karger wrote: } Subject: Re: key management % The point is that mutual suspicion on a single host is an operating % system issue - not a cryptographic protocol issue. Yes for a single host. However, once one has networked hosts then one must also consider using cryptographic mechanisms to maintain per-user separation for data in transit between the networked systems. If one lacks such separation on networked hosts, then it is not feasible to provide per-user separation of data on the hosts themselves because the data might be compromised whilst transiting the network. It is the latter problem that is being discussed in the context of IPv4 and IPv6 security. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Dec 13 20:35:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38787 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 15:41:08 -0500 Received: by interlock.ans.net id AA16523 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 15:38:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 15:38:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 15:38:53 -0500 Message-Id: <199412132035.PAA01929@faline.bellcore.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: Diffie-Hellman In-Reply-To: Your message of Tue, 13 Dec 1994 11:51:16 -0800. <9412131951.AA29182@miraj.Eng.Sun.COM> Date: Tue, 13 Dec 1994 15:35:10 -0500 From: "Avi Rubin" > >M. Burmeister: "On the Risk of Opening Distributed Keys", Crypto '94. > >which performs cryptanalysis of the protocols presented in >Yacobi's papers, and shows them to contain (at least theoretical) >weaknesses using certain forms of known key attacks? > >Ashar. Yes, the triangle attack seems highly theoretical, and from personal communication with Yacov Yacobi, should be easy to fix. *********************************************************************** Aviel D. Rubin Email: rubin@faline.bellcore.com Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html 445 South St. Morristown, NJ 07960 Voice: +1 201 829 4105 USA FAX: +1 201 829 5889 From ipsec-request@ans.net Tue Dec 13 21:10:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38744 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 16:14:04 -0500 Received: by interlock.ans.net id AA44818 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 16:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 13 Dec 1994 16:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 16:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 16:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 16:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 16:10:55 -0500 Message-Id: <9412132110.AA37231@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: atkinson@itd.nrl.navy.mil Cc: James P Hughes , ipsec@ans.net Subject: Proposal: Perfect forward secrecy a MUST In-Reply-To: Your message of "Tue, 13 Dec 1994 14:00:30 EST." <9412131400.ZM11663@sundance.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 16:10:42 -0500 From: " " Ran, Jim and others, I agree with your position: speed should not stop us from requiring perfect forward secrecy (in particular when used in conjunction with a short-lived key refresh module, as we propose in MKMP, the overhead should be reasonable even for low-end, mobile devices). However I think we should be even more explicit about whether we want perfect forward secrecy to be a must. Aziz has pointed out that this feature does not come for free, and I think we are all saying that at least the computational cost is not prohibitive. Maybe, however, Aziz had other `costs' in mind, such as the requirement of an interaction and `session' (i.e. keeping the key as a state). Aziz (and others), could you enumerate all the disadvantages/costs associated with deciding on perfect forward secrecy as a requirement? Ran, Jim, Hugo, Phil, others: do you think we should require perfect forward secrecy in spite of the costs in computation, interaction and state? I vote to make perfect forward secrecy a requirement. I think it gives a substantial boost in security at a cost which is reasonable in almost every scenario. We could allow optional implementations which agree also to work without it, if needed; this is the exception. Best, Amir Enc: note from Ran > > I agree with Jim Hughes (and others) that computational speed is not a > major issue because processor capabilities keep improving rapidly. > > Ran > atkinson@itd.nrl.navy.mil > (speaking as an individual) > From ipsec-request@ans.net Tue Dec 13 21:18:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24750 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 16:20:46 -0500 Received: by interlock.ans.net id AA31861 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 16:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 16:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 16:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 16:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 16:18:41 -0500 Message-Id: <9412132118.AA13009@snark.imsi.com> To: pkarger@gte.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 15:31:22 EST." <9412132031.AA16359@pkarger.tcc> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 16:18:05 -0500 From: "Perry E. Metzger" "Paul A. Karger" says: > The point is that mutual suspicion on a single host is an operating system > issue - not a cryptographic protocol issue. That is untrue. If multiple users share the same key, and they have access to their own keys, they can trivially read each others traffic. If they don't have access to their own keys, they can still cause each other significant pain and suffering. Chosen plaintext attacks that heretofore seemed absurd become trivial. It becomes neccessary to trust the remote host rather than trusting that the remote host is in possession of a user based authenticator. Attacks against other users communications can be attempted based on the fact that the users share the same SAIDs. There is more. Perhaps a paper on the subject would be a good idea. In any case, however, forcing different users to use the same SAID is not acceptable. Perry From ipsec-request@ans.net Tue Dec 13 21:31:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA32471 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 16:53:32 -0500 Received: by interlock.ans.net id AA34042 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 16:47:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 16:47:36 -0500 Message-Id: <199412132147.AA05110@interlock.ans.net> To: atkinson@itd.nrl.navy.mil Cc: pkarger@gte.com, Avi Rubin , ipsec@ans.net, solo@BBN.COM Subject: Re: key management In-Reply-To: Your message of Tue, 13 Dec 94 15:12:10 -0500. <9412131512.ZM11826@sundance.itd.nrl.navy.mil> Date: Tue, 13 Dec 94 16:31:53 -0500 From: solo@BBN.COM Satisfying user granularity identification, authentication, and access control at the IP layer seems to be one of those issues where desired capabilities and feasibility clash. It is very reasonable to imagine, for single user hosts, assigning an authenticated host identity of the flavor "David Solo's workstation" Because I am the only user, a peer host or application can reasonably conclude that it is me and make a corresponding authorization decision. Another user who uses the same machine might instantiate a different host identity but still operates in a single user configuration. In a multi-user environment, providing different identities at the IP level is incompatible with both typical host assurance and with the protocol architecture. Note, by the way, that solving this on the receive end is much more complicated than on the sending end of a datagram. In order meaningfully provide user granularity of separation, a host has to authenticate the user, pass that information down to the IP/IPSEC level, and preserve the integrity of the path. This suggest non-standard application and transport implementations. On the receive side, the problem is worse. An IP datagram arrives with an SAID. At the time IP/IPSEC per datagram processing takes place, including a reliable access control decision, there is no way to control the subsequent processing of the information, let alone communicating that data through the transport layer and to a subsequent application. At a minimum, this requires some change to the transport processing and application. While an IP level user authentication architecture might be feasible in a high assurance operating system intended to provide reliable separation, it is far less realistic in common, lower assurance configurations. Further, if you are going to create special applications to handle this processing, why not directly handle user authentication at the application level. I don't doubt that the IPv6 and other communities would like to see the general user I&A problem solved at the network layer, but this is mostly inconsistent with protocol layering and certainly inconsistent with low assurance operating systems. On the other hand, I do agree that IKMP, as distinct from IPSP, should be capable of creating security associations based on a variety of granularities. My objection is to the notion of providing user based separation via IPSP on multi-user systems. I would be happy to see someone describe a feasible architecture to provide reliable user I&A, separation, and access control at both the sending and receiving end for low assurance, multi-user hosts. Dave > Date: Tue, 13 Dec 94 15:12:10 EST > From: Ran Atkinson > Subject: Re: key management > > > On Dec 13, 14:12, Paul A. Karger wrote: > } Subject: Re: key management > > % Mutually suspicious users can only share the same host if you > % have a trusted operating system of some kind to separate them. > > It isn't clear to me what you mean by "trusted operating system". > > If you mean an OS with Mandatory Access Controls (e.g. B1 or better > per Orange Book), then I disagree. A C2 operating system with > Discretionary Access Controls permits user A to configure permissions > such that user B does not have access to user A's data and resources. > If user A is on such a system and does not trust user B, then user A > can configure its permissions accordingly. MAC is needed when one is > trying to enforce some kind of multi-level security policy, not merely > to separate mutually suspicious users. > > Ran > atkinson@itd.nrl.navy.mil > > > From ipsec-request@ans.net Tue Dec 13 22:17:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17004 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 17:21:53 -0500 Received: by interlock.ans.net id AA08776 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 17:17:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 17:17:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 17:17:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 17:17:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 17:17:21 -0500 Message-Id: <9412132217.AA16596@pkarger.tcc> To: perry@imsi.com Cc: pkarger@gte.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 94 16:18:05 EST." <9412132118.AA13009@snark.imsi.com> Date: Tue, 13 Dec 94 17:17:17 -0500 From: "Paul A. Karger" in reply to many messages on mutual suspicion on a multi-user host: Sigh! I tried to give a simple answer to a simple question about mutual suspicion on a multi-user host, and the feedback just gets more and more complex about issues that weren't even in the original question and answer. I guess I wasn't communicating clearly enough, so let me try again from the top. Rather than trying to address each point, let me restate what I was trying to say which was VERY SIMPLE. The original question was: >> >>2) Mutually distrustful users on a single host CANNOT be trusted to >>know each others keys. Systems that use host keying conflate >>different users cryptographic keys, making all sorts of unfortunate >>attacks possible. Preventing seperate users from using each others >>keys is necessary. > >How do you propose for mutually suspicious users to use >the same host? What I was trying to say was: If you have mutual suspicion on a multi-user host, you can only achieve security by trusting the operating system to keep things separate and mediated. No matter what you do cryptographically on the networking protocols, you must trust the operating system, because it is holding your cleartext data and might be holding the cryptographic keys as well. I was not implying any particular orange book level, nor was I implying that a trusted operating system was sufficient (by itself) for resolving mutual suspicion in a multi-user system that is networked. Only that a trusted operating system is NECESSARY. If you don't have a trustworthy operating system, you are in deep trouble. Unfortunately, there are VERY FEW trustworthy operating systems out there. That was all I was trying to say. Now, let me add a couple of points beyond what I was saying originally. There are also cryptographic implications of the need for a trusted operating system. If you can trust the operating system (and you have to!), then all traffic between a given pair of systems might as well be under the same key, because even if separate session keys are used for each user, the operating systems at each end can intermingle the cleartext, if they so choose. (This assumes that the crypto system is immune to chosen plaintext attack. If it is NOT immune to chosen plaintext, then using a single key for a pair of systems is a bad thing, as Perry pointed out.) (This also assumes that the operating systems and/or crypto hardware devices don't make the keys visible to the users.) Digital's ethernet encryption device (DESNC) was designed in exactly this way. Keys were negotiated on a per-host-pair basis for all users on those hosts. Keys always remained inside the DESNC hardware boxes, so users never saw the keys. The assumption was that DES was sufficiently resistent to chosen plaintext attack for the application domain of DESNC. Note that if two mutually suspicious users are both communicating between the same pair of systems, they have to trust BOTH operating systems. Even if the crypto protocols use separate keys for each session, the operating systems on either end can compromise the cleartext data. If users and/or user-mode software has access to the crypto keys, then the problems get even worse, because any Trojan horse or virus therefore could have access to the keys. I hope this helps understand my comments. Paul From ipsec-request@ans.net Tue Dec 13 23:48:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA32308 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 18:52:37 -0500 Received: by interlock.ans.net id AA18567 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 18:48:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 13 Dec 1994 18:48:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 18:48:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 18:48:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 18:48:46 -0500 Message-Id: <9412132348.AA13258@snark.imsi.com> To: solo@BBN.COM Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 16:31:53 EST." <199412132147.AA05110@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Dec 1994 18:48:15 -0500 From: "Perry E. Metzger" solo@BBN.COM says: > In a multi-user environment, providing different identities at the > IP level is incompatible with both typical host assurance and with > the protocol architecture. Note, by the way, that solving this > on the receive end is much more complicated than on the sending end > of a datagram. > > In order meaningfully provide user granularity of separation, a > host has to authenticate the user, pass that information down to the > IP/IPSEC level, and preserve the integrity of the path. This suggest > non-standard application and transport implementations. You make all this sound difficult. None of it involves any great difficulty. Imagine using Kerberos (as a strawman) for key management, and an interface that allows you to set SAIDs to be used on a per-socket basis. The kernel must enforce a mechanism to only allow you to set a SAID that you "own" on a socket. At this point, the problem becomes trivial. Implementation-wise (pardon the BSD orientation), you just support some sort of SAID structure in your kernel that includes a user id (for authorization checking) and have the TCB or the equivalent for the transport in question have a pointer to an SAID if security is on. The transport interface to the network layer code passes along the SAID to use -- the network layer need not understand anything about which user is which, only about SAIDs. On the receive side, the network layer passes the SAID up with the (decrypted) packet so that the transport can compare the SAID against the one it is supposed to be using for the socket in question. Per user key management stuff is handled by having the kerberos system stash shared service keys in new SAIDs in the kernel owned by the given user. As you can see, this is hardly difficult. It requires some tiny modifications to the transport code, a couple of small kernel interfaces, and a key management system that understands user level credentials. Perry From ipsec-request@ans.net Wed Dec 14 00:28:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17780 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 19:34:49 -0500 Received: by interlock.ans.net id AA34248 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 19:31:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 19:31:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 19:31:59 -0500 Date: Tue, 13 Dec 1994 16:28:28 -0800 From: Phil Karn Message-Id: <199412140028.QAA11139@servo.qualcomm.com> To: dee@skidrow.tay.dec.com Cc: ipsec@ans.net In-Reply-To: <9412130126.AA01402@skidrow.tay.dec.com> (dee@skidrow.tay.dec.com) Subject: Re: Diffie-Hellman (note by Hugo) >Let me second Ashar. Different users need different levels of >security. For those who ask for confidentiality, then I think we need >to provide strong confidentiality with perfect forward secrecy. For >those who ask for just authentication, we need to provide strong >authentication but secrecy of any sort is not a question. This is an appealing argument, but it carries the danger that we'll come up with so many different mechanisms that we either have less than perfect interoperability, or everybody will have to implement everything, which means a lot more work and more delay in reaching the market. I would much prefer a single scheme (for interoperability) that can solve the worst case problem, but with "tuning knobs" to speed things up when less than maximum security is acceptable. Photuris and similar authenticated Diffie-Hellman schemes can do this very nicely. For absolute maximum security, the background task that generates Diffie-Hellman public/private keys and signs them with RSA could run continuously, soaking up all available CPU time. And each time a new local DH key is generated, you could renegotiate new session keys for all of your existing SAIDs. At the other extreme you could generate a DH key pair and sign it just once, keeping it "forever" across system reboots. This essentially collapses into SKIP as I understand it. Or you could find a happy middle. My point is that a single protocol CAN meet all of these cases, which is a big interoperability win. I don't really think the cost of Diffie-Hellman is all that intolerable. I used it all last week on my not-blazingly-fast laptop. It took a few seconds each time, not so long to tempt me to bypass it. This is a big improvement over last time when I used full-sized (1024 bit) exponents instead of shorter (128-bit) exponents to generate a 56-bit DES key. And that's with plain RSAREF code, which is known to be at least 2-3x slower than several other widely available modexp routines. And I'm not yet hiding the first two exponentiations in the background, which will nearly triple the apparent performance of the protocol. In sum: Diffie-Hellman performance is already acceptable in most cases, near-term performance concerns are better met by varying the parameters of a single protocol rather than by creating multiple incompatible protocols, and faster CPUs and improved code and protocols will eventually moot the DH performance issue anyway. Phil From ipsec-request@ans.net Wed Dec 14 01:25:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31728 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 20:30:17 -0500 Received: by interlock.ans.net id AA17899 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 20:25:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 20:25:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 20:25:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 20:25:44 -0500 Date: Tue, 13 Dec 1994 18:25:31 -0700 From: Hilarie Orman Message-Id: <199412140125.SAA03833@umbra.CS.Arizona.EDU> To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199412140028.QAA11139@servo.qualcomm.com> Subject: Re: Diffie-Hellman (note by Hugo) > I don't really think the cost of Diffie-Hellman is all that > intolerable. I used it all last week on my not-blazingly-fast laptop. > It took a few seconds each time, not so long to tempt me to bypass it. I'm concerned that this might cease to be true for hosts running applications that require connections to lots of different hosts. Distributed system maintenance actions, for example. From ipsec-request@ans.net Tue Dec 13 15:46:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16740 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 20:50:12 -0500 Received: by interlock.ans.net id AA11656 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 20:46:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 20:46:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 20:46:17 -0500 Date: Tue, 13 Dec 94 20:46:13 EST From: meadows@itd.nrl.navy.mil (Catherine A. Meadows) Message-Id: <9412140146.AA22209@itd.nrl.navy.mil> To: ipsec@ans.net Subject: a comment/question on perfect forward secrecy Cc: meadows@itd.nrl.navy.mil Hi: I have been following ipsec for some time, and now that perfect forward secrecy has become a topic of conversation, I'd like to make some comments that express some concerns about it that I've had for a while. The goal of perfect forward secrecy, as I see it, is to ensure that there is no single secret whose compromise would compromise the secrecy of past message traffic. Perfect forward secrecy does this by ensuring that compromise of a master key does not compromise secrecy of old session keys. Authenticated Diffie-Hellman guarantees perfect forward secrecy because master keys are used only to provide authentication, not secrecy. However, master keys may not be the only secrets whose compromise can compromise old message traffic. Suppose that a pseudo-random number generator is used to generate the key agreement keys. Such pseudo-random number generators produce a sequence R1, R2, ..... where Rn is produced by running the algorithm on a secret seed and Rn-1. Thus, if the seed and one old key were compromised, all keys generated after that would be compromised. In many cases, it also possible to run the algorithm in reverse, that is, produce Rn-1 from Rn and the secret seed. In that case, if the seed and one key were compromised, then all previous keys would be compromised, thus apparently wiping out many of the advantages of perfect forward secrecy. One possible way of solving this problem would be to use a genuine random source instead of a pseudo-random number generator. If that's not practical, then you could eliminate some of the problem by using a pseudo-random number generator that's irreversible. One such is Blum, Blum, and Shub, which is also based on exponentiation, and would thus add to the cost of the protocol, although this could be mitigated by having keys generated ahead of time. Does anyone know if this problem has been considered at all when looking at perfect forward secrecy? Cathy Meadows Center for High Assurance Computer Systems Naval Research Laboratory From ipsec-request@ans.net Wed Dec 14 02:38:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17702 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 21:41:47 -0500 Received: by interlock.ans.net id AA25342 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 21:39:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 21:39:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 21:39:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 21:39:02 -0500 Date: Tue, 13 Dec 1994 19:38:50 -0700 From: Hilarie Orman Message-Id: <199412140238.TAA06409@umbra.CS.Arizona.EDU> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9412132348.AA13258@snark.imsi.com> Subject: Re: key management > On the receive side, the network layer passes > the SAID up with the (decrypted) packet so that the transport can > compare the SAID against the one it is supposed to be using for the > socket in question. Do you mean that the transport layer checks that the user id associated with the SAID is the same as the user id associated with the socket? From ipsec-request@ans.net Wed Dec 14 04:27:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27340 (5.65c/IDA-1.4.4 for ); Tue, 13 Dec 1994 23:32:52 -0500 Received: by interlock.ans.net id AA25334 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 13 Dec 1994 23:27:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 13 Dec 1994 23:27:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 13 Dec 1994 23:27:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 13 Dec 1994 23:27:54 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 23:27:49 -0500 To: Hilarie Orman , ipsec@ans.net From: crocker@cybercash.com (Steve Crocker) Subject: elliptic crypto Hilarie, Bellovin's message re NeXT's elliptic crypto patent contains most of the info we had. We did do a little work to extend the system for signatures, but it wasn't particularly deep. I don't know what NeXT did -- or plans to do -- with its work. I suspect license issues are inevitably involved. Steve -------------------- Steve Crocker CyberCash, Inc. Work: +1 703 620 1222 2086 Hunters Crest Way Fax: +1 703 391 2651 Vienna, VA 22181 crocker@cybercash.com From ipsec-request@ans.net Wed Dec 14 05:09:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16870 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 00:11:19 -0500 Received: by interlock.ans.net id AA10527 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 00:08:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 00:08:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 00:08:43 -0500 Date: Tue, 13 Dec 1994 21:09:47 -0800 From: Phil Karn Message-Id: <199412140509.VAA11595@servo.qualcomm.com> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: <9412130040.AA04772@webster.imsi.com> (perry@imsi.com) Subject: Re: key management >I believe that many of the given key management protocols are still >deficient in so far as Perry's concerns are valid, but they all seem to address what I'd call certificate management, as opposed to session key management which is what we're really discussing right now. In the tried-and-true tradition of the Internet, we've been building IP security bottom-up, which I think is the right thing to do. As I said in my talk on Photuris, I assume for now that each end already has a local trusted list of public keys for authorized users, along with a policy database stating what the holder of each corresponding private key will be allowed to do once they prove they hold it (e.g., puncture a routing firewall, access services on that particular host, etc). We can worry about *how* that database gets built later, just as we put off session key management until we had rough consensus on a packet encapsulation format. There's something to be said for letting the concrete harden on your foundation before building the upper stories... Phil From ipsec-request@ans.net Wed Dec 14 05:29:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16199 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 00:32:25 -0500 Received: by interlock.ans.net id AA10522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 00:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 00:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 00:30:25 -0500 Date: Tue, 13 Dec 1994 21:29:46 -0800 From: Phil Karn Message-Id: <199412140529.VAA11622@servo.qualcomm.com> To: housley@spyrus.com Cc: ipsec@ans.net, perry@imsi.com In-Reply-To: <9411137873.AA787334262@spysouth.spyrus.com> (housley@spyrus.com) Subject: Re: key management >I agree with number 2, we need to pick a certificate format. However, I >think that certificates to support IPSP should contain host names, not user >names. I disagree. One big application I have in mind for IPSP is to support mobile/portable users operating from temporary IP addresses, e.g., from the IETF terminal room. As long as you have the secret RSA (or DSS) key that corresponds to the public key already on file with your security gateway back at work, you can puncture your company's firewall and gain complete logical IP connectivity in a secure fashion from any IP address you happen to be using. In this situation it makes a lot of sense for the keys in the IPSP gateway to have the names of your users on them. Phil From ipsec-request@ans.net Wed Dec 14 05:57:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27326 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 00:57:57 -0500 Received: by interlock.ans.net id AA10512 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 00:56:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 00:56:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 00:56:00 -0500 Date: Tue, 13 Dec 1994 21:57:11 -0800 From: Phil Karn Message-Id: <199412140557.VAA11694@servo.qualcomm.com> To: perry@imsi.com Cc: rubin@faline.bellcore.com, ipsec@ans.net In-Reply-To: <9412131841.AA12609@snark.imsi.com> (perry@imsi.com) Subject: Re: key management >> How do you propose for mutually suspicious users to use >> the same host? >Let them use different keys for their traffic. Thats part of the IPng >spec. The key management we are developing is intended for use on both >platforms. Not only that, but let them use an operating system. Isn't protecting mututally untrustworthy applications from each other one of the traditional functions of an operating system, at least a "real" one? Phil From ipsec-request@ans.net Wed Dec 14 06:19:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23943 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 01:20:24 -0500 Received: by interlock.ans.net id AA19039 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 01:17:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 01:17:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 01:17:41 -0500 Date: Tue, 13 Dec 1994 22:19:04 -0800 From: Phil Karn Message-Id: <199412140619.WAA11709@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: ipsec@ans.net In-Reply-To: <199412140125.SAA03833@umbra.CS.Arizona.EDU> (message from Hilarie Orman on Tue, 13 Dec 1994 18:25:31 -0700) Subject: Re: Diffie-Hellman (note by Hugo) >> I don't really think the cost of Diffie-Hellman is all that >> intolerable. I used it all last week on my not-blazingly-fast laptop. >> It took a few seconds each time, not so long to tempt me to bypass it. >I'm concerned that this might cease to be true for hosts running applications >that require connections to lots of different hosts. Distributed system >maintenance actions, for example. Yes, but: 1) Such hosts generally have far more CPU horsepower than my laptop, and 2) The precomputed stuff (the first DH exponentiation and the RSA signing) can be shared across multiple security associations, especially when they are being created rapidly, i.e., more often than the normal background precomputation rate. Again, if you "turn the knob" on the Photuris background key generation rate all the way down, you essentially get SKIP's level of performance. But unlike SKIP, *my* protocol goes all the way up to 11... :-) Phil From ipsec-request@ans.net Wed Dec 14 06:35:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16340 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 01:37:45 -0500 Received: by interlock.ans.net id AA19178 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 01:34:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 01:34:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 01:34:25 -0500 Date: Tue, 13 Dec 1994 22:35:28 -0800 From: Phil Karn Message-Id: <199412140635.WAA11737@servo.qualcomm.com> To: meadows@itd.nrl.navy.mil Cc: ipsec@ans.net, meadows@itd.nrl.navy.mil In-Reply-To: <9412140146.AA22209@itd.nrl.navy.mil> (meadows@itd.nrl.navy.mil) Subject: Re: a comment/question on perfect forward secrecy >However, master keys may not be the only secrets whose compromise >can compromise old message traffic. Suppose that a pseudo-random >number generator is used to generate the key agreement keys. >Does anyone know if this problem has been considered at all when looking >at perfect forward secrecy? Yes. I consider random number generation to be the Achilles heel of all these schemes, and I've given mine a lot of thought. The random number generator in my current code was inspired by PGP, but with some tricks of my own. In my NOS code (a TCP/IP operating environment for DOS in which I've been prototyping this stuff) I maintain an internal random number generator state that is continually "churned" by keyboard strokes and other random external events. That is, whenever you hit a key (for any purpose -- there's a direct hook into the keyboard driver) while the program is running, the scan code and the PC's real time clock (~1 us count rate) are concatenated with the previous generator state and hashed through MD5. The result becomes the new generator state. Whenever I need to generate random data, I hash the current state along with a counter. The output becomes 16 bytes of random data that I give to the user (e.g., a Diffie-Hellman routine). If the user needs more, I increment the counter and rehash as needed. In essence, I maintain a "reservoir" of entropy, adding to it whenever I can and drawing from it as needed. Assuming the reservoir is reasonably full when I start, I can continue to generate random data even without the addition of additional entropy at the cost of degenerating from theoretical randomness (can't guess the sequence even with unlimited computer power) to practical randomness (can't guess the sequence without enough computing power to invert MD5). One not-quite-resolved problem is an unattended system that never sees any keyboard activity. A security gateway, for example. I do try to seed the generator state at startup with a few tricks: 1) hashing all of main memory, including Ethernet and disk buffers, BIOS data, etc 2) Reading the 1uS time-of-day count in a tight CPU loop and hashing the results. On some (but not all) machines that use separate crystals to clock the CPU and the TOD clocks, you'll get a fairly random-looking dither in the increment between successive clock reads. This doesn't work for all PCs, though, especially the newer ones that generate all their clocks from a single crystal and a PLL synthesizer. I do need to add a few more tricks I've heard about, e.g., timing floppy disk and/or hard disk accesses, and perhaps hashing cleartext packets. And it probably wouldn't hurt to save the random state on disk when shutting down so I can use it as yet another source of entropy when starting up, much like PGP's randseed.bin file. Phil From ipsec-request@ans.net Wed Dec 14 07:34:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20964 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 02:33:54 -0500 Received: by interlock.ans.net id AA10624 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 02:31:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 02:31:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 02:31:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 02:31:28 -0500 Message-Id: <9412140734.AA17932@skidrow.tay.dec.com> To: ipsec@ans.net Subject: randomness (was Re: a comment/question on perfect forward secrecy ) In-Reply-To: Your message of "Tue, 13 Dec 94 22:35:28 PST." <199412140635.WAA11737@servo.qualcomm.com> Date: Wed, 14 Dec 94 02:34:34 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp The long delayed informational RFC on generating randomness has been submitted to the RFC editor. The version submitted is below. Donald Security Area Donald E. Eastlake, 3rd Request for Comments: XXXX DEC Category: Informational Stephen D. Crocker Cybercash Jeffrey I. Schiller MIT December 1994 Randomness Requirements for Security ---------- ------------ --- -------- Donald E. Eastlake 3rd, Stephen D. Crocker, & Jeffrey I. Schiller Status of This Document This document provides information for the Internet community. It does not specify any type of Internet standard. Distribution of this document is unlimited. Abstract Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications. Eastlake, Crocker, & Schiller [Page 1] RFC XXXX Randomness Requirements for Security December 1994 Acknowledgements Comments on this document that have been incorporated were received from (in alphabetic order) the following: David M. Balenson (TIS) Don T. Davis (consultant) Carl Ellison (Stratus) Marc Horowitz (MIT) Christian Huitema (INRIA) Charlie Kaufman (IRIS) Steve Kent (BBN) Hal Murray (DEC) Neil Haller (Bellcore) Richard Pitkin (DEC) Tim Redmond (TIS) Doug Tygar (CMU) Eastlake, Crocker, & Schiller [Page 2] RFC XXXX Randomness Requirements for Security December 1994 Table of Contents Status of This Document....................................1 Abstract...................................................1 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Requirements............................................6 3. Traditional Pseudo-Random Sequences.....................8 4. Unpredictability.......................................10 4.1 Problems with Clocks and Serial Numbers...............10 4.2 Timing and Content of External Events.................11 4.3 The Fallacy of Complex Manipulation...................11 4.4 The Fallacy of Selection from a Large Database........12 5. Hardware for Randomness................................13 5.1 Volume Required.......................................13 5.2 Sensitivity to Skew...................................13 5.2.1 Using Stream Parity to De-Skew......................14 5.2.2 Using Transition Mappings to De-Skew................15 5.2.3 Using FFT to De-Skew................................16 5.2.4 Using Compression to De-Skew........................16 5.3 Existing Hardware Can Be Used For Randomness..........17 5.3.1 Using Existing Sound/Video Input....................17 5.3.2 Using Existing Disk Drives..........................17 6. Recommended Non-Hardware Strategy......................18 6.1 Mixing Functions......................................18 6.1.1 A Trivial Mixing Function...........................18 6.1.2 Stronger Mixing Functions...........................19 6.1.3 Diff-Hellman as a Mixing Function...................20 6.1.4 Using a Mixing Function to Stretch Random Bits......21 6.1.5 Other Factors in Choosing a Mixing Function.........21 6.2 Non-Hardware Sources of Randomness....................22 6.3 Cryptographically Strong Sequences....................23 6.3.1 Traditional Strong Sequences........................23 6.3.2 The Blum Blum Shub Sequence Generator...............24 7. Key Generation Standards...............................26 7.1 US DoD Recommendations for Password Generation........26 7.2 X9.17 Key Generation..................................26 8. Examples of Randomness Required........................28 8.1 Password Generation..................................28 Eastlake, Crocker, & Schiller [Page 3] RFC XXXX Randomness Requirements for Security December 1994 8.2 A Very High Security Cryptographic Key................29 8.2.1 Effort per Key Trial................................29 8.2.2 Meet in the Middle Attacks..........................29 8.2.3 Other Considerations................................30 9. Conclusion.............................................32 10. Security Considerations...............................32 References................................................33 Authors Addresses.........................................35 Eastlake, Crocker, & Schiller [Page 4] RFC XXXX Randomness Requirements for Security December 1994 1. Introduction Software cryptography is coming into wider use. Systems like Kerberos, PEM, PGP, etc. are maturing and becoming a part of the network landscape [PEM]. These systems provide substantial protection against snooping and spoofing. However, there is a potential flaw. At the heart of all cryptographic systems is the generation of secret, unguessable (i.e., random) numbers. For the present, the lack of generally available facilities for generating such unpredictable numbers is an open wound in the design of cryptographic software. For the software developer who wants to build a key or password generation procedure that runs on a wide range of hardware, the only safe strategy so far has been to force the local installation to supply a suitable routine to generate random numbers. To say the least, this is an awkward, error-prone and unpalatable solution. It is important to keep in mind that the requirement is for data that an adversary has a very low probability of guessing or determining. This will fail if pseudo-random data is used which only meets traditional statistical tests for randomness or which is based on limited range sources, such as clocks. Frequently such random quantities are determinable by an adversary searching through an embarrassingly small space of possibilities. This informational document suggests techniques for producing random quantities that will be resistant to such attack. It recommends that future systems include hardware random number generation or provide access to existing hardware that can be used for this purpose. It suggests methods for use if such hardware is not available. And it gives some estimates of the number of random bits required for sample applications. Eastlake, Crocker, & Schiller [Page 5] RFC XXXX Randomness Requirements for Security December 1994 2. Requirements Probably the most commonly encountered randomness requirement today is the user password. This is usually a simple character string. Obviously, if a password can be guessed, it does not provide security. (For re-usable passwords, it is desirable that users be able to remember the password. This may make it advisable to use pronounceable character strings or phrases composed on ordinary words. But this only affects the format of the password information, not the requirement that the password be very hard to guess.) Many other requirements come from the cryptographic arena. Cryptographic techniques can be used to provide a variety of services including confidentiality and authentication. Such services are based on quantities, traditionally called "keys", that are unknown to and unguessable by an adversary. In some cases, such as the use of symmetric encryption with the one time pads [CRYPTO*] or the US Data Encryption Standard [DES], the parties who wish to communicate confidentially and/or with authentication must all know the same secret key. In other cases, using what are called asymmetric or "public key" cryptographic techniques, keys come in pairs. One key of the pair is private and must be kept secret by one party, the other is public and can be published to the world. It is computationally infeasible to determine the private key from the public key. [ASYMMETRIC, CRYPTO*] The frequency and volume of the requirement for random quantities differs greatly for different cryptographic systems. Using pure RSA [CRYPTO*], random quantities are required when the key pair is generated, but thereafter any number of messages can be signed without any further need for randomness. The public key Digital Signature Algorithm that has been proposed by the US National Institute of Standards and Technology (NIST) requires good random numbers for each signature. And encrypting with a one time pad, in principle the strongest possible encryption technique, requires a volume of randomness equal to all the messages to be processed. In most of these cases, an adversary can try to determine the "secret" key by trial and error. (This is possible as long as the key is enough smaller than the message that the correct key can be uniquely identified.) The probability of an adversary succeeding at this must be made acceptably low, depending on the particular application. The size of the space the adversary must search is related to the amount of key "information" present in the information theoretic sense [SHANNON]. This depends on the number of different secret values possible and the probability of each value as follows: Eastlake, Crocker, & Schiller [Page 6] RFC XXXX Randomness Requirements for Security December 1994 ----- \ Bits-of-info = \ - p * log ( p ) / i 2 i / ----- where i varies from 1 to the number of possible secret values and p sub i is the probability of the value numbered i. (Since p sub i is less than one, the log will be negative so each term in the sum will be non-negative.) If there are 2^n different values of equal probability, then n bits of information are present and an adversary would, on the average, have to try half of the values, or 2^(n-1) , before guessing the secret quantity. If the probability of different values is unequal, then there is less information present and fewer guesses will, on average, be required by an adversary. In particular, any values that the adversary can know are impossible, or are of low probability, can be initially ignored by an adversary, who will search through the more probable values first. For example, consider a cryptographic system that uses 56 bit keys. If these 56 bit keys are derived by using a fixed pseudo-random number generator that is seeded with an 8 bit seed, then an adversary needs to search through only 256 keys (by running the pseudo-random number generator with every possible seed), not the 2^56 keys that may at first appear to be the case. Only 8 bits of "information" are in these 56 bit keys. Eastlake, Crocker, & Schiller [Page 7] RFC XXXX Randomness Requirements for Security December 1994 3. Traditional Pseudo-Random Sequences Most traditional sources of random numbers use deterministic sources of "pseudo-random" numbers. These typically start with a "seed" quantity and use numeric or logical operations to produce a sequence of values. [KNUTH] has a classic exposition on pseudo-random numbers. Applications he mentions are simulation of natural phenomena, sampling, numerical analysis, testing computer programs, decision making, and games. None of these have the same characteristics as the sort of security uses we are talking about. Only in the last two could there be an adversary trying to find the random quantity. However, in these cases, the adversary normally has only a single chance to use a guessed value. In guessing passwords or attempting to break an encryption scheme, the adversary normally has many, perhaps unlimited, chances at guessing the correct value and should be assumed to be aided by a computer. For testing the "randomness" of numbers, Knuth suggests a variety of measures including statistical and spectral. These tests check things like autocorrelation between different parts of a "random" sequence or distribution of its values. They could be met by a constant stored random sequence, such as the "random" sequence printed in the CRC Standard Mathematical Tables [CRC]. A typical pseudo-random number generation technique, known as a linear congruence pseudo-random number generator, is modular arithmetic where the N+1th value is calculated from the Nth value by V = ( V * a + b )(Mod c) N+1 N The above technique has a strong relationship to linear shift register pseudo-random number generators, which are well understood cryptographically [SHIFT*]. In such generators bits are introduced at one end of a shift register as the Exclusive Or (binary sum without carry) of bits from selected fixed taps into the register. For example: Eastlake, Crocker, & Schiller [Page 8] RFC XXXX Randomness Requirements for Security December 1994 +----+ +----+ +----+ +----+ | B | <-- | B | <-- | B | <-- . . . . . . <-- | B | <-+ | 0 | | 1 | | 2 | | n | | +----+ +----+ +----+ +----+ | | | | | | | V +-----+ | V +----------------> | | V +-----------------------------> | XOR | +---------------------------------------------------> | | +-----+ V = ( ( V * 2 ) + B .xor. B ... )(Mod 2^n) N+1 N 0 2 The goodness of traditional pseudo-random number generator algorithms is measured by statistical tests on such sequences. Carefully chosen values of the initial V and a, b, and c or the placement of shift register tap in the above simple processes can produce excellent statistics. These sequences may be adequate in simulations (Monte Carlo experiments) as long as the sequence is orthogonal to the structure of the space being explored. Even there, subtle patterns may cause problems. However, such sequences are clearly bad for use in security applications. They are fully predictable if the initial state is known. Depending on the form of the pseudo-random number generator, the sequence may be determinable from observation of a short portion of the sequence [CRYPTO*, STERN]. For example, with the generators above, one can determine V(n+1) given knowledge of V(n). In fact, it has been shown that with these techniques, even if only one bit of the pseudo-random values are released, the seed can be determined from short sequences. Not only have linear congruent generators been broken, but techniques are now known for breaking all polynomial congruent generators. [KRAWCZYK] Eastlake, Crocker, & Schiller [Page 9] RFC XXXX Randomness Requirements for Security December 1994 4. Unpredictability Randomness in the traditional sense described in section 3 is NOT the same as the unpredictability required for security use. For example, use of a widely available constant sequence, such as that from the CRC tables, is very weak against an adversary. Once they learn of or guess it, they can easily break all security, future and past, based on the sequence. [CRC] Yet the statistical properties of these tables are good. The following sections describe the limitations of some randomness generation techniques and sources. 4.1 Problems with Clocks and Serial Numbers Computer clocks, or similar operating system or hardware values, provide significantly fewer real bits of unpredictability than might appear from their specifications. Tests have been done on clocks on numerous systems and it was found that their behavior can vary widely and in unexpected ways. One version of an operating system running on one set of hardware may actually provide, say, microsecond resolution in a clock while a different configuration of the "same" system may always provide the same lower bits and only count in the upper bits at much lower resolution. This means that successive reads on the clock may produce identical values even if enough time has passed that the value "should" change based on the nominal clock resolution. There are also cases where frequently reading a clock can produce artificial sequential values because of extra code that checks for the clock being unchanged between two reads and increases it by one! Designing portable application code to generate unpredictable numbers based on such system clocks is particularly challenging because the system designer does not always know the properties of the system clocks that the code will execute on. Use of a hardware serial number such as an Ethernet address may also provide fewer bits of uniqueness than one would guess. Such quantities are usually heavily structured and subfields may have only a limited range of possible values or values easily guessable based on approximate date of manufacture or other data. For example, it is likely that most of the Ethernet cards installed on Digital Equipment Corporation (DEC) hardware within DEC were manufactured by DEC itself, which significantly limits the range of built in addresses. Problems such as those described above related to clocks and serial numbers make code to produce unpredictable quantities difficult if Eastlake, Crocker, & Schiller [Page 10] RFC XXXX Randomness Requirements for Security December 1994 the code is to be ported across a variety of computer platforms and systems. 4.2 Timing and Content of External Events It is possible to measure the timing and content of mouse movement, key strokes, and similar user events. This is a reasonable source of unguessable data with some qualifications. On some machines, inputs such as key strokes are buffered. Even though the user's inter- keystroke timing may have sufficient variation and unpredictability, there might not be an easy way to access that variation. Another problem is that no standard method exists to sample timing details. This makes it hard to build standard software intended for distribution to a large range of machines based on this technique. The amount of mouse movement or the keys actually hit are usually easier to access than timings but may yield less unpredictability as the user may provide highly repetitive input. Other external events, such as network packet arrival times, can also be used with care. In particular, the possibility of manipulation of such times by an adversary must be considered. 4.3 The Fallacy of Complex Manipulation One strategy which may give a misleading appearance of unpredictability is to take a very complex algorithm (or an excellent traditional pseudo-random number generator with good statistical properties) and calculate a cryptographic key by starting with the current value of a computer system clock as the seed. An adversary who knew roughly when the generator was started would have a relatively small number of seed values to test as they would know likely values of the system clock. Large numbers of pseudo-random bits could be generated but the search space an adversary would need to check could be quite small. Thus very strong and/or complex manipulation of data will not help if the adversary can learn what the manipulation is and there is not enough unpredictability in the starting seed value. Even if they can not learn what the manipulation is, they may be able to use the limited number of results stemming from a limited number of seed values to defeat security. Another serious strategy error is to assume that a very complex pseudo-random number generation algorithm will produce strong random numbers when there has been no theory behind or analysis of the Eastlake, Crocker, & Schiller [Page 11] RFC XXXX Randomness Requirements for Security December 1994 algorithm. There is a excellent example of this fallacy right near the beginning of chapter 3 in [KNUTH] where the author describes a complex algorithm. It was intended that the machine language program corresponding to the algorithm would be so complicated that a person trying to read the code without comments wouldn't know what the program was doing. Unfortunately, actual use of this algorithm showed that it almost immediately converged to a single repeated value in one case and a small cycle of values in another case. Not only does complex manipulation not help you if you have a limited range of seeds but blindly chosen complex manipulation can destroy the randomness in a good seed! 4.4 The Fallacy of Selection from a Large Database Another strategy that can give a misleading appearance of unpredictability is selection of a quantity randomly from a database and assume that its strength is related to the total number of bits in the database. For example, typical USENET servers as of this date process over 35 megabytes of information per day. Assume a random quantity was selected by fetching 32 bytes of data from a random starting point in this data. This does not yield 32*8 = 256 bits worth of unguessability. Even after allowing that much of the data is human language and probably has more like 2 or 3 bits of information per byte, it doesn't yield 32*2.5 = 80 bits of unguessability. For an adversary with access to the same 35 megabytes the unguessability rests only on the starting point of the selection. That is, at best, about 25 bits of unguessability in this case. The same argument applies to selecting sequences from the data on a CD ROM or Audio CD recording or any other large public database. If the adversary has access to the same database, this "selection from a large volume of data" step buys very little. However, if a selection can be made from data to which the adversary has no access, such as system buffers on an active multi-user system, it may be of some help. Eastlake, Crocker, & Schiller [Page 12] RFC XXXX Randomness Requirements for Security December 1994 5. Hardware for Randomness Is there any hope for strong portable randomness in the future? There might be. All that's needed is a physical source of unpredictable numbers. A thermal noise or radioactive decay source and a fast, free-running oscillator would do the trick directly [GIFFORD]. This is a trivial amount of hardware, and could easily be included as a standard part of a computer system's architecture. Furthermore, any system with a spinning disk or the like has an adequate source of randomness [DAVIS]. All that's needed is the common perception among computer vendors that this small additional hardware and the software to access it is necessary and useful. 5.1 Volume Required How much unpredictability is needed? Is it possible to quantify the requirement in, say, number of random bits per second? The answer is not very much is needed. For DES, the key is 56 bits and, as we show in an example in Section 8, even the highest security system is unlikely to require a keying material of over 200 bits. If a series of keys are needed, they can be generated from a strong random seed using a cryptographically strong sequence as explained in Section 6.3. A few hundred random bits generated once a day would be enough using such techniques. Even if the random bits are generated as slowly as one per second and it is not possible to overlap the generation process, it should be tolerable in high security applications to wait 200 seconds occasionally. These numbers are trivial to achieve. It could be done by a person repeatedly tossing a coin. Almost any hardware process is likely to be much faster. 5.2 Sensitivity to Skew Is there any specific requirement on the shape of the distribution of the random numbers? The good news is the distribution need not be uniform. All that is needed is a conservative estimate of how non- uniform it is to bound performance. Two simple techniques to de-skew the bit stream are given below and stronger techniques are mentioned in Section 6.1.2 below. Eastlake, Crocker, & Schiller [Page 13] RFC XXXX Randomness Requirements for Security December 1994 5.2.1 Using Stream Parity to De-Skew Consider taking a sufficiently long string of bits and map the string to "zero" or "one". The mapping will not yield a perfectly uniform distribution, but it can be as close as desired. One mapping that serves the purpose is to take the parity of the string. This has the advantages that it is robust across all degrees of skew up to the estimated maximum skew and is absolutely trivial to implement in hardware. The following analysis gives the number of bits that must be sampled: Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is between 0 and 0.5 and is a measure of the "eccentricity" of the distribution. Consider the distribution of the parity function of N bit samples. The probabilities that the parity will be one or zero will be the sum of the odd or even terms in the binomial expansion of (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 - e, the probability of a zero. These sums can be computed easily as N N 1/2 * ( ( p + q ) + ( p - q ) ) and N N 1/2 * ( ( p + q ) - ( p - q ) ). (Which one corresponds to the probability the parity will be 1 depends on whether N is odd or even.) Since p + q = 1 and p - q = 2e, these expressions reduce to N 1/2 * [1 + (2e) ] and N 1/2 * [1 - (2e) ]. Neither of these will ever be exactly 0.5 unless e is zero, but we can bring them arbitrarily close to 0.5. If we want the probabilities to be within some delta d of 0.5, i.e. then N ( 0.5 + ( 0.5 * (2e) ) ) < 0.5 + d. Solving for N yields N > log(2d)/log(2e). (Note that 2e is less than 1, so its log is negative. Division by a negative number reverses the sense of an inequality.) Eastlake, Crocker, & Schiller [Page 14] RFC XXXX Randomness Requirements for Security December 1994 The following table gives the length of the string which must be sampled for various degrees of skew in order to come within 0.001 of a 50/50 distribution. +---------+--------+-------+ | Prob(1) | e | N | +---------+--------+-------+ | 0.5 | 0.00 | 1 | | 0.6 | 0.10 | 4 | | 0.7 | 0.20 | 7 | | 0.8 | 0.30 | 13 | | 0.9 | 0.40 | 28 | | 0.95 | 0.45 | 59 | | 0.99 | 0.49 | 308 | +---------+--------+-------+ The last entry shows that even if the distribution is skewed 99% in favor of ones, the parity of a string of 308 samples will be within 0.001 of a 50/50 distribution. 5.2.2 Using Transition Mappings to De-Skew Another technique, originally due to von Neumann [VON NEUMANN], is to examine a bit stream as a sequence of non-overlapping pairs. You could then discard any 00 or 11 pairs found, interpret 01 as a 0 and 10 as a 1. Assume the probability of a 1 is 0.5+e and the probability of a 0 is 0.5-e where e is the eccentricity of the source and described in the previous section. Then the probability of each pair is as follows: +------+-----------------------------------------+ | pair | probability | +------+-----------------------------------------+ | 00 | (0.5 - e)^2 = 0.25 - e + e^2 | | 01 | (0.5 - e)*(0.5 + e) = 0.25 - e^2 | | 10 | (0.5 + e)*(0.5 - e) = 0.25 - e^2 | | 11 | (0.5 + e)^2 = 0.25 + e + e^2 | +------+-----------------------------------------+ This technique will completely eliminate any bias but at the expense of taking an indeterminate number of input bits for any particular desired number of output bits. The probability of any particular pair being discarded is 0.5 + 2e^2 so the expected number of input bits to produce X output bits is X/(0.25 - e^2). This technique assumes that the bits are from a stream where each bit has the same probability of being a 0 or 1 as any other bit in the stream and that bits are not correlated, i.e., that the bits are Eastlake, Crocker, & Schiller [Page 15] RFC XXXX Randomness Requirements for Security December 1994 identical independent distributions. If alternate bits were from two correlated sources, for example, the above analysis breaks down. The above technique also provides another illustration of how a simple statistical analysis can mislead if one is not always on the lookout for patterns that could be exploited by an adversary. If the algorithm were mis-read slightly so that overlapping successive bits pairs were used instead of non-overlapping pairs, the statistical analysis given is the same; however, instead of provided an unbiased uncorrelated series of random 1's and 0's, it instead produces a totally predictable sequence of exactly alternating 1's and 0's. 5.2.3 Using FFT to De-Skew When real world data consists of strongly biased or correlated bits, it may still contain useful amounts of randomness. This randomness can be extracted through use of the discrete Fourier transform or its optimized variant, the FFT. Using the Fourier transform of the data, strong correlations can be discarded. If adequate data is processed and remaining correlations decay, spectral lines approaching statistical independence and normally distributed randomness can be produced [BRILLINGER]. 5.2.4 Using Compression to De-Skew Reversible compression techniques also provide a crude method of de- skewing a skewed bit stream. This follows directly from the definition of reversible compression and the formula in Section 2 above for the amount of information in a sequence. Since the compression is reversible, the same amount of information must be present in the shorter output than was present in the longer input. By the Shannon information equation, this is only possible if, on average, the probabilities of the different shorter sequences are more uniformly distributed than were the probabilities of the longer sequences. Thus the shorter sequences are de-skewed relative to the input. However, many compression techniques add a somewhat predicatable preface to their output stream and may insert such a sequence again periodically in their output or otherwise introduce subtle patterns of their own. They should be considered only a rough technique compared with those described above or in Section 6.1.2. At a minimum, the beginning of the compressed sequence should be skipped and only later bits used for applications requiring random bits. Eastlake, Crocker, & Schiller [Page 16] RFC XXXX Randomness Requirements for Security December 1994 5.3 Existing Hardware Can Be Used For Randomness As described below, many computers come with hardware that can, with care, be used to generate truly random quantities. 5.3.1 Using Existing Sound/Video Input Increasingly computers are being built with inputs that digitize some real world analog source, such as sound from a microphone or video input from a camera. Under appropriate circumstances, such input can provide reasonably high quality random bits. The "input" from a sound digitizer with no source plugged in or a camera with the lens cap on, if the system has enough gain to detect anything, is essentially thermal noise. For example, on a SPARCstation, one can read from the /dev/audio device with nothing plugged into the microphone jack. Such data is essentially random noise although it should not be trusted without some checking in case of hardware failure. It will, in any case, need to be de-skewed as described elsewhere. Combining this with compression to de-skew one can, in UNIXese, generate a huge amount of medium quality random data by doing cat /dev/audio | compress - >random-bits-file 5.3.2 Using Existing Disk Drives Disk drives have small random fluctuations in their rotational speed due to chaotic air turbulence [DAVIS]. By adding low level disk seek time instrumentation to a system, a series of measurements can be obtained that include this randomness. Such data is usually highly correlated so that significant processing is needed, including FFT (see section 5.2.3). Nevertheless experimentation has shown that, with such processing, disk drives easily produce 100 bits a minute or more of excellent random data. Partly offsetting this need for processing is the fact that disk drive failure will normally be rapidly noticed. Thus, problems with this method of random number generation due to hardware failure are very unlikely. Eastlake, Crocker, & Schiller [Page 17] RFC XXXX Randomness Requirements for Security December 1994 6. Recommended Non-Hardware Strategy What is the best overall strategy for meeting the requirement for unguessable random numbers in the absence of a reliable hardware source? It is to obtain random input from a large number of uncorrelated sources and to mix them with a strong mixing function. Such a function will preserve the randomness present in any of the sources even if other quantities being combined are fixed or easily guessable. This may be advisable even with a good hardware source as hardware can also fail, though this should be weighed against any increase in the chance of overall failure due to added software complexity. 6.1 Mixing Functions A strong mixing function is one which combines two or more inputs and produces an output where each output bit is a different complex non- linear function of all the input bits. On average, changing any input bit will change about half the output bits. But because the relationship is complex and non-linear, no particular output bit is guaranteed to change when any particular input bit is changed. Consider the problem of converting a stream of bits that is skewed towards 0 or 1 to a shorter stream which is more random, as discussed in Section 5.2 above. This is simply another case where a strong mixing function is desired, mixing the input bits to produce a smaller number of output bits. The technique given in Section 5.2.1 of using the parity of a number of bits is simply the result of successively Exclusive Or'ing them which is examined as a trivial mixing function immediately below. Use of stronger mixing functions to extract more of the randomness in a stream of skewed bits is examined in Section 6.1.2. 6.1.1 A Trivial Mixing Function A trivial example for single bit inputs is the Exclusive Or function, which is equivalent to addition without carry, as show in the table below. This is a degenerate case in which the one output bit always changes for a change in either input bit. But, despite its simplicity, it will still provide a useful illustration. Eastlake, Crocker, & Schiller [Page 18] RFC XXXX Randomness Requirements for Security December 1994 +-----------+-----------+----------+ | input 1 | input 2 | output | +-----------+-----------+----------+ | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 | +-----------+-----------+----------+ If inputs 1 and 2 are uncorrelated and combined in this fashion then the output will be an even better (less skewed) random bit than the inputs. If we assume an "eccentricity" e as defined in Section 5.2 above, then the output eccentricity relates to the input eccentricity as follows: e = 2 * e * e output input 1 input 2 Since e is never greater than 1/2, the eccentricity is always improved except in the case where at least one input is a totally skewed constant. This is illustrated in the following table where the top and left side values are the two input eccentricities and the entries are the output eccentricity: +--------+--------+--------+--------+--------+--------+--------+ | e | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 | +--------+--------+--------+--------+--------+--------+--------+ | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | | 0.10 | 0.00 | 0.02 | 0.04 | 0.06 | 0.08 | 0.10 | | 0.20 | 0.00 | 0.04 | 0.08 | 0.12 | 0.16 | 0.20 | | 0.30 | 0.00 | 0.06 | 0.12 | 0.18 | 0.24 | 0.30 | | 0.40 | 0.00 | 0.08 | 0.16 | 0.24 | 0.32 | 0.40 | | 0.50 | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 | +--------+--------+--------+--------+--------+--------+--------+ However, keep in mind that the above calculations assume that the inputs are not correlated. If the inputs were, say, the parity of the number of minutes from midnight on two clocks accurate to a few seconds, then each might appear random if sampled at random intervals much longer than a minute. Yet if they were both sampled and combined with xor, the result would be zero most of the time. 6.1.2 Stronger Mixing Functions The US Government Data Encryption Standard [DES] is an example of a strong mixing function for multiple bit quantities. It takes up to 120 bits of input (64 bits of "data" and 56 bits of "key") and produces 64 bits of output each of which is dependent on a complex Eastlake, Crocker, & Schiller [Page 19] RFC XXXX Randomness Requirements for Security December 1994 non-linear function of all input bits. Other strong encryption functions with this characteristic can also be used by considering them to mix all of their key and data input bits. Another good family of mixing functions are the "message digest" or hashing functions such as The US Government Secure Hash Standard [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series. These functions all take an arbitrary amount of input and produce an output mixing all the input bits. The MD* series produce 128 bits of output and SHS produces 160 bits. Although the message digest functions are designed for variable amounts of input, DES and other encryption functions can also be used to combine any number of inputs. If 64 bits of output is adequate, the inputs can be packed into a 64 bit data quantity and successive 56 bit keys, padding with zeros if needed, which are then used to successively encrypt using DES in Electronic Codebook Mode [DES MODES]. If more than 64 bits of output are needed, use more complex mixing. For example, if inputs are packed into three quantities, A, B, and C, use DES to encrypt A with B as a key and then with C as a key to produce the 1st part of the output, then encrypt B with C and then A for more output and, if necessary, encrypt C with A and then B for yet more output. Still more output can be produced by reversing the order of the keys given above to stretch things. The same can be done with the hash functions by hashing various subsets of the input data to produce multiple outputs. But keep in mind that it is impossible to get more bits of "randomness" out than are put in. An example of using a strong mixing function would be to reconsider the case of a string of 308 bits each of which is biased 99% towards zero. The parity technique given in Section 5.2.1 above reduced this to one bit with only a 1/1000 deviance from being equally likely a zero or one. But, applying the equation for information given in Section 2, this 308 bit sequence has 5 bits of information in it. Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the result would yield 5 unbiased random bits as opposed to the single bit given by calculating the parity of the string. 6.1.3 Diff-Hellman as a Mixing Function Diffie-Hellman exponential key exchange is a technique that yields a shared secret between two parties that can be made computationally infeasible for a third party to determine even if they can observe all the messages between the two communicating parties. This shared secret is a mixture of initial quantities generated by each of them [D-H]. If these initial quantities are random, then the shared secret contains the combined randomness of them both, assuming they are uncorrelated. Eastlake, Crocker, & Schiller [Page 20] RFC XXXX Randomness Requirements for Security December 1994 6.1.4 Using a Mixing Function to Stretch Random Bits While it is not necessary for a mixing function to produce the same or fewer bits than its inputs, mixing bits cannot "stretch" the amount of random unpredictability present in the inputs. Thus four inputs of 32 bits each where there is 12 bits worth of unpredicatability (such as 4,096 equally probable values) in each input cannot produce more than 48 bits worth of unpredictable output. The output can be expanded to hundreds or thousands of bits by, for example, mixing with successive integers, but the clever adversary's search space is still 2^48 possibilities. Furthermore, mixing to fewer bits than are input will tend to strengthen the randomness of the output the way using Exclusive Or to produce one bit from two did above. The last table in Section 6.1.1 shows that mixing a random bit with a constant bit with Exclusive Or will produce a random bit. While this is true, it does not provide a way to "stretch" one random bit into more than one. If, for example, a random bit is mixed with a 0 and then with a 1, this produces a two bit sequence but it will always be either 01 or 10. Since there are only two possible values, there is still only the one bit of original randomness. 6.1.5 Other Factors in Choosing a Mixing Function For local use, DES has the advantages that it has been widely tested for flaws, is widely documented, and is widely implemented with hardware and software implementations available all over the world including source code available by anonymous FTP. The SHS and MD* family are younger algorithms which have been less tested but there is no particular reason to believe they are flawed. Both MD5 and SHS were derived from the earlier MD4 algorithm. They all have source code available by anonymous FTP [SHS, MD2, MD4, MD5]. DES and SHS have been vouched for the the US National Security Agency (NSA) on the basis of criteria that primarily remain secret. While this is the cause of much speculation and doubt, investigation of DES over the years has indicated that NSA involvement in modifications to its design, which originated with IBM, was primarily to strengthen it. No concealed or special weakness has been found in DES. It is almost certain that the NSA modification to MD4 to produce the SHS similarly strengthened the algorithm, possibly against threats not yet known in the public cryptographic community. DES, SHS, MD4, and MD5 are royalty free for all purposes. MD2 has been freely licensed only for non-profit use in connection with Privacy Enhanced Mail [PEM]. Between the MD* algorithms, some people believe that, as with "Goldilocks and the Three Bears", MD2 is strong Eastlake, Crocker, & Schiller [Page 21] RFC XXXX Randomness Requirements for Security December 1994 but too slow, MD4 is fast but too weak, and MD5 is just right. Another advantage of the MD* or similar hashing algorithms over encryption algorithms is that they are not subject to the same regulations imposed by the US Government prohibiting the unlicensed export or import of encryption/decryption software and hardware. The same should be true of DES rigged to produce an irreversible hash code but most DES packages are oriented to reversible encryption. 6.2 Non-Hardware Sources of Randomness The best source of input for mixing would be a hardware randomness such as disk drive timing effected by air turbulence, audio input with thermal noise, or radioactive decay. However, if that is not available there are other possibilities. These include system clocks, system or input/output buffers, user/system/hardware/network serial numbers and/or addresses and timing, and user input. Unfortunately, any of these sources can produce limited or predicatable values under some circumstances. Some of the sources listed above would be quite strong on multi-user systems where, in essence, each user of the system is a source of randomness. However, on a small single user system, such as a typical IBM PC or Apple Macintosh, it might be possible for an adversary to assemble a similar configuration. This could give the adversary inputs to the mixing process that were sufficiently correlated to those used originally as to make exhaustive search practical. The use of multiple random inputs with a strong mixing function is recommended and can overcome weakness in any particular input. For example, the timing and content of requested "random" user keystrokes can yield hundreds of random bits but conservative assumptions need to be made. For example, assuming a few bits of randomness if the inter-keystroke interval is unique in the sequence up to that point and a similar assumption if the key hit is unique but assuming that no bits of randomness are present in the initial key value or if the timing or key value duplicate previous values. The results of mixing these timings and characters typed could be further combined with clock values and other inputs. This strategy may make practical portable code to produce good random numbers for security even if some of the inputs are very weak on some of the target systems. However, it may still fail against a high grade attack on small single user systems, especially if the adversary has ever been able to observe the generation process in the past. A hardware based random source is still preferable. Eastlake, Crocker, & Schiller [Page 22] RFC XXXX Randomness Requirements for Security December 1994 6.3 Cryptographically Strong Sequences In cases where a series of random quantities must be generated, an adversary may learn some values in the sequence. In general, they should not be able to predict other values from the ones that they know. The correct technique is to start with a strong random seed, take cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and do not reveal the complete state of the generator in the sequence elements. If each value in the sequence can be calculated in a fixed way from the previous value, then when any value is compromised, all future values can be determined. This would be the case, for example, if each value were a constant function of the previously used values, even if the function were a very strong, non-invertible message digest function. It should be noted that if your technique for generating a sequence of key values is fast enough, it can trivially be used as the basis for a confidentiality system. If two parties use the same sequence generating technique and start with the same seed material, they will generate identical sequences. These could, for example, be xor'ed at one end with data being send, encrypting it, and xor'ed with this data as received, decrypting it due to the reversible properties of the xor operation. 6.3.1 Traditional Strong Sequences A traditional way to achieve a strong sequence has been to have the values be produced by hashing the quantities produced by concatenating the seed with successive integers or the like and then mask the values obtained so as to limit the amount of generator state available to the adversary. It may also be possible to use an "encryption" algorithm with a random key and seed value to encrypt and feedback some of the output encrypted value into the value to be encrypted for the next iteration. Appropriate feedback techniques will usually be recommended with the encryption algorithm. An example is shown below where shifting and masking are used to combine the cypher output feedback. This type of feedback is recommended in connection with DES [DES MODES]. Eastlake, Crocker, & Schiller [Page 23] RFC XXXX Randomness Requirements for Security December 1994 +---------------+ | V | | | n | +--+------------+ | | +---------+ | +---------> | | +-----+ +--+ | Encrypt | <--- | Key | | +-------- | | +-----+ | | +---------+ V V +------------+--+ | V | | | n+1 | +---------------+ Note that if a shift of one is used, this is the same as the shift register technique described in Section 3 above but with the all important difference that the feedback is determined by a complex non-linear function of all bits rather than a simple linear or polynomial combination of output from a few bit position taps. To predict values of a sequence from others when the sequence was generated by these techniques is equivalent to breaking the cryptosystem or inverting the "non-invertible" hashing involved with only partial information available. The less information revealed each iteration, the harder it will be for an adversary to predict the sequence. Thus it is best to use only one bit from each value. It has been shown that in some cases this makes it impossible to break a system even when the cryptographic system is invertible and can be broken if all of each generated value was revealed. 6.3.2 The Blum Blum Shub Sequence Generator Currently the generator which has the strongest public proof of strength is called the Blum Blum Shub generator after its inventors [BBS]. It is also very simple and is based on quadratic residues. It's only disadvantage is that is is computationally intensive compared with the traditional techniques give in 6.3.1 above. This is not a serious draw back if it is used for moderately infrequent purposes, such as generating session keys. Simply choose two large prime numbers, say p and q, which both have the property that you get a remainder of 3 if you divide them by 4. Let n = p * q. Then you choose a random number x relatively prime to n. The initial seed for the generator and the method for calculating subsequent values are then Eastlake, Crocker, & Schiller [Page 24] RFC XXXX Randomness Requirements for Security December 1994 2 s = ( x )(Mod n) 0 2 s = ( s )(Mod n) i+1 i You must be careful to use only a few bits from the bottom of each s. It is always safe to use only the lowest order bit. If you use no more than the log ( log ( s ) ) 2 2 i low order bits, then predicting any additional bits from a sequence generated in this manner is provable as hard as factoring n. As long as the initial x is secret, you can even make n public if you want. An intersting characteristic of this generator is that you can directly calculate any of the s values. In particular i ( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) ) s = ( s )(Mod n) i 0 This means that in applications where many keys are generated in this fashion, it is not necessary to save them all. Each key can be effectively indexed and recovered from that small index and the initial s and n. Eastlake, Crocker, & Schiller [Page 25] RFC XXXX Randomness Requirements for Security December 1994 7. Key Generation Standards Several public standards are now in place for the generation of keys. Two of these are described below. Both use DES but any equally strong or stronger mixing function could be substituted. 7.1 US DoD Recommendations for Password Generation The United States Department of Defense has specific recommendations for password generation [DoD]. They suggest using the US Data Encryption Standard [DES] in Output Feedback Mode [DES MODES] as follows: use an initialization vector determined from the system clock, system ID, user ID, and date and time; use a key determined from system interrupt registers, system status registers, and system counters; and, as plain text, use an external randomly generated 64 bit quantity such as 8 characters typed in by a system administrator. The password can then be calculated from the 64 bit "cipher text" generated in 64-bit Output Feedback Mode. As many bits as are needed can be taken from these 64 bits and expanded into a pronounceable word, phrase, or other format if a human being needs to remember the password. 7.2 X9.17 Key Generation The American National Standards Institute has specified a method for generating a sequence of keys as follows: s is the initial 64 bit seed 0 g is the sequence of generated 64 bit key quantities n k is a random key reserved for generating this key sequence Eastlake, Crocker, & Schiller [Page 26] RFC XXXX Randomness Requirements for Security December 1994 t is the time at which a key is generated to as fine a resolution as is available (up to 64 bits). DES ( K, Q ) is the DES encryption of quantity Q with key K g = DES ( k, DES ( k, t ) .xor. s ) n n s = DES ( k, DES ( k, t ) .xor. g ) n+1 n If g sub n is to be used as a DES key, then every eighth bit should be adjusted for parity for that use but the entire 64 bit unmodified g should be used in calculating the next s. Eastlake, Crocker, & Schiller [Page 27] RFC XXXX Randomness Requirements for Security December 1994 8. Examples of Randomness Required Below are two examples showing rough calculations of needed randomness for security. The first is for moderate security passwords while the second assumes a need for a very high security cryptographic key. 8.1 Password Generation Assume that user passwords change once a year and it is desired that the probability that an adversary could guess the password for a particular account be less than one in a thousand. Further assume that sending a password to the system is the only way to try a password. Then the crucial question is how often an adversary can try possibilities. Assume that delays have been introduced into a system so that, at most, an adversary can make one password try every six seconds. That's 600 per hour or about 15,000 per day or about 5,000,000 tries in a year. Assuming any sort of monitoring, it is unlikely someone could actually try continuously for a year. In fact, even if log files are only checked monthly, 500,000 tries is more plausible before the attack is noticed and steps taken to change passwords and make it harder to try more passwords. To have a one in a thousand chance of guessing the password in 500,000 tries implies a universe of at least 500,000,000 passwords or about 2^29. Thus 29 bits of randomness are needed. This can probably be achieved using the US DoD recommended inputs for password generation as it has 8 inputs which probably average over 5 bits of randomness each (see section 7.1). Using a list of 1000 words, the password could be expressed as a three word phrase (1,000,000,000 possibilities) or, using case insensitive letters and digits, six would suffice ((26+10)^6 = 2,176,782,336 possibilities). For a higher security password, the number of bits required goes up. To decrease the probability by 1,000 requires increasing the universe of passwords by the same factor which adds about 10 bits. Thus to have only a one in a million chance of a password being guessed under the above scenario would require 39 bits of randomness and a password that was a four word phrase from a 1000 word list or eight letters/digits. To go to a one in 10^9 chance, 49 bits of randomness are needed implying a five word phrase or ten letter/digit password. In a real system, of course, there are also other factors. For example, the larger and harder to remember passwords are, the more likely users are to write them down resulting in an additional risk of compromise. Eastlake, Crocker, & Schiller [Page 28] RFC XXXX Randomness Requirements for Security December 1994 8.2 A Very High Security Cryptographic Key Assume that a very high security key is needed for symmetric encryption / decryption between two parties. Assume an adversary can observe communications and knows the algorithm being used. Within the field of random possibilities, the adversary can try key values in hopes of finding the one in use. Assume further that brute force trial of keys is the best the adversary can do. 8.2.1 Effort per Key Trial How much effort will it take to try each key? For very high security applications it is best to assume a low value of effort. Even if it would clearly take tens of thousands of computer cycles or more to try a single key, there may be some pattern that enables huge blocks of key values to be tested with much less effort per key. Thus it is probably best to assume no more than a couple hundred cycles per key. (There is no clear lower bound on this as computers operate in parallel on a number of bits and a poor encryption algorithm could allow many keys or even groups of keys to be tested in parallel. However, we need to assume some value and can hope that a reasonably strong algorithm has been chosen for our hypothetical high security task.) If the adversary can command a highly parallel processor or a large network of work stations, 2*10^10 cycles per second is probably a minimum assumption for availability today. Looking forward just a couple years, there should be at least an order of magnitude improvement. Thus assuming 10^9 keys could be checked per second or 3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is reasonable. This implies a need for a minimum of 51 bits of randomness in keys to be sure they cannot be found in a month. Even then it is possible that, a few years from now, a highly determined and resourceful adversary could break the key in 2 weeks (on average they need try only half the keys). 8.2.2 Meet in the Middle Attacks If chosen or known plain text and the resulting encrypted text are available, a "meet in the middle" attack is possible if the structure of the encryption algorithm allows it. (In a known plain text attack, the adversary knows all or part of the messages being encrypted, possibly some standard header or trailer fields. In a chosen plain text attack, the adversary can force some chosen plain text to be encrypted, possibly by "leaking" an exciting text that would then be sent by the adversary over an encrypted channel.) Eastlake, Crocker, & Schiller [Page 29] RFC XXXX Randomness Requirements for Security December 1994 An oversimplified explanation of the meet in the middle attack is as follows: the adversary can half-encrypt the known or chosen plain text with all possible first half-keys, sort the output, then half- decrypt the encoded text with all the second half-keys. If a match is found, the full key can be assembled from the halves and used to decrypt other parts of the message or other messages. At its best, this type of attack can halve the exponent of the work required by the adversary while adding a large but roughly constant factor of effort. To be assured of safety against this, a doubling of the amount of randomness in the key to a minimum of 102 bits is required. The meet in the middle attack assumes that the cryptographic algorithm can be decomposed in this way but we can not rule that out without a deep knowledge of the algorithm. Even if a basic algorithm is not subject to a meet in the middle attack, an attempt to produce a stronger algorithm by applying the basic algorithm twice (or two different algorithms sequentially) with different keys may gain less added security than would be expected. Such a composite algorithm would be subject to a meet in the middle attack. Enormous resources may be required to mount a meet in the middle attack but they are probably within the range of the national security services of a major nation. Essentially all nations spy on other nations government traffic and several nations are believed to spy on commercial traffic for economic advantage. 8.2.3 Other Considerations Since we have not even considered the possibilities of special purpose code breaking hardware or just how much of a safety margin we want beyond our assumptions above, probably a good minimum for a very high security cryptographic key is 128 bits of randomness which implies a minimum key length of 128 bits. If the two parties agree on a key by Diffie-Hellman exchange [D-H], then in principle only half of this randomness would have to be supplied by each party. However, there is probably some correlation between their random inputs so it is probably best to assume that each party needs to provide at least 96 bits worth of randomness for very high security if Diffie-Hellman is used. This amount of randomness is beyond the limit of that in the inputs recommended by the US DoD for password generation and could require user typing timing, hardware random number generation, or other sources. It should be noted that key length calculations such at those above are controversial and depend on various assumptions about the cryptographic algorithms in use. In some cases, a professional with Eastlake, Crocker, & Schiller [Page 30] RFC XXXX Randomness Requirements for Security December 1994 a deep knowledge of code breaking techniques and of the strength of the algorithm in use could be satisfied with less than half of the key size derived above. Eastlake, Crocker, & Schiller [Page 31] RFC XXXX Randomness Requirements for Security December 1994 9. Conclusion Generation of unguessable "random" secret quantities for security use is an essential but difficult task. We have shown that hardware techniques to produce such randomness would be relatively simple. In particular, the volume and quality would not need to be high and existing computer hardware, such as disk drives, can be used. Computational techniques are available to process low quality random quantities from multiple sources or a larger quantity of such low quality input from one source and produce a smaller quantity of higher quality, less predictable key material. In the absence of hardware sources of randomness, a variety of user and software sources can frequently be used instead with care; however, most modern systems already have hardware, such as disk drives or audio input, that could be used to produce high quality randomness. Once a sufficient quantity of high quality seed key material (a few hundred bits) is available, strong computational techniques are available to produce cryptographically strong sequences of unpredicatable quantities from this seed material. 10. Security Considerations The entirety of this document concerns techniques and recommendations for generating unguessable "random" quantities for use as passwords, cryptographic keys, and similar security uses. Eastlake, Crocker, & Schiller [Page 32] RFC XXXX Randomness Requirements for Security December 1994 References [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems, edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview Press, Inc. [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub. [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day, 1981, David Brillinger. [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber Publishing Company. [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication, John Wiley & Sons, 1981, Alan G. Konheim. [CRYPTO2] - Cryptography: A New Dimension in Computer Data Security, A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H. Meyer & Stephen M. Matyas. [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, 1994, Bruce Schneier. [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and Philip Fenstermacher. [DES] - Data Encryption Standard, United States of America, Department of Commerce, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) 46-1. - Data Encryption Algorithm, American National Standards Institute, ANSI X3.92-1981. (See also FIPS 112, Password Usage, which includes FORTRAN code for performing DES.) [DES MODES] - DES Modes of Operation, United States of America, Department of Commerce, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) 81. - Data Encryption Algorithm - Modes of Operation, American National Standards Institute, ANSI X3.106-1983. [D-H] - New Directions in Cryptography, IEEE Transactions on Information Technology, November, 1976, Whitfield Diffie and Martin E. Hellman. [DoD] - Password Management Guideline, United States of America, Department of Defense, Computer Security Center, CSC-STD-002-85. Eastlake, Crocker, & Schiller [Page 33] RFC XXXX Randomness Requirements for Security December 1994 (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85 as one of its appendices.) [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988, David K. Gifford [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing Company, Second Edition 1982, Donald E. Knuth. [KRAWCZYK] - How to Predict Congruential Generators, Journal of Algorithms, V. 13, N. 4, December 1992, H. Krawczyk [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B. Kaliski [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R. Rivest [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R. Rivest [PEM] - RFCs 1421 through 1424: - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, 02/10/1993, B. Kaliski - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, 02/10/1993, S. Kent - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, 02/10/1993, J. Linn [SHANNON] - The Mathematical Theory of Communication, University of Illinois Press, 1963, Claude E. Shannon. (originally from: Bell System Technical Journal, July and October 1948) [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised Edition 1982, Solomon W. Golomb. [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher Systems, Aegean Park Press, 1984, Wayne G. Barker. [SHS] - Secure Hash Standard, United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 180, April 1993. [STERN] - Secret Linear Congruential Generators are not Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern. [VON NEUMANN] - Various techniques used in connection with random digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963, J. von Neumann. Eastlake, Crocker, & Schiller [Page 34] RFC XXXX Randomness Requirements for Security December 1994 Authors Addresses Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Stephen D. Crocker CyberCash Inc. 2086 Hunters Crest Way Vienna, VA 22181 Telephone: +1 703-620-1222(w) +1 703-391-2651 (fax) EMail: crocker@cybercash.com Jeffrey I. Schiller Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 Telephone: +1 617 253 0161(w) EMail: jis@mit.edu Eastlake, Crocker, & Schiller [Page 35] From ipsec-request@ans.net Wed Dec 14 08:53:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16033 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 03:59:37 -0500 Received: by interlock.ans.net id AA07827 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 03:53:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 03:53:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 03:53:13 -0500 From: szabo@netcom.com (Nick Szabo) Message-Id: <199412140853.AAA14435@netcom14.netcom.com> Subject: Re: key management To: karn@qualcomm.com (Phil Karn) Date: Wed, 14 Dec 1994 00:53:09 -0800 (PST) Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199412140509.VAA11595@servo.qualcomm.com> from "Phil Karn" at Dec 13, 94 09:09:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1103 Phil Karn: > Perry's concerns are valid, but they all seem to address what I'd call > certificate management, as opposed to session key management which is > what we're really discussing right now. In the tried-and-true > tradition of the Internet, we've been building IP security bottom-up, > which I think is the right thing to do. If we design the bottom elements before designing the certificate management, we need to make sure that these elements are independent of any particular model of certificate management, whether hierarchical, web of trust, or some of the interesting Kerberos-inspired ideas Perry has proposed. Indeed, perhaps we should not assume that _any_ certificate management scheme will work. I'm seeing a trend of public key distribution becoming the hangup of a wide variety of Internet commerce and security endeavors. X.509 is widely distrusted in the context of the Internet, and the informal PGP web of trust seems quite unsatisfactory to many. If it doesn't get discussed here I hope we can find another high SNR forum for it. Nick Szabo szabo@netcom.com From ipsec-request@ans.net Wed Dec 14 02:00:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16856 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 07:16:20 -0500 Received: by interlock.ans.net id AA30561 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 07:08:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 07:08:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 07:08:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 07:08:52 -0500 Date: Wed, 14 Dec 94 07:00:35 EST From: cmadson@wellfleet.com (Cheryl Madson) Message-Id: <9412141200.AA19289@wellfleet> To: ipsec@ans.net Subject: user keys Cc: cmadson@wellfleet.com This is a very fast delurk: I can't put my hands on Ran's spec at the moment. Anyhow, I trust that the requirement on per-user keying is for end systems only (or for intermediate systems that need to protect the data that they themselves generate); I hope that this wasn't being envisioned for encrypting routers or other external "transparant" encrypting devices. After I finish my beta-release firedrill, I'll have more comments to make about security associations. After I catch my breath ;-). - C From ipsec-request@ans.net Wed Dec 14 13:45:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29454 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 08:51:24 -0500 Received: by interlock.ans.net id AA28386 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 08:45:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 14 Dec 1994 08:45:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 08:45:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 08:45:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 08:45:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 08:45:42 -0500 Message-Id: <9412141345.AA32702@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Clogging attacks on SKIP: can we assume Kij is precomputed In-Reply-To: Your message of "Tue, 13 Dec 1994 11:35:49 PST." <9412131935.AA29173@miraj.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 08:45:38 -0500 From: " " Ashar and other collegues, In Ashar's response I found two different issues which we should clarify. I'll dedicate this note to the first, which is: can we assume in SKIP that the receiver can pre-compute all Kij pairs. It apprears to me that's what Ashar suggests: > First, let me mention that the pair keys Kij always (conceptually) > exist, and can be precomputed *prior* to any communication attempt. > I think this is not reasonable for many applications. In particular, it is not reasonable for the `firewall' application where a firewall of an organization is the endpoint of (some) tunnels leading to the organization, a scenario which the group has decided we must support (see Paul's note). The number of potential Kij's is simply too large (practically unbounded). > This can be done by following a prioritized list using the per node > ACL (which you always need, because otherwise there is no need to > authenticate). Allow me to disagree: you don't always need an ACL (certainly not an `explicit ACL' - even when ACL is needed, many times one can have `wildcards' to specify large groups). For example, some firewalls may have a policy to allow all communication in, except for some blacklisted, but also log the event (and use the authentication to maintain the blacklist). Others may allow all communication from any machine belonging to specific trading partners or to all internal machines. While these examples are dramatic for the firewall scenario, they apply almost as well to `regular' hosts. > Note that this sort of precomputation cannot be performed > using traditional (non-SKIP) interactive schemes, because there > are no shared secrets prior to communication. Again I must disagree. The pre-computation involves also getting the (certified or otherwise authenticated) public keys. This is just the same as the initial communication (and computation) of any other scheme for long-lived keys. > This precomputation > can follow usage patterns of the machine, or some administrative > action. > Agree with this statement. The clogging attack results from the fact the attacker is not limited to your _usual_ patterns. You either risk denying service to unusual patterns or getting clogged. In any case this is an administration problem one has to address and warn the implementors from. I"ll try to respond on your other points later. Best, Amir From ipsec-request@ans.net Wed Dec 14 14:16:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35563 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 09:23:16 -0500 Received: by interlock.ans.net id AA37248 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 09:17:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 09:17:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 09:17:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 09:17:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 09:17:32 -0500 Message-Id: <9412141416.AA13822@snark.imsi.com> To: Hilarie Orman Cc: karn@qualcomm.com, ipsec@ans.net Subject: Re: Diffie-Hellman (note by Hugo) In-Reply-To: Your message of "Tue, 13 Dec 1994 18:25:31 MST." <199412140125.SAA03833@umbra.CS.Arizona.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 09:16:49 -0500 From: "Perry E. Metzger" Hilarie Orman says: > > I don't really think the cost of Diffie-Hellman is all that > > intolerable. I used it all last week on my not-blazingly-fast laptop. > > It took a few seconds each time, not so long to tempt me to bypass it. > > I'm concerned that this might cease to be true for hosts running applications > that require connections to lots of different hosts. Distributed system > maintenance actions, for example. The question is not so much the number of connections you have as how often you get a connection, since that is when SAIDs are negotiated. Given Phil's methods, most of the calculation can be done in background and only two exponentiations need be done in "real time". Even fairly loaded mail servers that I have run have received connections on a fairly evenly distributed basis, so this does not seem overly onerous even on today's hardware. What I am more concerned about is that we are tying our negotiations to a particular algorithm rather than a particular protocol. If next week Diffie Hellman were somehow broken (and remember that no complete proof of the equivalence of D-H and the discrete log problem has ever been produced, although proofs with "holes" have been achieved), we would all be up the creek -- ditto for all our other algorithms. More realistically, there are likely to be better algorithms developed someday. I'd prefer if we had a format that contained "Hi there; I'm a key negotiation packet. I'd like to use D-H to negotiate with you (and to speed things up if you accept I've got a D-H component embedded so that if you accept I don't have to send it in another packet) but if you don't want to use D-H I also deal with Kerberos and Foobar-97." In other words, I'd like to have a baseline requirement that you use D-H, and the ability to optimise whatever we use so that we don't send a dozen packets, but it would be very nice if we could build our protocol such that we are not out of luck should we find in five years that fast gazorknoplant key negotiation (developed the previous month) is far better than D-H. Perry From ipsec-request@ans.net Wed Dec 14 14:20:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35568 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 09:23:58 -0500 Received: by interlock.ans.net id AA26800 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 09:21:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 09:21:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 09:21:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 09:21:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 09:21:09 -0500 Message-Id: <9412141420.AA13831@snark.imsi.com> To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 19:38:50 MST." <199412140238.TAA06409@umbra.CS.Arizona.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 09:20:42 -0500 From: "Perry E. Metzger" Hilarie Orman says: > > On the receive side, the network layer passes > > the SAID up with the (decrypted) packet so that the transport can > > compare the SAID against the one it is supposed to be using for the > > socket in question. > > Do you mean that the transport layer checks that the user id associated > with the SAID is the same as the user id associated with the socket? No. The socket could only be bound to a particular SAID by the owner of the SAID -- that check need only be done once. The transport need merely make sure that if it has been set to use a SAID for its work that the network layer's idea of what SAID was being used is the same as its own. Perry From ipsec-request@ans.net Wed Dec 14 14:58:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38679 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 10:02:15 -0500 Received: by interlock.ans.net id AA03438 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 09:58:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 09:58:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 09:58:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 09:58:12 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 09:58:21 -0500 To: cmadson@wellfleet.com (Cheryl Madson), ipsec@ans.net From: crocker@cybercash.com (Steve Crocker) Subject: Re: user keys Cc: cmadson@wellfleet.com "delurk"!? I love it! -------------------- Steve Crocker CyberCash, Inc. Work: +1 703 620 1222 2086 Hunters Crest Way Fax: +1 703 391 2651 Vienna, VA 22181 crocker@cybercash.com From ipsec-request@ans.net Wed Dec 14 16:32:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16913 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 11:34:26 -0500 Received: by interlock.ans.net id AA33329 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 11:32:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 11:32:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 11:32:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 11:32:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 11:32:33 -0500 Message-Id: <9412141632.AA14068@snark.imsi.com> To: ipsec@ans.net Subject: key management layering Date: Wed, 14 Dec 1994 11:32:11 -0500 From: "Perry E. Metzger" [this is the second copy of this message; the first appears to have bounced. I am sorry if you see it more than once.] Phil Karn says: > >I believe that many of the given key management protocols are still > >deficient in so far as > > Perry's concerns are valid, but they all seem to address what I'd call > certificate management, as opposed to session key management which is > what we're really discussing right now. In the tried-and-true > tradition of the Internet, we've been building IP security bottom-up, > which I think is the right thing to do. Your point about the fact that these should be handled in separate layers is, in my opinion, completely correct. My concern is not that the key management protocols come with certificate management (or whatever its called) built in but that they have sufficient hooks that such systems can be added on top. Some of the mechanisms we have been presented with thus far (like Photuris) have places where such hooks can be added. Some do not and indeed may make assumptions that make such hooks impossible. I am merely pointing out that this is a real issue and that the hooks have to be thought about in some detail. Perry From ipsec-request@ans.net Wed Dec 14 16:30:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38675 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 11:34:27 -0500 Received: by interlock.ans.net id AA24088 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 11:30:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 11:30:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 11:30:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 11:30:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 11:30:18 -0500 Message-Id: <9412141630.AA14061@snark.imsi.com> To: cmadson@wellfleet.com (Cheryl Madson) Cc: ipsec@ans.net Subject: Re: user keys In-Reply-To: Your message of "Wed, 14 Dec 1994 07:00:35 EST." <9412141200.AA19289@wellfleet> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 11:30:02 -0500 From: "Perry E. Metzger" Cheryl Madson says: > Anyhow, I trust that the requirement on per-user keying is for end > systems only (or for intermediate systems that need to protect the > data that they themselves generate); I hope that this wasn't being > envisioned for encrypting routers or other external "transparant" > encrypting devices. I believe that you are correct on this, or that, rather, in the "secure routing between secure networks over insecure networks" case case the "user" might be thought of as the routing system and not the end user. By the way, "user" really means "entity doing something to make the packet enter the IPSP layer". On an end system, thats a client or server program combined with the user id. This is not necessarily an individual user in many cases; one might have different keys for different daemons, for example, even though on some operating systems the daemons might run under the same "user". Of course, this all an excessively complicated way of saying that, yes, indeed, routers don't have to (and indeed in practice cannot) provide per end-user keys -- although they might still provide multiple keys between the same endpoints for all sorts of other reasons, like assigning some traffic to faster but less secure crypto methods or breaking up traffic to try to deceive SAID based traffic analysis. .pm From ipsec-request@ans.net Wed Dec 14 11:50:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29645 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 11:50:24 -0500 Received: by interlock.ans.net id AA13539 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 11:46:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 11:46:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 11:46:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 11:46:25 -0500 Date: Wed, 14 Dec 94 08:29:16 From: "Housley, Russ" Encoding: 1937 Text Message-Id: <9411147874.AA787422556@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re[2]: key management Perry: You prove my point. You say: > ..., it doesn't, although it does require that the transport layer > have the ability to tell the network layer which SAID to use. This means that EVERY transport layer implemntation must be modified to use IPSP with the key management you propose. The whole reason for placing the security protocol in the IP layer is lost if we have to modify the consumers of IP services to be IPSP and IKMP aware. My understanding was that the IP layer was selected so that the security could be slipped into the protocol stack with alot of transparency. If IPSP has the same interface as IP, then none of the consumers of IP service need to be modified, although they do need to be relinked. IPv6 may have an advantage here since they are defining a new protocol, they also get to design a new service interface. The new service interface MAY be more compatible with your goal. You go on to say: > There are very good reasons that the IPng directorate made the > decision they did. I wouldn't discard the recommendation without > extremely serious thought. I have given this alot of thought. In fact, I have been involved in security protocol design efforts since 1986, and this issue comes up in each new effort. Please do not confuse Kerberos with IPSP. Kerberos is an application layer protocol, not a network layer protocol. Thus, it does not have to deal with multiplexing at the transpot layer. If you want to protect traffic from application process to application process, then I suggest you abandon IPSP and work on a security protocol that lives in the application layer or a security protocol that lives in the transport layer (and applies the security before multiplexing). I think that IPSP has many advantages, but in my opinion, it should not be used (or abused) to provide application-to-application security. Russ From ipsec-request@ans.net Wed Dec 14 17:08:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29653 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 12:13:51 -0500 Received: by interlock.ans.net id AA45131 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 12:09:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 14 Dec 1994 12:09:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 12:09:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 12:09:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 12:09:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 12:09:13 -0500 Message-Id: <9412141708.AA32726@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Phil Karn Cc: meadows@itd.nrl.navy.mil, ipsec@ans.net, cschow@watson.ibm.com Subject: Re: randomness & perfect forward (or proactive?) secrecy In-Reply-To: Your message of "Tue, 13 Dec 1994 22:35:28 PST." <199412140635.WAA11737@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 12:08:13 -0500 From: " " > >However, master keys may not be the only secrets whose compromise > >can compromise old message traffic. Suppose that a pseudo-random > >number generator is used to generate the key agreement keys. > > >Does anyone know if this problem has been considered at all when looking > >at perfect forward secrecy? Our `Network Randomization Protocol (NRP)' is addressing exactly this issue. This is work by Chee-seng Chow and myself. It is based on the (proven secure) protocol which Ran Canetti and myself presented in Crypto 94. In fact, NRP achieves an even higher degree of security than perfect forward secrecy, which I suspect is actually what both of you want. We call it `Proactive Security', namely security recovers from break-ins. For more info on Proactive Security see the crypto paper or several forthcoming additional works. I'll also be happy to discuss it, but I feel this list is not the right place. The idea of NRP is to combine sampling methods as Phil describes below with a distributed security-recovering mechanism based on peer-to-peer support, much like the Network Time Protocol (NTP). Right now we only have hooks to put your own sampling routine, but we're working on it. For details and free code see: software.watson.ibm.com/pub/security/nrp.tar. We may submit this as i-draft; we want first to complete and add a randomness sampling routine and to port it to platforms other than AIX (it's a portable design but we tested so far only on AIX). The priorities of these tasks could be affected by the interest we see. Phil, is your stuff public-domain? In this case we'll like to merge the two systems as they appear to be exactly complementary. Or, maybe you can make some parts public? Best, Amir Herzberg p.s. Chee-seng, let's discuss this. Enc: response from Phil > > Yes. I consider random number generation to be the Achilles heel of > all these schemes, and I've given mine a lot of thought. The random > number generator in my current code was inspired by PGP, but with some > tricks of my own. > > In my NOS code (a TCP/IP operating environment for DOS in which I've > been prototyping this stuff) I maintain an internal random number > generator state that is continually "churned" by keyboard strokes and > other random external events. That is, whenever you hit a key (for any > purpose -- there's a direct hook into the keyboard driver) while the > program is running, the scan code and the PC's real time clock (~1 us > count rate) are concatenated with the previous generator state and > hashed through MD5. The result becomes the new generator state. > > Whenever I need to generate random data, I hash the current state > along with a counter. The output becomes 16 bytes of random data that > I give to the user (e.g., a Diffie-Hellman routine). If the user needs > more, I increment the counter and rehash as needed. > > In essence, I maintain a "reservoir" of entropy, adding to it whenever > I can and drawing from it as needed. Assuming the reservoir is > reasonably full when I start, I can continue to generate random data > even without the addition of additional entropy at the cost of > degenerating from theoretical randomness (can't guess the sequence > even with unlimited computer power) to practical randomness (can't > guess the sequence without enough computing power to invert MD5). > > One not-quite-resolved problem is an unattended system that never sees > any keyboard activity. A security gateway, for example. I do try to seed > the generator state at startup with a few tricks: > > 1) hashing all of main memory, including Ethernet and disk buffers, > BIOS data, etc > > 2) Reading the 1uS time-of-day count in a tight CPU loop and hashing the > results. On some (but not all) machines that use separate crystals to > clock the CPU and the TOD clocks, you'll get a fairly random-looking > dither in the increment between successive clock reads. This doesn't work > for all PCs, though, especially the newer ones that generate all their > clocks from a single crystal and a PLL synthesizer. > > I do need to add a few more tricks I've heard about, e.g., timing > floppy disk and/or hard disk accesses, and perhaps hashing cleartext > packets. And it probably wouldn't hurt to save the random state on > disk when shutting down so I can use it as yet another source of > entropy when starting up, much like PGP's randseed.bin file. > > Phil > > > > From ipsec-request@ans.net Wed Dec 14 17:12:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20745 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 12:16:49 -0500 Received: by interlock.ans.net id AA45209 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 12:14:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 12:14:52 -0500 From: Ran Atkinson Message-Id: <9412141212.ZM1236@sundance.itd.nrl.navy.mil> Date: Wed, 14 Dec 1994 12:12:06 -0500 In-Reply-To: "Housley, Russ" "Re[2]: key management" (Dec 14, 8:29) References: <9411147874.AA787422556@spysouth.spyrus.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: Re[2]: key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 14, 8:29, Housley, Russ wrote: } Subject: Re[2]: key management % This means that EVERY transport layer implemntation must be modified % to use IPSP with the key management you propose. The whole reason for % placing the security protocol in the IP layer is lost if we have to % modify the consumers of IP services to be IPSP and IKMP aware. Yes, though such modifications are not especially complex in many common implementations (e.g. BSD derived). Access to the TCP implementation source within an OS is normally included when one has access to the IP implementation sources, though probably not in every obscure case. % My understanding was that the IP layer was selected so that the % security could be slipped into the protocol stack with alot of % transparency. If IPSP has the same interface as IP, then none of the % consumers of IP service need to be modified, although they do need to % be relinked. I do not think that transparency was particularly the primary reason for the decision though it might have been one factor. Some of us agitated specifically for transport-layer encryption and support for transport-layer encryption with IPv4 security was -- at one time -- agreed to (using an SP3N-like approach). % IPv6 may have an advantage here since they are defining a new protocol, % they also get to design a new service interface. The new service % interface MAY be more compatible with your goal. It appears to be MUCH more work to move an existing TCP implemnetation to work over IPv6 than to modify that implementation to pass the data down that is needed for per user keying -- in a BSD-derived implementation. In an implementation that has strict layering (e.g. x-kernel), implementing support for per-user keying is a more complex issue. The IPv6 ESP spec specifically discusses the use of ESP in transport-mode to provide transport-layer encryption. Support for transport-layer encryption (e.g. keep IP header cleartext whilst encrypting the TCP, UDP, routing, or ICMP data) was an explicit design goal. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Dec 14 17:46:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38258 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 12:52:20 -0500 Received: by interlock.ans.net id AA16895 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 12:46:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 14 Dec 1994 12:46:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 12:46:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 12:46:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 12:46:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 12:46:19 -0500 From: uri@watson.ibm.com Message-Id: <9412141746.AA17150@buoy.watson.ibm.com> Subject: Re: Re[2]: key management To: housley@spyrus.com (Housley, Russ) Date: Wed, 14 Dec 1994 12:46:14 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9411147874.AA787422556@spysouth.spyrus.com> from "Housley, Russ" at Dec 14, 94 08:29:16 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 812 Housley, Russ says: > My understanding was that the IP layer was selected so that the security > could be slipped into the protocol stack with a lot of transparency. Sure! > > There are very good reasons that the IPng directorate made the > > decision they did. I wouldn't discard the recommendation without > > extremely serious thought. > I have given this a lot of thought. In fact, I have been involved in > security protocol design efforts since 1986, and this issue comes up in > each new effort............. > I think that IPSP has many advantages, but in my opinion, it should not be > used (or abused) to provide application-to-application security. Couldn't agree more. Glad I'm not the only one holding this opinion. -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Wed Dec 14 17:59:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA32286 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 13:08:10 -0500 Received: by interlock.ans.net id AA30399 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 13:03:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 13:03:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 13:03:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 13:03:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 13:03:36 -0500 From: Charlie Watt Sender: Charlie Watt Message-Id: <9412141759.AA03160@mordred.sware.com> Subject: Re: key management To: perry@imsi.com Date: Wed, 14 Dec 1994 12:59:12 -0500 (EST) Cc: ho@cs.arizona.edu, ipsec@ans.net In-Reply-To: <9412141420.AA13831@snark.imsi.com> from "Perry E. Metzger" at Dec 14, 94 09:20:42 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 8508 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, BtfNWd0yc+o/5ugko7e5dlvnImnzNGysIme7K/XMhUX5rexzzvN4W3ASDtSnqnAg C+ztnbUstE9axehnZoFLTwE= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > Perry E. Metzger" > > > solo@BBN.COM says: > > In a multi-user environment, providing different identities at the > > IP level is incompatible with both typical host assurance and with > > the protocol architecture. Note, by the way, that solving this > > on the receive end is much more complicated than on the sending end > > of a datagram. > > > > In order meaningfully provide user granularity of separation, a > > host has to authenticate the user, pass that information down to the > > IP/IPSEC level, and preserve the integrity of the path. This suggest > > non-standard application and transport implementations. > > You make all this sound difficult. None of it involves any great > difficulty. ... > As you can see, this is hardly difficult. It requires some tiny > modifications to the transport code, a couple of small kernel > interfaces, and a key management system that understands user level > credentials. > > Perry Unfortunately this is incorrect. MaxSix -- the multilevel-secure network implementation commonly implemented on Compartmented Mode Workstations and other MLS systems -- is an example of a network layer security protocol. The single biggest mistake made in the original version of MaxSix was the passing of process-related security attributes (identity information, labels, etc...) at the network layer protocol. This caused several subtle problems. I'll only mention two, for they are representative of the rest: - - NFS transfers disk blocks on its own volition in order to provide read-ahead and write-behind. These network transfers: a) are performed outside of any normal user context. b) transfer data that may correctly be associated with several concurrent users -- e.g. a remotely mounted /etc/hosts file. c) arbitrarily reuse a small pool of network addresses on behalf of all client processes. - - A number of transport protocols, and convergence protocols that sit above the transport, such as RFC 1006 over TCP, will multiplex the data from several users over a single network "association" -- e.g., within a single IP packet there may be data originating from several separate users. The end result is that if you support per-user keys at the IP level, you will need substantial rewrites of: - at least some transport layer protocols, - your file system, in order to maintain the state necessary to determine which user process is associated with network data, and to segment the network layer data so that it only pertains to a single user. This can be done. We've been shipping this for 4 1/2 years. But the porting and maintenance costs are prohibitive. In my opinion there is a better solution that meets Perry's requirements -- but not within the current charter of the IPSEC WG. I describe it here (with apologies) for lack of a better forum. SecureWare is currently working on its "Extended Global Security Architecture" (EGSA) (blame the marketing guys for the pretentious name). I will describe it briefly, -- not to suggest that the WG consider any of this work, but rather: 1) out of fear that the WG will eventually move toward a standard that I believe to be of limitted utility. 2) to provide an example of why I believe the current focus of the group is insufficient, and why it cannot be fixed unless the IETF develops a more clear vision of distributed computing, along with the means to coordinate the various working groups in order to reach that vision. 3) to provide a basis for discussion. Effective distributed security requires the application of cryptographic security services at two layers of the protocol stack (a big assumption, I know): - the network layer to provide host-to-host services. This is perhaps most appropriate for use within gateways for creating virtual private networks, but does have some utility within a local network. - the application layer in order to support distributed applications. But this application layer security protocol should be independent of and transparent to any true application layer protocol such as ftp or telnet. The EGSA provides for both layers. In addition, it implements the application layer security protocol twice: a) as a true application layer library that can be linked with an application. b) as a module within the protocol stack that sits on top of the transports as a "secure socket" layer. This approach works well with multiuser operating systems where the protocol stack can be easily extended (e.g. Unix). It allows for the provision of security on a per-user basis transparently to the application. We have a version of this that currently handles TCP and TP0 on both socket and stream-based versions of Unix. It links directly into several variants of Unix without requiring modified vendor source. A five minute operation, ALL applications secured. As both a) and b) are implementations of the same application layer protocol, they interoperate. The EGSA also provides a single, common API to the application layer security services regardless of implementation. Within the EGSA, these two security layers (network and application) are implemented using the same two protocols (and the same source base!): - the Peer Authentication and Key Management Protocol (PAKMP) is misnamed. It actually provides four distinct services: 1) peer authentication. 2) negotiation of the minimum security services to be applied to an "association" (authentication, integrity, confidentiality, labeling/access control). 3) negotiation of a per-association key. At the application layer this is per-connection. At the network layer this can be per-host pair, or per application address pair (i.e. unique key for a specific instance of local IP address/port: remote IP address/port. 4) exchange of credentials -- where credentials are extended X.509 certificates signed by an "authority" granting a set of authorizations (id, roles, command auths, clearance, etc...) to a principal (user, host, etc...). The results of this exchange are available to either participant through the API. E.g., a server application can retrieve the credentials and authenticated identity of a client in order to make access control decisions for the resource it manages. A gateway can retrieve the credentials of a peer in order to make a routing decision for sensitive information. - the Network Data Security Enhancement Protocol (NDSEP) (currently a variant of SP3, sorry), which uses the negotiated per-association key to apply message authentication, data integrity, confidentiality, etc..., as required. The minimal set of security services to be provided for an "association" are specified by the network security officer through a database that controls which associations are permitted, and what services, protocols and algorithms should be applied to them. A security-aware application can use the API to request additional services or alternate protocols/algorithms, if desired. There a number of other pieces: user I&A is certificate-based using a Directory Service, user key management ties into the login process for unitary login, credentials may include configurable security policies, etc... But this is enough to illustrate what I believe to be the most important points if we are to evolve towards useful distributed computing: 1) a network layer security protocol cannot provide the universal bandaid to fix all security problems. If it is overloaded, it will severely break existing operating systems. 2) in addition to network layer security, we need support for secure distributed applications. 3) it would be a big win if applications could be secured transparently and without modification. 4) the two security layers should be coordinated to minimize both the development and processing burdens. 5) for supporting applications within the distributed environment a "key management protocol" by itself is insufficient, for authentication without authorization is useless. 6) key management, particularly when used for identifying and authenticating users, has system implications far beyond network layer security. These issues must be handled through a consistent architecture for distributed operation. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Dec 14 18:13:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27549 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 13:21:33 -0500 Received: by interlock.ans.net id AA15298 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 13:17:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 13:17:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 13:17:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 13:17:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 13:17:02 -0500 Message-Id: <9412141813.AA14282@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: key management In-Reply-To: Your message of "Wed, 14 Dec 1994 08:29:16." <9411147874.AA787422556@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 13:13:46 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > You prove my point. You say: > > > ..., it doesn't, although it does require that the transport layer > > have the ability to tell the network layer which SAID to use. > > This means that EVERY transport layer implementation must be modified to use > IPSP with the key management you propose. Yes. It has to be modified. So what? The modifications are very small and hardly onerous. If you want to use different SAIDs with different sockets, which is without any real doubt a requirement, the layer handling the sockets has to know how to specify an SAID. Paraphrasing from "The Elements of Networking Style", layering is supposed to be a tool, not a straight-jacket. > The whole reason for placing the security protocol in the IP layer > is lost if we have to modify the consumers of IP services to be IPSP > and IKMP aware. That is not the case. Part of the purpose as I perceived it was to make sure that every application didn't have to implement a new protocol or implement the same one over and over again. Part of the purpose was to help provide immunity to traffic analysis. Part of it was to provide the ability to build secure tunnels between insecure networks. Part of it was so that (being Unix-centric for a moment -- other OSes have analogs) an ordinary "write" system call would end up doing the "right thing" without having to have the application deal with the encryption and authentication. Part of it was indeed so that existing *applications* could get some authentication added without needing to do any work. However, I don't recall anyone ever saying that we should cripple the functionality so that we wouldn't have to add a few dozen lines of code to the TCP and UDP implementations. Those are, by the way, what you mean when you say "transports". > My understanding was that the IP layer was selected so that the security > could be slipped into the protocol stack with alot of transparency. Yes, thats true. Very small changes need to be made to take advantage of the work being done at the network layer, which is indeed where the bulk of the protocol work is. The protocol only needs to be specified at the network layer, too, since the operation of selecting a particular SAID for a particular socket is an OS dependent operation. That doesn't mean you don't want to be able to do it, however. > If IPSP has the same interface as IP, then none of the consumers of > IP service need to be modified, although they do need to be relinked. My applications, which are consumers of IP service, won't even need to be re-linked if I choose not use the new features. However, I don't see the need to add a piddling few lines of code in to other portions of the stack onerous. My intention is to change the interface to IP to allow a (possibly null) SAID to be specified by the higher layers. I'll have to change about a half dozen places where that call is made, and then I'm done. Any transport that wants to be able to specify SAIDs will have to have a little more work done to store them along with the control block for a given socket and know to specify that SAID when calling IP -- not a big deal at all. > I have given this alot of thought. In fact, I have been involved in > security protocol design efforts since 1986, and this issue comes up in > each new effort. Kerberos works today. Its the only thing widely deployed that does. I trust experience over "alot of thought". Kerberos has taught us that having our key management system give us good per user (or user-like entity) authentication and key management is a very good thing. > Please do not confuse Kerberos with IPSP. We are talking about IKMP, not IPSP. Please do not confuse that portion of the discussion. > Kerberos is an application layer protocol, not a network layer > protocol. Kerberos is a key management and authentication system. It does nothing about encrypting packets. The two are orthogonal. I'm mentioning that if you want to layer something that would provide you with the ability to, for instance, build authenticated and encrypted applications on top of IKMP/IPSP, you will need to provide at least Kerberos's level of per-user key separation. That means you will need to be able to set a SAID per socket. The IPSP layer has to be able to support this, but thats not what we are discussing (or at least, not what we were discussing). > If you want to protect traffic from application process to application > process, then I suggest you abandon IPSP and work on a security protocol > that lives in the application layer or a security protocol that lives in > the transport layer (and applies the security before multiplexing). I disagree. Why build a new mechanism when a perfectly good one exists? IPSP does everything I want as a bottom layer, and I see no reason to build a new mechanism into each and every transport that does what IPSP does. Its very simple to just allow the transports to specify what SAID should be used, and then suddenly IPSP does exactly what I want. The implementation I'm working on, which will be free, is going to have this functionality. > I think that IPSP has many advantages, but in my opinion, it should not be > used (or abused) to provide application-to-application security. If all we wanted to do was to provide the ability to produce secure tunnels between insecure networks, we would need no key management at all -- just use sneaker-net or use PEM or PGP to mail new keys. If you want to do anything interesting in security, you have to be able to build secure applications -- like secure file systems or remote login programs. Without that, none of this is interesting. From ipsec-request@ans.net Wed Dec 14 18:35:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27251 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 13:41:45 -0500 Received: by interlock.ans.net id AA21990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 13:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 13:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 13:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 13:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 13:36:39 -0500 Message-Id: <9412141835.AA14340@snark.imsi.com> To: Charlie Watt Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Wed, 14 Dec 1994 12:59:12 EST." <9412141759.AA03160@mordred.sware.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 13:35:59 -0500 From: "Perry E. Metzger" Charlie Watt says: > Unfortunately this is incorrect. MaxSix -- the multilevel-secure network > implementation commonly implemented on Compartmented Mode Workstations and > other MLS systems -- is an example of a network layer security protocol. > The single biggest mistake made in the original version of MaxSix was the > passing of process-related security attributes (identity information, > labels, etc...) at the network layer protocol. There was no suggestion here that network layer information pass process related security information. There was only a suggestion that transports should be able to specify that a particular SAID should be used for a particular packet -- i.e. that it should be possible to specify a SAID be used for a particular socket. There was no stated requirement that a particular application need use this capacity. You mention NFS as a problem. Nothing we've discussed forces you to use a particular model for how NFS is to be handled. It only provides you with the capability to have different NFS requests handled with different SAIDs -- if and only if you, as the secure NFS implementor, choose to. I see nothing wrong with this. It is useful in the majority of cases. The fact that in some small set of cases it is not useful does not mean that we should not provide the capacity to the 80% of cases where it is worthwhile. Perry From ipsec-request@ans.net Wed Dec 14 18:48:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26552 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 13:52:43 -0500 Received: by interlock.ans.net id AA12511 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 13:50:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 13:50:19 -0500 From: Ran Atkinson Message-Id: <9412141348.ZM1468@sundance.itd.nrl.navy.mil> Date: Wed, 14 Dec 1994 13:48:46 -0500 In-Reply-To: Charlie Watt "Re: key management" (Dec 14, 12:59) References: <9412141759.AA03160@mordred.sware.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 14, 12:59, Charlie Watt wrote: % Unfortunately this is incorrect. MaxSix -- the multilevel-secure % network implementation commonly implemented on Compartmented Mode % Workstations and other MLS systems -- is an example of a network layer % security protocol. The above is greatly misleading. Neither MAXSIX nor DNSIX specify "network layer security protocols". Both specify ways to transfer labeled information (without authentication) between two hosts implementation the same labelling protocol set. No security is provided by either protocol. Labels are provided. Host operating systems use those untrustworthy labels to make Mandatory Access Control decisions. % The single biggest mistake made in the original version of MaxSix was % the passing of process-related security attributes (identity information, % labels, etc...) at the network layer protocol. No. Actually the biggest single mistake continues to be the omission of any reasonable authentication that the label received and the label sent are in fact the same or any authentication binding the data and the label together. It is trivial to spoof either DNSIX or MAXSIX precisely because neither has authentication. % The end result is that if you support per-user keys at the IP level, you % will need substantial rewrites of: % % - at least some transport layer protocols, % - your file system, This above is provably false by an existance proof of a BSD-based implementation of IP oriented encryption that does support per user keying. Note that user does not equate to any particular human in every case, consider the various non-human login ids as one example. % This can be done. We've been shipping this for 4 1/2 years. But the % porting and maintenance costs are prohibitive. They'd probably be A LOT less expensive to maintain if MAXSIX were less of a random hack than it actually is (CIPSO being a stellar example of a bad specification included as part of MAXSIX). I believe that the DNSIX/MAXSIX code is expensive to port and maintain, but SecureWare seems to do a nicely profitable business doing just that. Expense of DNSIX/MAXSIX code does not correlate to encryption code costs, so the statement is largely irrelevant to the current discussion. % Effective distributed security requires the application of cryptographic % security services at two layers of the protocol stack (a big assumption, % I know): I would agree with "more than one layer" but can't agree with "two layers". For example, email probably does need built-in security (e.g. PEM) but other applications do not need that and are instead better served by transport-layer and/or network-layer encryption. Link/subnet encryption is always needed to protect against traffic analysis. % - the application layer in order to support distributed % applications. But this application layer security protocol should be % independent of and transparent to any true application layer protocol % such as ftp or telnet. Transport-layer encryption (e.g. keyed on a per socket + destination-addr basis) is a useful tool in many circumstances because it permits strong security services to be provided without having to modify any application-layer protocol and without being forced to modify every application binary. % - the Network Data Security Enhancement Protocol (NDSEP) % (currently a variant of SP3, sorry), which uses the negotiated % per-association key to apply message authentication, data integrity, % confidentiality, etc..., as required. Aside: In retrospect a solid case can be made that this WG should have simply used SP3D for its packet format and as the basis for further development. At the time it was not so clear. % 1) a network layer security protocol cannot provide the universal % bandaid to fix all security problems. Agree. There is no magic bullet of any flavour. % 2) in addition to network layer security, we need support for secure % distributed applications. Disagree. Adding security to each application is too costly both in initial implementation and in operations & maintenance costs. % 3) it would be a big win if applications could be secured transparently % and without modification. Yes. Transport-layer encryption can do this as can network-layer encryption. Application-layer encryption cannot NOT do this because adding encryption at the application-layer cannot be made transparent. Adding it below the network API is a requirement if one seeks transparency and below that network API it is no longer application-layer. % 4) the two security layers should be coordinated to minimize both the % development and processing burdens. Actually, keeping the layers separate can be a BIG HUGE win in some systems. The above is not true as a general rule but is sometimes true. % 5) for supporting applications within the distributed environment a "key % management protocol" by itself is insufficient, for authentication % without authorization is useless. Agree that session key establishment is necessary but insufficient. However it is a reasonable problem to start attacking now. Authorisation is already widely available in C2-like operating systems, so the second claim is relevant only to DOS and MacOS (and similar OS) users and not germane here. % 6) key management, particularly when used for identifying and % authenticating users, has system implications far beyond network layer % security. Disagree. It might have wide spread system implications but it might well not have such wide spread system implications. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Dec 14 19:01:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31674 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 14:15:52 -0500 Received: by interlock.ans.net id AA21624 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 14:11:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 14:11:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 14:11:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 14:11:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 14:11:18 -0500 From: Charlie Watt Sender: Charlie Watt Message-Id: <9412141901.AA03267@mordred.sware.com> Subject: Re: key management To: perry@imsi.com Date: Wed, 14 Dec 1994 14:01:47 -0500 (EST) Cc: watt@sware.com, ipsec@ans.net In-Reply-To: <9412141835.AA14340@snark.imsi.com> from "Perry E. Metzger" at Dec 14, 94 01:35:59 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2342 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, ACFPlIcfsOoFrXilcL+Im06r4mEB6gd7s/BgfdFZbN+6m5Fk55WhPvFqZ84ARZx5 tRWYJuk8C7BA/M54LohZ5+Q= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > Perry Metzger: > > Charlie Watt says: > > Unfortunately this is incorrect. MaxSix -- the multilevel-secure network > > implementation commonly implemented on Compartmented Mode Workstations and > > other MLS systems -- is an example of a network layer security protocol. > > The single biggest mistake made in the original version of MaxSix was the > > passing of process-related security attributes (identity information, > > labels, etc...) at the network layer protocol. > > There was no suggestion here that network layer information pass > process related security information. There was only a suggestion that > transports should be able to specify that a particular SAID should be > used for a particular packet -- i.e. that it should be possible to > specify a SAID be used for a particular socket. There was no stated > requirement that a particular application need use this capacity. > That's fine. Forgive the misunderstanding, I misread your requirement: > 1) They lack a specified method for managing separate keys for > separate users; this is an articulated requirement for the IPv6 > case according to the IPng Directorate. and the following justification for it: > ... I can build applications like a secure telnet or a secure NFS service, > which I cannot do with ANY of the thus far articulated key management > systems. I would argue that any system that is not more functional > than Kerberos (in the sense of providing all that kerberos does but > with public keys and scalability) is not sufficient for our > purposes. The key management system need not itself provide all the > Kerberos functionality, but it must have clearly obvious hooks for > handling naming and user level keying. - ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to mean that you wished to select keys based upon user identity, and to use that ability to provide application layer I&A. If that is an incorrect interpretation of what you mean, please explain it again, for you lost something in the explanation. The rest of my prior message went on to agree with you: yes we need these capabilities, but with the following provisos: - application layer support needs to be kept out of a network layer security protocol. - the two need to be coordinated or we will wind up with a big mess. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Dec 14 03:14:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16842 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 14:17:05 -0500 Received: by interlock.ans.net id AA06338 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 14:14:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 14:14:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 14:14:44 -0500 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Message-Id: <9412141914.AA23809@slced1> Subject: Re: Diffie-Hellman (note by Hugo) GOOD PROPOSAL To: perry@imsi.com Date: Wed, 14 Dec 94 11:14:39 PST Cc: ipsec@ans.net In-Reply-To: <9412141416.AA13822@snark.imsi.com>; from "Perry E. Metzger" at Dec 14, 94 9:16 am Reply-To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II ) X-Orgztn: PHD NSWC (NSWSES) 4A05 Port Hueneme, CA 93043 - Opinions: Only Mine X-Phones: 805.982.7180, DSN 551, VoiceMail 805.340.6471, DPage: 655.2017 X-Mailer: ELM [version 2.3 PL11] Perry, You hit the head right on the nail .. 250 Ata-Persons for you .. /ev/ Everyone else wants to stay in this time consuming, revenue producing posture of reinventing security as fast as their bud can break it .. some of us think we have real work and customers who just dont want to hear about you cant buy comsec gear for networks and have to wait to be breached. Tnx /Ev/ This came from Perry E. Metzger: > In other words, I'd like to have a baseline requirement that you use > D-H, and the ability to optimise whatever we use so that we don't send > a dozen packets, but it would be very nice if we could build our > protocol such that we are not out of luck should we find in five years > that fast gazorknoplant key negotiation (developed the previous month) > is far better than D-H. -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.cotdazr.org efb@gcpacix.uucp + + efb@nosc.mil efb@oxnardsd.org [EFB15] WA6CRE Gold Coast Sun Users + + Opinions, MINE, NOT Uncle_s | WWW b-news postmaster xntp dns gnu Linux + + Info Super Highway Consulting Put Business or Country on the Internet + From ipsec-request@ans.net Wed Dec 14 19:31:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20827 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 14:37:48 -0500 Received: by interlock.ans.net id AA25250 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 14:31:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 14:31:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 14:31:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 14:31:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 14:31:56 -0500 Message-Id: <9412141931.AA14445@snark.imsi.com> To: Charlie Watt Cc: ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Wed, 14 Dec 1994 14:01:47 EST." <9412141901.AA03267@mordred.sware.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 14:31:39 -0500 From: "Perry E. Metzger" Charlie Watt says: > > There was no suggestion here that network layer information pass > > process related security information. There was only a suggestion that > > transports should be able to specify that a particular SAID should be > > used for a particular packet -- i.e. that it should be possible to > > specify a SAID be used for a particular socket. There was no stated > > requirement that a particular application need use this capacity. > > > That's fine. > > Forgive the misunderstanding, I misread your requirement: > > > 1) They lack a specified method for managing separate keys for > > separate users; this is an articulated requirement for the IPv6 > > case according to the IPng Directorate. That was a reference to the key management layer, not to the IPSP stuff. They are separate. I realize that I am perhaps being more confusing rather than less confusing here but the general point is this -- we have to be able to deal with the per-user situation, but the intent is not to alter IPSP but to indicate that hooks are needed in IPSP implementations to deal with this. The intent is to handle the identification of the users at what Phil Karn calls the "certificate management" layer. IKMPs that can't deal with certificates for users but assume that you must have only per host keys, or IPSP implementations that can't deal with the idea that multiple SAIDs might be in use between systems and might be set on a per socket basis, make it impossible to do this and are thus a problem. However, the IPSP layer knows nothing about users -- it only groks SAIDs. There is a requirement on IPSP (or rather, on the v6 equivalent which we ought to follow as well) that implementations must provide ways to let different users use different SAIDs, but there is no requirement that the layer know anything about these users. My note was that some key management systems are thinking in terms of managing SAIDs on the machine level only -- which is bad. Hooks are needed to deal with user based keying. Also, some IKMPs are also thinking in terms of authenticating machines to machines only, and not in terms of being able to deal with multiple users, and this, too, is bad. > you wished to select keys based upon user identity, I do, but that is above the IPSP layer, not at it. > and to > use that ability to provide application layer I&A. Indeed, I wish to, but that is not to be handled in IPSP beyond the fact that IPSP gives you the ability to know which SAID was used with which incoming packet and to select which SAID should be used with an outgoing one. > - application layer support needs to be kept out of a network layer > security protocol. > > - the two need to be coordinated or we will wind up with a big mess. I completely agree. Perry From ipsec-request@ans.net Wed Dec 14 04:23:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12628 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 15:28:59 -0500 Received: by interlock.ans.net id AA21239 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 15:22:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 15:22:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 15:22:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 15:22:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 15:22:49 -0500 Date: Wed, 14 Dec 94 12:23:34 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412142023.AA00296@miraj.Eng.Sun.COM> To: amir@watson.ibm.com Subject: Re: Proposal: Perfect forward secrecy a MUST Cc: ipsec@ans.net >From ipsec-request@ans.net Tue Dec 13 14:30:39 1994 >However I think we should be even more explicit about whether we want >perfect forward secrecy to be a must. Aziz has pointed out that this >feature does not come for free, and I think we are all saying that at least >the computational cost is not prohibitive. Actually, when I said it doesn't "come for free", I was quoting you in an earlier message. From amir@watson.ibm.com >I agree with Hugo. The requirement of `perfect forward secrecy' is non >trivial and does not come for free >Aziz (and others), could you enumerate all the disadvantages/costs associated >with deciding on perfect forward secrecy as a requirement? Sure, I would be happy to. Think about time critical network management operations that have authentication of management entities as a prime concern. Burdening this application with a high overhead session oriented key-management for the sake of perfect forward secrecy, (when secrecy itself is not an issue) is very poor system design. The whole reason for running SNMP primarily on top of UDP was to keep it lightweight and quick. Now you want to add an elaborate high overhead protocol underneath it as a *mandatory* feature, which has no justification in this context. Think about ICMP messages. Do you want to have a session/exponentiations for each and every one of them, for the sake of perfect forward secrecy, when secrecy itself may not be a concern? There are many many such examples, and I am sure members of the list can come up with their own. Do you believe that vendors that sell IPSP will turn on strong encryption by default? You stated at the IETF meeting that you (IBM) want to build exportable products (with weak or no encryption). Now you are pushing a feature as mandatory that makes sense only when used with strong encryption (something that you yourselves dont intend to make the default). Working for a computer company, I understand that computers are getting faster every year. We love to sell our latest and fastest computers, but we also realize that we can't expect our customers to throw out all the equipment that they have already purchased and spent billions of dollars on, as soon as the new models arrive. The installed base of computers does not vanish easily, and we should be careful about mandating features that are *not* necessary in many circumstances, and which pose an unreasonable protocol and computational burden to the millions of computers installed in the field *today*. Therefore I cast a strong *no* vote to making this feature mandatory. (I have already stated that I support this as an optional feature for situations where secrecy is essential). Ashar. From ipsec-request@ans.net Wed Dec 14 20:53:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38408 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:05:27 -0500 Received: by interlock.ans.net id AA05018 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 15:59:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 15:59:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 15:59:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 15:59:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 15:59:38 -0500 From: Charlie Watt Sender: Charlie Watt Message-Id: <9412142053.AA00643@mordred.sware.com> Subject: Re: key management To: atkinson@itd.nrl.navy.mil Date: Wed, 14 Dec 1994 15:53:23 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9412141348.ZM1468@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Dec 14, 94 01:48:46 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 6690 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, ClxFW3WX2f1/TALW1+EgV9XNmyoI3kH5xkZ4Nw5Xdcl+TsEwTDVixTX5J6shtI7d PkcZoHWDTYOmq9Koo5ywgEc= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > Ran Atkinson writes: > % On Dec 14, 12:59, Charlie Watt wrote: > > % Unfortunately this is incorrect. MaxSix -- the multilevel-secure > % network implementation commonly implemented on Compartmented Mode > % Workstations and other MLS systems -- is an example of a network layer > % security protocol. > > The above is greatly misleading. > > Neither MAXSIX nor DNSIX specify "network layer security > protocols". Both specify ways to transfer labeled information > (without authentication) between two hosts implementation the same > labelling protocol set. No security is provided by either protocol. > Labels are provided. Host operating systems use those untrustworthy > labels to make Mandatory Access Control decisions. Ran, in order to judge a solution, you must understand the constraints of the problem for which it was intended. The DoD's Goal Security Architecture for which MaxSix was designed specifies that the network media will be physically protected. Within this constraint the passing of security attributes between trusted hosts and the enforcement of security policies based upon those attributes do in fact provide peer authentication, data integrity and data confidentiality -- and do so at least as reliably as you are going to get using comparable cryptographic services between insecure OS's such as Windows. (I won't break your crypto, I'll come in through the back door and borrow your keys). With the addition of a cryptographic front end, it will even do so reliably in a more hostile environment. All-in-all, it is a good solution for a specific problem. Is it an adequate solution for other environments without a front end? No, of course not. But then, a dishwasher does a pretty lousy job washing clothes. If you have a different problem, use a different tool. > > % The single biggest mistake made in the original version of MaxSix was > % the passing of process-related security attributes (identity > information, > % labels, etc...) at the network layer protocol. > > No. > > Actually the biggest single mistake continues to be the > omission of any reasonable authentication that the label received and > the label sent are in fact the same or any authentication binding the > data and the label together. It is trivial to spoof either DNSIX or > MAXSIX precisely because neither has authentication. No. It is not trivial to spoof MaxSix because you cannot connect your untrusted system to the network. You would either be shot, or it would be fronted by a crypto box. > > % The end result is that if you support per-user keys at the IP level, > you > % will need substantial rewrites of: > % > % - at least some transport layer protocols, > % - your file system, > > This above is provably false by an existance proof of a > BSD-based implementation of IP oriented encryption that does support > per user keying. Note that user does not equate to any particular > human in every case, consider the various non-human login ids as one > example. Yes, it is easy to solve the problem by correctly defining your terms. As Ran suggests, you can easily have per-user keying such that the "user" you identify has no correlation with the actual user causing transfer of the data. This doesn't sound very useful to me. But perhaps you have a different problem :-). > > % - the application layer in order to support distributed > % applications. But this application layer security protocol > should be > % independent of and transparent to any true application layer > protocol > % such as ftp or telnet. > > Transport-layer encryption (e.g. keyed on a per socket + > destination-addr basis) is a useful tool in many circumstances because > it permits strong security services to be provided without having to > modify any application-layer protocol and without being forced to > modify every application binary. I agree. But remember, an application layer protocol is not necessarily something that is run in the Unix "user space". It is (aside from being poorly defined for the Internet stack) a communications protocol that sits above the transport layer. Thus what I suggested, an application layer protocol implemented within the protocol stack as extensions to the socket/ TLI/XTI programming interface provides the same benefits. > % 2) in addition to network layer security, we need support for secure > % distributed applications. > > Disagree. Adding security to each application is too costly both in > initial implementation and in operations & maintenance costs. > > % 3) it would be a big win if applications could be secured transparently > % and without modification. > > Yes. > > Transport-layer encryption can do this as can network-layer encryption. > Application-layer encryption cannot NOT do this because adding encryption > at the application-layer cannot be made transparent. Adding it below > the network API is a requirement if one seeks transparency and below > that network API it is no longer application-layer. Of course I can. We're shipping products that do precisely this. I can link a module into most Unix-based stacks that provide strong user authentication, integrity and confidentiality transparently to all applications. Don't confuse an application with an application layer communications protocol. > % 5) for supporting applications within the distributed environment a > "key > % management protocol" by itself is insufficient, for authentication > % without authorization is useless. > > Agree that session key establishment is necessary but insufficient. > However it is a reasonable problem to start attacking now. > > Authorisation is already widely available in C2-like operating > systems, so the second claim is relevant only to DOS and MacOS (and > similar OS) users and not germane here. But they do not provide distributed authorizations, without which you will wind up with an administrative nightmare in a large-scale installation. This is a problem that needs to be considered. > > % 6) key management, particularly when used for identifying and > % authenticating users, has system implications far beyond network layer > % security. > > Disagree. It might have wide spread system implications but it might > well not have such wide spread system implications. Perhaps. But if you don't think about it up front, what if you're wrong? Is there harm in giving thought to an architecture that meets all of our requirements for distributed computing? Or should we just hope that all these little pieces fall magically into place? > > Ran > atkinson@itd.nrl.navy.mil Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Dec 14 05:05:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35602 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:07:37 -0500 Received: by interlock.ans.net id AA38947 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:06:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 16:06:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:06:08 -0500 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Message-Id: <9412142105.AA24155@slced1> Subject: Re: Diffie-Hellman, IPsec, etc. To: atkinson@itd.nrl.navy.mil Date: Wed, 14 Dec 94 13:05:52 PST Cc: ipsec@ans.net In-Reply-To: <9412141442.ZM1558@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Dec 14, 94 2:42 pm Reply-To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II ) X-Orgztn: PHD NSWC (NSWSES) 4A05 Port Hueneme, CA 93043 - Opinions: Only Mine X-Phones: 805.982.7180, DSN 551, VoiceMail 805.340.6471, DPage: 655.2017 X-Mailer: ELM [version 2.3 PL11] SPEAKING out loud without the Caveat Lite on is a good way to assault too broad a target zone. I apologize. I also believe some notable part of the security fixit folks are perhaps more than wonderful opportunists and solutions oriented to protecting assets cheaply for a long time are better than solutions that WILL need to be regrown REAL SOON. VR /Ev/ This came from Ran Atkinson: > > On Dec 14, 11:14, Everett F Batey wrote: > > % Everyone else wants to stay in this time consuming, revenue producing > % posture of reinventing security as fast as their bud can break it .. > % some of us think we have real work and customers who just dont want to > % hear about you cant buy comsec gear for networks and have to wait to > % be breached. > > Hmmm. I hope you are excluding me from "everyone else". :-) > > Actually, I was the one who stood up in San Jose at the end of > interminable key mgmt presentations and said "I want Diffie-Hellman > for key mgmt and I want it to use RSA keys obtained from the Domain > Name System, using the Eastlake-Kaufman DNS Security approach, for > authentication of the DH exchange. > > I'm also the one that helped force the "must implement security" > requirement into all IPv6 implementations, is pushing per-user keying > for better security, and who is building a fully encrypting IPv6 > implementation that I hope to give away once completed (subject to > official approvals of course). > > Ran -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.cotdazr.org efb@gcpacix.uucp + From ipsec-request@ans.net Wed Dec 14 21:20:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16793 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:28:03 -0500 Received: by interlock.ans.net id AA27754 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:24:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:24:59 -0500 From: Ran Atkinson Message-Id: <9412141620.ZM2125@sundance.itd.nrl.navy.mil> Date: Wed, 14 Dec 1994 16:20:52 -0500 In-Reply-To: solo@BBN.COM "Re: key management" (Dec 13, 16:31) References: <9412132147.AA16940@itd.nrl.navy.mil> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Human I&A, IPsec, and their non-relationship Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil All, I've been trying to sort out why so many folks appear to be talking past each other recently on this list. I think I might have partly figured it out -- if I'm correct part of the problem is a communication gap between several folks (including me) . I'll make a stab at clarifying in hopes that will help. Please bear with me and don't respond to this note before you've read the entire note. I'm excerpting from Dave Solo's email because he has written clearly enough that I think I understand where he's coming from. Some of the other messages from various folks that I've read lately leave me fairly confused as to the author's point. Thanks in advance, Ran ---------------------------------------------------------------------- On Dec 13, 16:31, solo@BBN.COM wrote: % Subject: Re: key management % % Satisfying user granularity identification, authentication, and access % control at the IP layer seems to be one of those issues where desired % capabilities and feasibility clash. I do not believe that anyone has proposed or is currently advocating use of network-layer or transport-layer encryption to provide human--computer identification or authentication. % In a multi-user environment, providing different identities at the % IP level is incompatible with both typical host assurance and with % the protocol architecture. To my understanding of what you mean by "providing different identities", I disagree with the statement quoted above (details immediately follow). One straight-forward way to implement this in UNIX on the sending side is for the upper layer to either (1) pick the SAID value based on source uid and destination IP address and pass down that SAID as part of the socket information to the lower layer or (2) for the encrypting layer to obtain source uid from socket state directly and destination IP address in the existing manner, use those two data points to call a function returning the needed key, algorithm, and other security data for the outgoing packet. Other methods can be devised. These 2 are just examples -- I'm not making any assertions about which implementation strategy would be best. On the receive side, the receiver gets an encrypted/ authenticated packet containing a plain-text SAID. It feeds that SAID into a function and gets the key, algorithm and other security association data as the return from that function. It then processes the packet using the data returned from that call and (if successful in decrypting/authenticating) passes the received upper layer data to the upper layer in the usual manner (possibly including a flag indicating the data was received encrypted or that authentication succeeded). Each side maintains a logical table (implemented however one likes) that is indexed by SAID and the Destination Address (because SAIDs in IPv6 are receiver-oriented to be compatible with IP multicast). That table contains all of the security association parameters (e.g. key, algorithm, algorithm mode, maybe a sensitivity level, etc). Please note the absence of ALL human-computer Identification/Authentication in the above process description. % Note, by the way, that solving this % on the receive end is much more complicated than on the sending end % of a datagram. Please explain, preferably using the above process as a discussion point. % In order meaningfully provide user granularity of separation, a % host has to authenticate the user, pass that information down to the % IP/IPSEC level, and preserve the integrity of the path. This suggest % non-standard application and transport implementations. % % On the receive side, the problem is worse. An IP datagram arrives % with an SAID. At the time IP/IPSEC per datagram processing takes place, % including a reliable access control decision, there is no way to control % the subsequent processing of the information, let alone communicating % that data through the transport layer and to a subsequent application. % At a minimum, this requires some change to the transport processing and % application. % % While an IP level user authentication architecture might be feasible % in a high assurance operating system intended to provide reliable % separation, it is far less realistic in common, lower assurance % configurations. Further, if you are going to create special % applications to handle this processing, why not directly handle user % authentication at the application level. % % I don't doubt that the IPv6 and other communities would like to see % the general user I&A problem solved at the network layer, but this % is mostly inconsistent with protocol layering and certainly % inconsistent with low assurance operating systems. Again, I do not believe that anyone is advocating use of packet encryption to provide human-computer identification and authentication. The above text appears (to me) to be attempting to argue that it is unwise to attempt to use packet encryption to provide human-computer identification and authentication. % On the other hand, I do agree that IKMP, as distinct from IPSP, % should be capable of creating security associations based on % a variety of granularities. My objection is to the notion of % providing user based separation via IPSP on multi-user systems. I read the above as saying that per userid keying is a desirable feature. If so, I agree fully. Am I mistaken in my understanding of the quoted text ? (new context follows) As I (probably incompletely) understand Perry's discussion about using Kerberos, he is suggesting using Kerberos as one (of several possible) way to distribute keys amongst Kerberised systems implementing packet encryption. Where I think things got confusing is that Kerberos currently does also provide human-computer I&A as one of its features, though perhaps a feature not directly related to implementing packet encryption. Within communities already using Kerberos, it seems to me very sensible to reuse the Needham-Schroeder key management technology already implemented within Kerberos as a possible way to distribute packet encryption keys and related data. (new context follows) The IPv6 documents do not in any place discuss human-computer I&A. The "per user keying" discussed there can be accurately described in very UNIX-centric terms as "per uid keying". On systems which do not have the concept of different users (e.g. DOS, MacOS), per-host-keying and per-user-keying are in fact the same -- but only because that OS limitation is a special case. (new context follows) As a document author, I find it fairly frustrating when people (ASIDE: I really am speaking generally here, I'm NOT talking about any particular individual) discuss easily available electronic documents without having read them before talking about them. If folks who are uncomfortable with any part of the per-user-keying discussion or the IPv6-specific parts of the discussion have not yet actually read the currently online Internet Drafts, PLEASE read them before commenting further on the public list. The IPv6 documents are all online as Internet Drafts at the I-D archive site near you and all have online filenames of the form "draft-atkinson-ipng-*.txt". Thanks. (I'm now putting on my Asbestos coated clothes and waiting :-) Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Dec 14 21:31:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23826 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:40:27 -0500 Received: by interlock.ans.net id AA34081 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:35:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 16:35:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:35:32 -0500 Message-Id: <199412142131.NAA01395@large.cisco.com> X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Phil Karn Cc: housley@spyrus.com, ipsec@ans.net Subject: Re: key management In-Reply-To: Your message of "Tue, 13 Dec 1994 21:29:46 PST." <199412140529.VAA11622@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 13:31:38 -0800 From: David Carrel > >I agree with number 2, we need to pick a certificate format. However, I > >think that certificates to support IPSP should contain host names, not user > >names. > > I disagree. One big application I have in mind for IPSP is to support ... > In this situation it makes a lot of sense for the keys in the IPSP > gateway to have the names of your users on them. Phil, you're right that for many situations a "user" certificate is what's appropriate. But for some situations an IP address or host-name certificate is more appropriate. There is nothing that precludes us from using both. Let's not limit ourselves to using only one. Dave From ipsec-request@ans.net Wed Dec 14 21:46:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27257 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:54:38 -0500 Received: by interlock.ans.net id AA03390 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:50:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:50:15 -0500 From: Ran Atkinson Message-Id: <9412141646.ZM2268@sundance.itd.nrl.navy.mil> Date: Wed, 14 Dec 1994 16:46:26 -0500 In-Reply-To: Charlie Watt "Re: key management" (Dec 14, 15:53) References: <9412142053.AA00643@mordred.sware.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 14, 15:53, Charlie Watt wrote: % It is not trivial to spoof MaxSix because you cannot connect your % untrusted system to the network. You would either be shot, or it would % be fronted by a crypto box. The above statement is not true for any environment that I am aware of that MAXSIX is actually used. I am aware of a number of actual environments where MAXSIX is in use. People might claim the above to be true but I know of zero cases where it is actually true. As such it represents an unreasonable design assumption. Further, no DoD document on security architecture says anything about "unable to connect an untrusted system to the network" while many talk about "keeping uncleared people outside of (some) room". Charlie's statement and the actual statements in DoD documents are significantly different in their implications for MAXSIX. > This above is provably false by an existance proof of a > BSD-based implementation of IP oriented encryption that does support > per user keying. Note that user does not equate to any particular > human in every case, consider the various non-human login ids as one > example. % As Ran suggests, you can easily have per-user keying such that the % "user" you identify has no correlation with the actual user causing transfer % of the data. This doesn't sound very useful to me. Charlie knows full well that is not what I suggested. I suggested that per user keying is straight-forward because the OS already provides human-computer I&A using OS-specific mechanisms, each process has an associated userid, and the stack knows that userid and so can pick the appropiate key associated with that userid. My approach is implementable and works. Human-Computer I&A is outside the scope of this WG's effort. > Transport-layer encryption (e.g. keyed on a per socket + > destination-addr basis) is a useful tool in many circumstances because > it permits strong security services to be provided without having to > modify any application-layer protocol and without being forced to > modify every application binary. % I agree. But remember, an application layer protocol is not necessarily % something that is run in the Unix "user space". It is (aside from being % poorly defined for the Internet stack) a communications protocol that % sits above the transport layer. Thus what I suggested, an application layer % protocol implemented within the protocol stack as extensions to the % socket/ TLI/XTI programming interface provides the same benefits. We have a difference in definitions here, though perhaps not a difference of substance. I do not believe that anything below the network API is "application-layer". Charlie does appear to believe that one can have "application-layer" things below the network API. The difference in definitions is not especially important, IMHO, other than to keep straight what each person is actually proposing. What is important is that we appear to agree that the security mechanism needs to be below the network API if one needs to have security provided to application programs without modifying each application program or apFrom ipsec-request@ans.net Wed Dec 14 21:26:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24695 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:54:37 -0500 Received: by interlock.ans.net id AA08791 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:51:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 16:51:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:51:25 -0500 Date: Wed, 14 Dec 1994 16:26:26 -0500 From: rubin@faline.bellcore.com (Avi Rubin) Message-Id: <199412142126.QAA08100@faline.bellcore.com> To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com Subject: Re: Proposal: Perfect forward secrecy a MUST Cc: ipsec@ans.net, yacov@faline.bellcore.com Has anyone proposed any protocols for "perfect forward secrecy"? Is this concept any different than protocols that are resistant to known-key attacks? Are we worried about the compromise of both master keys of communicating parties, or a bunch of session keys being compromised not leading to compromise of all the others? Everyone is throwing the term "perfect forward secrecy" around, but it seems that there is another term already in the literature for what is being described, and I haven't seen a formal definition of the requirement that is being debated. In addition, before the computational feasability is decided, it would be nice to know exactly what protocols we are dealing with. Is there a particular protocol that is under consideration that meets all the requirements, or is everyone arguing about the concept in general? Avi plication protocol separately. Such application-layer (my definition of application layer here :-) modifications seem needless in many cases and always increase the cost of deploying and using security. > Transport-layer encryption can do this as can network-layer encryption. > Application-layer encryption cannot NOT do this because adding encryption > at the application-layer cannot be made transparent. Adding it below > the network API is a requirement if one seeks transparency and below > that network API it is no longer application-layer. % Of course I can. We're shipping products that do precisely this. I % can link a module into most Unix-based stacks that provide strong user % authentication, integrity and confidentiality transparently to all % applications. Don't confuse an application with an application layer % communications protocol. Again, this appears to be a matter of Charlie having a different defintion of "application-layer" than I do. I would characterise his implementation of security below the API as being below the "application-layer". It appears that he and I are in violent agreement on most of this but differ in our definitions of "application layer". > Agree that session key establishment is necessary but insufficient. > However it is a reasonable problem to start attacking now. > > Authorisation is already widely available in C2-like operating > systems, so the second claim is relevant only to DOS and MacOS (and > similar OS) users and not germane here. % But they do not provide distributed authorizations, without which you % will wind up with an administrative nightmare in a large-scale installation. % This is a problem that needs to be considered. Distributed authorisation is outside the scope of the IPsec WG and might even be outside the scope of the IETF (to the extent it is an OS issue, it is clearly outside the scope of the IETF). Some folks use Kerberos for this. Others use a combination of techniques, often including Sun's NIS/YP technology. While the problem might be interesting, it belongs in fora other than this mailing list, which is ostensibly focused on packet encryption and key mangagement techniques being developed by the IETF for the Internet. % Is there harm in giving thought to an architecture that meets all of % our requirements for distributed computing? Or should we just hope that % all these little pieces fall magically into place? There is harm in redefining the problems addressed by this mailing list from a narrow one that is within the scope of this IETF working group to one that is beyond the scope of the entire IETF. Such redefinition and the resulting diffusion of the discussion tend to significantly impede progress on the narrow technical problems that really ARE within our scope. The WG is already late in developing our specifications and we need to stay focused on things within our charter. There exist other places that the broader issue can be discussed or such places could be created easily (e.g. a new mailing list). The issue is not whether ANY discussion is legitimate but rather WHERE different discussions should live (i.e. its a sorting problem). Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Dec 14 21:45:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29569 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 16:54:41 -0500 Received: by interlock.ans.net id AA38960 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 16:49:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 16:49:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 16:49:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 16:49:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 16:49:54 -0500 Message-Id: <9412142145.AA15908@snark.imsi.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Proposal: Perfect forward secrecy a MUST In-Reply-To: Your message of "Wed, 14 Dec 1994 12:23:34 PST." <9412142023.AA00296@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 16:45:57 -0500 From: "Perry E. Metzger" Ashar Aziz says: > Think about time critical network management operations that > have authentication of management entities as a prime concern. > > Burdening this application with a high overhead session > oriented key-management for the sake of perfect forward > secrecy, (when secrecy itself is not an issue) is very poor > system design. In real network management systems, each managed entity typically communicates with a small number (usually one) of management stations. At the beginning (and maybe every day) they will end up spending a second or so setting up SAIDs, and maybe again every day or two, but thats probably the end of it. You picked a particularly bad example. > Think about ICMP messages. Do you want to have a session/exponentiations > for each and every one of them, for the sake of perfect forward > secrecy, when secrecy itself may not be a concern? ICMP messages are a much better example -- in a big network where you will typically not have much occasion to the host telling you "destination unreachable" or what have you. However, I'll note that you still have to spend some time looking up the key for the destination host no matter what you do if you are going to authenticate, so the situation isn't perfect regardless. Also, its not a question of secrecy at all in this case, because I suspect that people will use authentication only in this case and not encryption. However... > Therefore I cast a strong *no* vote to making this feature > mandatory. (I have already stated that I support this as > an optional feature for situations where secrecy is essential). I agree that we shouldn't make perfect forward key secrecy or perfect forward a requirement for all your work. However, I think that the ability to use perfect forward secrecy based systems if you wish is a requirement, because you will have instances where you will need it. I'd also say that any scheme that unfairly penalizes the use of perfect forward secrecy is also a problem. If you use perfect forward secrecy you shouldn't have to pay any more than the cost of the D-H algorithm. In particular, perfect forward secrecy shouldn't be some sort of hack hung on the side of the algorithm but should be as easy to use as any other supported mode. Key management systems that are too closely linked with a particular cryptographic algorithm are likely a problem given that technology advances with time. Certainly we must require a base algorithm for interoperability (specifying too many options is a recipe for disaster as the ISO crowd has shown) but that doesn't mean we should handcuff ourselves to Diffie-Hellman, when other better things might come along. Perry From ipsec-request@ans.net Wed Dec 14 06:24:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29621 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 17:33:50 -0500 Received: by interlock.ans.net id AA37873 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 17:24:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 17:24:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 17:24:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 17:24:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 17:24:42 -0500 Date: Wed, 14 Dec 94 14:24:47 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412142224.AA00361@miraj.Eng.Sun.COM> To: perry@imsi.com Subject: Re: Proposal: Perfect forward secrecy a MUST Cc: ipsec@ans.net >From perry@imsi.com Wed Dec 14 13:51:44 1994 >In real network management systems, each managed entity typically >communicates with a small number (usually one) of management >stations. At the beginning (and maybe every day) they will end up >spending a second or so setting up SAIDs, and maybe again every day or >two, but thats probably the end of it. You picked a particularly bad >example. Having open long-term open security associations with a large number of managed entities at the management station is not a particularly inviting prospect, considering that rebooting a management entity requires re-establishing all those associations. Since there aren't long-term network connections that are typically left open between management entity and managed entities, having long term open security connections between them doesn't sound like the right thing to do either. > If you use perfect forward >secrecy you shouldn't have to pay any more than the cost of the D-H >algorithm. I believe the proposal I made at the meeting comes close to this overhead. I didn't do a count of the computational overhead of the other perfect forward secrecy proposals, but keep in mind that protocols that authenticate using signatures have a higher computational overhead than just the DH algorithm. I believe that at least some of the other proposals do signature based authentication. (The SKIP based proposal that I made has an overhead equal to just the DH part, once cached shared master keys exist). Regards, Ashar. From ipsec-request@ans.net Wed Dec 14 22:28:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34746 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 17:33:52 -0500 Received: by interlock.ans.net id AA31006 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 17:28:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 17:28:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 17:28:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 17:28:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 17:28:49 -0500 Message-Id: <9412142228.AA15975@snark.imsi.com> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Kerberos and why I brought it up... In-Reply-To: Your message of "Wed, 14 Dec 1994 16:20:52 EST." <9412141620.ZM2125@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 17:28:40 -0500 From: "Perry E. Metzger" Ran Atkinson says: > As I (probably incompletely) understand Perry's discussion about using > Kerberos, he is suggesting using Kerberos as one (of several possible) > way to distribute keys amongst Kerberised systems implementing packet > encryption. Where I think things got confusing is that Kerberos > currently does also provide human-computer I&A as one of its features, > though perhaps a feature not directly related to implementing packet > encryption. Within communities already using Kerberos, it seems to me > very sensible to reuse the Needham-Schroeder key management technology > already implemented within Kerberos as a possible way to distribute > packet encryption keys and related data. I agree with what you've said in that paragraph, but it isn't quite what I was getting at. When all the layers (IPSP, IKMP, some certificate management, etc) are complete, we should be able to build secure networked distributed applications from them. My concern was that some of the extant proposals might not allow us to do that. I suggested that we use Kerberos as a functionality benchmark -- if you can't build, say, a secure telnet on top of our new security protocols, and especially if we can't build one that is as functional as a kerberos based secure telnet, then we haven't done our job. Entity authentication (be that users or servers) is not IPSP's job or necessarily IKMP's job, but it has to be constructable with the tools we ultimately provide. Perry From ipsec-request@ans.net Wed Dec 14 22:35:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29668 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 17:40:59 -0500 Received: by interlock.ans.net id AA02972 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 17:36:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 17:36:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 17:36:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 17:36:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 17:36:35 -0500 Message-Id: <9412142235.AA16001@snark.imsi.com> To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: Proposal: Perfect forward secrecy a MUST In-Reply-To: Your message of "Wed, 14 Dec 1994 14:24:47 PST." <9412142224.AA00361@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 17:35:07 -0500 From: "Perry E. Metzger" Ashar Aziz says: > Having open long-term open security associations with a large > number of managed entities at the management station is not a > particularly inviting prospect, considering that rebooting > a management entity requires re-establishing all those associations. True as that is, rebooting a management station as it stands is a huge problem. As an example, SPECTRUM from Cabletron takes quite a long time to restart -- long enough that I am not sure anyone would notice the association re-establishment time. > I believe the proposal I made at the meeting comes close to this > overhead. I must admit to not having studied that portion of your proposal in sufficient detail -- I ought to dig out my draft again. Perry From ipsec-request@ans.net Wed Dec 14 08:01:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12589 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 19:07:22 -0500 Received: by interlock.ans.net id AA16177 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 19:00:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 19:00:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 19:00:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 19:00:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 19:00:34 -0500 Date: Wed, 14 Dec 94 16:01:46 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412150001.AA00438@miraj.Eng.Sun.COM> To: perry@imsi.com Subject: Re: Proposal: Perfect forward secrecy a MUST Cc: ipsec@ans.net >From perry@imsi.com Wed Dec 14 15:30:36 1994 >Ashar Aziz says: >> Having open long-term open security associations with a large >> number of managed entities at the management station is not a >> particularly inviting prospect, considering that rebooting >> a management entity requires re-establishing all those associations. > >True as that is, rebooting a management station as it stands is a huge >problem. As an example, SPECTRUM from Cabletron takes quite a long >time to restart -- long enough that I am not sure anyone would notice >the association re-establishment time. I must admit to not being familiar with the SPECTRUM technology, so I dont know why reboots are a problem. However, I cannot in principle discern why a management station reboot has to be such a cumbersome process, where establishing many (possibly several hundred) security associations can be considered a small additional overhead. Ashar. P.S. This particular case was intended to be simply an example, and is not terribly germane to the overall argument, so we dont have to go into great depth on this one. From ipsec-request@ans.net Wed Dec 14 06:50:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38688 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 19:49:00 -0500 Received: by interlock.ans.net id AA32311 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 19:41:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 19:41:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 19:41:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 19:41:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 19:41:53 -0500 Date: Wed, 14 Dec 94 14:50:06 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412142250.AA00380@miraj.Eng.Sun.COM> To: rubin@faline.bellcore.com Subject: Re: Proposal: Perfect forward secrecy a MUST Cc: ipsec@ans.net, yacov@faline.bellcore.com >From rubin@faline.bellcore.com Wed Dec 14 13:54:55 1994 >Has anyone proposed any protocols for "perfect forward >secrecy"? Is this concept any different than protocols >that are resistant to known-key attacks? Are we worried >about the compromise of both master keys of communicating >parties, or a bunch of session keys being compromised not >leading to compromise of all the others? I believe the issue is primarily one of which keys does an intruder learn, and what does that allow him to determine about past encrypted traffic. If a scheme has long-term keys (a common though not necessary feature in many key-management protocols) then perfect forward secrecy means that compromise of both sides long term keys should not allow an intruder to learn encrypted traffic sent prior to the key compromise. This assumes that an intruder has recorded all the encrypted traffic, and once he/she learns the long term keys, is in a position to see if that helps him/her decrypt that past recorded encrypted traffic. I dont believe that, at least the way I use the term perfect forward secrecy, or the way Whit Diffie presented this in his 1990 Paris Securicom paper, that compromise of temporary traffic keys (e.g session keys or packet keys) is what is being referred to here. I should point out that none of this either mandates session oriented key management or even DH. It just so happens that the only practical known ways of doing this involve using session oriented DH. However, if you consider a public key cryptosystem where key-pair generation is an efficient operation, (RSA does not qualify), then one could generate ephemeral public-private key pairs of this cryptosystem, and use that to communicate session keys. This is essentially the reason why DH is usually used, because public-private key-pair generation is an efficient operation for DH (requires a single exponentiation) as opposed to key-pair generation for cryptosystems like RSA (where key-pair generation is computationally prohibitive for use in this manner). This does not mean that public key cryptosystems which have a low-overhead for key-pair generation will not eventually be discovered. Such cryptosystems will make good candidates for use in conjunction with perfect forward secrecy protocols. >Is there a particular protocol that is >under consideration that meets all the requirements, or is >everyone arguing about the concept in general? I believe a number of such protocols were presented at the San Jose IETF meeting. Ashar. From ipsec-request@ans.net Wed Dec 14 03:31:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25549 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 20:54:07 -0500 Received: by interlock.ans.net id AA25126 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 20:47:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 20:47:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 20:47:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 20:47:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 20:47:59 -0500 Date: Wed, 14 Dec 94 11:31:56 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412141931.AA00250@miraj.Eng.Sun.COM> To: perry@imsi.com Subject: Re: key management Cc: ipsec@ans.net >From: perry@imsi.com (Perry E. Metzger) >From ipsec-request@ans.net Tue Dec 13 08:17:53 1994 > 2) All but SKIP lack clearly articulated key certificates (and SKIP's > seem to be X.509 based, which is probably non-optimal) Perry, The reason I picked X.509 was that there was precedence in IETF protocols (PEM) for using that certificate encoding format. If there are specific issues/deficiencies using the X.509 approach which may be fixed using some alternative scheme, I would like to learn of that and would be happy to incorporate any such suggestions into the draft. > (I'm also a bit concerned that SKIP would need >some alteration to handle user level keying.) The way I see it is that this is primarily a naming/certificate management issue. I dont think that the basic SKIP protocol would need to be modified to handle user level keying. Additional wording would be needed to identify per user certificates/SAIDs. However, the only reason this alteration would be needed to the certificate management section of SKIP is because the SKIP draft talks about certificate management, while the other proposals have so far punted on this issue. Ashar. From ipsec-request@ans.net Wed Dec 14 16:35:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34613 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 22:28:45 -0500 Received: by interlock.ans.net id AA19102 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 22:17:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 22:17:12 -0500 Message-Id: <199412150317.AA31130@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 22:17:12 -0500 Date: Wed, 14 Dec 94 21:35:41 EST From: hugo@watson.ibm.com To: Ashar.Aziz@eng.sun.com, rubin@faline.bellcore.com Cc: ipsec@ans.net, yacov@faline.bellcore.com Subject: Ephemeral RSA Ref: Your note of Wed, 14 Dec 94 14:50:06 PST (attached) Ashar says: >> However, if you consider a public key cryptosystem >> where key-pair generation is an efficient operation, >> (RSA does not qualify), then one could generate >> ephemeral public-private key pairs of this cryptosystem, >> and use that to communicate session keys. Just for the amusement: if you count ONLY real-time operations, then using ephemeral RSA keys is significantly more efficent than DH. A chooses off-line two RSA primes and computes their product n. Then for key exchange A sends n to B. B encrypts a key using RSA with the public key n and sends it to A. A decrypts to find the key. The on-line cost is two multiplications (with public exponent 3) for B, and one RSA decryption for A (the later is up to 4 times faster than a single DH exponentiation using the Chinesse Remainder Thm). This is about 8 times less computation than the two (real-time) exponentiations required by DH. Hugo From ipsec-request@ans.net Wed Dec 14 17:32:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34683 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 22:43:36 -0500 Received: by interlock.ans.net id AA26717 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 22:32:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 22:32:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 22:32:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 22:32:30 -0500 Date: Wed, 14 Dec 1994 22:32:23 +0500 From: Theodore Ts'o Message-Id: <9412150332.AA08227@dcl.MIT.EDU> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Ran Atkinson's message of Wed, 14 Dec 1994 16:20:52 -0500, <9412141620.ZM2125@sundance.itd.nrl.navy.mil> Subject: Re: Human I&A, IPsec, and their non-relationship Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1568 From: Ran Atkinson Date: Wed, 14 Dec 1994 16:20:52 -0500 I've been trying to sort out why so many folks appear to be talking past each other recently on this list. I think I might have partly figured it out -- if I'm correct part of the problem is a communication gap between several folks (including me).... Actually, I think the problem is that people have not been explicit about their goals..... % Satisfying user granularity identification, authentication, and access % control at the IP layer seems to be one of those issues where desired % capabilities and feasibility clash. I do not believe that anyone has proposed or is currently advocating use of network-layer or transport-layer encryption to provide human--computer identification or authentication. Actually, over the past couple of IETF's, I have heard people saying, "isn't IPSEC going to make Kerberos obsolete?" I think there are those who believe that the key management protocols and per-user keying of connection is precisely enough to replace the functionality of application level security protocols like Kerberos. Of course, if you're going to do this, there are all sorts of additional problems that one has to solve, some of which have already been pointed out on this list. As long as we agree on the goals, then I hopefully a lot of this miscommunication will go away. So --- are we all in agreement with Ran that IPSEC is *not* trying to solve the human-computer authentication problem? - Ted From ipsec-request@ans.net Wed Dec 14 03:16:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16108 (5.65c/IDA-1.4.4 for ); Wed, 14 Dec 1994 23:01:27 -0500 Received: by interlock.ans.net id AA32008 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 14 Dec 1994 22:51:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 14 Dec 1994 22:51:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 14 Dec 1994 22:51:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Dec 1994 22:51:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Dec 1994 22:51:24 -0500 Date: Wed, 14 Dec 94 11:16:26 PST From: Ashar.Aziz@eng.sun.com (Ashar Aziz) Message-Id: <9412141916.AA00245@miraj.Eng.Sun.COM> To: amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP Cc: ipsec@ans.net >From amir@watson.ibm.com Wed Dec 14 05:47:17 1994 > >In Ashar's response I found two different issues which we should clarify. >I'll dedicate this note to the first, which is: can we assume in SKIP that >the receiver can pre-compute all Kij pairs. It apprears to me that's what >Ashar suggests: > >> First, let me mention that the pair keys Kij always (conceptually) >> exist, and can be precomputed *prior* to any communication attempt. >> > >I think this is not reasonable for many applications. In particular, it >is not reasonable for the `firewall' application where a firewall of an >organization is the endpoint of (some) tunnels leading to the organization, >a scenario which the group has decided we must support (see Paul's note). >The number of potential Kij's is simply too large (practically unbounded). We have to be clear what firewall scenario we are talking about. If we are talking about firewall-to-firewall, then the number of Kijs is proportional to the square of the number of firewalls, *not* the square of the number of endpoints on either side of them. This is usually a small number even with sites having thousands of endpoints, because it is related to the number of sites, not the number of machines in those sites. Second, the end-node to firewall, a scenario used to access organizations from either home or some public network is limited to the number of machines coming in over the public networks using that one particular access point. This cannot be a very large number, because there is a practical limit to what a particular firewall machine can support in terms of simultaneous independent transactions, and in most cases is also bounded for these practical reasons. So, I disagree with your contention that the Kijs become unbounded for the firewall scenario. >> This can be done by following a prioritized list using the per node >> ACL (which you always need, because otherwise there is no need to >> authenticate). > >Allow me to disagree: you don't always need an ACL (certainly not an `explicit >ACL' - even when ACL is needed, many times one can have `wildcards' to specify >large groups). For example, some firewalls may have a policy to allow all >communication in, except for some blacklisted, but also log the event (and >use the authentication to maintain the blacklist). Others may allow all >communication from any machine belonging to specific trading partners or >to all internal machines. While these examples are dramatic for the firewall >scenario, they apply almost as well to `regular' hosts. An ACL always exists, whether it is wildcarded or expressed in "not allowed" terms. What I was trying to say is that if everyone is allowed, there is no point to authenticate the access. >> Note that this sort of precomputation cannot be performed >> using traditional (non-SKIP) interactive schemes, because there >> are no shared secrets prior to communication. > >Again I must disagree. The pre-computation involves also getting the >(certified or otherwise authenticated) public keys. This is just the same >as the initial communication (and computation) of any other scheme for >long-lived keys. I must also disagree with your contention. This is *not* the same as the initial communication to compute session or master keys using traditional techniques, because precomputing SKIP master keys doesn't even require the machines for which master keys are being computed to be connected to the network or to be online. All that is required are the remote certificates, which may be obtained from a local cache, a local directory server etc. This is a very practical matter, because in firewall scenarios, end node machines (residing in e.g. homes) dont have to be powered up for this computation to occur, nor do expensive telephone/ISDN/etc. calls have to made to the home to establish these keys. Ashar. From ipsec-request@ans.net Thu Dec 15 11:24:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24601 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 06:53:34 -0500 Received: by interlock.ans.net id AA29725 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 06:35:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 06:35:13 -0500 Message-Id: <199412151135.AA29721@interlock.ans.net> Date: 15 Dec 94 11:24:00 GMT From: "Tim Dean" Subject: Re: Re[2]: key management To: "ipsec" For what it's worth, when we were building an IP-layer security protocol, we realized at an early stage that user level authentication and other security services could be achieved *without* the necessity of having a separate key per user in the security layer: in fact one key per end system pair is all that is needed, provided some kind of user identification field is carried inside each encrypted packet. The reason is that you have to trust your security layer to properly handle data before encryption and after decryption, whether one key or many is used; and an attacker on the network can't do anything more if everything is encrypted with one key than he can do with many keys (provided a bit of careful thought is given to Integrity Check Values). Therefore you might as well just use one key. Doing this also has several other added benefits: 1) The cost of key management is greatly reduced. 2) Management of user ids is totally decoupled from management of Security Associations (SAs): SAs are hard enough things to manage without interactions with higher layers adding further complexity. If they're decoupled, key/SA rollover can be achieved transparently to the user. 3) The number of users operating over a particular SA is hidden from eavesdroppers on the network. Best, Tim Dean dean@hydra.dra.hmg.gb From ipsec-request@ans.net Thu Dec 15 13:56:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24671 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 09:15:24 -0500 Received: by interlock.ans.net id AA25088 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 08:56:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 08:56:48 -0500 Message-Id: <199412151356.AA38396@interlock.ans.net> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, solo@BBN.COM Subject: Re: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of Wed, 14 Dec 94 16:20:52 -0500. <9412141620.ZM2125@sundance.itd.nrl.navy.mil> Date: Thu, 15 Dec 94 08:56:55 -0500 From: solo@BBN.COM Ran, > Date: Wed, 14 Dec 94 16:20:52 EST > From: Ran Atkinson > Subject: Human I&A, IPsec, and their non-relationship > ---------------------------------------------------------------------- > On Dec 13, 16:31, solo@BBN.COM wrote: > % Subject: Re: key management > % > % Satisfying user granularity identification, authentication, and access > % control at the IP layer seems to be one of those issues where desired > % capabilities and feasibility clash. > > I do not believe that anyone has proposed or is currently > advocating use of network-layer or transport-layer encryption to > provide human--computer identification or authentication. > > % In a multi-user environment, providing different identities at the > % IP level is incompatible with both typical host assurance and with > % the protocol architecture. > > To my understanding of what you mean by "providing different > identities", I disagree with the statement quoted above (details > immediately follow). > > One straight-forward way to implement this in UNIX on the > sending side is for the upper layer to either (1) pick the SAID value > based on source uid and destination IP address and pass down that SAID > as part of the socket information to the lower layer or (2) for the > encrypting layer to obtain source uid from socket state directly and > destination IP address in the existing manner, use those two data > points to call a function returning the needed key, algorithm, and > other security data for the outgoing packet. Other methods can be > devised. These 2 are just examples -- I'm not making any assertions > about which implementation strategy would be best. > > On the receive side, the receiver gets an encrypted/ > authenticated packet containing a plain-text SAID. It feeds that SAID > into a function and gets the key, algorithm and other security > association data as the return from that function. It then processes > the packet using the data returned from that call and (if successful > in decrypting/authenticating) passes the received upper layer data to > the upper layer in the usual manner (possibly including a flag > indicating the data was received encrypted or that authentication > succeeded). > > Each side maintains a logical table (implemented however one > likes) that is indexed by SAID and the Destination Address (because > SAIDs in IPv6 are receiver-oriented to be compatible with IP > multicast). That table contains all of the security association > parameters (e.g. key, algorithm, algorithm mode, maybe a sensitivity > level, etc). > > Please note the absence of ALL human-computer > Identification/Authentication in the above process description. The problem I have with this scenario and with Perry's example is understanding what services/advantages you are getting by having multiple security associations between the hosts at the IP layer. In both cases, you are saying that you will rely on the transport and application layers to accurately convey uid/SAID information to be used by the IPSP layer. If you trust those protocol layers, why not have a single "secure pipe" (based on host oriented keying material) between the system and rely on the applications to perform user I&A (a conclusion I agree with). If you don't trust thos layers, then per-user security associations at the IP layer aren't useful. Typically, providing distinct security associations (either explicitly or by carrying protected demultiplexing information) is useful only when secure (de)multiplexing takes place immediately following the security protocol processing - either via trusted protocol implementations or by having multiple instantiations of the protocols (in this case xport and above) separated by a high assurance operating system. Since neither of these situations applies in most cases you are discussing, I have a hard time seeing what the goals of per-user security associations at the IP layer are (vs. seeing how you can implement it). That's why I am arguing against a "requirement" for a mechanism, rather than a service. > > % Note, by the way, that solving this > % on the receive end is much more complicated than on the sending end > % of a datagram. > > Please explain, preferably using the above process as a discussion > point. This comment depends on how the IPSP and km functions fit into a series of exchanges. If you had a model which expected the applications to negotiate security association information (as part of an I&A and access control process) prior to creating the IP security association, then you could end up in a situation where you want IPSP to perform decisions (whether to allow unprotected datagrams through, access control for datagrams, etc.) based on the state of higher layer protocols. Such a situation isn't too bad on the sending side since the sending process can communicate this information but is harder on the receiving end where the information IPSP has to work with is limited. This issue applies only in certain cases but I haven't seen a complete proposal of how someone plans to use per-user keying as part of integrated solution. Dave From ipsec-request@ans.net Thu Dec 15 13:56:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24620 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 09:47:08 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Thu, 15 Dec 1994 09:36:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 09:36:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Thu, 15 Dec 1994 09:36:44 -0500 Message-Id: <199412151356.AA38396@interlock.ans.net> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, solo@BBN.COM Subject: Re: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of Wed, 14 Dec 94 16:20:52 -0500. <9412141620.ZM2125@sundance.itd.nrl.navy.mil> Date: Thu, 15 Dec 94 08:56:55 -0500 From: solo@BBN.COM Ran, > Date: Wed, 14 Dec 94 16:20:52 EST > From: Ran Atkinson > Subject: Human I&A, IPsec, and their non-relationship > ---------------------------------------------------------------------- > On Dec 13, 16:31, solo@BBN.COM wrote: > % Subject: Re: key management > % > % Satisfying user granularity identification, authentication, and access > % control at the IP layer seems to be one of those issues where desired > % capabilities and feasibility clash. > > I do not believe that anyone has proposed or is currently > advocating use of network-layer or transport-layer encryption to > provide human--computer identification or authentication. > > % In a multi-user environment, providing different identities at the > % IP level is incompatible with both typical host assurance and with > % the protocol architecture. > > To my understanding of what you mean by "providing different > identities", I disagree with the statement quoted above (details > immediately follow). > > One straight-forward way to implement this in UNIX on the > sending side is for the upper layer to either (1) pick the SAID value > based on source uid and destination IP address and pass down that SAID > as part of the socket information to the lower layer or (2) for the > encrypting layer to obtain source uid from socket state directly and > destination IP address in the existing manner, use those two data > points to call a function returning the needed key, algorithm, and > other security data for the outgoing packet. Other methods can be > devised. These 2 are just examples -- I'm not making any assertions > about which implementation strategy would be best. > > On the receive side, the receiver gets an encrypted/ > authenticated packet containing a plain-text SAID. It feeds that SAID > into a function and gets the key, algorithm and other security > association data as the return from that function. It then processes > the packet using the data returned from that call and (if successful > in decrypting/authenticating) passes the received upper layer data to > the upper layer in the usual manner (possibly including a flag > indicating the data was received encrypted or that authentication > succeeded). > > Each side maintains a logical table (implemented however one > likes) that is indexed by SAID and the Destination Address (because > SAIDs in IPv6 are receiver-oriented to be compatible with IP > multicast). That table contains all of the security association > parameters (e.g. key, algorithm, algorithm mode, maybe a sensitivity > level, etc). > > Please note the absence of ALL human-computer > Identification/Authentication in the above process description. The problem I have with this scenario and with Perry's example is understanding what services/advantages you are getting by having multiple security associations between the hosts at the IP layer. In both cases, you are saying that you will rely on the transport and application layers to accurately convey uid/SAID information to be used by the IPSP layer. If you trust those protocol layers, why not have a single "secure pipe" (based on host oriented keying material) between the system and rely on the applications to perform user I&A (a conclusion I agree with). If you don't trust thos layers, then per-user security associations at the IP layer aren't useful. Typically, providing distinct security associations (either explicitly or by carrying protected demultiplexing information) is useful only when secure (de)multiplexing takes place immediately following the security protocol processing - either via trusted protocol implementations or by having multiple instantiations of the protocols (in this case xport and above) separated by a high assurance operating system. Since neither of these situations applies in most cases you are discussing, I have a hard time seeing what the goals of per-user security associations at the IP layer are (vs. seeing how you can implement it). That's why I am arguing against a "requirement" for a mechanism, rather than a service. > > % Note, by the way, that solving this > % on the receive end is much more complicated than on the sending end > % of a datagram. > > Please explain, preferably using the above process as a discussion > point. This comment depends on how the IPSP and km functions fit into a series of exchanges. If you had a model which expected the applications to negotiate security association information (as part of an I&A and access control process) prior to creating the IP security association, then you could end up in a situation where you want IPSP to perform decisions (whether to allow unprotected datagrams through, access control for datagrams, etc.) based on the state of higher layer protocols. Such a situation isn't too bad on the sending side since the sending process can communicate this information but is harder on the receiving end where the information IPSP has to work with is limited. This issue applies only in certain cases but I haven't seen a complete proposal of how someone plans to use per-user keying as part of integrated solution. Dave From ipsec-request@ans.net Thu Dec 15 14:38:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16271 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 09:59:00 -0500 Received: by interlock.ans.net id AA37520 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 09:42:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 09:42:34 -0500 From: Ran Atkinson Message-Id: <9412150938.ZM2919@sundance.itd.nrl.navy.mil> Date: Thu, 15 Dec 1994 09:38:57 -0500 In-Reply-To: solo@BBN.COM "Re: Human I&A, IPsec, and their non-relationship" (Dec 15, 8:56) References: <9412151356.AA27959@itd.nrl.navy.mil> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: Human I&A, IPsec, and their non-relationship Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Dec 15, 8:56, solo@BBN.COM wrote: % The problem I have with this scenario and with Perry's example is % understanding what services/advantages you are getting by % having multiple security associations between the hosts at the % IP layer. In both cases, you are saying that you will rely on % the transport and application layers to accurately convey uid/SAID % information to be used by the IPSP layer. If you trust those % protocol layers, why not have a single "secure pipe" (based on % host oriented keying material) between the system and rely % on the applications to perform user I&A (a conclusion I agree % with). If you don't trust thos layers, then per-user security % associations at the IP layer aren't useful. I am glad we agree that application I&A is outside the scope of this effort. I disagree that per-userid-keying is not useful. One widely used example is the problem of mutually suspicious users (Alice, Bob) on some host X where none of those users has special privileges (in UNIX terms, none of them are root). In such a case when per-userid-keying is not provided, then user Alice can create arbitrary plaintext/ciphertext pairs between its host and another host Y in order to assist in Alice's cryptanalysis to determine what data Bob is sending to someone on host Y that Bob does not want Alice to know about. Using a separate key per userid will entirely preclude that attack strategy. The IPv6 specs say that an _implementation_ must support per-userid-keying but also specifically says that an implementation MAY support host-to-host keying as well. This means that the system administrator is capable of using per-userid-keying or use host-to-host keying and can make that choice as a local policy matter. % Typically, providing distinct security associations (either % explicitly or by carrying protected demultiplexing information) is % useful only when secure (de)multiplexing takes place immediately % following the security protocol processing - either via trusted % protocol implementations or by having multiple instantiations of the % protocols (in this case xport and above) separated by a high assurance % operating system. Since neither of these situations applies in most % cases you are discussing, I have a hard time seeing what the goals of % per-user security associations at the IP layer are (vs. seeing how you % can implement it). That's why I am arguing against a "requirement" % for a mechanism, rather than a service. Customers who desire high assurance that some mechanism works will probably purchase high assurance implementations of that mechanism. Many customers desire some mechanism but are not very concerned about the assurance level of the implementation of that mechanism. More generally, assurance arguments are outside the legitimate scope of this WG because the IETF only specifies mechanisms, not assurance of quality I consider every version of UNIX I've used or closely examined to be low-assurance. The prototyping work we're currently engaged in here is similarly low-assurance since the original code was low-assurance That does not make per-userid-keying useless even for the low assurance implementations. Contrariwise it means that the separation between users that is provided by the network has similar assurance characteristics to the separation between users provided by the operating system. It is not economically sensible to have significantly different assurance for the network separation than for the computer separation because a chain is only as strong as its weakest link. % This comment depends on how the IPSP and km functions fit into a % series of exchanges. If you had a model which expected the % applications to negotiate security association information (as part of % an I&A and access control process) prior to creating the IP security % association, then you could end up in a situation where you want IPSP % to perform decisions (whether to allow unprotected datagrams through, % access control for datagrams, etc.) based on the state of higher layer % protocols. I do not have such a model. % Such a situation isn't too bad on the sending side since % the sending process can communicate this information but is % harder on the receiving end where the information IPSP has to work % with is limited. This issue applies only in certain cases but I % haven't seen a complete proposal of how someone plans to use % per-user keying as part of integrated solution. I am not suggesting per-userid-keying primarily for use in application-layer I&A and I am not suggesting any particular approach to application-layer I&A. I believe application-layer I&A to be completely outside the scope of this WG's effort. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Dec 15 15:14:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20980 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 10:36:00 -0500 Received: by interlock.ans.net id AA03349 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 10:14:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 15 Dec 1994 10:14:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 10:14:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 10:14:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 10:14:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 10:14:51 -0500 Message-Id: <9412151514.AA45155@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Proposal: Perfect forward (proactive) SECURITY a MUST In-Reply-To: Your message of "Wed, 14 Dec 1994 12:23:34 PST." <9412142023.AA00296@miraj.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Dec 1994 10:14:41 -0500 From: " " Ashar and all, > >From ipsec-request@ans.net Tue Dec 13 14:30:39 1994 > >However I think we should be even more explicit about whether we want > >perfect forward secrecy to be a must. Aziz has pointed out that this > >feature does not come for free, and I think we are all saying that at least > >the computational cost is not prohibitive. > > Actually, when I said it doesn't "come for free", I was quoting > you in an earlier message. Correct; of course it does not come for free!! This is the reason for us to discuss and try to decide on the tradeoffs. In fact I've already mentioned that perfect forward secrecy would cost us both some performance as well as requiring a state. It appears to me the computational cost is not too bad, and (as I explain below) that the state is not a sufficient barrier either. I asked if you have additional arguments I did not consider, and of course I'll like us to discuss the tradeoffs in order to reach agreement. Again: I don't see this as black and white... It's a tradeoff. But, we must decide, and therefore I also state my position: the price is reasonable. Let's require perfect forward (proactive) security. > >Aziz (and others), could you enumerate all the disadvantages/costs associated > >with deciding on perfect forward secrecy as a requirement? > > Sure, I would be happy to. > > Think about time critical network management operations that > have authentication of management entities as a prime concern. > > Burdening this application with a high overhead session > oriented key-management for the sake of perfect forward > secrecy, (when secrecy itself is not an issue) I believe people care not just about `perfect forward secrecy' but more generally about `forward SECURITY', which we call `proactive security'. Namely, the security of the system (inc. authentication) should recover from break-ins which reveal the secret keys of the parties. This would be assured by, e.g., running DH periodically. At least, I believe requiring such `proactive security' or `forward security' is reasonable for us, since so far I don't see the prohibitively large costs. I think this is proper design since strong security which does not cost much would allow the protocol to be used for more scenario and for longer time. > The whole reason for running SNMP primarily > on top of UDP was to keep it lightweight and quick. Now you > want to add an elaborate high overhead protocol underneath > it as a *mandatory* feature, which has no justification > in this context. First of all, our protocol is lightweight, simple, provably secure and quick. Second, I did not say that we would not support other options. In fact I tend to feel that some implementations could support a well-defined feature that allows less secure but more efficient SKIP-like security. My only question is what is the requirement we should place on our base protocol. We need to agree in order to get more progress. In particular, I think well of your work, and I believe that if we reach consensus, you could contribute more by helping in the design of a base protocol with interaction with an optional non-interactive mode. Peace! > > Think about ICMP messages. Do you want to have a session/exponentiations > for each and every one of them, for the sake of perfect forward > secrecy, when secrecy itself may not be a concern? Again the issue is not merely secrecy but also authentication. Furthermore, I think that for many applications such as ICMP, even SKIP may require communication before getting Kij as I've explained in another message. Essentially, if the two parties know each other a-priori and cache Kij, they could just as well keep a long-lived key derived by a protocol... If they don't then they still have to go to some directory to get public keys (even in SKIP). > Do you believe that vendors that sell IPSP will turn on > strong encryption by default? How is this related? Strong authentication is fine! (I'll love to have strong encryption too and IBM is lobbying to get this) > You stated at the IETF meeting > that you (IBM) want to build exportable products (with > weak or no encryption). I certainly did not say `no encryption'. Also, we don't `want' to, but we are forced to by law. We try to change the law and we try to provide the maximal legal security. > Now you are pushing a feature as > mandatory that makes sense only when used with strong > encryption (something that you yourselves dont intend to > make the default). Ashar, you got it upside down. First, this feature is great for authentication, not just secrecy. Second, for secrecy, this feature is very useful in conjunction with WEAK, EXPORTABLE ENCRYPTION!! Namely, even if the bad guys can break some keys, they cannot break the other keys without working again, and does not collect info on any master keys. The last point may not be too critical if one uses very good security for the master keys (as is exportable), but the fact remains that the proactive security is very valueable with weak encryption as the security is recovering from break-ins! > > Working for a computer company, I understand that computers are > getting faster every year. We love to sell our latest and fastest > computers, but we also realize that we can't expect our customers > to throw out all the equipment that they have already purchased > and spent billions of dollars on, as soon as the new models arrive. Agreed. > > The installed base of computers does not vanish easily, and we > should be careful about mandating features that are *not* necessary > in many circumstances, and which pose an unreasonable protocol > and computational burden to the millions of computers installed > in the field *today*. Agreed. However I don't think the overhead of a rarely-invoked protocol is so significant. Compare this to SKIP, where you essentially suggest that the public keys would be changed by some off-line operation. > > Therefore I cast a strong *no* vote to making this feature > mandatory. (I have already stated that I support this as > an optional feature for situations where secrecy is essential). I understand and respect your position. I'm happy to observe that we both want both modes, one to be the default and the other as option. We just have different preferences to which is default. Maybe further discussions would allow us to agree, if not, then I think the group should try to decide in order to proceed. Clearly, even picking the wrong one as default should not be as bad as continued disagreement (if this is really the wrong choice then people will just use the option). Best, Amir From ipsec-request@ans.net Thu Dec 15 07:36:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37884 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 13:31:40 -0500 Received: by interlock.ans.net id AA11862 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 13:19:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 13:19:33 -0500 Message-Id: <199412151819.AA16463@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 13:19:33 -0500 Date: Thu, 15 Dec 94 12:36:41 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Perfect fwd secrecy and authentication Ashar and others, In several mails from Ashar, and supported by other people, it is observed that perfect fwd secrecy (PFS) is irrelevant to (packet) authentication. In the strict academic sense of PFS this is true. But in the more specific (and less academically precise) setting in which we discuss these issues (we are essentially concerned with what does an adversary gain by finding one party's private key) the performance of an authenticated key exchange as Diffie-Hellman IS relevant ALSO to the issue of packet authentication (and not only secrecy). SKIP is a good illustration of that. If you do "plain" SKIP (as appears in Ashar's draft) then by knowing the private key of one party, say A, you can send authenticated packets from this party to anybody you choose. (In the case of SKIP you also can send authentciated packets to A from anybody else). However, if you do perform an authenticated DH for key exchange, then the way to use the knowledge of A's private key is to actively impersonate A in the key exchange protocol with, say, B. Once an adversary does that it can start injecting authenticated packets from A to B. The are several important differences between the later and the plain SKIP case: *It is generally easier to inject packets in a "one-way" form than actively imposing an interaction (in the later the adversary has to solve the problem of routing the DH response to itself instead of to the legal IP target). *It is easier to detect an adversary that exchanges DH keys with you (especially when the real party A tries also to exchange a key with you after a while) than one that just injects traffic (especially if the legal party A is currently inactive or you may maintain more than one session with A). One can even enhance the DH exchange to improve detection (e.g. using some form of chaining between consecutive exchanges) and even build special system control mechanisms to deal with this detection (of course the later should NOT be part of standard IKMP!) *The adversary needs to run a DH exchange with EACH party with which it wants to impersonate A (in SKIP once he knows A's key he can do it with everyone) *The adversary cannot impersonate B to A by knowing A's key only (while in SKIP it could). Hugo From ipsec-request@ans.net Thu Dec 15 20:05:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29565 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 15:16:37 -0500 Received: by interlock.ans.net id AA05548 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 15:05:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 15 Dec 1994 15:05:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 15:05:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 15:05:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 15:05:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 15:05:53 -0500 Message-Id: <9412152005.AA45223@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Ashar.Aziz@eng.sun.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Clogging attacks on SKIP In-Reply-To: Your message of "Wed, 14 Dec 1994 11:16:26 PST." <9412141916.AA00245@miraj.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Dec 1994 15:05:17 -0500 From: " " Ashar Aziz says: > >> First, let me mention that the pair keys Kij always (conceptually) > >> exist, and can be precomputed *prior* to any communication attempt. > >> > >I think this is not reasonable for many applications. In particular, it > >is not reasonable for the `firewall' application where a firewall of an > >organization is the endpoint of (some) tunnels leading to the organization, > >a scenario which the group has decided we must support (see Paul's note). > >The number of potential Kij's is simply too large (practically unbounded). > > We have to be clear what firewall scenario we are talking about. > > If we are talking about firewall-to-firewall No. > Second, the end-node to firewall, a scenario used to access organizations > from either home or some public network This is the scenario I talk about. The end-node does not even have to be of an employee, though. It could be a customer, or employee of a trading partner, etc... > is limited to the number of > machines coming in over the public networks using that one particular > access point. No - it is limited to the number of machines which _may_ use this access point. This number can be prohibitively large. Furthermore, it is impractical to require that all these machines are predefined to the firewall, due to administrative reasons (when a new employee joins in we can't update all firewalls of the company, much less of all partners). > So, I disagree with your contention that the Kijs become unbounded > for the firewall scenario. > I don't see your justification. Please address the context I've elaborated on above. > An ACL always exists, whether it is wildcarded or expressed in > "not allowed" terms. What I was trying to say is that if everyone > is allowed, there is no point to authenticate the access. I agree with this. But what you said implied that the existance of an ACL limits the number of potential keys that should be pre-stored. Clearly this argument does not hold for wildcard ACLs. That was my argument. > I must also disagree with your contention. This is *not* the same > as the initial communication to compute session or master keys using > traditional techniques, because precomputing SKIP master keys doesn't even > require the machines for which master keys are being computed to be connected > to the network or to be online. All that is required are the remote > certificates, which may be obtained from a local cache, a local directory > server etc. You are right - this is different. Therefore, this is an advantage of having SKIPish master keys. However it still applies only to known partners. Best, Amir From ipsec-request@ans.net Thu Dec 15 20:26:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31043 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 15:36:58 -0500 Received: by interlock.ans.net id AA12200 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 15:27:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 15:27:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 15:27:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 15:27:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 15:27:49 -0500 Date: Thu, 15 Dec 1994 12:26:24 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9412152026.AA02353@miraj.> To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com Subject: Re: Proposal: Perfect forward (proactive) SECURITY a MUST Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > Again: I don't see this as black and white... It's a tradeoff. But, we must > decide, and therefore I also state my position: the price is reasonable. > Let's require perfect forward (proactive) security. I think I have already stated my position on this. Now it's for the rest of the group to voice their opinion (if they haven't already done so). Now for a clarification. I didn't see a perfect forward secrecy proposal in your MKMP document, other than one which was SKIP based (in the appendix), i.e using SKIP to exchange ephemeral DH values. (The master key update protocol in the body of the MKMP document provides good as opposed to perfect forward secrecy). As I have already confirmed offline with Hugo, this is the same proposal that I made at the San Jose IETF, (and which I also mentioned verbally at the Toronto IETF). So, is this the proposal that you are advocating for perfect forward secrecy? If so, we are at least coming closer to an agreement. The issue now is whether this is mandatory for situations which dont require secrecy, or optional for situations which require secrecy (which is what I support). (I should mention that Whit Diffie, the person who originally presented this concept, agrees with my position on this.) > First of all, our protocol is lightweight, simple, provably secure and quick. > Second, I did not say that we would not support other options. In fact I tend > to feel that some implementations could support a well-defined feature that > allows less secure but more efficient SKIP-like security. My only question is > what is the requirement we should place on our base protocol. We need to > agree in order to get more progress. In particular, I think well of your > work, and I believe that if we reach consensus, you could contribute more > by helping in the design of a base protocol with interaction with an optional > non-interactive mode. Peace! Peace on you and others as well! (After all, this is the season, isn't it?) My view on this is that if something is going to be a default, it should be the simple and lightweight thing. Take for example, UDP. Having IP, UDP is a no-brainer. TCP on the other hand requires more work. So, requiring UDP is not a major requirement. Same for SKIP. It is simple, efficient and essentially a no-brainer. Requiring this on every node does not constitute a major burden to either implementors or the platforms on which it is to run. There are no complicated state machines to deal with here, and the computational burden is minimal. (I dont consider your interactive proposal with the complex state machine, the requirement for bypass traffic, and the problem of dealing with half-open connections when one side crashes as terribly simple, at least not in comparison with SKIP). Also, as I mentioned in my IETF talk (and as your MKMP document also notes in the appendix) it is possible to have perfect forward secrecy on top of SKIP, without requiring a different crypto algorithm's (e.g RSA) authenticated public keys. The authentic DH public keys may be obtained either from secure DNS (per the Kaufman-Eastlake draft) or using some certificate format distributed using a standard directory service. I should point out that this would have the lowest computational overhead of any perfect forward secrecy scheme, (including, I believe, the Yacobi scheme) and furthermore does not suffer from the (admittedly theoretical) triangle attack (Burmeister, Crypto '94). If we can agree on these two modes, one session-less, simple and efficient, and the other heavier-weight, more complex and session oriented, then we will have essentially the equivalent of what already exists in the Internet for transport protocols, namely UDP and TCP. We can then argue over which one should be required and which one should be optional. Can we at least agree on this? Or do you have another perfect forward secrecy proposal that you would like to support? > > Do you believe that vendors that sell IPSP will turn on > > strong encryption by default? > > How is this related? Strong authentication is fine! (I'll love to have > strong encryption too and IBM is lobbying to get this) This is related because perfect forward secrecy is only important if you have secrecy! Authentication-only with perfect-forward secrecy is an oxymoron. > Ashar, you got it upside down. First, this feature is great for authentication, > not just secrecy. What are you talking about? Perfect forward secrecy is great for authentication? How can forward secrecy make sense, when there is no secrecy to begin with? (I will address Hugo's concerns later, which are related to key compromise and dont really fall in the category of perfect forward secrecy, as the way the term is used in the literature, and by the person who invented it). > Agreed. However I don't think the overhead of a rarely-invoked protocol is so > significant. Compare this to SKIP, where you essentially suggest that the > public keys would be changed by some off-line operation. I am afraid you lost me here. What are you referring to? I suggested offline computation of ephemeral DH keys, wrt the perfect forward secrecy-on-SKIP proposal. When did I refer to changing SKIP public keys offline? > I understand and respect your position. I'm happy to observe that we both > want both modes, one to be the default and the other as option. We just have > different preferences to which is default. I also respect your work and position, and hope our disagreements will not prevent continued joint work in helping define/discuss the requirements/details of the key-management scheme that will ultimately be deployed. Best regards, peace and goodwill, Ashar. From ipsec-request@ans.net Thu Dec 15 20:44:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29680 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 15:58:21 -0500 Received: by interlock.ans.net id AA16638 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 15:44:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 15 Dec 1994 15:44:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 15:44:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 15:44:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 15:44:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 15:44:33 -0500 From: uri@watson.ibm.com Message-Id: <9412152044.AA18182@buoy.watson.ibm.com> Subject: Re: Human I&A, IPsec, and their non-relationship To: atkinson@itd.nrl.navy.mil Date: Thu, 15 Dec 1994 15:44:26 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9412150938.ZM2919@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Dec 15, 94 09:38:57 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2255 Ran Atkinson says: > I am glad we agree that application I&A is outside the scope of this > effort. (:-) > I disagree that per-userid-keying is not useful. > One widely used example is the problem of mutually suspicious users > (Alice, Bob) on some host X where none of those users has special > privileges (in UNIX terms, none of them are root). In such a case > when per-userid-keying is not provided, then user Alice can create > arbitrary plaintext/ciphertext pairs between its host and another host > Y in order to assist in Alice's cryptanalysis to determine what data > Bob is sending to someone on host Y that Bob does not want Alice to > know about. So what? A trivial case of chosen plaintext attack? What's the big deal about it? Aren't you going to require your algorithms be at least chosen-plaintext-attack secure? Also, in addition to that, not-brain-dead hosts would probably update the keys before the amount of traffic encrypted by them allows anything bad to happen. > Using a separate key per userid will entirely preclude that attack > strategy. Again, this is only to secure host-to-host communications. It's more than likely, that security-cautious higher levels will have their *own* authentication and protection. For surely no sane application is going to trust user A from host B just because IP layer says so? > That does not make per-userid-keying useless even for the low > assurance implementations. Contrariwise it means that the separation > between users that is provided by the network has similar assurance > characteristics to the separation between users provided by the > operating system. But... If I can break it at system/host level, I don't need to bother with the network level at all. And if I can't break it on host level, then it's VERY UNLIKELY I'd be able to get anything from network...No? > I am not suggesting per-userid-keying primarily for use in > application-layer I&A and I am not suggesting any particular approach > to application-layer I&A. Yes. But still, what are the goals/reasons for supporting per-application SAIDs/keys? If only preventing chosen plaintext attacks, I'd say - who cares. -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Thu Dec 15 21:05:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38298 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 16:13:32 -0500 Received: by interlock.ans.net id AA34989 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 16:05:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 16:05:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 16:05:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 16:05:29 -0500 Date: Thu, 15 Dec 1994 14:05:03 -0700 From: Hilarie Orman Message-Id: <199412152105.OAA06892@umbra.CS.Arizona.EDU> To: atkinson@sundance.itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Yourmessage <9412150938.ZM2919@sundance.itd.nrl.navy.mil> Subject: Re: Human I&A, IPsec, and their non-relationship The motivation for per-user keying based on chosen plaintext seems unconvincing to me. The amount of data sent per key can be controlled by the OS, and adjusted to a conservative value based on the algorithm in use. Wouldn't it be cheaper and safer to rekey host-host connections than to negotiate and rekey many user/host keys? BTW, the per-user keying isn't particularly a problem for the xkernel, as our crypto extensions do key management based on a very general addressing form, and we've worked with user id's in implementing Kerberos as a protocol "layer" (albeit a complicated layer). But we were still able to keep all this out of the transport layer. It would be "cleaner" for all IPSP implementations if the user id stayed above the transport layer and the SAID's stayed below. From ipsec-request@ans.net Thu Dec 15 21:30:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27532 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 16:41:30 -0500 Received: by interlock.ans.net id AA35153 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 16:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 15 Dec 1994 16:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 16:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 16:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 16:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 16:30:31 -0500 From: uri@watson.ibm.com Message-Id: <9412152130.AA18270@buoy.watson.ibm.com> Subject: Re: Human I&A, IPsec, and their non-relationship To: ho@cs.arizona.edu (Hilarie Orman) Date: Thu, 15 Dec 1994 16:30:26 -0500 (EST) Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <199412152105.OAA06892@umbra.CS.Arizona.EDU> from "Hilarie Orman" at Dec 15, 94 02:05:03 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 541 Hilarie Orman says: > The motivation for per-user keying based on chosen plaintext seems > unconvincing to me. The amount of data sent per key can be controlled > by the OS, and adjusted to a conservative value based on the algorithm > in use. Wouldn't it be cheaper and safer to rekey host-host > connections than to negotiate and rekey many user/host keys? Oh yes! Not only cheaper, but *simpler*! And I think, KISS ideology saved more than one life (:-). -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Thu Dec 15 22:51:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29500 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 18:01:09 -0500 Received: by interlock.ans.net id AA33696 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 17:52:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 15 Dec 1994 17:52:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 17:52:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 17:52:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 17:52:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 17:52:30 -0500 Message-Id: <9412152251.AA33427@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ipsec@ans.net Subject: Known Key attack references (note from Yacov Yacobi) Date: Thu, 15 Dec 1994 17:51:41 -0500 From: " " Known key attack was first defined in my crypto'89, 90 papers. Recently Desmedt and Burmester used it (ACM'93, Crypto'94). KKA against authentication and key agreement protocols assumes that badguy has session keys and exchanged messages of some sessions other than the target session. It may be adaptive. Yacov ------- End of Forwarded Message From ipsec-request@ans.net Thu Dec 15 06:53:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18495 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 18:01:09 -0500 Received: by interlock.ans.net id AA26299 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 17:53:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 17:53:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 17:53:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 17:53:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 17:53:08 -0500 Date: Thu, 15 Dec 94 14:53:46 PST From: ashar@miraj.eng.sun.com (Ashar Aziz) Message-Id: <9412152253.AA00829@miraj.Eng.Sun.COM> To: Ashar.Aziz@eng.sun.com, hugo@watson.ibm.com Subject: Re: Ephemeral RSA Cc: ipsec@ans.net, yacov@faline.bellcore.com >From hugo@watson.ibm.com Wed Dec 14 19:18:44 1994 >Just for the amusement: if you count ONLY real-time >operations, then using ephemeral RSA keys is significantly >more efficent than DH. >A chooses off-line two RSA primes and computes their product n. >Then for key exchange A sends n to B. >B encrypts a key using RSA with the public key n and sends it to A. >A decrypts to find the key. > >The on-line cost is two multiplications (with public exponent 3) for B, >and one RSA decryption for A (the later is up to 4 times faster than > a single DH exponentiation using the Chinesse Remainder Thm). >This is about 8 times less computation than the two (real-time) >exponentiations required by DH. :-) Well, this is amusing. Are you proposing we do this, or was this just an FYA? Ashar. From ipsec-request@ans.net Thu Dec 15 23:10:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17089 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 18:19:39 -0500 Received: by interlock.ans.net id AA37128 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 18:10:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 18:10:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 18:10:48 -0500 Message-Id: <9412152310.AA17665@columbia.sparta.com> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of "Thu, 15 Dec 94 09:38:57 EST." <9412150938.ZM2919@sundance.itd.nrl.navy.mil> Date: Thu, 15 Dec 94 18:10:02 -0500 From: Carl Muckenhirn In message <9412150938.ZM2919@sundance.itd.nrl.navy.mil> you wrote: > On Dec 15, 8:56, solo@BBN.COM wrote: > > % The problem I have with this scenario and with Perry's example is > % understanding what services/advantages you are getting by > % having multiple security associations between the hosts at the > % IP layer. In both cases, you are saying that you will rely on > % the transport and application layers to accurately convey uid/SAID > % information to be used by the IPSP layer. If you trust those > % protocol layers, why not have a single "secure pipe" (based on > % host oriented keying material) between the system and rely > % on the applications to perform user I&A (a conclusion I agree > % with). If you don't trust thos layers, then per-user security > % associations at the IP layer aren't useful. > > I am glad we agree that application I&A is outside the scope of this > effort. I disagree that per-userid-keying is not useful. > > One widely used example is the problem of mutually suspicious users > (Alice, Bob) on some host X where none of those users has special > privileges (in UNIX terms, none of them are root). In such a case > when per-userid-keying is not provided, then user Alice can create > arbitrary plaintext/ciphertext pairs between its host and another host > Y in order to assist in Alice's cryptanalysis to determine what data > Bob is sending to someone on host Y that Bob does not want Alice to > know about. > One has to ask, how is Alice creating this dictionary, she has no "special privileges" so how is she gathering the ciphertext to match her chosen plaintext? (another machine on the net, okay) How is she distinguishing between her encrypted IP datagrams and Bob's? Is it the SAID, if so why give an attacker this hint, if you only do host based ID's all IPSPgrams look the same. If we are talking about a vanilla system (i.e., SunOS 4.x) there are much easier hacks to get access to Bob's stuff than resorting to cryptanalytic attacks. This also raises some questions about cryptographic security. If we assume that the users don't get access to the actual key, Alice is attempting to perform a chosen plaintext attack through which the key is recovered. What algorithms are in use, CBC DES is not vulnerable (we are lead to believe) to such an attack so use of CBC DES (or CBC IDEA for that matter) reduces Alice's problem to one of cracking DES, which if she can do it doesn't matter if she uses chosen plaintext or not and the per-userid keying doesn't help. But per userid keying does allow her to perform some level of traffic analysis on Bob's traffic with someone on host Y. At the IETF Phil Karn expressed the opinion that traffic analysis should be a concern. If we use IPSP to provide per-userid keying (which must be in cleartext and available to the receiving IPSP) user profiles can be developed simply by watching the SAIDs. If per-host key is used, all one gets is the aggregate between hosts (which may still present a problem for the truly paranoid). > I consider every version of UNIX I've used or closely examined to be > low-assurance. The prototyping work we're currently engaged in here > is similarly low-assurance since the original code was low-assurance > That does not make per-userid-keying useless even for the low > assurance implementations. Contrariwise it means that the separation > between users that is provided by the network has similar assurance > characteristics to the separation between users provided by the > operating system. > It is not economically sensible to have > significantly different assurance for the network separation than for > the computer separation because a chain is only as strong as its > weakest link. I agree completely with this statement. With per-user(id) keying you are attempting to provide a high-assurance (cryptographic) separation between user when their data is on the network but are more than willing (you have no choice) to live with low-assurance when the data is in the computer. Dave's point earlier was just this, protect the information between hosts as best you can, but let the host worry about separating users (it is the only thing that can) if you want good assurance, buy a high assurance O/S. carl. From ipsec-request@ans.net Thu Dec 15 23:31:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38444 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 18:39:53 -0500 Received: by interlock.ans.net id AA19727 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 18:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 18:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 18:30:25 -0500 Date: Thu, 15 Dec 1994 15:31:46 -0800 From: Phil Karn Message-Id: <199412152331.PAA00542@servo.qualcomm.com> To: amir@watson.ibm.com Cc: meadows@itd.nrl.navy.mil, ipsec@ans.net, cschow@watson.ibm.com In-Reply-To: <9412141708.AA32726@gimili.watson.ibm.com> (amir@watson.ibm.com) Subject: Re: randomness & perfect forward (or proactive?) secrecy >Phil, is your stuff public-domain? In this case we'll like to merge the >two systems as they appear to be exactly complementary. Or, maybe you can make >some parts public? I intend to place my Photuris stuff completely in the public domain once I'm done with it. I haven't released any code yet mainly because it's still a quick hack that's not done. Phil From ipsec-request@ans.net Fri Dec 16 00:19:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38430 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 19:39:14 -0500 Received: by interlock.ans.net id AA46968 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 19:20:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 15 Dec 1994 19:20:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 15 Dec 1994 19:20:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 19:20:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 19:20:27 -0500 Date: Thu, 15 Dec 1994 16:19:05 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9412160019.AA05219@miraj.> To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From daemon@ns Thu Dec 15 12:09 PST 1994 > No - it is limited to the number of machines which _may_ use this access > point. This number can be prohibitively large. Furthermore, it is > impractical to require that all these machines are predefined to the > firewall, due to administrative reasons (when a new employee joins in we > can't update all firewalls of the company, much less of all partners). > > > So, I disagree with your contention that the Kijs become unbounded > > for the firewall scenario. > > > I don't see your justification. Please address the context I've > elaborated on above. I already have. What I was and am trying to say is that *in case* explicit ACLs exist, these can help in precomputing master keys (and many circumstances *will* have explicit ACLs). In cases where this is not feasible, usage patterns and/or administrative action can facilitate this. The *worst* that can happen is that, only in case of wildcard ACLs, *unusual* access patterns *may* be denied service during a clogging attack. This isn't all that bad, especially since someone who desperately seeks service and is being denied, can be asked to put on the priority list and regain access, even if the clogging attack continues. (Note that administrators would always be on the priority list, and would always be able to take such action in a secure manner, even remotely). Can the same be said of the master key update protocol in your MKMP document? (I am still waiting for your response on this issue and the other issue on saving sender resources.) This resistance to denial-of-service attacks in SKIP doesn't require special protocol messages especially designed for this purpose, or even messages. It just comes naturally. (And this is because SKIP is operationally a shared-key scheme, and uses a zero-message public-key operation just for the bootstrap.) Ashar. From ipsec-request@ans.net Fri Dec 16 04:01:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16377 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 23:08:36 -0500 Received: by interlock.ans.net id AA28500 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 15 Dec 1994 23:00:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 15 Dec 1994 23:00:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 23:00:43 -0500 Date: Thu, 15 Dec 1994 20:01:37 -0800 From: Phil Karn Message-Id: <199412160401.UAA00836@servo.qualcomm.com> To: carrel@cisco.com Cc: housley@spyrus.com, ipsec@ans.net In-Reply-To: <199412142131.NAA01395@large.cisco.com> (message from David Carrel on Wed, 14 Dec 1994 13:31:38 -0800) Subject: Re: key management >you're right that for many situations a "user" certificate is what's >appropriate. But for some situations an IP address or host-name >certificate is more appropriate. There is nothing that precludes us from >using both. Let's not limit ourselves to using only one. Absolutely not. I've left the "ownership" of a certificate completely arbitrary. That certainly seems to cover all the bases. More specifically, for expediency and also because I like it, I'm using the existing PGP public key infrastructure. The convention there is that keys are owned by people who identify themselves with email addresses, but absolutely nothing in PGP enforces this -- user IDs can be arbitrary text strings with any meaning you choose to give them. Phil From ipsec-request@ans.net Fri Dec 16 09:24:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18519 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 09:24:46 -0500 Received: by interlock.ans.net id AA23870 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 09:20:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 09:20:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 09:20:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 09:20:55 -0500 Date: Fri, 16 Dec 94 06:01:38 From: "Housley, Russ" Encoding: 5443 Text Message-Id: <9411167875.AA787586498@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Re[2]: key management Perry: > > You prove my point. You say: > > > > > ..., it doesn't, although it does require that the transport layer > > > have the ability to tell the network layer which SAID to use. > > > > This means that EVERY transport layer implementation must be modified to use > > IPSP with the key management you propose. > > Yes. It has to be modified. So what? The modifications are very > small and hardly onerous. If you want to use different SAIDs with > different sockets, which is without any real doubt a requirement, > the layer handling the sockets has to know how to specify an SAID. > > Paraphrasing from "The Elements of Networking Style", layering is > supposed to be a tool, not a straight-jacket. I am not trying to put a straight-jacket on anyone or on any design. Rather, I am trying to preserve some layer independence. Layer independence has allowed many experiments to proceed on the Internet because they could take advantage of the services provided by existing protocol layers. If one layer must provide parameters that it would not otherwise care about, then the layers are not indpenedent. In your case, the transport layer (be it TCP, UDP, TP0/RFC1006/TCP, or any other) must pass a SAID to the IPSP layer. From other messages, I get the feeling that the application layer is passing the SAID to the transport, although you have not stated this explicitly. This means that the transport doesn't care about the SAID, and this leads me to believe that the security service that you want is being applied at an in appropriate place. I simply restate my opinion: user-keyed security services should be applied in a layer that is easily mapped to the user. And, that is not the network layer. > > The whole reason for placing the security protocol in the IP layer > > is lost if we have to modify the consumers of IP services to be IPSP > > and IKMP aware. > > That is not the case. Part of the purpose as I perceived it was to > make sure that every application didn't have to implement a new > protocol or implement the same one over and over again. Part of the > purpose was to help provide immunity to traffic analysis. Part of it > was to provide the ability to build secure tunnels between insecure > networks. Part of it was so that (being Unix-centric for a moment -- > other OSes have analogs) an ordinary "write" system call would end > up doing the "right thing" without having to have the application > deal with the encryption and authentication. Part of it was indeed > so that existing *applications* could get some authentication added > without needing to do any work. However, I don't recall anyone ever > saying that we should cripple the functionality so that we wouldn't > have to add a few dozen lines of code to the TCP and UDP > implementations. Those are, by the way, what you mean when you say > "transports". Gee, I do not remeber you at the meetings where the IPSEC charter was drafted. We did the first draft at the Washington, DC IETF meeting. I'm glad that you find the IP security service so useful, but I can guarentee you that traffic analysis was not one of our reasons. In fact, the network layer is too high in the protocol stack if you are really concerned about traffic analysis. > > My understanding was that the IP layer was selected so that the security > > could be slipped into the protocol stack with alot of transparency. > > Yes, thats true. Very small changes need to be made to take advantage > of the work being done at the network layer, which is indeed where the > bulk of the protocol work is. The protocol only needs to be specified > at the network layer, too, since the operation of selecting a particular > SAID for a particular socket is an OS dependent operation. That doesn't > mean you don't want to be able to do it, however. I agree with almost everything you say in the paragraph. However, you must be careful that to implemntations with different ideas of key granularity do not cause each other problems. For example, suppose an IPSP implementation that uses one key for the tranmission of all data between two hosts trying to communicate with another IPSP implementation that uses a different key for each TCP connection. If they only have one open TCP connection, everything works. Then, when a second (differently keyed) TCP connection is established, the first host may throw away the first key. After all, only one key is needed and the "newer" one was kept. The elements of procedure associated with the security association management are very important to interoperability. Different models can lead to big failures. > > I think that IPSP has many advantages, but in my opinion, it should not > > be used (or abused) to provide application-to-application security. > > If all we wanted to do was to provide the ability to produce secure > tunnels between insecure networks, we would need no key management at > all -- just use sneaker-net or use PEM or PGP to mail new keys. If > you want to do anything interesting in security, you have to be able > to build secure applications -- like secure file systems or remote > login programs. Without that, none of this is interesting. I could not disagree more. Automated key management is needed for any widely deployed security protocol. Russ From ipsec-request@ans.net Fri Dec 16 15:16:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16203 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 10:20:22 -0500 Received: by interlock.ans.net id AA22840 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 10:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 16 Dec 1994 10:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 10:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 10:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 10:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 10:16:16 -0500 Message-Id: <9412161516.AA41873@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: uri@watson.ibm.com, ipsec@ans.net Subject: Proposal: user-keys are implementation decision In-Reply-To: Your message of "Thu, 15 Dec 1994 16:30:26 EST." <9412152130.AA18270@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Dec 1994 10:16:10 -0500 From: " " Uri says: > Hilarie Orman says: > > The motivation for per-user keying based on chosen plaintext seems > > unconvincing to me. The amount of data sent per key can be controlled > > by the OS, and adjusted to a conservative value based on the algorithm > > in use. Wouldn't it be cheaper and safer to rekey host-host > > connections than to negotiate and rekey many user/host keys? > > Oh yes! Not only cheaper, but *simpler*! And I think, KISS ideology > saved more than one life (:-). Although I see the value of per-user keys, in particular in defeating choosen plain/ciphertext attacks, I agree with Uri and Hilarie. In fact I think IKMP and IPSP already include an unstructured SAID mechanism which should allow implementations which wish to provide seperate keys for each user to do so. So, why don't we concentrate on designing the protocols, and leave these issues along, at least for now. Best, Amir From ipsec-request@ans.net Fri Dec 16 15:39:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38165 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 10:44:50 -0500 Received: by interlock.ans.net id AA40418 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 10:41:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 10:41:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 10:41:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 10:41:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 10:41:41 -0500 Message-Id: <9412161539.AA02297@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: key management In-Reply-To: Your message of "Fri, 16 Dec 1994 06:01:38." <9411167875.AA787586498@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 16 Dec 1994 10:39:03 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > I am not trying to put a straight-jacket on anyone or on any design. > Rather, I am trying to preserve some layer independence. Layer > independence has allowed many experiments to proceed on the Internet > because they could take advantage of the services provided by existing > protocol layers. There is so little layer independence in, for example, the BSD networking code (perhaps the most widely deployed implementation) that I see little reason to try to preserve an illusion of something that was never there. This is not to say that the code is badly structured -- it is well built. Layer violations are, however, required to deal with real-world networking. > If one layer must provide parameters that it would not otherwise care > about, then the layers are not indpenedent. You mean like the fact that the ip_output routine in the BSD kernel is written to allow per-socket caching of routing information? In the pristine, pure, layered universe that never was we weren't supposed to have the transport know about the existence of routing. How about the flags and options passed down from the transport? Guess we can't have those, either. Quoting Padlipsky, "Do you want protocols that look nice or protocols that work nice?" Actually, I the mechanism I've proposed looks nice, too. Its a remarkably clean mechanism. I've been playing with what it does to the applications and the kernel internals and it looks like it achieves my personal goals for simplicity combined with power. Perry From ipsec-request@ans.net Fri Dec 16 16:05:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16224 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 11:14:56 -0500 Received: by interlock.ans.net id AA21757 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 11:05:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 16 Dec 1994 11:05:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 11:05:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 11:05:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 11:05:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 11:05:15 -0500 Message-Id: <9412161605.AA43759@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Phil Karn , ipsec@ans.net, cschow@watson.ibm.com Subject: Re: randomness & perfect forward (or proactive?) secrecy In-Reply-To: Your message of "Thu, 15 Dec 1994 15:31:46 PST." <199412152331.PAA00542@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Dec 1994 11:05:08 -0500 From: " " Phil, > >Phil, is your stuff public-domain? In this case we'll like to merge the > >two systems as they appear to be exactly complementary. Or, maybe you can make > >some parts public? > > I intend to place my Photuris stuff completely in the public domain once > I'm done with it. I haven't released any code yet mainly because it's > still a quick hack that's not done. That's great! But, I ment the randomness samplying sw, not Photuris (or would it also be part of Photuris?). If that's going to be public, let me suggest we consider to merge it with the Network Randomization Protocol (NRP) which we have already put in public domain (software.watson.ibm.com/pub/security/nrp.tar). As to Photuris vs. MKMP and other key management proposals, I would like to work with others to converge; I like many things about Photuris, and if the WG is not too shy of the performance costs, I'll be happy to have all of its functionallity (for long term keys), together with the efficiency and security of MKMP (for short term keys). I'm also flexible on supporting also a non-interactive SKIPish mode. There are some technical tradeoffs and alternatives which we should discuss together and decide on (in particular as Ashar have noted I see some advantages to authenticating the DH by another DH key rather than RSA - but again I'll like to discuss the tradeoffs which do exist). Best, Amir From ipsec-request@ans.net Fri Dec 16 12:07:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16678 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 12:07:13 -0500 Received: by interlock.ans.net id AA45250 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 12:02:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 12:02:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 12:02:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 12:02:28 -0500 Date: Fri, 16 Dec 94 08:44:10 From: "Housley, Russ" Encoding: 533 Text Message-Id: <9411167875.AA787596250@spysouth.spyrus.com> Cc: ipsec@ans.net Subject: Re: Human I&A, IPsec, and their non-relationship Hilarie Orman says: > The motivation for per-user keying based on chosen plaintext seems > unconvincing to me. The amount of data sent per key can be controlled > by the OS, and adjusted to a conservative value based on the algorithm > in use. Wouldn't it be cheaper and safer to rekey host-host > connections than to negotiate and rekey many user/host keys? Completely agree. Further, I think that selection of the security association should be based on information that is normally used in the IP layer. Russ From ipsec-request@ans.net Fri Dec 16 12:07:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29479 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 12:07:13 -0500 Received: by interlock.ans.net id AA36041 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 12:02:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 12:02:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 12:02:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 12:02:33 -0500 Date: Fri, 16 Dec 94 08:43:57 From: "Housley, Russ" Encoding: 244 Text Message-Id: <9411167875.AA787596237@spysouth.spyrus.com> To: atkinson@itd.nrl.navy.mil, "Theodore Ts'o" Cc: ipsec@ans.net Subject: Re[2]: Human I&A, IPsec, and their non-relationship > So --- are we all in agreement with Ran that IPSEC is *not* trying to > solve the human-computer authentication problem? I agree. IPSEC is not trying to solve the human-to-computer identification and authentication problem. Russ From ipsec-request@ans.net Fri Dec 16 17:43:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17265 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 12:47:14 -0500 Received: by interlock.ans.net id AA27225 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 12:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 12:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 12:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 12:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 12:43:50 -0500 Message-Id: <9412161743.AA02654@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of "Fri, 16 Dec 1994 08:43:57." <9411167875.AA787596237@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 16 Dec 1994 12:43:06 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > > So --- are we all in agreement with Ran that IPSEC is *not* trying to > > solve the human-computer authentication problem? > > I agree. IPSEC is not trying to solve the human-to-computer > identification and authentication problem. The fact that we are not trying to solve it, however, does not mean we should impede its being solved. I think it is actually a requirement that any solution *not* impede authentication systems being built on top of our protocols. .pm From ipsec-request@ans.net Fri Dec 16 07:53:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20454 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 13:00:47 -0500 Received: by interlock.ans.net id AA27862 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 12:53:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 12:53:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 12:53:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 12:53:32 -0500 Date: Fri, 16 Dec 1994 12:53:05 +0500 From: Theodore Ts'o Message-Id: <9412161753.AA08811@dcl.MIT.EDU> To: ipsec@ans.net Subject: News item from Edupage... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 774 For those of you who don't follow Edupage, you might find this interesting.... our actions are indeed being watched! - Ted NEXT STEPS FOR INTERNET SECURITY The Internet Security Protocol group has succeeded in defining the security services of the IP security protocol, including data confidentiality, data integrity, authentication and access control. It's now working to combine the requirements for highly compressed encoding, which conserves bandwidth, with the requirement for a fixed, easy-to-parse format, which is essential to high-speed processing. Future tasks include developing companion key technology as an application-layer protocol, and establishing requirements for the encapsulation and key management protocols. (Telecommunications Dec.'94 p.55) From ipsec-request@ans.net Fri Dec 16 18:48:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16848 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 13:53:54 -0500 Received: by interlock.ans.net id AA30927 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 13:46:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 13:46:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 13:46:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 13:46:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 13:46:44 -0500 From: Charlie Watt Sender: Charlie Watt Message-Id: <9412161848.AA02617@mordred.sware.com> Subject: Re: Re[2]: Human I&A, IPsec, and their non-relationship To: perry@imsi.com Date: Fri, 16 Dec 1994 13:48:49 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9412161743.AA02654@snark.imsi.com> from "Perry E. Metzger" at Dec 16, 94 12:43:06 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1461 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, CcjMnRnpJZiNm94mqk/HbPmddcp6rOgKIgVTQwQEgtTVn5EzezRh6fU8LEb5LCJh dYby+g5iZ12BUYpEHsbxER0= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > > > "Housley, Russ" says: > > > So --- are we all in agreement with Ran that IPSEC is *not* trying to > > > solve the human-computer authentication problem? > > > > I agree. IPSEC is not trying to solve the human-to-computer > > identification and authentication problem. > > The fact that we are not trying to solve it, however, does not mean we > should impede its being solved. I think it is actually a requirement > that any solution *not* impede authentication systems being built on > top of our protocols. > > .pm Perry, I may finally understand. Is this an accurate summary: The network layer security protocol adopted by IPSEC should provide host-to-host security services, including peer-host authentication. It may be beneficial to allow multiple security associations between a given pair of hosts. If so, no specific connotation is implied for the different associations -- such meaning might be determined by the individual NLSP service consumers, or by a specific implementation of the NLSP. To provide its services, the NLSP requires the use of a key management service. As there will be other IETF protocols and services requiring key management, and as it is desirable to minimize the number of overlapping protocols, the key management protocol developed for use by the NLSP should support (or at least not preclude) use with these other services, such as user authentication. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Fri Dec 16 19:49:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38831 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 14:54:06 -0500 Received: by interlock.ans.net id AA10605 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 14:49:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 14:49:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 14:49:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 14:49:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 14:49:39 -0500 Message-Id: <9412161949.AA02980@snark.imsi.com> To: Charlie Watt Cc: ipsec@ans.net Subject: Re: Re[2]: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of "Fri, 16 Dec 1994 13:48:49 EST." <9412161848.AA02617@mordred.sware.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 16 Dec 1994 14:49:19 -0500 From: "Perry E. Metzger" Charlie Watt says: > Perry, > > I may finally understand. Is this an accurate summary: > > The network layer security protocol adopted by IPSEC should provide > host-to-host security services, including peer-host authentication. Yes, so far as it goes. > It may be beneficial to allow multiple security associations between > a given pair of hosts. Here, I'd say that we MUST allow multiple security associations between a given pair of hosts. Ignoring all other questions, simply having different levels of security/performance tradeoffs for different communications requires it. > If so, no specific connotation is implied > for the different associations -- such meaning might be determined by > the individual NLSP service consumers, or by a specific implementation > of the NLSP. Correct from the point of view of the NLSP documents -- that is, the NLSP must provide multiple associatiosn, and mustn't try to figure out what they mean, as it isn't the business of the network layer. However, in order to be able to manage these multiple associations, it is going to be necessary to allow transports and applications above them to pick which association is used for which socket. For instance, say that you want (for whatever reason) all your SMTP traffic authenticated with MD5 and all of your telnet traffic encrypted with RC4. Unless the transports can tell the network layer "oh, by the way, please use SAID #567945 with this packet I'm about to hand you" there is no way to accomplish this. Given the facility to have applications tell the transport to use a particular SAID and to have the transport pass that information through to the network layer, however, it becomes possible to do this sort of per socket association. I'd say that being able to do that sort of thing is a requirement OF THE FINISHED IPSEC SYSTEM, but not of the network layer security protocol PER SE. The NLSP qua NLSP just has to be able to support multiple associations. I'll point out, by the way, that if you don't support multiple associations between a pair of nodes you don't need SAIDs and can get along perfectly well without them -- at that point you simply know from negotiation what the one and only security transform and key in use between a host pair are and there is nothing more to say on the matter. The whole point of SAIDs was to make multiple associations between hosts possible. > To provide its services, the NLSP requires the use of a key management > service. Yes... > As there will be other IETF protocols and services > requiring key management, and as it is desirable to minimize the > number of overlapping protocols, the key management protocol developed > for use by the NLSP should support (or at least not preclude) use with > these other services, such as user authentication. Correct as far as it goes. One of my other points, however, is that given a facility that makes it possible to set SAIDs on a per socket basis one can then take one more step. If an SAID is associated with a particular user/userlike entity pair as a result of a key negotiation, then one can let applications draw inferences about what the identity of a remote entity initiating communications is without having to involve the applications in key negotiation at all. That is to say, one can have, say, an rlogin daemon note that the socket that just was established was labeled with SAID #76583, and that SAID #76583 was established (according to information stashed by some layer above the key negotation layer) by the key association with the principal name "joe@foo.com". It can then infer that the remote entity is the entity that has the private key associated with "joe@foo.com" and check an access control list to decide whether to automatically log in "joe@foo.com" as the user "jsmith", as requested by the remote rlogin client. In short, one can build very nice tools given the ability to have per-socket settable SAIDs, and given the ability to draw certain inferences about remote entities based on identifiers attached to keys used by the key negotiation/management layer. These tools have many of the properties of Kerberos like systems and allow us to build secure applications. Any specification that would impede constructing things this way is, IMHO, a bad idea, although I would certainly not mandate having the transport layer know anything about users or even what SAIDs are used with beyond the fact that it can be asked to request that the IP layer use a particular one. None of this places any requirement on the NLSP beyond being able to handle multiple associations between a host pair that are semantically undefined at the NLSP layer. None of this places any requirement on the key management layer beyond being able to handle establishment of multiple associations between hosts using keys that some entity on the hosts possesses. Perry From ipsec-request@ans.net Fri Dec 16 14:57:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37836 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 14:57:26 -0500 Received: by interlock.ans.net id AA21681 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 14:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 14:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 14:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 14:54:46 -0500 Date: Fri, 16 Dec 94 11:43:00 From: "Housley, Russ" Encoding: 607 Text Message-Id: <9411167876.AA787606980@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: key management Perry: > Quoting Padlipsky, "Do you want protocols that look nice or protocols > that work nice?" As always, Mike has a unique way of putting things. Anyway, I realize that efficient protocol implemntations often smush the layers. However, it must be done in such a way that interoperability is not impacted. The examples that you describe in your message provide increased effieiency without any impact on the syntax or semantics of the remote end. However, the use you describe of the SAID might impact the distant implemntation. I think I have already given one example. Russ From ipsec-request@ans.net Fri Dec 16 20:01:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31058 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 15:09:06 -0500 Received: by interlock.ans.net id AA26344 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 15:02:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 15:02:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 15:02:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 15:02:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 15:02:16 -0500 Message-Id: <9412162001.AA03012@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[4]: key management In-Reply-To: Your message of "Fri, 16 Dec 1994 11:43:00." <9411167876.AA787606980@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 16 Dec 1994 15:01:38 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > However, the use you describe of the SAID might impact the > distant implemntation. I think I have already given one example. I agree that handling per-socket SAIDs will indeed require that both the local and the remote host have their transport implementations understand how to perform these actions. The changes to the transport, however, seem small -- they end up being a truly tiny amount of code. Given that for a small change one can gain pretty big wins, I think its a worthwhile feature to layer on top of IPSP. Even ignoring user issues, it is very natural to want different kinds of traffic to get different kinds of encryption applied, and this is the only reasonable way that I can think of to achieve that. Perry From ipsec-request@ans.net Fri Dec 16 21:14:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38664 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 16:18:32 -0500 Received: by interlock.ans.net id AA41294 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 16:14:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 16:14:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 16:14:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 16:14:24 -0500 Date: Fri, 16 Dec 1994 14:14:14 -0700 From: Hilarie Orman Message-Id: <199412162114.OAA09861@umbra.CS.Arizona.EDU> To: ipsec@ans.net Subject: ipv4 broadcast There's been no discussion of handling ipv4 broadcast. I seek enlightenment from the collective consciousness. From ipsec-request@ans.net Fri Dec 16 23:27:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38466 (5.65c/IDA-1.4.4 for ); Fri, 16 Dec 1994 19:34:28 -0500 Received: by interlock.ans.net id AA23829 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 16 Dec 1994 19:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 16 Dec 1994 19:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 16 Dec 1994 19:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 16 Dec 1994 19:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 16 Dec 1994 19:29:51 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 16 Dec 1994 19:29:51 -0500 Date: 16 Dec 94 17:27:00 -0600 To: ipsec@ans.net Subject: Re: ipv4 broadcast Message-Id: I offer no enlightenment or opinions (yet ...). Only a appeal that anyone wanting to comment on the use of IPSP to protect IPv4 Broadcast please attempt to format their thoughts into paragraphs that might be included into our specification (to be posted late next week): Section XX.X IPv4 Broadcast If the comments include suggestions for SAID usage or reserved SAIDs please include another paragraph for inclusion in: Section XX.W Security Association Identifier (SAID) Regards, Paul _______________________________________________________________________________ Subject: ipv4 broadcast Author: ho@cs.arizona.edu@INTERNET Date: 12/16/94 3:14 PM There's been no discussion of handling ipv4 broadcast. I seek enlightenment from the collective consciousness. From ipsec-request@ans.net Sat Dec 17 07:24:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18631 (5.65c/IDA-1.4.4 for ); Sat, 17 Dec 1994 12:31:56 -0500 Received: by interlock.ans.net id AA25641 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 17 Dec 1994 12:28:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 17 Dec 1994 12:28:45 -0500 Message-Id: <199412171728.AA40229@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 17 Dec 1994 12:28:45 -0500 Date: Sat, 17 Dec 94 12:24:08 EST From: hugo@watson.ibm.com To: ashar@miraj.eng.sun.com, Ashar.Aziz@eng.sun.com Cc: ipsec@ans.net, yacov@faline.bellcore.com Subject: Ephemeral RSA Ref: Your note of Thu, 15 Dec 94 14:53:46 PST (attached) Ashar, >>From hugo@watson.ibm.com Wed Dec 14 19:18:44 1994 >>Just for the amusement: if you count ONLY real-time >>operations, then using ephemeral RSA keys is significantly >>more efficent than DH. > >:-) Well, this is amusing. Are you proposing we do this, or was this >just an FYA? To prove that it was just for fun I am answering this on Saturday... Besides, it is a good exercise on how one can abuse the arguments of disregarding off-line operations and extrapolation of computing power growth. Hugo From ipsec-request@ans.net Mon Dec 19 01:54:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16869 (5.65c/IDA-1.4.4 for ); Sun, 18 Dec 1994 20:58:27 -0500 Received: by interlock.ans.net id AA10310 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 18 Dec 1994 20:53:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 18 Dec 1994 20:53:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 18 Dec 1994 20:53:59 -0500 Date: Sun, 18 Dec 1994 17:54:09 -0800 From: Phil Karn Message-Id: <199412190154.RAA01254@unix.ka9q.ampr.org> To: ho@cs.arizona.edu Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <199412152105.OAA06892@umbra.CS.Arizona.EDU> (message from Hilarie Orman on Thu, 15 Dec 1994 14:05:03 -0700) Subject: Re: Human I&A, IPsec, and their non-relationship Back in Toronto we had some pretty heavy off-line debates over per-user vs per-host keying. I basically took your position: a single key per host pair was enough, and we didn't need a big SAID. Several others, notably Ran Atkinson and Steve Bellovin, argued strongly for at least supporting the facility. I think I also heard the chosen-plaintext argument (at least it doesn't sound new) and it didn't convince me either. Any cipher that can't resist a chosen plaintext attack is certainly not one to use in this day and age. A somewhat better argument is that not all traffic between a pair of hosts is equally sensitive. One could respond that you just pick a cipher that's strong enough for the most sensitive traffic and then use it for everything, but this might be considered prohibitive on slower machines. But the argument that finally persuaded me to concede was the possibility of one user decrypting the traffic of another user on the same host by playing it back with the SAID changed. It does seem that you could prevent this with some sort of user ID buried inside the packet, as long as it's protected against modification. The closest we come to user IDs are the TCP and UDP port numbers, but it's obvious that this isn't a particularly strong mechanism on, say, BSD. I just wait for my victim to finish with his socket. Then I bind to it, play back the traffic (easier with UDP than TCP) and have the kernel decrypt it for me. So some sort of "real" IPSP user ID would be needed. Essentially, it would be a protected SAID. Although there are some advantages to this (e.g., preventing traffic analysis at per-user granularity) it would still have to be in addition to the existing clear SAID mechanism which is needed to handle host-to-host keying issues (e.g., multiple levels of security vs performance). And then you'd have to show that there is no way for one OS user to read another's traffic even though they share the same keys. It does seem on the surface that simply giving each user his own session key is the most effective way to enforce user-user separation, as well as adapting to different security/performance tradeoffs. Phil From ipsec-request@ans.net Mon Dec 19 02:07:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15967 (5.65c/IDA-1.4.4 for ); Sun, 18 Dec 1994 21:14:12 -0500 Received: by interlock.ans.net id AA10255 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 18 Dec 1994 21:06:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 18 Dec 1994 21:06:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 18 Dec 1994 21:06:46 -0500 Date: Sun, 18 Dec 1994 18:07:00 -0800 From: Phil Karn Message-Id: <199412190207.SAA01264@unix.ka9q.ampr.org> To: uri@watson.ibm.com Cc: ho@cs.arizona.edu, atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <9412152130.AA18270@buoy.watson.ibm.com> (uri@watson.ibm.com) Subject: Re: Human I&A, IPsec, and their non-relationship Reply-To: karn@qualcomm.com >> The motivation for per-user keying based on chosen plaintext seems >> unconvincing to me. The amount of data sent per key can be controlled >> by the OS, and adjusted to a conservative value based on the algorithm >> in use. Wouldn't it be cheaper and safer to rekey host-host >> connections than to negotiate and rekey many user/host keys? >Oh yes! Not only cheaper, but *simpler*! And I think, KISS ideology >saved more than one life (:-). Well, nothing says you have to do DH for each user. Inspired by Jeff Schiller's comments about 802.10, in Photuris I will use DH to establish some shared secret material between the hosts and then hash that to generate distinct session keys for each SAID. The session key will probably be generated along the lines of key = MD5(DH shared secret, cookie1, cookie2, SAID) where cookie1 and cookie2 are the Photuris cookies in sort order. This clearly makes session key establishment cheap enough to permit frequent session rekeying. E.g., each SAID could be given an administrative lifetime in seconds and/or packets, after which a new one is created with a new key, the old one is destroyed, and traffic rerouted to use the new SAID. The new SAID's key would use the current DH shared secret. This itself may be periodically regenerated by placing a maximum lifetime on a particular DH public/private part, or if perfect forward secrecy is not desired it may be static. Phil From ipsec-request@ans.net Mon Dec 19 06:03:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37647 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 01:18:09 -0500 Received: by interlock.ans.net id AA25841 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 01:03:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 01:03:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 01:03:18 -0500 Date: Sun, 18 Dec 1994 22:03:30 -0800 From: Phil Karn Message-Id: <199412190603.WAA01434@unix.ka9q.ampr.org> To: amir@watson.ibm.com Cc: ipsec@ans.net, cschow@watson.ibm.com Reply-To: karn@qualcomm.com In-Reply-To: <9412161605.AA43759@gimili.watson.ibm.com> (amir@watson.ibm.com) Subject: Re: randomness & perfect forward (or proactive?) secrecy >But, I ment the randomness samplying sw, not Photuris (or would it also be >part of Photuris?). Oh, sorry. As pointed out in the excellent Schiller/Eastlake/Crocker RFC, randomness sampling is inherently machine dependent. So it's a separate module in addition to my Photuris code. I'm working in a 486-type PC environment so it would probably have to be redone for other machines. But I'm willing to make my code available with those caveats once I'm happy with it. Re merging Photuris: as I said during my talk to the WG, I was particularly interested in stimulating a discussion about the merits of the design philosophy. And I certainly seem to have succeeded in that! (I do hope it will eventually produce some sort of consensus, though...) I still believe that a single protocol like Photuris, with the proper tuning knobs, can satisfy both the needs of those with strong security requirements and those with performance concerns. I haven't seen much discussion of this particular aspect; am I off base here? Phil From ipsec-request@ans.net Mon Dec 19 10:48:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37700 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 06:00:17 -0500 Received: by interlock.ans.net id AA31652 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 05:47:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 05:47:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 05:47:23 -0500 Date: Mon, 19 Dec 1994 02:48:13 -0800 From: Phil Karn Message-Id: <199412191048.CAA01748@unix.ka9q.ampr.org> To: ipsec@ans.net Subject: Size of IV field in DES-CBC mode Reply-To: karn@qualcomm.com I almost hate to bring this up since we seemed to have such a consensus at the first San Jose meeting, but... Do we really need a full 8 bytes for the IV field in the baseline DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 bytes are mapped properly into the actual 8-byte DES IV field they should do an acceptable job of ensuring that every packet ciphertext is completely different even when the corresponding plaintext begins with constant values (e.g., TCP or UDP port numbers). Comments? Phil From ipsec-request@ans.net Mon Dec 19 12:21:58 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20551 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 07:34:30 -0500 Received: by interlock.ans.net id AA19782 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 07:23:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 07:23:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 07:23:03 -0500 Message-Id: <9412191222.AA21960@columbia.sparta.com> To: karn@qualcomm.com Cc: ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Size of IV field in DES-CBC mode In-Reply-To: Your message of "Mon, 19 Dec 94 02:48:13 PST." <199412191048.CAA01748@unix.ka9q.ampr.org> Date: Mon, 19 Dec 94 07:21:58 -0500 From: Carl Muckenhirn In message <199412191048.CAA01748@unix.ka9q.ampr.org> you wrote: > I almost hate to bring this up since we seemed to have such a > consensus at the first San Jose meeting, but... > > Do we really need a full 8 bytes for the IV field in the baseline > DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of > the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 > bytes are mapped properly into the actual 8-byte DES IV field they > should do an acceptable job of ensuring that every packet ciphertext > is completely different even when the corresponding plaintext begins > with constant values (e.g., TCP or UDP port numbers). > > Comments? > > Phil > > I agree that 4 bytes should be more than enough (4G datagrams). Also, in the multicast case (not much of a concern so far) you simply concatenate the sending IPaddr and the transmitted IV for your 8 byte DES IV. Now we don't have to worry about IV clashes among the multicast participants. This approach should also work for unicast IP. There no need for "mapping" between the 4 byte IV and the full IV (cryptographically, there is not a problem (for CBC) with simply left or right padding the IV). carl. From ipsec-request@ans.net Sun Dec 18 22:35:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37792 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 07:47:07 -0500 Received: by interlock.ans.net id AA34721 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 07:35:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 07:35:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 07:35:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 07:35:45 -0500 Date: Mon, 19 Dec 94 05:35:34 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9412191235.AA02934@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: karn@qualcomm.com Subject: Re: Size of IV field in DES-CBC mode Cc: ipsec@ans.net 4 bytes will do, but for CBC mode, some sort of expansion (e.g. CRC-32) to 64 bits would be nice just to make sure. -- -Colin From ipsec-request@ans.net Mon Dec 19 15:02:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25480 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 09:42:11 -0500 Received: by interlock.ans.net id AA09955 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 09:34:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 09:34:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 09:34:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 09:34:52 -0500 Date: Mon, 19 Dec 94 17:02:20 +0200 From: kate@digiw.fi (Kate Marika Alhola) Message-Id: <9412191502.AA27532@digiw.fi> To: ipsec@ans.net Subject: Few SwiPe questions I have read Swipe documents "The swIPe IP Security Protocol INTERNET DRAFT John Ioannidis" and "The Architecture and Implementation of Network-Layer Security Under Unix by John Ioannidis and Matt Blaze". I have my own embedded router implementation, that is designed to implement both Swipe and Tunneling. Then few simple questions. The "Arhhitecture ..." document says, that Swipe uses IP protocol 94, that is defined IP over IP tunneling protocol, and this number is reserved for it in RFC, but i can't find any more document about it. I have not found any RFC about it, nor even any references to any other ftp/www accessible documents about it. Is there really any documents existing about it ? Is it same, that Cisco NOS encapsulated tunneling protocol, that is also non documented ? I know, that may be diferent than IPIP, but i just like to see, are there implementation similarities, that io can use with both of them, and could i use ID field making diference between encrypted Swipe and clear-text proto 94 packets. Then, in same document, there is DF (Dont Fragment) bit emphasized with bold font (Figure 2). Does it menan something, does Swipe define, that encrypted datagrams should not fragmentted and both ends should use MTU-discovery or other methods to avoid fragmenting. Kate Alhola From ipsec-request@ans.net Mon Dec 19 14:57:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14387 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 10:04:53 -0500 Received: by interlock.ans.net id AA23262 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 09:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 09:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 09:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 09:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 09:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 09:58:13 -0500 Message-Id: <9412191457.AA31912@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: karn@qualcomm.com Cc: uri@watson.ibm.com, ho@cs.arizona.edu, atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net Subject: Re: Human I&A, IPsec, and their non-relationship In-Reply-To: Your message of "Sun, 18 Dec 1994 18:07:00 PST." <199412190207.SAA01264@unix.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 09:57:51 -0500 From: " " Phil, you are right: the key is doing frequent, efficient updates of the `session keys'. Your suggestion below is essentially identical to what we proposed (in MKMP); you need to deal with the protocol to do this to avoid replay, loss of sync etc, which is exactly the MKMP protocol. > The session key will probably be generated along the lines of > > key = MD5(DH shared secret, cookie1, cookie2, SAID) > > where cookie1 and cookie2 are the Photuris cookies in sort order. > > This clearly makes session key establishment cheap enough to permit > frequent session rekeying. E.g., each SAID could be given an > administrative lifetime in seconds and/or packets, after which a new > one is created with a new key, the old one is destroyed, and traffic > rerouted to use the new SAID. I suggest we make sure that at least this component of deriving session keys from master keys is one and common across all implementations. Furthermore I agree with you that we can have a single protocol which is tunable to meet different security/efficiency tradeoffs... I'll like to have more technical discussion about this protocol to achieve all our goals. More on this later. Best, Amir From ipsec-request@ans.net Mon Dec 19 15:03:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18550 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 10:08:08 -0500 Received: by interlock.ans.net id AA12594 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 10:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 10:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 10:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 10:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 10:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 10:03:32 -0500 Message-Id: <9412191503.AA20665@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: karn@qualcomm.com Cc: amir@watson.ibm.com, ipsec@ans.net, cschow@watson.ibm.com Subject: Re: randomness & perfect forward (or proactive?) secrecy In-Reply-To: Your message of "Sun, 18 Dec 1994 22:03:30 PST." <199412190603.WAA01434@unix.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 10:03:17 -0500 From: " " > >But, I ment the randomness samplying sw, not Photuris (or would it also be > >part of Photuris?). > > Oh, sorry. As pointed out in the excellent Schiller/Eastlake/Crocker > RFC, randomness sampling is inherently machine dependent. So it's a > separate module in addition to my Photuris code. I'm working in a > 486-type PC environment so it would probably have to be redone for > other machines. But I'm willing to make my code available with those caveats > once I'm happy with it. Great, please keep us posted. Of course I agree that this code (as well as NRP) are not a part of the key management protocol, they are just general tools for getting randomness. > > Re merging Photuris: as I said during my talk to the WG, I was > particularly interested in stimulating a discussion about the merits > of the design philosophy. And I certainly seem to have succeeded in that! > (I do hope it will eventually produce some sort of consensus, though...) Agree. > > I still believe that a single protocol like Photuris, with the proper > tuning knobs, can satisfy both the needs of those with strong security > requirements and those with performance concerns. I haven't seen much > discussion of this particular aspect; am I off base here? I agree with this too, although I believe we'll still have multiple protocols to support existing scenarios (e.g. enterprises already using Kerberos/DCE). But we don't need more than one public key protocol with the right knobs (maybe including one for non-interactivity as in SKIP). Best, Amir From ipsec-request@ans.net Mon Dec 19 15:48:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27315 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 10:55:20 -0500 Received: by interlock.ans.net id AA17133 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 10:50:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 10:50:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 10:50:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 10:50:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 10:50:33 -0500 Message-Id: <9412191548.AA06015@snark.imsi.com> To: kate@digiw.fi (Kate Marika Alhola) Cc: ipsec@ans.net Subject: Re: Few SwiPe questions In-Reply-To: Your message of "Mon, 19 Dec 1994 17:02:20 +0200." <9412191502.AA27532@digiw.fi> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 10:48:53 -0500 From: "Perry E. Metzger" swIPe is aging badly but I'll happily answer (as best as I can) your main question.... Kate Marika Alhola says: > Then few simple questions. The "Arhhitecture ..." document says, that > Swipe uses IP protocol 94, that is defined IP over IP tunneling protocol, The documents in question are very closely tied to the swIPe prototype that was built. The prototype used 94, but 94 is really meant for other things. Remember that swIPe was more a proof of concept than something "cleaned up" and designed for use. 94 is really for IP in IP tunneling, not for swIPe. The prototype stole it because, well, it was there. There is work going on to turn the swIPe prototype into something that looks a lot more like IPSP. I'd discourage people from using the existing swIPe for anything but applications that need to be run *today*. Perry From ipsec-request@ans.net Mon Dec 19 17:31:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12604 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 12:35:23 -0500 Received: by interlock.ans.net id AA25129 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 12:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 12:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 12:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 12:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 12:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 12:31:58 -0500 Message-Id: <9412191731.AA20280@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ipsec@ans.net Cc: Paul_Lambert-P15452@email.mot.com, cschow@watson.ibm.com Subject: Clarification: NRP's licensing status & IKMP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 12:31:49 -0500 From: " " I wish to clarify a few points about NRP's licensing status and its relation to IKMP proposals, as a response to several questions from Paul and others: 1. NRP is not a proposal for IKMP, was just mentioned as something people implementing security may want to look at. NRP (Network Randomization Protocol) is a tool to provide proactively-secure randomness, so it is relevant to IKMP just as it is relevant to other security protocols/systems. 2. Warning: modifications to NRP must be made available to IBM (i.e. this is fine for making other public domain stuff but problematic for products). This is similar to the status of many other `public domain' sw, e.g. RSAREF, PGP, ... 3. IBM is not necessarily giving free use of its copyright/patent protected property for distribution of deriviatives of NRP. (However, experimental use is allowed - this is a general IBM policy.) I expect that we would be able to give free use for `reasonable deriviatives', i.e. sw that does not extend NRP to completely new functions... (There are patent applications which I believe cover NRP but they are really targeted at more advanced functions - NRP stuff should be for free) 4. We'll be happy to work with implementors that need changes to these terms however let's do it off list since NRP is really a side issue for this WG (see point 1 above). 5. NRP is fully exportable. We are working on a new release of NRP where we would have `tested portability' and implement local sampling. Best, Amir ------- End of Forwarded Message From ipsec-request@ans.net Mon Dec 19 18:33:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14578 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 13:46:55 -0500 Received: by interlock.ans.net id AA23423 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 13:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 13:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 13:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 13:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 13:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 13:33:18 -0500 From: uri@watson.ibm.com Message-Id: <9412191833.AA17626@buoy.watson.ibm.com> Subject: Re: Size of IV field in DES-CBC mode To: karn@qualcomm.com Date: Mon, 19 Dec 1994 13:33:10 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199412191048.CAA01748@unix.ka9q.ampr.org> from "Phil Karn" at Dec 19, 94 02:48:13 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 683 Phil Karn says: > Do we really need a full 8 bytes for the IV field in the baseline > DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of > the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 > bytes are mapped properly into the actual 8-byte DES IV field they > should do an acceptable job of ensuring that every packet ciphertext > is completely different even when the corresponding plaintext begins > with constant values (e.g., TCP or UDP port numbers). I'd say 4 bytes is enough. And if needed - they can be mapped onto 8 bytes (expanded) relatively cheaply. -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Mon Dec 19 18:51:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14647 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 13:59:38 -0500 Received: by interlock.ans.net id AA47094 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 13:52:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 13:52:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 13:52:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 13:52:12 -0500 Message-Id: <9412191851.AA00797@skidrow.tay.dec.com> To: ipsec@ans.net Subject: Re: Clarification: NRP's licensing status & IKMP In-Reply-To: Your message of "Mon, 19 Dec 94 12:31:49 EST." <9412191731.AA20280@gimili.watson.ibm.com> Date: Mon, 19 Dec 94 13:51:21 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp While improvements in random number generation are great, I see no reason for any part of the ipsec standard to prefer any particular method. I would expect it merely emphasize the importance of this and to have a few references to general overview documents on the subject. Donald From: " " X-Mailer: exmh version 1.5.1 12/2/94 To: ipsec@ans.net Cc: Paul_Lambert-P15452@email.mot.com, cschow@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > >I wish to clarify a few points about NRP's licensing status and its relation >to IKMP proposals, as a response to several questions from Paul and others: > >1. NRP is not a proposal for IKMP, was just mentioned as something people >implementing security may want to look at. NRP (Network Randomization >Protocol) is a tool to provide proactively-secure randomness, so it is >relevant to IKMP just as it is relevant to other security protocols/systems. > >2. Warning: modifications to NRP must be made available to IBM (i.e. this is >fine for making other public domain stuff but problematic for products). >This is similar to the status of many other `public domain' sw, e.g. RSAREF, >PGP, ... > >3. IBM is not necessarily giving free use of its copyright/patent protected >property for distribution of deriviatives of NRP. (However, experimental use >is allowed - this is a general IBM policy.) I expect that we would >be able to give free use for `reasonable deriviatives', i.e. sw that does >not extend NRP to completely new functions... > >(There are patent applications which I believe cover NRP but they are really >targeted at more advanced functions - NRP stuff should be for free) > >4. We'll be happy to work with implementors that need changes to these terms >however let's do it off list since NRP is really a side issue for this WG (see >point 1 above). > >5. NRP is fully exportable. > >We are working on a new release of NRP where we would have `tested portability' >and implement local sampling. > >Best, Amir > > >------- End of Forwarded Message > > From ipsec-request@ans.net Mon Dec 19 19:15:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14348 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:16:42 -0500 Received: by interlock.ans.net id AA46300 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:10:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 14:10:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:10:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:10:26 -0500 Message-Id: <9412191915.AA18390@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 13:15:49 -0600 To: uri@watson.ibm.com, karn@qualcomm.com From: hughes@hughes.network.com (James P Hughes) Subject: Re: Size of IV field in DES-CBC mode Cc: ipsec@ans.net At 1:33pm 12/19/94 -0500, uri@watson.ibm.com wrote: >Phil Karn says: >> Do we really need a full 8 bytes for the IV field in the baseline >> DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of >> the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 >> bytes are mapped properly into the actual 8-byte DES IV field they >> should do an acceptable job of ensuring that every packet ciphertext >> is completely different even when the corresponding plaintext begins >> with constant values (e.g., TCP or UDP port numbers). What this means is that the number of packets until there are 2 with the same IV is 65K packets. 2 packets with the same IV is not necessarily a problem. Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Dec 19 18:11:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30995 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:18:38 -0500 Received: by interlock.ans.net id AA16426 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:14:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 14:14:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 14:14:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 14:14:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:14:45 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:14:45 -0500 Date: 19 Dec 94 12:11:00 -0600 To: uri@watson.ibm.com, karn@qualcomm.com Cc: ipsec@ans.net, zmuda@spyrus.com Subject: Re[2]: Size of IV field in DES-CBC mode Message-Id: -----BEGIN PGP SIGNED MESSAGE----- This does should like a good improvement for DES-CBC. If I do not hear any objections, I will try to get this into this weeks ipsp I-D release. No guarantees since we are in mid-edit now, but it would be a small tweak for the next release. If we do specify only 4-bytes, we need specific text describing the usage of this field. Do we: - PAD with zeros ... - PAD with a fixed (non-zero) pattern - use the SAID also (to get to 8-bytes) - PAD with SAID determined bits (secret to outside observer) - expand (with MD5) to 8-bytes Comments? Paul -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBLvV3vK045jYe3y+lAQGF3wMAs7Tjt7US+768gI4IaiJ1K6NHyFCkQxX6 MT6O4Mgtfs7WuiZ+SL106yg/jVaw3rLaiOlH8wAaUH8XAmJ4GQmIE806lv9YspY0 D7tqOgfRVLe6NSLqlc80MDEczYDiFGnB =bbCi -----END PGP SIGNATURE----- From ipsec-request@ans.net Mon Dec 19 19:17:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16207 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:23:23 -0500 Received: by interlock.ans.net id AA42134 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:17:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 14:17:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 14:17:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 14:17:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:17:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:17:35 -0500 From: uri@watson.ibm.com Message-Id: <9412191917.AA22084@buoy.watson.ibm.com> Subject: Re: Re[2]: Size of IV field in DES-CBC mode To: Paul_Lambert-P15452@email.mot.com Date: Mon, 19 Dec 1994 14:17:17 -0500 (EST) Cc: karn@qualcomm.com, ipsec@ans.net, zmuda@spyrus.com In-Reply-To: from "Paul_Lambert-P15452@email.mot.com" at Dec 19, 94 12:11:00 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 379 Paul_Lambert-P15452@email.mot.com says: > This does should like a good improvement for DES-CBC. Yup! (:-) > If we do specify only 4-bytes, we need specific text describing the > usage of this field. > Do we: > - ........other methods....... > - expand (with MD5) to 8-bytes I vote for MD5. -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Mon Dec 19 19:24:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14196 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:29:12 -0500 Received: by interlock.ans.net id AA23336 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:24:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 14:24:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 14:24:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 14:24:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:24:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:24:27 -0500 Message-Id: <9412191924.AA20311@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re: Clarification: NRP's licensing status & IKMP In-Reply-To: Your message of "Mon, 19 Dec 1994 13:51:21 EST." <9412191851.AA00797@skidrow.tay.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 14:24:09 -0500 From: " " Donald and all, Please understand: I'm NOT proposing that NRP would be a part or mentioned in ipsec standards!! (IPSEC standard should mention your `randomness RFC'; I'll be happy if you do mention NRP in a future release of your randomness RFC, of course, since I find this RFC a very useful discussion.) I only mentioned NRP in IPSEC since I believed that many in that audiance would be interested in such a tool to get secure random numbers even if the attacker can peek into internal seed values... I've tried to make it clear from the very beginning that this is just information and not a proposal (how could it be? it is not doing any key management...). BTW, I'm not sure yet if this was a mistake. Quite a few got the wrong impression that I propose that NRP would be involved somehow with the ipsec-generated standards, but also quite a few people seem to be really interested in NRP... Best, Amir (To the interested: following your questions/requests, we'll be putting in software.watson.ibm.com/pub/security also some relevant papers in addition to the tar file with the sources and manual, see the read.me file or do ls since I'm undecided about names etc.) Enc: msg from Donald > > While improvements in random number generation are great, I see no > reason for any part of the ipsec standard to prefer any particular > method. I would expect it merely emphasize the importance of this and > to have a few references to general overview documents on the subject. > > Donald > > > From: " " > X-Mailer: exmh version 1.5.1 12/2/94 > To: ipsec@ans.net > Cc: Paul_Lambert-P15452@email.mot.com, cschow@watson.ibm.com > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > > > >I wish to clarify a few points about NRP's licensing status and its relation > >to IKMP proposals, as a response to several questions from Paul and others: > > > >1. NRP is not a proposal for IKMP, was just mentioned as something people > >implementing security may want to look at. NRP (Network Randomization > >Protocol) is a tool to provide proactively-secure randomness, so it is > >relevant to IKMP just as it is relevant to other security protocols/systems. > > > >2. Warning: modifications to NRP must be made available to IBM (i.e. this is > >fine for making other public domain stuff but problematic for products). > >This is similar to the status of many other `public domain' sw, e.g. RSAREF, > >PGP, ... > > > >3. IBM is not necessarily giving free use of its copyright/patent protected > >property for distribution of deriviatives of NRP. (However, experimental use > >is allowed - this is a general IBM policy.) I expect that we would > >be able to give free use for `reasonable deriviatives', i.e. sw that does > >not extend NRP to completely new functions... > > > >(There are patent applications which I believe cover NRP but they are really > >targeted at more advanced functions - NRP stuff should be for free) > > > >4. We'll be happy to work with implementors that need changes to these terms > >however let's do it off list since NRP is really a side issue for this WG (see > >point 1 above). > > > >5. NRP is fully exportable. > > > >We are working on a new release of NRP where we would have `tested portability' > >and implement local sampling. > > > >Best, Amir > > > > > >------- End of Forwarded Message > > > > From ipsec-request@ans.net Mon Dec 19 19:50:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38449 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:55:14 -0500 Received: by interlock.ans.net id AA02824 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 14:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 14:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:50:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:50:44 -0500 Message-Id: <9412191950.AA07388@snark.imsi.com> To: karn@qualcomm.com Cc: ipsec@ans.net Subject: Re: Size of IV field in DES-CBC mode In-Reply-To: Your message of "Mon, 19 Dec 1994 02:48:13 PST." <199412191048.CAA01748@unix.ka9q.ampr.org> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 14:50:09 -0500 From: "Perry E. Metzger" Phil Karn says: > Do we really need a full 8 bytes for the IV field in the baseline > DES-CBC mode? Well, if you are on a gigabit network, you would run through all possibilities for only 32 bits of IV very, very fast. Of course, DES is likely a foolish choice for encrypting any serious traffic, anyway, but for 3DES it makes sense to have a reasonable sized IV. Myself, I'd say this should be handled by having a different transform that handles smaller IVs -- or at least, even if the DES case uses small IVs the 3DES case should not by default. Perry From ipsec-request@ans.net Mon Dec 19 18:55:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23895 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 14:57:45 -0500 Received: by interlock.ans.net id AA02946 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 14:55:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 14:55:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 14:55:11 -0500 Date: Mon, 19 Dec 94 18:55:35 GMT From: "William Allen Simpson" Message-Id: <3576.bill.simpson@um.cc.umich.edu> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: key management > There is harm in redefining the problems addressed by this > mailing list from a narrow one that is within the scope of this IETF > working group to one that is beyond the scope of the entire IETF. > Such redefinition and the resulting diffusion of the discussion tend > to significantly impede progress on the narrow technical problems that > really ARE within our scope. The WG is already late in developing our > specifications and we need to stay focused on things within our > charter. There exist other places that the broader issue can be > discussed or such places could be created easily (e.g. a new mailing > list). The issue is not whether ANY discussion is legitimate but > rather WHERE different discussions should live (i.e. its a sorting > problem). > While trying to catch up on my 1.7 MB of email (from the week after IETF -- I did the IETF week in the intervening weekend), I would like to thank you for your pithy and accurate comments. Particularly the one about reading the drafts! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Dec 19 20:02:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18445 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 15:13:42 -0500 Received: by interlock.ans.net id AA29855 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 15:06:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 15:06:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 15:06:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 15:06:23 -0500 Message-Id: <9412192002.AA05356@skidrow.tay.dec.com> To: ipsec@ans.net Subject: Re: Size of IV field in DES-CBC mode In-Reply-To: Your message of "Mon, 19 Dec 94 13:15:49 CST." <9412191915.AA18390@hughes.network.com> Date: Mon, 19 Dec 94 15:02:56 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp 2**16 = 65K 2**32 = 4 gig If it would be a good thing to pad the IV to 8 bytes with the source address for multicast, why not always do that? (And actually, since I think we should make some effort for commonality with IPv6, just say its the "bottom 4 bytes" of the source address.) Donald From: hughes@hughes.network.com (James P Hughes) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: uri@watson.ibm.com, karn@qualcomm.com Cc: ipsec@ans.net >At 1:33pm 12/19/94 -0500, uri@watson.ibm.com wrote: >>Phil Karn says: >>> Do we really need a full 8 bytes for the IV field in the baseline >>> DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of >>> the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 >>> bytes are mapped properly into the actual 8-byte DES IV field they >>> should do an acceptable job of ensuring that every packet ciphertext >>> is completely different even when the corresponding plaintext begins >>> with constant values (e.g., TCP or UDP port numbers). > >What this means is that the number of packets until there are 2 with the >same IV is 65K packets. 2 packets with the same IV is not necessarily a >problem. > > >Jim > >---------------------- >James P Hughes >Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Dec 19 19:29:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35337 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 15:38:13 -0500 Received: by interlock.ans.net id AA46320 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 15:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 15:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 15:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 15:33:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 15:33:18 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 15:33:18 -0500 Date: 19 Dec 94 13:29:00 -0600 To: amir@watson.ibm.com Cc: ipsec@ans.net Subject: Re[2]: Clarification: NRP's licensing status & IKMP Message-Id: Amir, Thanks for the clarification. Hopefully we can now move forward now with discussions relevant to the specifications that we are developing. >Subject: Re: Clarification: NRP's licensing status & IKMP >Author: amir@watson.ibm.com@INTERNET stuff skipped ... >Donald and all, > >Please understand: I'm NOT proposing that NRP would be a part or mentioned >in ipsec standards!! (IPSEC standard should mention your `randomness RFC'; I had one more observation ... > >2. Warning: modifications to NRP must be made available to IBM (i.e. this is > >fine for making other public domain stuff but problematic for products). > >This is similar to the status of many other `public domain' sw, e.g. RSAREF, > >PGP, ... Not all public domain software is created equal (licensed the same). !!! From "license.txt" contained in: !!! !!! software.watson.ibm.com/pub/security/nrp.tar !!! > f. IBM requests that the user supply to IBM a copy > of any changes, enhancements, or derivative > works which the user may create. The user > grants IBM and its subsidiaries an irrevocable, > nonexclusive, worldwide and royalty-free > license to use, execute, reproduce, display, > perform, prepare derivative works based upon, > and distribute, (INTERNALLY AND EXTERNALLY) > copies of any and all such materials and > derivative works thereof, and to sublicense > others to do any, some, or all of the > foregoing, (including supporting > documentation). Coders beware, any incorporation of NRP code into a project forfeits ownership to IBM. Paul From ipsec-request@ans.net Mon Dec 19 19:37:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38763 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 15:50:58 -0500 Received: by interlock.ans.net id AA40714 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 15:46:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 15:46:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 15:46:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 15:46:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 15:46:07 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 15:46:07 -0500 Date: 19 Dec 94 13:37:00 -0600 To: dee@skidrow.tay.dec.com Cc: ipsec@ans.net Subject: Address as IV [was] Size of IV field in DES-CBC mode Message-Id: Donald, Violating protocol layering is usually a bad idea. Environments exist where an end-system address may not follow the SAID end-to-end. IP addresses are supposed to be end-to-end, but many real systems translate the addresses. Your proposed approach will not work for IPv4. Is this a problem for IPv6? Paul _______________________________________________________________________________ Subject: Re: Size of IV field in DES-CBC mode Author: dee@skidrow.tay.dec.com@INTERNET Date: 12/19/94 2:02 PM X-Mts: smtp 2**16 = 65K 2**32 = 4 gig If it would be a good thing to pad the IV to 8 bytes with the source address for multicast, why not always do that? (And actually, since I think we should make some effort for commonality with IPv6, just say its the "bottom 4 bytes" of the source address.) Donald From: hughes@hughes.network.com (James P Hughes) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: uri@watson.ibm.com, karn@qualcomm.com Cc: ipsec@ans.net >At 1:33pm 12/19/94 -0500, uri@watson.ibm.com wrote: >>Phil Karn says: >>> Do we really need a full 8 bytes for the IV field in the baseline >>> DES-CBC mode? 4 bytes would be enough to maintain 32-bit alignment of >>> the next-layer transport header (e.g., TCP, UDP or IP). And if these 4 >>> bytes are mapped properly into the actual 8-byte DES IV field they >>> should do an acceptable job of ensuring that every packet ciphertext >>> is completely different even when the corresponding plaintext begins >>> with constant values (e.g., TCP or UDP port numbers). > >What this means is that the number of packets until there are 2 with the >same IV is 65K packets. 2 packets with the same IV is not necessarily a >problem. > > >Jim > >---------------------- >James P Hughes >Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Dec 19 21:27:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17126 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 16:34:16 -0500 Received: by interlock.ans.net id AA45919 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 16:30:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 16:30:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 16:30:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 16:30:44 -0500 Message-Id: <9412192127.AA10912@skidrow.tay.dec.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Address as IV [was] Size of IV field in DES-CBC mode In-Reply-To: Your message of "19 Dec 94 13:37:00 CST." Date: Mon, 19 Dec 94 16:27:01 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul: That's a good point. Uri: How much of a security gain do you really see from using a 64 bit extract of the MD5 of this 32 bit quantity instead of, for example, just duplicating the 32 bits in each half of the IV? Donald From: Paul_Lambert-P15452@email.mot.com To: dee Cc: ipsec@ans.net > >Donald, > >Violating protocol layering is usually a bad idea. Environments exist where an >end-system address may not follow the SAID end-to-end. IP addresses are >supposed to be end-to-end, but many real systems translate the addresses. > >Your proposed approach will not work for IPv4. Is this a problem for IPv6? > >Paul >_______________________________________________________________________________ >Subject: Re: Size of IV field in DES-CBC mode >Author: dee@skidrow.tay.dec.com@INTERNET >Date: 12/19/94 2:02 PM > >X-Mts: smtp > > >2**16 = 65K >2**32 = 4 gig > >If it would be a good thing to pad the IV to 8 bytes with the source >address for multicast, why not always do that? (And actually, since I >think we should make some effort for commonality with IPv6, just say >its the "bottom 4 bytes" of the source address.) > >Donald From ipsec-request@ans.net Mon Dec 19 11:28:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18664 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 16:34:16 -0500 Received: by interlock.ans.net id AA19507 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 16:28:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 16:28:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 16:28:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 16:28:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 16:28:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 16:28:25 -0500 Message-Id: <9412192128.AA37833@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Paul_Lambert-P15452@email.mot.com Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Re[3]: Clarification: NRP's licensing status & IKMP In-Reply-To: Your message of "19 Dec 1994 13:29:00 CST." Date: Mon, 19 Dec 94 16:28:17 EST From: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Dec 1994 16:28:17 -0500 From: " " > Thanks for the clarification. Hopefully we can now move forward now with > discussions relevant to the specifications that we are developing. Agreed! Sorry to have added noise! Let's stop it (move more discussion off list) > > I had one more observation ... > > > >2. Warning: modifications to NRP must be made available to IBM (i.e. this is > > >fine for making other public domain stuff but problematic for products). > > >This is similar to the status of many other `public domain' sw, e.g. RSAREF, > > >PGP, ... > > Not all public domain software is created equal (licensed the same). > I'm sure not all Public-domain stuff has such clauses, but the two examples I gave do have so they are traps just as much as NRP is. If this is a problem to somebody considering NRP, help me resolve it by discussing this off-list, preferably with some good examples of comparable sw that was given to the public without similar clauses. Thanks! Amir > Coders beware, any incorporation of NRP code into a project forfeits ownership > to IBM. Please, Paul: the problem is just for non-public domain use. I agree this is still a problem for many of us - we have to deal with exactly this problem in my group! But, IBM does not become owner, just has free license... If all gets free license this does not mean much. Again: these are the same terms as of RSAREF, for example (as far as I can see). > > > Paul From ipsec-request@ans.net Mon Dec 19 17:06:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38716 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:06:08 -0500 Received: by interlock.ans.net id AA13059 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 16:55:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 16:55:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 16:55:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 16:55:32 -0500 Date: Mon, 19 Dec 94 13:26:07 From: "Housley, Russ" Encoding: 457 Text Message-Id: <9411197878.AA787872367@spysouth.spyrus.com> To: uri@watson.ibm.com, karn@qualcomm.com Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net, jis@mit.edu Subject: Re[2]: Human I&A, IPsec, and their non-relationship Phil: > Well, nothing says you have to do DH for each user. Inspired by Jeff > Schiller's comments about 802.10, in Photuris I will use DH to > establish some shared secret material between the hosts and then > hash that to generate distinct session keys for each SAID. I do not know what Jeff said, but the whole point od SPAWN-KEY is to allow multiple security associations to be created from one key agreement (e.g., D-H exchange). Russ From ipsec-request@ans.net Mon Dec 19 22:02:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38723 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:06:27 -0500 Received: by interlock.ans.net id AA45949 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:02:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 17:02:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 17:02:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:02:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:02:40 -0500 Message-Id: <9412192202.AA09007@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: End to End integrity (was 4 byte vs 8 byte IVs for DES) In-Reply-To: Your message of "19 Dec 1994 13:37:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 17:02:17 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > Violating protocol layering is usually a bad idea. Environments > exist where an end-system address may not follow the SAID > end-to-end. IP addresses are supposed to be end-to-end, but many > real systems translate the addresses. I'll point out something that we didn't discuss in sufficient detail in San Jose. For very good reasons (so that you can have guarantees about the integrity of the addresses) Ran's spec for v6 includes a pseudoheader consisting of the invariant parts of the header of the IP datagram in his authentication header. I strongly feel we should be specifying something similar. This is doubly important in the multicast case where a third party could simply re-label the origin of the packet without any knowledge at all of the contents or key and still have it check out just fine if the origin and destination addresses are changed. Given that you need to be able to maintain end to end integrity of the source and destination addresses, some of your arguments become a bit more interesting/different... Perry From ipsec-request@ans.net Mon Dec 19 22:14:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14275 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:26:02 -0500 Received: by interlock.ans.net id AA10130 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:18:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:18:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:18:22 -0500 Message-Id: <9412192214.AA24404@columbia.sparta.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Size of IV field in DES-CBC mode In-Reply-To: Your message of "Mon, 19 Dec 94 15:02:56 EST." <9412192002.AA05356@skidrow.tay.dec.com> Date: Mon, 19 Dec 94 17:14:01 -0500 From: Carl Muckenhirn In message <9412192002.AA05356@skidrow.tay.dec.com> you wrote: > > 2**16 = 65K > 2**32 = 4 gig > I think that Jim is refering to the Birthday Paradox, so given an evenly distributed population of 2**32, the probability that a match will be found exceeds 50% with a sample of sqrt(2**32) = 2**16. If we assume randomly distributed IVs, then the expected sample should go to 1/2*(2**32)=2**31. Furthermore if we are talking about CBC, a one-up counter works just as well as a random value (the only property of interest is change, not magnitude of change) and we can use all 32 bits. (Again this is for CBC, other modes have other concerns.) > If it would be a good thing to pad the IV to 8 bytes with the source > address for multicast, why not always do that? (And actually, since I > think we should make some effort for commonality with IPv6, just say > its the "bottom 4 bytes" of the source address.) > > Donald I think that's a wonderful idea (always padding with source address). Using the bottom 4 bytes of an IPv6 address may also work, though there may be some IV-space clashes since they are not guaranteed to be different per-host as IPv4 addrs are. Alternatively use the Senders SAID (we might even be able to reduce the amount of bit shuffling if we put the SAID directly before the IV (with no intervening bits). carl. From ipsec-request@ans.net Mon Dec 19 21:12:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16340 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:26:50 -0500 Received: by interlock.ans.net id AA22990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 17:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 17:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 17:22:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:22:02 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:22:02 -0500 Date: 19 Dec 94 15:12:00 -0600 To: dee@skidrow.tay.dec.com Cc: ipsec@ans.net Subject: Summary - IV field in DES-CBC mode Message-Id: Options for shorter IV for IPSP DES-CBC modes of operation: ! 1) PAD with zeros ... ! 2) PAD with a fixed (non-zero) pattern !! 3) use the SAID also (to get to 8-bytes) 4) PAD with SAID determined bits (secret to outside observer) 5) expand (with MD5) to 8-bytes X 6) use part of IP address !! 7) duplicating the 32 bits in each half of the IV Option 4 adds yet another secret to negotiate. IVs do not need to be secret. We do need to consider high speed implementations of IPSP. Option 5 (using MD5 to create the extra 32 bits of IV) would create significant extra processing. Option 6 will not work. This leaves options 1, 2, 3 and 7. I am partial to option 3, using the SAID as part of the IV. Some DES implementations expect the IV to be "in front" of the encrypted data. Option 7 also seems quite simple... Paul From ipsec-request@ans.net Mon Dec 19 22:33:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38426 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:37:52 -0500 Received: by interlock.ans.net id AA27990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:34:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 17:34:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 17:34:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 17:34:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:34:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:34:00 -0500 From: uri@watson.ibm.com Message-Id: <9412192233.AA18015@buoy.watson.ibm.com> Subject: Re: Address as IV [was] Size of IV field in DES-CBC mode To: dee@skidrow.tay.dec.com (Donald E. Eastlake 3rd) Date: Mon, 19 Dec 1994 17:33:51 -0500 (EST) Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net In-Reply-To: <9412192127.AA10912@skidrow.tay.dec.com> from "Donald E. Eastlake 3rd" at Dec 19, 94 04:27:01 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 383 Donald E. Eastlake 3rd says: > Uri: How much of a security gain do you really see from using a 64 bit > extract of the MD5 of this 32 bit quantity instead of, for example, > just duplicating the 32 bits in each half of the IV? Honestly - I concede, not much. Just a matter of personal preference (:-). -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Mon Dec 19 22:34:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38434 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:38:41 -0500 Received: by interlock.ans.net id AA11869 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:35:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 19 Dec 1994 17:35:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 17:35:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 17:35:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:35:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:35:02 -0500 From: uri@watson.ibm.com Message-Id: <9412192234.AA17512@buoy.watson.ibm.com> Subject: Re: Address as IV [was] Size of IV field in DES-CBC mode To: dee@skidrow.tay.dec.com (Donald E. Eastlake 3rd) Date: Mon, 19 Dec 1994 17:34:56 -0500 (EST) Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net In-Reply-To: <9412192127.AA10912@skidrow.tay.dec.com> from "Donald E. Eastlake 3rd" at Dec 19, 94 04:27:01 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 469 Donald E. Eastlake 3rd says: > Uri: How much of a security gain do you really see from using a 64 bit > extract of the MD5 of this 32 bit quantity instead of, for example, > just duplicating the 32 bits in each half of the IV? Let me recall the last one: if other ingredients are added, like taking MD5 of this 320bit quantity plus something from SA - this may improve security somewhat. -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Mon Dec 19 22:49:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27290 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 17:57:42 -0500 Received: by interlock.ans.net id AA13194 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 17:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 17:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 17:53:52 -0500 Message-Id: <9412192249.AA24557@columbia.sparta.com> To: Paul_Lambert-P15452@email.mot.com Cc: dee@skidrow.tay.dec.com, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Address as IV [was] Size of IV field in DES-CBC mode In-Reply-To: Your message of "19 Dec 94 13:37:00 CST." Date: Mon, 19 Dec 94 17:49:25 -0500 From: Carl Muckenhirn Don't you just love these X.400 addresses: In message you wrote: > > Donald, > > Violating protocol layering is usually a bad idea. Environments exist where > an > end-system address may not follow the SAID end-to-end. IP addresses are > supposed to be end-to-end, but many real systems translate the addresses. > > Your proposed approach will not work for IPv4. Is this a problem for IPv6? > > Paul Paul, I'm not exactly sure what you mean. Is IPSP associated with the IP-layer or not? If it is, then a unique IP address must be available at each end of the "association", it may be a "red" address, unknown to the network at large, or a "black" address, available to the network at large. In either case, for the datagram to be delivered to a decryptor, it must be addressable, and the encryptor-decrytor pair must know each other's "encrypting" address. The other option is that IPSP is associated with the transport layer, where several IP providers (addresses) may map to a particular transport provider. But this option is hard to accommodate at gateways. carl. From ipsec-request@ans.net Tue Dec 20 00:13:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20761 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 19:23:23 -0500 Received: by interlock.ans.net id AA45978 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 19:12:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 19:12:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 19:12:27 -0500 Date: Mon, 19 Dec 1994 16:13:15 -0800 From: Phil Karn Message-Id: <199412200013.QAA02783@unix.ka9q.ampr.org> To: colin@nyx10.cs.du.edu Cc: ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <9412191235.AA02934@nyx10.cs.du.edu> (colin@nyx10.cs.du.edu) Subject: Re: Size of IV field in DES-CBC mode >4 bytes will do, but for CBC mode, some sort of expansion (e.g. CRC-32) to >64 bits would be nice just to make sure. Or perhaps just repeating the 4 bytes to make 8? It's sufficient to ensure that the XOR of the IV and the first block of plaintext always differs in at least one bit. Phil From ipsec-request@ans.net Tue Dec 20 00:18:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38451 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 19:27:44 -0500 Received: by interlock.ans.net id AA40187 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 19:19:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 19:19:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 19:19:06 -0500 Date: Mon, 19 Dec 1994 16:18:32 -0800 From: Phil Karn Message-Id: <199412200018.QAA02793@unix.ka9q.ampr.org> To: kate@digiw.fi Cc: ipsec@ans.net In-Reply-To: <9412191502.AA27532@digiw.fi> (kate@digiw.fi) Subject: Re: Few SwiPe questions Protocol 94 is John Ioannidis's tunneling protocol. He got it back when he did his own mobile IP work. If you just want to tunnel IP inside of IP with nothing between them, use protocol #4. Phil From ipsec-request@ans.net Tue Dec 20 00:40:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38607 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 19:51:53 -0500 Received: by interlock.ans.net id AA21777 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 19:41:42 -0500 Date: Mon, 19 Dec 1994 16:40:15 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9412200040.AA00357@miraj.> To: Paul_Lambert-P15452@email.mot.com Subject: Re: Summary - IV field in DES-CBC mode Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Mon Dec 19 15:04 PST 1994 > Options for shorter IV for IPSP DES-CBC modes of operation: > > ! 1) PAD with zeros ... > ! 2) PAD with a fixed (non-zero) pattern > !! 3) use the SAID also (to get to 8-bytes) > 4) PAD with SAID determined bits (secret to outside observer) > 5) expand (with MD5) to 8-bytes > X 6) use part of IP address > !! 7) duplicating the 32 bits in each half of the IV > > This leaves options 1, 2, 3 and 7. > > I am partial to option 3, using the SAID as part of the IV. Some DES > implementations expect the IV to be "in front" of the encrypted data. > > Option 7 also seems quite simple... I prefer option 7 (let's keep it simple). Regards, Ashar. From ipsec-request@ans.net Tue Dec 20 00:55:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35393 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 20:04:18 -0500 Received: by interlock.ans.net id AA39126 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 19:56:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 19:56:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 19:56:03 -0500 Date: Mon, 19 Dec 1994 16:55:39 -0800 From: Phil Karn Message-Id: <199412200055.QAA02909@unix.ka9q.ampr.org> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: <9412191950.AA07388@snark.imsi.com> (perry@imsi.com) Reply-To: karn@qualcomm.com Subject: Re: Size of IV field in DES-CBC mode >Well, if you are on a gigabit network, you would run through all >possibilities for only 32 bits of IV very, very fast. Of course, DES >is likely a foolish choice for encrypting any serious traffic, anyway, >but for 3DES it makes sense to have a reasonable sized IV. Seems to me that you'd be foolish to encrypt as many as 4,294,967,296 packets in any cipher without changing session keys. Especially given a simple and cheap mechanism for rekeying without necessarily having to go through another DH exchange. In photuris you could simply place a limit on the lifetime (in seconds and in packets) of a SAID. When you reach this limit, you create a new security association (which implies a new session key, since the SAID is an input to the hash function) and destroy the old one. Remember again that the only purpose of an IV is to ensure that ciphertext never repeats even when the (beginning of) the plaintext does. Phil From ipsec-request@ans.net Tue Dec 20 01:34:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16986 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 20:36:54 -0500 Received: by interlock.ans.net id AA40590 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 20:33:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 20:33:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 20:33:49 -0500 Date: Mon, 19 Dec 1994 17:34:17 -0800 From: Phil Karn Message-Id: <199412200134.RAA03111@unix.ka9q.ampr.org> To: perry@imsi.com Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net In-Reply-To: <9412192202.AA09007@snark.imsi.com> (perry@imsi.com) Reply-To: karn@qualcomm.com Subject: Re: End to End integrity (was 4 byte vs 8 byte IVs for DES) >in San Jose. For very good reasons (so that you can have guarantees >about the integrity of the addresses) Ran's spec for v6 includes a >pseudoheader consisting of the invariant parts of the header of the IP >datagram in his authentication header. I strongly feel we should be >specifying something similar. This is doubly important in the I'm not sure I agree. I think there's a fairly widespread feeling that the pseudoheaders in the UDP and TCP checksums were a mistake, or at least not really necessary. Even if deliberate misrouting is an issue, what good would it do you given that each host pair has its own unique key anyway? I haven't thought as much about multicast, but it seems to me there's not much you can do to protect against a rogue member who already has the session key. Other than rekeying to exclude him, of course. Phil From ipsec-request@ans.net Tue Dec 20 02:52:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29616 (5.65c/IDA-1.4.4 for ); Mon, 19 Dec 1994 22:13:27 -0500 Received: by interlock.ans.net id AA44185 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 19 Dec 1994 21:52:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 19 Dec 1994 21:52:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 19 Dec 1994 21:52:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Dec 1994 21:52:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Dec 1994 21:52:59 -0500 Message-Id: <9412200252.AA09550@snark.imsi.com> To: karn@qualcomm.com Cc: ipsec@ans.net Subject: Re: End to End integrity (was 4 byte vs 8 byte IVs for DES) In-Reply-To: Your message of "Mon, 19 Dec 1994 17:34:17 PST." <199412200134.RAA03111@unix.ka9q.ampr.org> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 21:52:44 -0500 From: "Perry E. Metzger" Phil Karn says: > I haven't thought as much about multicast, but it seems to me there's > not much you can do to protect against a rogue member who already has > the session key. Other than rekeying to exclude him, of course. The problem is, in my mind, that someone OUTSIDE the group can switch around headers on you without needing the key. The SAID is shared by all members of the multicast group so anyone outside the group could swap source addresses at will. This is not necessarily a horrible opening, but we ought to consider the consequences of not authenticating the addresses carefully. Just because we can't think of attacks to exploit this offhand doesn't mean that a clever attack might not be out there. That doesn't mean we should adopt a pseudoheader approach, but I think we shouldn't be too hasty on this point. .pm From ipsec-request@ans.net Mon Dec 19 17:30:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27490 (5.65c/IDA-1.4.4 for ); Tue, 20 Dec 1994 02:33:12 -0500 Received: by interlock.ans.net id AA21120 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 20 Dec 1994 02:30:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 20 Dec 1994 02:30:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Dec 1994 02:30:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Dec 1994 02:30:14 -0500 Date: Tue, 20 Dec 94 00:30:03 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9412200730.AA05785@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: cfm@columbia.sparta.com Subject: Re: Size of IV field in DES-CBC mode Cc: ipsec@ans.net > I think that Jim is refering to the Birthday Paradox, so given an evenly > distributed population of 2**32, the probability that a match will be found > exceeds 50% with a sample of sqrt(2**32) = 2**16. If we assume randomly > distributed IVs, then the expected sample should go to 1/2*(2**32)=2**31. > Furthermore if we are talking about CBC, a one-up counter works just as well > as a random value (the only property of interest is change, not magnitude of > change) and we can use all 32 bits. (Again this is for CBC, other modes have > other concerns.) A counter works better for CFB than CBC. Consider: if x[] are the plaintext blocks and y[] are the ciphertext blocks, then y[0] = CRYPT(x[0] ^ IV). We want to be reasonably sure that the y[0]'s always differ, which means making sure that the x[0] ^ IV pattern always differs. Since the x[0] pattern is difficult to predicy (although maybe some things can be said about it), you have to get your variation from the IV. If the IV follows a simple pattern, and the x[0] happens to follow a parallel pattern, you can get "cancellation" of the changes and all of a sudden you have, for two messages M and M', y[0] == y'[0] so x[0] ^ x'[0] == IV ^ IV'. Can you make guarantees about the contents of x[0]? If it is random, or the bits which overlap the variable part of the IV don't change, then things work well. But if it is correlated with the IV, things are bad. That's why I suggested expanding a sequence number with a CRC-32: it's a cheap and well-understood bit-mixing function which is unlikely to occur in the header by accident. (An alternative is to incerment the IV by an odd number which is *not* 1.) > reduce the amount of bit shuffling if we put the SAID directly before the IV > (with no intervening bits). If you specify a source of bits to use to extend the IV, then the IV size can be easily varied by negotiation. -- -Colin From ipsec-request@ans.net Tue Dec 20 14:50:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24000 (5.65c/IDA-1.4.4 for ); Tue, 20 Dec 1994 11:04:44 -0500 Received: by interlock.ans.net id AA37525 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 20 Dec 1994 10:54:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 20 Dec 1994 10:54:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 20 Dec 1994 10:54:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 20 Dec 1994 10:54:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Dec 1994 10:54:26 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Dec 1994 10:54:26 -0500 Date: 20 Dec 94 08:50:00 -0600 To: cfm@columbia.sparta.com Cc: ipsec@ans.net Subject: Re[2]: Address as IV [was] Size of IV field in DES-CBC mode Message-Id: Carl, >Is IPSP associated with the IP-layer or not? If it is, then a unique IP >address must be available at each end of the "association", it may be a "red" >address, unknown to the network at large, or a "black" address, available to >the network at large. In either case, for the datagram to be delivered to a >decryptor, it must be addressable, and the encryptor-decrytor pair must know >each other's "encrypting" address. In the real world, IP addresses are not always end-to-end. Examples: - Tunneling of non-IP protocols - Mobile IP - IP / IPSP1 / IPSP2 (double encryption with IPSP) note that an address may be available implicily to IPSP2 but not explicitly Also, consider router-like scenarios where a device decrypts traffic for multiple addresses. Traffic between pairs of router-like devices could be protected with a single SAID, even though there might be several visible "black" addresses. We should not limit the usage of IPSP by using specific IP fields outside of the IPSP encapsulation. For our specific descussion on IVs, there are several other viable options. >The other option is that IPSP is associated with the transport layer, where >several IP providers (addresses) may map to a particular transport provider. >But this option is hard to accommodate at gateways. I do not know what you mean here and it seems of the topic of IVs for DES-CBC ... Paul From ipsec-request@ans.net Tue Dec 20 15:23:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27442 (5.65c/IDA-1.4.4 for ); Tue, 20 Dec 1994 11:48:53 -0500 Received: by interlock.ans.net id AA40334 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 20 Dec 1994 11:41:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Dec 1994 11:41:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Dec 1994 11:41:18 -0500 Date: Tue, 20 Dec 94 15:23:04 GMT From: "William Allen Simpson" Message-Id: <3580.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Size of IV field in DES-CBC mode > From: colin@nyx10.cs.du.edu (Colin Plumb) > That's why I suggested expanding a sequence number with a CRC-32: it's a cheap > and well-understood bit-mixing function which is unlikely to occur in the > header by accident. > > If you specify a source of bits to use to extend the IV, then the IV size can > be easily varied by negotiation. > If you can specify a source of bits to use for the IV, then you don't need an IV in the packets at all. My suggestion would be to always use a 32-bit IV, and extend it to 64 with the inverse of the IV. That way, you always get at least a 2-bit change from a previous IV (counter), and it would very likely not match changes in the following data (certainly not TCP or UDP). Yes, a CRC-32 might be better, but I'd rather keep it simple. I'm for saving both bytes _and_ processing. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Dec 20 16:51:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23912 (5.65c/IDA-1.4.4 for ); Tue, 20 Dec 1994 11:55:58 -0500 Received: by interlock.ans.net id AA35370 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 20 Dec 1994 11:52:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 20 Dec 1994 11:52:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 20 Dec 1994 11:52:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Dec 1994 11:52:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Dec 1994 11:52:41 -0500 Message-Id: <9412201651.AA10332@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[2]: Address as IV [was] Size of IV field in DES-CBC mode In-Reply-To: Your message of "20 Dec 1994 08:50:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Dec 1994 11:51:21 -0500 From: "Perry E. Metzger" I'll point out that, in general, since user layer protocols make frequent use of IP addresses (see, for instance, FTP), it is not in general possible to operate conventional TCP/IP applications in which addresses are not the same end to end. (Socks based firewalls take enormous pains to allow users to hide this from the remote applications, not always with success.) Paul_Lambert-P15452@email.mot.com says: > In the real world, IP addresses are not always end-to-end. Examples: > > - Tunneling of non-IP protocols In this context, however, we would assume that the encrypting IPSP tunnel would have to end at the end of the IP tunnel since IPSP is only defined in an IP context. (other contexts might be defined but this being the IETF we concern ourselves with IP.) > - Mobile IP Mobile IP addresses ARE end to end. > - IP / IPSP1 / IPSP2 (double encryption with IPSP) But in this instance, again, we would assume that the end of each encrypting tunnel would necessarily have access to the IP address from the beginning of the tunnel. > Also, consider router-like scenarios where a device decrypts traffic for > multiple addresses. Traffic between pairs of router-like devices could be > protected with a single SAID, even though there might be several visible > "black" addresses. Thats true, one might have a router protect things on behalf of other hosts, but, but as SAIDs have been defined in our discussions as being endpoint dependent rather than some sort of universal identifier, it isn't the option of the transmitter to use a single SAID for all such traffic. In any case, in the context of using a hash of the source and/or destination address with other material as an IV, it appears that layering problems or the end-to-endness of IP addresses should NOT be a reason not to do this. There may, of course, be other reasons not to. Perry From ipsec-request@ans.net Tue Dec 20 17:33:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31580 (5.65c/IDA-1.4.4 for ); Tue, 20 Dec 1994 13:44:11 -0500 Received: by interlock.ans.net id AA18638 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 20 Dec 1994 13:39:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 20 Dec 1994 13:39:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 20 Dec 1994 13:39:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 20 Dec 1994 13:39:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Dec 1994 13:39:46 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Dec 1994 13:39:46 -0500 Date: 20 Dec 94 11:33:00 -0600 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: Address as IV [was] Size of IV field in DES-CBC m Message-Id: Perry, >In this context, however, we would assume that the encrypting IPSP >tunnel would have to end at the end of the IP tunnel since IPSP is >only defined in an IP context. (other contexts might be defined but >this being the IETF we concern ourselves with IP.) You are correct that the scope of our work is to protect IP. My end-to-endness issue is valid primarily for mixed (IP and non-IP) environments. The binding of IP addresses to an SAID need not be one-to-one. A pair of router-like devices can communicate over a single security association (one SAID), but use multiple "black" IP addresses. This is part of a more complicated scenario that is partially documented in the SP3 cooperating families appendix (see the NIST publication). I am not a strong advocate of this approach, but once again, if possible we should not limit the capabilities of IPSP by our choice of an IV extension mechanism. There seem to be lots of other alternatives for IV extension .... Paul From ipsec-request@ans.net Wed Dec 21 16:15:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38475 (5.65c/IDA-1.4.4 for ); Wed, 21 Dec 1994 11:25:45 -0500 Received: by interlock.ans.net id AA43460 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 21 Dec 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 21 Dec 1994 11:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 21 Dec 1994 11:15:43 -0500 Message-Id: <9412211615.AA28252@columbia.sparta.com> To: Paul_Lambert-P15452@email.mot.com Cc: cfm@columbia.sparta.com, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Networking Model for Crypto-services [was] Re[2]: Address as IV [was] Size of IV field in DES-CBC mode In-Reply-To: Your message of "20 Dec 94 08:50:00 CST." Date: Wed, 21 Dec 94 11:15:05 -0500 From: Carl Muckenhirn In message you wrote: > > Carl, > > >Is IPSP associated with the IP-layer or not? If it is, then a unique IP > >address must be available at each end of the "association", it may be a "red > " > >address, unknown to the network at large, or a "black" address, available to > >the network at large. In either case, for the datagram to be delivered to a > >decryptor, it must be addressable, and the encryptor-decrytor pair must know > >each other's "encrypting" address. > > In the real world, IP addresses are not always end-to-end. Examples: > > - Tunneling of non-IP protocols This is true, the IP addresses are not true end-to-end, but they are end-to-end between the cooperating IPSP entities. > - Mobile IP I'm not sure exactly, but I don't believe that the IP address will change between transmission and receipt (it may be re-routed). > - IP / IPSP1 / IPSP2 (double encryption with IPSP) > note that an address may be available implicily to IPSP2 but not explicitly Is this double encryption at the same node? If so is this to be a feature of IPSP? If it is serial (my host and then a router encrypt the message), it must be undone serially (with IP processing between decryption steps) and the addresses must be known. > > Also, consider router-like scenarios where a device decrypts traffic for > multiple addresses. Traffic between pairs of router-like devices could be > protected with a single SAID, even though there might be several visible > "black" addresses. This may be the crux of my problem. Do you envision router-based encryptors putting the addresses of the true recipients on the "black" side (unencrypted), or do the "black" addresses simply indicate the source and destination encryptors? I expect that when doing encapsulation at a router the true addresses are carried as part of the encapsulated data, and that the addresses used to transport IP datagrams through the unprotected network indicate the encryptor and the decryptor (which may be the true recipient or the router serving the recipient). If the router attempts to simply encrypt the data on the way out, without changing the addresses to map to the encryption service providers, several potential problems arise. First, how is fragementation dealt with, for a destination on a richly connected network, fragments may arrive through different (encrypting) routers. For decryption to be correctly performed the entire datagram must be reassembled, where is this done? Since the only destination address provided is the host, he will get all of the fragments and reassemble them, but how does he decrypt it? Second, Lets assume that the routers do MTU discovery, fragment before encryption, and encrypt as mentioned above (only addresses visible are true source and destination). How are the keys and SAIDs shared between all routers serving the destination? > > We should not limit the usage of IPSP by using specific IP fields outside of > the IPSP encapsulation. For our specific descussion on IVs, there are several > other viable options. My immediate reason for pursuing the IP address usage is to support the multicast work we are doing. With multicast users sharing a key, IV clashes may pose a problem, IP source addresses provide a clean way to divide up the IV space uniquely. Also, stealing the IP address should be less computationally intensive than CRCs or MD5 (though not padding or repeating the pattern). I agree that several different options exist, but this seemed to be as good a point as any to begin this discussion of network models. I've been a little troubled by the lack of coverage of the potential addressing issues. In the BLACKER, CANEWARE, and SDNS work a great deal of thought went into defining a model of encryptor addressing (single catenent vs dual catenet) which would actually work in the networks envisioned. > > > > The other option is that IPSP is associated with the transport layer, where > > several IP providers (addresses) may map to a particular transport provider. > > But this option is hard to accommodate at gateways. > > I do not know what you mean here and it seems of the topic of IVs for DES-CBC This does not have anything to do with IVs, but with addressing models. > Paul carl. From ipsec-request@ans.net Wed Dec 21 19:28:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31580 (5.65c/IDA-1.4.4 for ); Wed, 21 Dec 1994 15:40:30 -0500 Received: by interlock.ans.net id AA32287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 21 Dec 1994 15:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 21 Dec 1994 15:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 21 Dec 1994 15:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 21 Dec 1994 15:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 21 Dec 1994 15:32:46 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 21 Dec 1994 15:32:46 -0500 Date: 21 Dec 94 13:28:00 -0600 To: cfm@columbia.sparta.com Cc: ipsec@ans.net Subject: Re[2]: Networking Model for Crypto-services [was] Re[2]: Ad Message-Id: Carl, >This is true, the IP addresses are not true end-to-end, but they are >end-to-end between the cooperating IPSP entities. What if an IPSP encapsulated packet is originated from a system that is not running IP? This is not in the scope of our IETF specification, but has been proposed in other forums (ISO 11577 over IEEE 802.3). In the IETF environment we have a cleaner networking model, but once again we should not limit the application of IPSP by the selection of a an IV mechanism that requires a specific layering of protocols. >> >> Also, consider router-like scenarios where a device decrypts traffic for >> multiple addresses. Traffic between pairs of router-like devices could be >> protected with a single SAID, even though there might be several visible >> "black" addresses. > >This may be the crux of my problem. Do you envision router-based encryptors >putting the addresses of the true recipients on the "black" side >(unencrypted), or do the "black" addresses simply indicate the source and >destination encryptors? I expect that when doing encapsulation at a router >the true addresses are carried as part of the encapsulated data, and that the >addresses used to transport IP datagrams through the unprotected network >indicate the encryptor and the decryptor (which may be the true recipient >or the router serving the recipient). > >If the router attempts to simply encrypt the data on the way out, without >changing the addresses to map to the encryption service providers, several >potential problems arise. First, how is fragementation dealt with, for a >destination on a richly connected network, fragments may arrive through >different (encrypting) routers. For decryption to be correctly performed the >entire datagram must be reassembled, where is this done? Since the only >destination address provided is the host, he will get all of the fragments >and reassemble them, but how does he decrypt it? Second, Lets assume that the >routers do MTU discovery, fragment before encryption, and encrypt as >mentioned above (only addresses visible are true source and destination). How >are the keys and SAIDs shared between all routers serving the destination? The mapping of "Red" to "Black" addresses is an interesting issue. There are many mapping combinations, and most can and have been made to work. In the IPSP specification we should provide a recommendation on this topic. The simplest approach is to set the Black addresses equal to the decrypting peer entity address and the source Black address to the source encrypting entities address. This is the best approach for preliminary releases of IPSP. All of the issues that you raise above on "transparent" address mapping are legitimate, but have been solved before. I only wanted to illustrate examples of many-to-one mappings of IP addresses to SAID. I am not advocating this approach for our baseline IPSP. >> >> We should not limit the usage of IPSP by using specific IP fields outside of >> the IPSP encapsulation. For our specific discussion on IVs, there are several >> other viable options. > >My immediate reason for pursuing the IP address usage is to support the >multicast work we are doing. With multicast users sharing a key, IV >clashes may pose a problem, IP source addresses provide a clean way to >divide up the IV space uniquely. Also, stealing the IP address should be less >computationally intensive than CRCs or MD5 (though not padding or repeating >the pattern). Please provide a better explanation of IV clash. This sounds like an algorithm specific issue. We have been discussing the DES-CBC-MD5 usage of a shortened IV. Does DES-CBC-MD5 have a IV clash problem with multicast traffic? >I agree that several different options exist, but this seemed to be as good a >point as any to begin this discussion of network models. I've been a little >troubled by the lack of coverage of the potential addressing issues. In the >BLACKER, CANEWARE, and SDNS work a great deal of thought went into defining a >model of encryptor addressing (single catenent vs dual catenet) which would >actually work in the networks envisioned. Single versus dual catenet is early eighties terminology that does not adequately capture all of the possible addressing approaches. Currently, the IPSP work is tending towards a "dual IP" model with peer encryptor addressing (IP / IPSP / IP). Note that the IPSP model is cleaner than the SDNS model (IP/SP3-D) which had SP3-D define a field that contained a complete IP header. The most significant change from SP3 to IPSP is the addition of a next protocol field in IPSP! SP3 required a interoperability mode that only carried "red" addresses (SP3-I) and a no address mode (SP3-N). IPSP uses the next protocol field to encapsulate or tunnel a "red" IP packet (like SP3-D) or directly carry transport data (like SP3-N). Back to addressing, I propose that we decouple the lower layer IP address from the processing of the IPSP encapsulation. If we do this, any of the addressing models can be made to work. Paul From ipsec-request@ans.net Wed Dec 21 21:08:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23977 (5.65c/IDA-1.4.4 for ); Wed, 21 Dec 1994 16:14:51 -0500 Received: by interlock.ans.net id AA09640 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 21 Dec 1994 16:09:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 21 Dec 1994 16:09:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 21 Dec 1994 16:09:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 21 Dec 1994 16:09:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 21 Dec 1994 16:09:52 -0500 Message-Id: <9412212109.AA12645@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[2]: Networking Model for Crypto-services [was] Re[2]: Ad In-Reply-To: Your message of "21 Dec 1994 13:28:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Dec 1994 16:08:59 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > What if an IPSP encapsulated packet is originated from a system that > is not running IP? This is not in the scope of our IETF > specification, Solving the problem for the internet is a hard enough problem, in my opinion. We should be concentrating on that. > The mapping of "Red" to "Black" addresses is an interesting issue. Not the least of which because ordinary TCP/IP applications work poorly in conditions in which addresses are mapped. Application level firewalls have to take considerable pains to conceal this mapping -- I doubt that we can solve such a problem here. > There are many mapping combinations, and most can and have been made > to work. In the IPSP specification we should provide a > recommendation on this topic. Given the complexity of this problem -- how would you get FTP to work in such an environment? -- I suggest that we swiftly beat a retreat from the question of address mapping. > Back to addressing, I propose that we decouple the lower layer IP > address from the processing of the IPSP encapsulation. If we do > this, any of the addressing models can be made to work. Would this mean that endpoints would have to process SAIDs without any notion of what host a given IPSP packet came from? This would be a new twist on the proposal as made thus far. Perry From ipsec-request@ans.net Wed Dec 21 23:23:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14553 (5.65c/IDA-1.4.4 for ); Wed, 21 Dec 1994 19:35:59 -0500 Received: by interlock.ans.net id AA15382 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 21 Dec 1994 19:28:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 21 Dec 1994 19:28:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 21 Dec 1994 19:28:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 21 Dec 1994 19:28:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 21 Dec 1994 19:28:47 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 21 Dec 1994 19:28:47 -0500 Date: 21 Dec 94 17:23:00 -0600 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: Networking Model for Crypto-services [was] Re[2]: Message-Id: Perry, >Paul_Lambert-P15452@email.mot.com says: >> What if an IPSP encapsulated packet is originated from a system that >> is not running IP? This is not in the scope of our IETF >> specification, > >Solving the problem for the internet is a hard enough problem, in my >opinion. We should be concentrating on that. I agree totally. >> The mapping of "Red" to "Black" addresses is an interesting issue. > >Not the least of which because ordinary TCP/IP applications work >poorly in conditions in which addresses are mapped. Application level >firewalls have to take considerable pains to conceal this mapping -- I >doubt that we can solve such a problem here. > >> There are many mapping combinations, and most can and have been made >> to work. In the IPSP specification we should provide a >> recommendation on this topic. > >Given the complexity of this problem -- how would you get FTP to work >in such an environment? -- I suggest that we swiftly beat a retreat >from the question of address mapping. Yes, let's retreat for now. >> Back to addressing, I propose that we decouple the lower layer IP >> address from the processing of the IPSP encapsulation. If we do >> this, any of the addressing models can be made to work. > >Would this mean that endpoints would have to process SAIDs without any >notion of what host a given IPSP packet came from? This would be a new >twist on the proposal as made thus far. My proposal needs to be worded more precisely. I object to the use of lower layer protocol information in the cryptographic processing (like IV extension). This does not mean that an IPSP entity does not have knowledge of an incoming packets claimed origin. Paul From ipsec-request@ans.net Thu Dec 22 14:36:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16831 (5.65c/IDA-1.4.4 for ); Thu, 22 Dec 1994 10:10:28 -0500 Received: by interlock.ans.net id AA25411 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 22 Dec 1994 09:35:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 22 Dec 1994 09:35:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 22 Dec 1994 09:35:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 22 Dec 1994 09:35:44 -0500 Message-Id: <9412221436.AA00355@tardo.lkg.dec.com> To: ipsec@ans.net Subject: Unsubscribe Date: Thu, 22 Dec 94 09:36:21 -0500 From: tardo@tardo.lkg.dec.com X-Mts: smtp Unsubscribe, please. Thanks, Joe From ipsec-request@ans.net Thu Dec 22 20:27:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA32417 (5.65c/IDA-1.4.4 for ); Thu, 22 Dec 1994 16:43:29 -0500 Received: by interlock.ans.net id AA09593 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 22 Dec 1994 16:34:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 22 Dec 1994 16:34:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 22 Dec 1994 16:34:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 22 Dec 1994 16:34:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 22 Dec 1994 16:34:10 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 22 Dec 1994 16:34:10 -0500 Date: 22 Dec 94 14:27:00 -0600 To: """@ilbx.mot.com", Vaughn_Sasse-P26259@email.mot.com, ipsec@ans.net Cc: /DDV=ipsec#064#ans.net/DDT=RFC-822/O=SMTPGW/P=ILBE/A=MOT/C=US/@email.mot.com Subject: Re: Delivery Report from X.400 Message-Id: Excuse the double post if this note has already hit the list ... Paul _______________________________________________________________________________ /DDV=ipsec@ans.net/DDT=RFC-822/O=SMTPGW/P=ILBE/A=MOT/C=US/ ----------------------------------- Returned ----------------------------------- From: Lambert Paul P15452 at AZ-SECTEL Date: 12/22/1994 1:40:05PM Subject: draft ipsec attendance list cc: /DDV=ipsec@ans.net/DDT=RFC-822/O=SMTPGW/P=ILBE/A=MOT/C=US/ at #EMAIL -------------------------------------------------------------------------------- Many errors were introduced when the attendance list was typed in by my secretary. Please review the list below and let me know if we mangled your name or e-mail address. Paul -- draft attendance list - December 1994 -- Ran Atkinson atkinson@itd.nrl.navy.mil Werner Atmesher atmesher@di.epf7.ch Madelyn Badger Madelyn@hs.com Ward Bathrick ward@mls.hac.com Doug Bayer dbayer@microsoft.com Shaun Bharrat bharrat@dss.com Kym Blair kdblair@dockmaster.ncsc.mil Eric Blossom eb@comsec.com Uri Blumenthal uri@watson.ibm.com Ed Brencovich edb@dss.com Tip Brisco brisco@rutgers.edu David Carrel carrel@crisco.com Brett Chappell bchappe@relay.nswc.navy.mil Paul-Chen Cheng pau@watson.ibm.com Pau-Chan Cheng pau@watson.ibm.com Corwin corwin@asylum.sf.ca.us Hadmut Danisch danisch@isa.uka.de Whitfield Diffie whitfield.diffie@eng.sun.com Dale Drew ddrew@mci.net Steve Dussse Steve@rsa.com Donald Eastlake Dee@lkg.dec.com Greg Edwards edwardsg@lmsc.lockheed.com Mark Eichin eichin@cygnus.com David Ferenz Dferenz@shl.com Antonio Fernandez afa@bellcore.com Rich Fox kck@netcom.com Craig Fox craig@ftp.com Barbara Fraser byf@cert.org Jerome Freedman Jr. jfjre@mbunix.mitre.org Dan Frommer danf@radmail.rad.co.il Atsuchi Fujioko jun@sucaba.isl.ntt.jp Alexander Galitsky sasha@elivs.msk.su Maria Gallagher mgallagh@atlas.are.nasa.gov Juan A. Garay garay@watson.ibm.com Dale Geesey geeseyd@bah.com Jisoo Geiter geiter@mitre.org Rob Glenn glenn@snad.ncsl.nist.gov Dragan Grebaich dragan@bnr.ca Daniel T. Green degreen@relay.nswc.navy.mil Per-Olof Haeffner poh@fmu.se Neil Haller nmh@bellcore.com Dan Hanson hanson@afc4a.safb.af.mil Dewayne Hendricks dewayne@tetherless.com Marc Horowitz marc@cam.ov.com Russell Housley housley@spyrus.com Jim Hughes Hughes@network.com Dale Johnson dmj@mitre.org LaMont Jones lamont@hp.com Phil Karn Karn@qualcomm.com Charlie Kaufman charlieskaufman@iris.com Kevin Kim kkim@rch.mci.com Katsumi Kobayashi Klaus-Peter Kossabrowski kpk@cert.dfn.de Hugo Krawczyk hugo@watson.ibm.com Craig Labovitz labovit@merit.edu Paul Lambert Paul_Lambert@email.mot.com Ying-Da Lee ylee@syl.dl.nec.com Marcus Leech mleech@bnr.ca John Linn linn@ceng.ov.com John Lowry jlowry@bbn.com Betty Machmar machmar@hydra.dra.hug.gb Cheryl Madson cmadson@baynetworks.com Phil Maier Phil@lmsc.lockheed.com Louis Mamakos LOUIE@UUNET.UU.NET Shawn Mamras mamras@ftp.com Jeff Marcus marcus@jvnc.net Tom Markson markson@incog.com Antony Martin Martin@hydra.dra.hmg.gb Douglas Maughan wdmaugh@tycho.ncsc.mil Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Tod McQuillin devin@lm.com Perry Metzger perry@piermont.com Bob Moskowitz rgm3@is.chrysler.com Toni Murase murase@sumitomo.com Andrew Myles andrewm@mpce.mg.edu.ca Dan Nessett nessett@eng.sun.com Michael Oehler mjo@tycho.ncsc.mil Mark Oliver oli@hyperk.com Hilarie Orman ho@cs.arizona.edu Bill Owens owens@utd.rochester.edu Martin Patterson martinp@france.sun.com Charles Perkins perk@watson.ibm.com Bad Phan phan@itd.nrl.navy.mil Joseph Ramus Ramus@nersc.com Eric Rescorla ekr@eit.com Randy Rettberg rettberg@apple.com Carl Rigney cdr@livingston.com Aviel Rubin rubin@bellcore.com Vipin Samar vipin@eng.sun.com Mark Schertla MJS@tycho.ncsc.mil Allan M. Schiffman ams@eit.com Jeff Schiller jis@mit.edu John Scudder jgs@merit.edu Chris Seabrook cds@ossi.com Nachum Shacham shacham@csl.sri.com Bill Simpson BSimpson@morningstar.com Phil Smiley psmiley@lobby.ti.com Charles Smith chas@act.acu.oig.au David Solo solo@bbn.com Bill Sommerfield sommerfld@apollo.hp.com Don Stephenson dons@eng.sun.com Oscar Strohacker strog@vnet.ibm.com Kwang-Pill Sung scc@netcom.com Steve Sweeney Steven_Sweeney@3mail.3com.com Jagannadh S. Tangirala c1jaggu@watson.ibm.com John Taus taus@unet.ibm.com Ted Ts'o tytso@mit.edu Carolyn Turbyfmi turby@eng.sun.com Tony Valle tvalle@orlando.loral.com Paul Van Oorschot paulv@bnr.ca Dale Walters walters@snad.ncsl.nist.gov Howard Weiss llsw@columbia.sparta.com David Woodgate davidw@its.csiro.au Suguru Yamaguchi suguru@is.ais-nara.ac.jp Shin Yoshida yoshida@sumitomo.com Jim Zmuda zmuda@spyrus.com Glen Zorn gwz@cybersafe.com From ipsec-request@ans.net Thu Dec 22 21:13:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17752 (5.65c/IDA-1.4.4 for ); Thu, 22 Dec 1994 17:13:24 -0500 Received: by interlock.ans.net id AA26762 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 22 Dec 1994 17:10:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 22 Dec 1994 17:10:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 22 Dec 1994 17:10:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 22 Dec 1994 17:10:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 22 Dec 1994 17:10:30 -0500 From: Mariaccmail_Moctezuma-X10120C@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 22 Dec 1994 17:10:30 -0500 Date: 22 Dec 94 15:13:00 -0600 To: ipsec@ans.net Subject: Test Message Message-Id: This is a test for deliverability. Please disregard. Regards, Maria Moctezuma From ipsec-request@ans.net Fri Dec 23 19:44:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06479 (5.65c/IDA-1.4.4 for ); Fri, 23 Dec 1994 15:58:48 -0500 Received: by interlock.ans.net id AA45028 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 23 Dec 1994 15:53:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 23 Dec 1994 15:53:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 23 Dec 1994 15:53:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 23 Dec 1994 15:53:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 23 Dec 1994 15:53:16 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 23 Dec 1994 15:53:16 -0500 Date: 23 Dec 94 13:44:00 -0600 To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re[2]: IKMP Security Exchange Negotiation Message-Id: ---------------------------------- Forwarded ---------------------------------- From: Lambert Paul P15452 at AZ-SECTEL Date: 12/16/94 6:16PM To: ipsec@ans.net at #EMAIL cc: Lambert Paul P15452 Subject: Re[2]: IKMP Security Exchange Negotiation ------------------------------------------------------------------------------- Excuse the double posting if this has already hit the list. p.l. _______________________________________________________________________________ Subject: Re: IKMP Security Exchange Negotiation Author: Lambert Paul P15452 Date: 12/14/94 2:48 PM Here are a few ramblings about negotiation of different IKMP key establishment approaches. Paul ------------------- >ashar< >Like you said, it isn't free. If you dont want it, dont need it, >you shouldn't have to pay for it. > Paul, > > I pretty much agree with this....how do we get an IMKP protocol that > will let us do both? > > Jim Zmuda Jim, Use of a SAMP-like Security Exchange option negotiation might work. for example if we have Security Exchange Identifiers: A, B, C each with defined exchanges: A1, A2, A3, A4, A5, A6 B1, B2, B3, B4 C1, C2, C3, C4 The sequence of events (e.g. A1 to An) could correspond to a D-H exchange, a Photuris exchange (with cookies), or any other key establishment exchange. As an example you could send PDUs like: Note the arrows ( -> and <- indicate the flow of duplex traffic) Example 1 - Initiator declares that it can use A, B, or C security exchanges. Responder picks B. Exchange continues. -> (A,),(B,),(C,) <- (B,) -> (B,B1) <- (B,B2) -> (B,B3) ... etc. or Example 2 - Initiator declares A, or B and includes the first exchange info for both A and B. The responder replies with B and the second exchange step of B. Note that this saves two steps over example 1. -> (A,A1),(B,B1) <- (B,B2) ... etc. Example 3 - Initiator declares support for A, B, or C and includes the first exchange for A. Note that ordering could indicate initiator preference in the negotiation. This examples shows how the protocol can be optimized for a prefered approach, A, but still allow negotiation to another technique. -> (A,A1),(B,),(C,) <- (A,A2) -> (A,A3) -> (A,A4) ... etc. This negotiation approach would work quite well to support the various security requirements that the working group is pursuing. As another example, assume we have two Diffie-Hellman based exchanges: DH - a basic Diffie-Hellman approach KC - a Diffie-Hellman exchange with two extra exchanges to support cookie PDUs to reduce the impact of flooding attacks (Karn-Cookies). Example 4 - most systems might not want to use the extra PDUs to limit the flooding attacks. Most of the time the two extra cookie PDUs are not needed. -> (DH,DH1),(KC,) <- (DH,DH2) ... etc. Example 5 - The cookies are needed when a recipient feels threatened (purhaps it just recieved a bogus DH initiation). It is then very important to allow the recipient to request a cookie using a stateless response: -> (DH,DH1),(KC,) <- (KC,) -> (KC,KC1) <- (KC,KC2) ... etc. Example 6 - Example 6 adds two PDUs beyond the cookie exchange. This could be reduced if initiators always sent a cookie along with the more common DH (my assumption) exchange: -> (DH,DH1),(KC,KC1) <- (KC,KC2) ... etc. Example 6 may not be worth the extra exchange bits if example 5 is an uncommon scenario. From ipsec-request@ans.net Fri Dec 23 21:14:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24820 (5.65c/IDA-1.4.4 for ); Fri, 23 Dec 1994 16:16:51 -0500 Received: by interlock.ans.net id AA22981 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 23 Dec 1994 16:14:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 23 Dec 1994 16:14:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 23 Dec 1994 16:14:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 23 Dec 1994 16:14:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 23 Dec 1994 16:14:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 23 Dec 1994 16:14:06 -0500 Message-Id: <9412232114.AA19105@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com, ipsec@ans.net Subject: Re: Clogging attacks on SKIP In-Reply-To: Your message of "Thu, 15 Dec 1994 16:19:05 PST." <9412160019.AA05219@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Dec 1994 16:14:01 -0500 From: " " Hi Ashar and all, > I already have. What I was and am trying to say is that *in case* > explicit ACLs exist, these can help in precomputing master keys > (and many circumstances *will* have explicit ACLs). In cases > where this is not feasible, usage patterns and/or administrative > action can facilitate this. > > The *worst* that can happen is that, only in case of wildcard > ACLs, *unusual* access patterns *may* be denied service during > a clogging attack. This is what I was refering to. It appears a very reasonable case for a firewall which allows access to employees of large organization esp. if they are allowed to use DHCP. > This isn't all that bad, especially since > someone who desperately seeks service and is being denied, > can be asked to put on the priority list and regain access, > even if the clogging attack continues. (Note that administrators > would always be on the priority list, and would always be > able to take such action in a secure manner, even remotely). Of course such manual solutions would help (but even that should be noted in the spec!). Let me mention that if one really wants to, we _can_ give a complete solution to clogging in the non-interactive (SKIP) framework. Namely, require each request to be accompanied by MD5(IPaddresses, time, counter, x) where cnt is the counter of number of tries within the same `time' (which is roughly synchronized), and x is any number such that the last $l$ bits of the MD5 are zero. The sender has therefore to perform O(2^l) MD5 operations until finding a valid `ticket' - which should prevent him from clogging... My belief is that we can achieve almost all properties very similarly in the interactive and non-interactive cases and therefore we can have one tunable design which satisfies all of the goals in the exisiting proposals (inc non] interactivity as in SKIP although I still think this should be an option since it is less secure - see other note) > > Can the same be said of the master key update protocol in > your MKMP document? Of course this kind of solution could apply to that protocol. However since it appears that many people in the WG would like to have serious protection against clogging, I think this should be added to all proposals (not just denying service to all addresses when under attack). (I am still waiting for your response > on this issue and the other issue on saving sender resources.) I"m not sure what this is, but I'll be away for a while (and was too busy recently)... Best, Amir From ipsec-request@ans.net Fri Dec 23 21:47:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24724 (5.65c/IDA-1.4.4 for ); Fri, 23 Dec 1994 16:49:59 -0500 Received: by interlock.ans.net id AA07925 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 23 Dec 1994 16:47:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 23 Dec 1994 16:47:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 23 Dec 1994 16:47:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 23 Dec 1994 16:47:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 23 Dec 1994 16:47:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 23 Dec 1994 16:47:47 -0500 Message-Id: <9412232147.AA20692@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com, ipsec@ans.net Subject: Re: Proposal: Perfect forward (proactive) SECURITY a MUST In-Reply-To: Your message of "Thu, 15 Dec 1994 12:26:24 PST." <9412152026.AA02353@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Dec 1994 16:47:43 -0500 From: " " Ashar and all, > > > Again: I don't see this as black and white... It's a tradeoff. But, we must > > decide, and therefore I also state my position: the price is reasonable. > > Let's require perfect forward (proactive) security. > > I think I have already stated my position on this. Sorry but a clarification is still in place. I'm not talking about perfect forward secrecy. I"m talking about the ability to recover security after a break-in discovers your secret keys, which works when the attacker cannot completely control all communication. Namely, the security is based on a recovery mechanism such that the attacker has to break into several processors at the same time. I think these are good properties we want to support when the price is right. Now it's for the > rest of the group to voice their opinion (if they haven't already > done so). Agree! > > Now for a clarification. I didn't see a perfect forward secrecy > proposal in your MKMP document, other than one which was SKIP > based (in the appendix), i.e using SKIP to exchange ephemeral > DH values. (The master key update protocol in the body of the > MKMP document provides good as opposed to perfect forward > secrecy). Yes, this is what is proposed in the MKMP draft. But I think we can do better. > > As I have already confirmed offline with Hugo, this is the same > proposal that I made at the San Jose IETF, (and which I also > mentioned verbally at the Toronto IETF). So, is this the proposal > that you are advocating for perfect forward secrecy? If so, > we are at least coming closer to an agreement. Almost. However I think we can do better by authenticating the ephemeral DH using the keys from the _previous_instance_ of the ephemeral DH. One can either use just the previous shared ephemeral key or use the public exponents from previous time by computing shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1} Therefore in each round we authenticate the DH keys for next round. the result is that breaking req' breaking into both processors together and then an active attack (rather than just message injection as is possible in SKIP). Furthermore, processors can broadcast and compare the ephemeral DH public keys, making it even harder to cheat without being detected. This idea was developed in a new work with Ran Canetti which we would submit soon (maybe to Crypto). So my proposal is to have a protocol completely based on DH with a non-interactive and interactive modes (we can later decide if one of them is only optional). This protocol would have protection against clogging (even from unknown addresses and even non-interactive), anonymity if we desire (I'll explain how to do it non-interactively later - or ask Hugo), and proactive security at least in the interactive modes. > Also, as I mentioned in my IETF talk (and as your MKMP document also notes > in the appendix) it is possible to have perfect forward secrecy on top > of SKIP, without requiring a different crypto algorithm's (e.g RSA) > authenticated public keys. Sure!! Even proactive security (of course both forward secrecy and of course proactive req' interaction but we could have less secure non-interactive SKIP option) The authentic DH public keys may be obtained > either from secure DNS (per the Kaufman-Eastlake draft) or using > some certificate format distributed using a standard directory service. Or using PGP-like web of trust... I don't worry about this aspect so much. > > I should point out that this would have the lowest computational > overhead of any perfect forward secrecy scheme, (including, I believe, > the Yacobi scheme) and furthermore does not suffer from the > (admittedly theoretical) triangle attack (Burmeister, Crypto '94). I agree. > > If we can agree on these two modes, one session-less, simple and > efficient, and the other heavier-weight, more complex and session oriented, > then we will have essentially the equivalent of what already exists > in the Internet for transport protocols, namely UDP and TCP. Completely agree. That's what we should do. The interactive protocol is also tunable (freq of updates) > > We can then argue over which one should be required and which > one should be optional. Can we at least agree on this? Exactly what I want us to do. And it can achieve all goals of all existing proposals. > > Or do you have another perfect forward secrecy proposal that you > would like to support? See above, my proposal is a slight modification in using `chained DH' - this provides even better security. > > This is related because perfect forward secrecy is only important > if you have secrecy! > > Authentication-only with perfect-forward secrecy is an oxymoron. > > > Ashar, you got it upside down. First, this feature is great for authentication, > > not just secrecy. > > What are you talking about? Perfect forward secrecy is great > for authentication? How can forward secrecy make sense, when > there is no secrecy to begin with? NOt secrecy - SECUIRTY!! have to run, happy new year, Amir > > (I will address Hugo's concerns later, which are related to key > compromise and dont really fall in the category of perfect forward > secrecy, as the way the term is used in the literature, and by the > person who invented it). > > > Agreed. However I don't think the overhead of a rarely-invoked protocol is so > > significant. Compare this to SKIP, where you essentially suggest that the > > public keys would be changed by some off-line operation. > > I am afraid you lost me here. What are you referring to? I suggested > offline computation of ephemeral DH keys, wrt the perfect forward > secrecy-on-SKIP proposal. When did I refer to changing SKIP public > keys offline? > > > I understand and respect your position. I'm happy to observe that we both > > want both modes, one to be the default and the other as option. We just have > > different preferences to which is default. > > I also respect your work and position, and hope our disagreements will not > prevent continued joint work in helping define/discuss the requirements/details > of the key-management scheme that will ultimately be deployed. > > Best regards, peace and goodwill, > Ashar. From ipsec-request@ans.net Fri Dec 23 21:50:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14165 (5.65c/IDA-1.4.4 for ); Sat, 24 Dec 1994 06:52:31 -0500 Received: by interlock.ans.net id AA27617 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 24 Dec 1994 06:50:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 24 Dec 1994 06:50:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 24 Dec 1994 06:50:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 24 Dec 1994 06:50:13 -0500 Date: Sat, 24 Dec 94 04:50:05 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9412241150.AA07987@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: ipsec@ans.net Subject: Re: Re[2]: IKMP Security Exchange Negotiation Paul Lambert wrote: (Is that "P15452" a cookie to prevent flooding by junk mail?) > Example 5 - The cookies are needed when a recipient feels threatened (purhaps > it just recieved a bogus DH initiation). It is then very important to allow > the recipient to request a cookie using a stateless response: > -> (DH,DH1),(KC,) > <- (KC,) > -> (KC,KC1) > <- (KC,KC2) > ... etc. Please note that the initial setup message in Karn Cookies is stateless, i.e. the "KC1" sent from intiator is 0 bits long. (Well, okay, it's the IP address which is of non-zero size, but it's always included so you can send the reply, so the size attributable to the protocol is 0.) I was thinking of this for Photuris, although your technique is more general. So the second message would be KC2 (the cookie). The KC exchange is a bit odd, because it's to be used in *addition* to another protocol. I.e. you then go on to send (DH,DH1),KC2. Also note that a host that is making multiple connections can cache and re-use KC2 cookies. But if the cookie gets captured in some not-quite-on-line attack, the recipient could change it without notification, so the initiator sends (KC,KC2) and the recipient says "sorry, bad cookie, here's KC2'". It's basically as if the recipient rebooted, but connections to it may still be established. > Example 6 - Example 6 adds two PDUs beyond the cookie exchange. This could be > reduced if initiators always sent a cookie along with the more common DH (my > assumption) exchange: > -> (DH,DH1),(KC,KC1) > <- (KC,KC2) > ... etc. > > > Example 6 may not be worth the extra exchange bits if example 5 is an > uncommon scenario. It does depend. If I call KC1 the "believed cookie" (what the initiator hash cached, possibly all zero or something from a previous boot of the recipient) and KC2 the "true cookie" (computed from the recipient's secret), then the following options seem plausible. KC1 is a correct cookie (equal to KC2), while KC1' is an incorrect one. -> (DH,DH1),(KC,KC1) cookie correct <- (DH,DH2) ...etc. -> (DH,DH1),(KC,KC1') cookie incorrect, host doesn't care <- (DH,DH2) ...etc. or -> (DH,DH1),(KC,KC1') cookie incorrect, host doesn't care *now* <- (DH,DH2),(KC,KC2) just for future reference... ...etc. or -> (DH,DH1),(KC,KC1') cookie incorrect, responding host feels threatened <- (KC,KC2) -> (DH,DH1),(KC,KC1) <- (DH,DH2) ...etc. If you can optionally send a zero-length cookie, then KC1' is very little overhead when the recipient doesn't care and doesn't send a response. (Case 2, above). Also, the recipient could decide to stop feeling threatened after a while and start responding to initiations including a cookie by following case 3, and sending a zero-length KC2 response. This offers a saving of KC1' overhead, against the risk of having to revert to case 4 if it feels threatened again in future. So presumably it should be pretty sure of its safety before trading a few bits in a maessage for the risk of teo more messages and a round trip delay. -- -Colin From ipsec-request@ans.net Sat Dec 24 17:41:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14818 (5.65c/IDA-1.4.4 for ); Sat, 24 Dec 1994 13:49:33 -0500 Received: by interlock.ans.net id AA27394 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 24 Dec 1994 13:45:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Sat, 24 Dec 1994 13:45:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 24 Dec 1994 13:45:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 24 Dec 1994 13:45:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 24 Dec 1994 13:45:25 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 24 Dec 1994 13:45:25 -0500 Date: 24 Dec 94 11:41:00 -0600 To: colin@nyx10.cs.du.edu Cc: ipsec@ans.net Subject: Re[4]: IKMP Security Exchange Negotiation Message-Id: Colin, Thanks for the comments. >X-Disclaimer: Nyx is a public access Unix system run by the University > of Denver. The University has neither control over nor > responsibility for the opinions or correct identity of users. > >Paul Lambert wrote: >(Is that "P15452" a cookie to prevent flooding by junk mail?) I wish, it is more like corporate castor oil that is added by our X.400 gateway ... > >> Example 5 - The cookies are needed when a recipient feels threatened (purhaps >> it just recieved a bogus DH initiation). It is then very important to allow >> the recipient to request a cookie using a stateless response: >> -> (DH,DH1),(KC,) >> <- (KC,) >> -> (KC,KC1) >> <- (KC,KC2) >> ... etc. > >Please note that the initial setup message in Karn Cookies is stateless, >i.e. the "KC1" sent from intiator is 0 bits long. (Well, okay, it's the >IP address which is of non-zero size, but it's always included so you >can send the reply, so the size attributable to the protocol is 0.) >I was thinking of this for Photuris, although your technique is more general. >So the second message would be KC2 (the cookie). I had abstracted the exchanges and ignored the details of the Karn Cookies. >The KC exchange is a bit odd, because it's to be used in *addition* to >another protocol. I.e. you then go on to send (DH,DH1),KC2. I had assumed a bundling approach where the KC included a Diffie-Hellman or similar key establishment. For this example I really should have referenced Photuris and documented a PH exchange. I had not considered treating the KC or similar flooding prevent mechanisms separate from the key establishment. Previously, I have viewed the main protocol exchange as two steps: key establishment and attribute negotiation. It looks like a thrid optional cookie step could be added. Cookies could be built into a key exchange, or intergrated into the IKMP as separate processing. Regards, Paul From ipsec-request@ans.net Sat Dec 24 19:07:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19829 (5.65c/IDA-1.4.4 for ); Sat, 24 Dec 1994 15:17:12 -0500 Received: by interlock.ans.net id AA27625 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 24 Dec 1994 15:15:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Sat, 24 Dec 1994 15:15:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 24 Dec 1994 15:15:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 24 Dec 1994 15:15:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 24 Dec 1994 15:15:07 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 24 Dec 1994 15:15:07 -0500 Date: 24 Dec 94 13:07:00 -0600 To: minutes@cnri.reston.va.us, ipsec@ans.net Subject: IPSEC Minutes - December 1994 Message-Id: CURRENT MEETING REPORT Reported by Paul Lambert/Motorola Minutes of the IP Security Working Group (IPSEC) The IP Security (IPSEC) working group met three times during the 31st IETF. The first meeting focused on the development of the IP Security Protocol (IPSP) specification. The next two sessions covered the development of the Internet Key Management Protocol (IKMP). IP Security Protocol (IPSP) The IPSP draft-in-progress was discussed with some debate on specific PDU format issues. Rough consensus was reached on the encapsulation techniques and formats. The baseline security transformations for IPSP will place the Next Protocol, PAD Length, and optional PAD fields at the end of the protected data. These formats will be documented and released late in December as a draft IPSP specification. Jim Hughes (NSC) gave a short presentation on an implementation of a network layer security device. This system used an ethertype field rather than an IP next protocol field and provided sequence integrity and packet compression. Internet Key Management Protocol (IKMP) Seven presentations were given (Monday and Wednesday) on specific key management approaches and proposals. o SESAME V3 o "IEEE Standard 802.10C - Key Management" IEEE 802.10C o "Modular Key Management Protocol (MKMP)" (draft-cheng-modular-ikmp-00.txt) o "Simple Key-Management For Internet Protocols (SKIP)" (draft-ietf-ipsec-aziz-skip-00.txt) o "Photuris Key Management Protocol" (draft-karn-photuris-00.txt) o "Group Key Management Protocol (GKMP)" (draft-harney-gkmp-spec-00.txt, draft-harney-gkmp-arch-00.txt) o "Yet Another Key Management Proposal (YAKMP)" (http://www.network.com/external/news_releases/security.shtml) A presentation on SESAME V3 was given by Piers V McMahon (ICL Enterprises). SESAME V3 provides an approach for the interoperability of asymmetric and symmetric systems - in particular Kerberos and RSA. SESAME V3 KM protocol appears to have similar scope to the key management work in IEEE 802.10. This presentation was informational and no proposal was made to directly use SESAME V3 as IKMP. Russ Housley (Spyrus) gave a presentation on the IEEE 802.10C Key Management specification. The latest version of IEEE 802.10C is available on line (ftp from atlas.arc.nasa.gov in two files /pub/sils/kmpd6.ps1 and kmpd6.ps2) IEEE 802.10C uses the ISO Generic Upper Layer Security (GULS) specification, the OSI Upper Layer Architecture, and the ACSE protocol. Concern was expressed about the complexity of the GULS specification, but this concern was counteracted when Russ indicated that the specification would be rewritten in Internet style if the IETF adopted IEEE 802.10c. IEEE 802.10c was the most complete specification presented at the meeting. It provides a generic framework for key management, but does not currently provide a worked example of the cryptographic processing. The Modular Key Management Protocol (MKMP) was presented by Amir Herzberg (IBM). MKMP has been documented as an I-D (draft-cheng-modular-ikmp-00.txt) as a specific proposal for IKMP. MKMP proposes a modular approach with an upper module in which a long-lived (``master'') key is exchanged between the communicating parties, and a lower module, in which the already shared (master) key is used for the derivation, sharing and/or refreshment of additional short-lived keys to be used for the cryptographic transformations applied to the data. Some of the techniques in this proposal are covered by IBM patents. IBM is working to grant "royalty-free right" to use of US Patent #5,148,479 "if the IBM proposal is included in the final Internet standard" and "parties who commit to grant IBM rights of similar scope under their patents that relate to the Internet standard in question." Ashar Aziz (Sun Microsystems, Inc.) presented a "Simple Key-Management For Internet Protocols" (SKIP). SKIP is available as an Internet-Draft (draft- ietf-ipsec-aziz-skip-00.txt). SKIP was designed to solve a specific multicast scenario. The demonstration implementation of SKIP was running a video application. SKIP provides a means to create a key with a unique "one- way" key establishment. SKIP does not provide any attribute negotiation. A patent has been applied for by SUN on the SKIP mechanism, but SUN has taken a position that: "The SKIP patents (when they issue) will be placed in the public domain. Anyone may use it if they wish, with no rights or dues pertaining to Sun. There will be no need to license SKIP patent rights." Phil Karn (Qualcomm) presented "Photuris and IKMP Requirements". Photuris is an experimental protocol that Photuris is an experimental key management protocol intended for use with the IP Security Protocol (IPSP) in a point-to- point mode. Photuris combines Diffie-Hellman key exchange with RSA authentication to provide perfect forward secrecy and is also designed to thwart certain types of active denial of service attacks on host resources. Photuris exchanges a "cookie" before initiating public-key operations, thwarting the saboteur from flooding the recipient using random IP source addresses. Photuris also provides anonymity for the identities of the peer systems. The flooding prevention and anonymity requirements were well received by the working group. The "Group Key Management Protocol" (GKMP) was described by Carl Muckenhirn. GKMP is being submitted to the Working Group for consideration as a method of key management for multicast internet services and is documented in two Internet-Drafts (draft-harney-gkmp-spec-00.txt, draft-harney-gkmp-arch- 00.txt). The GKMP architecture describes the management of cryptographic keys for multicast communications. GKMP provides the ability to create and distribute keys within arbitrary-sized groups without the intervention of a global/centralized key manager. The GKMP combines techniques developed for creation of pairwise keys with techniques used to distribute keys from a KDC (i.e., symmetric encryption of keys) to distribute symmetric key to a group of hosts. Jim Hughes (Network Systems Corporation) gave a presentation on "Yet Another Key Management Proposal". The signaling used by NSC in their secure router product was described. The device uses RSA for authentication, Diffie- Hellman for key exchange, a number of symmetric ciphers, MD5 for data integrity and also provides data compression. NSC provided detailed descriptions of their design and stated that they intend to follow the recommendations and implement the results of the IPSEC working group. (http://www.network.com/external/news_releases/security.shtml) IKMP Discussion and Issues A group discussion on the various proposals focused on a matrix of comparison criteria. These criteria included: Published Internet-Draft, Key Exchange Independence, Worked Public Key Based Key Exchange, Public Key Methods, Symmetric Key Methods, Attribute Negotiations (for SA, and during which phase?), Application Protocol (not Built into IPSP), Multicast Support, Defeat Bogus Initiates, Hiding Certificates Exchanged (Encrypting), Working Code / Implementation, Security Management Protocol (versus just session key establishment), one-way exchange, perfect forward secrecy, RSAREF implementable, performance, and revocation. Evaluation of the proposal features will be discussed on the net by evaluating and ranking IKMP requirements. The work on IKMP will focus over the next period on the comparison and consolidation of the proposals. Attendees of December 1994 IPSEC Working Group Meetings Ran Atkinson atkinson@itd.nrl.navy.mil Werner Atmesher atmesher@di.epf7.ch Madelyn Badger Madelyn@hs.com Ward Bathrick ward@mls.hac.com Doug Bayer dbayer@microsoft.com Shaun Bharrat bharrat@dss.com Kym Blair kdblair@dockmaster.ncsc.mil Eric Blossom eb@comsec.com Uri Blumenthal uri@watson.ibm.com Ed Brencovich edb@dss.com Tip Brisco brisco@rutgers.edu David Carrel carrel@crisco.com Brett Chappell bchappe@relay.nswc.navy.mil Pau-Chan Cheng pau@watson.ibm.com Corwin corwin@asylum.sf.ca.us Hadmut Danisch danisch@isa.uka.de Whitfield Diffie whitfield.diffie@eng.sun.com Dale Drew ddrew@mci.net Steve Dussse Steve@rsa.com Donald Eastlake Dee@lkg.dec.com Greg Edwards edwardsg@lmsc.lockheed.com Mark Eichin eichin@cygnus.com David Ferenz Dferenz@shl.com Antonio Fernandez afa@bellcore.com Rich Fox kck@netcom.com Craig Fox craig@ftp.com Barbara Fraser byf@cert.org Jerome Freedman Jr. jfjr@mbunix.mitre.org Dan Frommer danf@radmail.rad.co.il Atsuchi Fujioko jun@sucaba.isl.ntt.jp Alexander Galitsky sasha@elivs.msk.su Maria Gallagher mgallagh@atlas.are.nasa.gov Juan A. Garay garay@watson.ibm.com Dale Geesey geeseyd@bah.com Jisoo Geiter geiter@mitre.org Rob Glenn glenn@snad.ncsl.nist.gov Dragan Grebaich dragan@bnr.ca Daniel T. Green dtgreen@relay.nswc.navy.mil Per-Olof Haeffner poh@fmu.se Neil Haller nmh@bellcore.com Dan Hanson hanson@afc4a.safb.af.mil Dewayne Hendricks dewayne@tetherless.com Amir Herzberg amir@watson.ibm.com Marc Horowitz marc@cam.ov.com Russell Housley housley@spyrus.com Jim Hughes Hughes@network.com Dale Johnson dmj@mitre.org LaMont Jones lamont@hp.com Phil Karn Karn@qualcomm.com Charlie Kaufman charlieskaufman@iris.com Kevin Kim kkim@rch.mci.com Katsumi Kobayashi Klaus-Peter Kossabrowski kpk@cert.dfn.de Hugo Krawczyk hugo@watson.ibm.com Craig Labovitz labovit@merit.edu Paul Lambert Paul_Lambert@email.mot.com Ying-Da Lee ylee@syl.dl.nec.com Marcus Leech mleech@bnr.ca John Linn linn@ceng.ov.com John Lowry jlowry@bbn.com Betty Machmar machmar@hydra.dra.hug.gb Cheryl Madson cmadson@baynetworks.com Phil Maier Phil@lmsc.lockheed.com Louis Mamakos LOUIE@UUNET.UU.NET Shawn Mamras mamras@ftp.com Jeff Marcus marcus@jvnc.net Tom Markson markson@incog.com Antony Martin Martin@hydra.dra.hmg.gb Douglas Maughan wdmaugh@tycho.ncsc.mil Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Tod McQuillin devin@lm.com Perry Metzger perry@piermont.com Bob Moskowitz rgm3@is.chrysler.com Toni Murase murase@sumitomo.com Andrew Myles andrewm@mpce.mg.edu.ca Dan Nessett nessett@eng.sun.com Michael Oehler mjo@tycho.ncsc.mil Mark Oliver oli@hyperk.com Hilarie Orman ho@cs.arizona.edu Bill Owens owens@utd.rochester.edu Martin Patterson martinp@france.sun.com Charles Perkins perk@watson.ibm.com Bad Phan phan@itd.nrl.navy.mil Joseph Ramus Ramus@nersc.com Eric Rescorla ekr@eit.com Randy Rettberg rettberg@apple.com Carl Rigney cdr@livingston.com Aviel Rubin rubin@bellcore.com Vipin Samar vipin@eng.sun.com Mark Schertler MJS@tycho.ncsc.mil Allan M. Schiffman ams@eit.com Jeff Schiller jis@mit.edu John Scudder jgs@merit.edu Chris Seabrook cds@ossi.com Nachum Shacham shacham@csl.sri.com Bill Simpson BSimpson@morningstar.com Phil Smiley psmiley@lobby.ti.com Charles Smith chas@act.acu.oig.au David Solo solo@bbn.com Bill Sommerfield sommerfld@apollo.hp.com Don Stephenson dons@eng.sun.com Oscar Strohacker strog@vnet.ibm.com Kwang-Pill Sung scc@netcom.com Steve Sweeney Steven_Sweeney@3mail.3com.com Jagannadh S. Tangirala c1jaggu@watson.ibm.com John Taus taus@unet.ibm.com Ted Ts'o tytso@mit.edu Carolyn Turbyfmi turby@eng.sun.com Tony Valle tvalle@orlando.loral.com Paul Van Oorschot paulv@bnr.ca Dale Walters walters@snad.ncsl.nist.gov Howard Weiss hsw@columbia.sparta.com David Woodgate davidw@its.csiro.au Suguru Yamaguchi suguru@is.ais-nara.ac.jp Shin Yoshida yoshida@sumitomo.com Jim Zmuda zmuda@spyrus.com Glen Zorn gwz@cybersafe.com