Received: from relay.hq.tis.com by neptune.TIS.COM id aa02898; 2 Sep 96 5:03 EDT Received: by relay.hq.tis.com; id FAA14957; Mon, 2 Sep 1996 05:06:20 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014955; Mon, 2 Sep 96 05:05:51 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14807; Mon, 2 Sep 96 05:05:07 EDT Received: by relay.hq.tis.com; id FAA14950; Mon, 2 Sep 1996 05:05:50 -0400 Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1) id xma014940; Mon, 2 Sep 96 05:05:20 -0400 Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id EAA17443 for ipsec@TIS.COM; Mon, 2 Sep 1996 04:17:50 -0400 Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id MAA20029 for ipsec@TIS.COM; Mon, 2 Sep 1996 12:54:47 +0500 Message-Id: <199609020754.MAA20029@sdnpk.undp.org> Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 0980 for ipsec@TIS.COM; Sun, 1 Sep 1996 18:27:53 PST +0500 From: Ashar Aziz To: rgm3@chrysler.com Date: Sun, 1 Sep 1996 18:27:51 +0000 Subject: Re: Will the real PFS please stand up? Cc: ipsec@TIS.COM X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Date: Thu, 29 Aug 1996 07:02:25 -0400 > To: Bill Sommerfeld , > Does this mean that an escrowing of J can yield j? And thus escrowing is > effective against SKIP PFS? If so, this is unexceptable. PFS must be > immune to key escrowing. No, escrowing of the long-term SKIP keys does not permit wire-tapping exchanges protected by SKIP PFS. I assume that this was your question? (I am a little lost by your use of J and j, since J in SKIP is identity, not a key, and therefore would not be the information that would be escrowed). > > For those that are looking for NSA boogiemen everywhere, look carefully at > this :) Last time I checked, I didn't work for the NSA ;-) Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa02921; 2 Sep 96 5:06 EDT Received: by relay.hq.tis.com; id FAA14971; Mon, 2 Sep 1996 05:09:20 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014967; Mon, 2 Sep 96 05:08:51 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14835; Mon, 2 Sep 96 05:08:07 EDT Received: by relay.hq.tis.com; id FAA14964; Mon, 2 Sep 1996 05:08:50 -0400 Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1) id xma014962; Mon, 2 Sep 96 05:08:47 -0400 Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id EAA17447 for ipsec@TIS.COM; Mon, 2 Sep 1996 04:17:51 -0400 Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id MAA20055 for ipsec@TIS.COM; Mon, 2 Sep 1996 12:54:53 +0500 Message-Id: <199609020754.MAA20055@sdnpk.undp.org> Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 2270 for ipsec@TIS.COM; Mon, 2 Sep 1996 12:45:49 PST +0500 From: Ashar Aziz To: ipsec@TIS.COM Date: Mon, 2 Sep 1996 12:45:47 +0000 Subject: Re: no SKIP/ISAKMP/OAKLEY resolution X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Hilarie Orman > The design group attempting to combine SKIP/OAKLEY/ISAKMP into one protocol > has been unable to resolve deeply held technical differences of opinion. > Some progress was made initially, but there has been no change in several > weeks now, so I must report failure, with great disappointment. > > In my opinion, this was a group effort and a group failure --- I > exhort the greater working group to find quick agreement on goals > and an acceptable solution. I too would like to express my deep disappointment with this outcome. Initially, we had hopes of finding a common basis for moving forward. However, we discovered soon afterwards that there were differences of opinion that we simply could not overcome. I understand that this has also disappointed many people in this WG. As a member of this design team, I am more than willing to share the responsibility for this combined failure. I believe that we all tried our best, but at the end of the day, this wasn't enough to achieve success. I join Hilarie in urging the larger WG to quickly come to consensus on the best way to proceed forward, given this unfortunate outcome. Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa03125; 2 Sep 96 5:18 EDT Received: by relay.hq.tis.com; id FAA15066; Mon, 2 Sep 1996 05:21:50 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015064; Mon, 2 Sep 96 05:21:30 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14971; Mon, 2 Sep 96 05:20:38 EDT Received: by relay.hq.tis.com; id FAA15058; Mon, 2 Sep 1996 05:21:20 -0400 Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1) id xma015054; Mon, 2 Sep 96 05:20:55 -0400 Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id EAA17442 for ipsec@TIS.COM; Mon, 2 Sep 1996 04:17:49 -0400 Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id MAA20013 for ipsec@TIS.COM; Mon, 2 Sep 1996 12:54:42 +0500 Message-Id: <199609020754.MAA20013@sdnpk.undp.org> Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 3227 for ipsec@TIS.COM; Sun, 1 Sep 1996 18:12:10 PST +0500 From: Ashar Aziz To: sommerfeld@apollo.hp.com Date: Sun, 1 Sep 1996 18:12:07 +0000 Subject: Re: Will the real PFS please stand up? Cc: ipsec@TIS.COM X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-approval@neptune.tis.com Precedence: bulk > To: "David M. Balenson" > Cc: ipsec@TIS.COM > Subject: Re: Will the real PFS please stand up? > Date: Wed, 28 Aug 1996 16:29:23 -0400 > From: Bill Sommerfeld > On a related note, the skip-pfs draft does PFS in a different way from > how it's done in the other protocols. > > Now, I don't consider myself a cryptographer, but something in > skip-pfs struck me as somewhat unconventional... I don't believe that SKIP PFS is the only protocol proposed that has the property that you are discussing. I believe that a scheme proposed by Hugo (SKEME :) also has the same property with respect to identity protection, as I recall from his presentation. > > This is not the first time that I've raised this issue, but I don't > think it's been resolved.. I believe that I sent a response to the ipsec mailing list the last time this issue was raised. Perhaps this got lost somewhere? > > As I read the draft, skip-pfs does not provide PFS protection of the > identity certificates of the communicating parties. > > The exchange is: > > I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij > J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij > > (key: i,j: long term secrets of I and J > x,y: ephemeral secrets > [encryption] > {integrity protection}) > > The resulting traffic is protected using a key derived from g^xy, > which seems to be OK. > > What concerns me is the use of g^xj to protect the ephemeral > certificates; it appears to me as if subsequent compromise of j will > allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, > revealing the identities of everyone who has corresponded with j > during the period of interest. > > Now, if I and J are just host identities, this isn't interesting > (because the same information is found in their IP addresses) but if > SKIP gets extended to do per-user keying I think we have a potential > problem. I'll me repeat what I said about this the last time. SKIP PFS does not provide PFS for identities. It does provide PFS for traffic. The issue here is a tradeoff between susceptibility of identity disclosure due to an active (man-in-the-middle) attack, or susceptibility to identity disclosure due to long-term key compromise. SKIP PFS provides protection against identity disclosure from a man-in-the-middle attack. Schemes that provide PFS for identities do not typically have this property. This means that identities can be discovered by an active attack on the key-exchange. This appears to be the trade-off. You can either have protection of identities from an active attack without PFS for indentities; or you can have PFS for identities but susceptibility to identity disclosure from a man-in-the-middle attack. Like I said, if the WG is strongly in favor of one or the other, then SKIP PFS can be modified accordingly. However, the last time I asked this question, there was no response on the mailing list. Personally, I prefer to keep it the way it is, because providing PFS for identity information, at the expense of protecting identities from man-in-the-middle, is more complex than the current exchange. Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa10235; 2 Sep 96 17:42 EDT Received: by relay.hq.tis.com; id RAA20924; Mon, 2 Sep 1996 17:45:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020919; Mon, 2 Sep 96 17:44:59 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25998; Mon, 2 Sep 96 17:44:14 EDT Received: by relay.hq.tis.com; id RAA20913; Mon, 2 Sep 1996 17:44:57 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma020909; Mon, 2 Sep 96 17:44:32 -0400 Received: from raptor1.raptor.com by eagle1.raptor.com via smtpd (for relay.hq.tis.com [192.94.214.100]) with SMTP; 2 Sep 1996 21:46:52 UT Received: from Joe_Tardo.raptor.com (ip99.mountain-view.ca.interramp.com [38.10.127.99]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id RAA00156; Mon, 2 Sep 1996 17:46:08 -0400 (EDT) Message-Id: <2.2.32.19960902214622.00707d00@204.7.242.10> X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Sep 1996 14:46:22 -0700 To: Ashar Aziz From: Joe Tardo Subject: Re: no SKIP/ISAKMP/OAKLEY resolution Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:45 PM 9/2/96 +0000, Ashar Aziz wrote: >> From: Hilarie Orman >> The design group attempting to combine SKIP/OAKLEY/ISAKMP into one protocol >> has been unable to resolve deeply held technical differences of opinion. > >Initially, we had hopes of finding a common basis for moving >forward. However, we discovered soon afterwards that there >were differences of opinion that we simply could not overcome. It would be very helpful if these differences of opinion were documented someplace. Is anyone going to do this? Thanks, Joe = ========================================================= = Joe Tardo Voice: 415-843-0991 Raptor Systems, Inc. 777 San Antonio Ave. Suite 92 Fax: 617-487-6755 Palo Alto, CA. 94303 = ========================================================= = Date: Sun, 1 Sep 1996 17:07:56 -0400 From: Hilarie Orman Message-Id: <199609012107.RAA15389@earth.hpc.org> To: David_Wheeler-P26179@email.mot.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199608292023.NAA29362@baskerville.CS.Arizona.EDU> Subject: Re: Everything degenerates to Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk How far does the group want to go to achieve consensus? One can easily design a single protocol that meets all the proposed goals for key management. What seems impossible is convince people that this all MUST be implemented. For every option there is a contingent that opposes it, for every option there is a contingent that supports it, for every subset there is a group that thinks it is too much to implement. (heavy sigh). The shopping list is: sessions, in-line key encrypting keys sublist for second item above: separate hdr, extensions to ESP/AH hdrs key determination via PFS or non-PFS identity protection via PFS or non-PFS authentication via DH, RSA encryption, RSA signatures, or DSS (El Gamal hasn't yet been seriously considered) X.509v3 and DNS KEY/SIG records for PK authentication certificate inclusion, certificate retrieval elliptic curve groups new group definitions via protocol ISAKMP framework, other framework (I think that's all) Agree whole-heartedly on what you want, set a design team to work, good will follow. Hilarie Orman Date: Mon, 2 Sep 1996 18:20:42 -0400 From: Hilarie Orman Message-Id: <199609022220.SAA19077@earth.hpc.org> To: tardo@raptor.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609022204.PAA13732@baskerville.CS.Arizona.EDU> Subject: Re: no SKIP/ISAKMP/OAKLEY resolution Sender: ipsec-approval@neptune.tis.com Precedence: bulk > It would be very helpful if these differences of opinion were > documented someplace. Is anyone going to do this? It's not obvious that the differences would be helpful to others; in any event, the team felt comfortable working privately and there were no plans to publicize the details of a failure. There's been a great of public discussion already, and of course, more is coming, so there's hardly a void of information. I feel that the shopping list I posted earlier contains the relevant issues, everyone of which has been addressed by one or more proposed protocols. If the working group can decide on which ones are essential, which are optional, then a solution can be quickly found. Hilarie Orman Received: from relay.hq.tis.com by neptune.TIS.COM id aa17906; 3 Sep 96 5:58 EDT Received: by relay.hq.tis.com; id GAA25744; Tue, 3 Sep 1996 06:01:44 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma025742; Tue, 3 Sep 96 06:01:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06272; Tue, 3 Sep 96 06:00:30 EDT Received: by relay.hq.tis.com; id GAA25739; Tue, 3 Sep 1996 06:01:14 -0400 Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1) id xma025734; Tue, 3 Sep 96 06:00:56 -0400 Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id EAA27786 for ipsec@TIS.COM; Tue, 3 Sep 1996 04:49:27 -0400 Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id KAA18955 for ipsec@TIS.COM; Tue, 3 Sep 1996 10:50:06 +0500 Message-Id: <199609030550.KAA18955@sdnpk.undp.org> Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 6607 for ipsec@TIS.COM; Mon, 2 Sep 1996 17:22:08 PST +0500 From: Ashar Aziz To: perry@piermont.com Date: Mon, 2 Sep 1996 17:22:06 +0000 Subject: Re: Patents by Sun? Cc: ipsec@TIS.COM X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Reply-to: perry@piermont.com > Date: Fri, 30 Aug 1996 16:51:40 -0400 > From: "Perry E. Metzger" > Glenn Scott writes: > > >I must admit I haven't yet tracked this down to confirm it (it might > > >be a hoax) but it appears by the looks of it that Ashar has patented > > >IPSEC. Again, I have to track down an independent copy to confirm > > >it. If the claims listed are genuine, they are all on their face > > >invalidated by prior art, but... > > > > I actually have a copy of the whole patent and since I'm one of the > > inventors I can at least state what we did: It's a way to use fake addressing > > to do some tunneling and topology hiding. > > That isn't what the claims section I received (which I posted) says. > > > This patent does not attempt to patent IPSEC. Having been through this > > stuff before I caution any reader to judge a patent's defensibility or what > > invalidates it by just its abstract. > > The abstract isn't the important part. The claims are -- they are the > portion which is legally actionable. Were the claims posted the actual > ones, or was I sent an inaccurate set of claims? The claims there > appear to cover *any* IPSEC style mechanism. This is the set that I > have in my possession. > Perry, I have learned of the issue of this patent from the postings on this list. My recollection of this patent (the work was done a few years ago, and isn't fresh in my mind) is that it isn't a patent on a generic IPSEC mechanism. Rather, this was related to the specific use of key-management and encryption on devices that were not IP addressable, yet intercepted IP traffic (hence the "signatureless" title, and the use of the bridge terminology). This related to a product that we were designing (SunScreen) which had the cloaking (or "stealth") feature, such that it was not IP addressable, for security reasons. I believe the techniques we were designing involved identifying tunnel end-points such that the actual encryption/decryption end-points (outer IP header) were not meaningful from an IP connectivity point of view, yet IP routing still worked, and the internal topology of networks protected by these devices remained hidden. I believe that this is essentially what Glenn said. Now, I don't have a copy of either the issued patent or the patent application (and since I am in a remote office, don't have easy access to these documents), but I have requested a copy be mailed to me. I will review the claims section, and send a follow-up message, if anything changes my recollection of this patent. (This may take a week or so.) Ashar. Message-Id: <3.0b11.32.19960902195918.0069e610@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Mon, 02 Sep 1996 20:04:47 -0400 To: Hilarie Orman From: Steve Crocker Subject: Re: Everything degenerates to Key Management Cc: David_Wheeler-P26179@email.mot.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk For what it's worth, here's my opinion: This is a vital area for the net. We should have had encryption at the IP level many years ago, and it remains vital. We should partition the features and implement a minimum set NOW and work on additional stuff later. In my opinion, the following is essential, urgent, sufficient for a number of vital purposes and does not inhibit future work: o Encryption algorithms which are not easily breakable. DES will do for now. o Key management: Anything which makes it possible for parties who know each other to invoke compatible keys. All else, including certificates, authentication, PFS, etc. is secondary. The work this group has done goes far beyond the minimal list above, so it should be possible to extract a workable scheme out of what's been done, get it out, and move forward. Steve At 05:07 PM 9/1/96 -0400, Hilarie Orman wrote: >How far does the group want to go to achieve consensus? One can >easily design a single protocol that meets all the proposed goals for >key management. What seems impossible is convince people that this >all MUST be implemented. For every option there is a contingent that >opposes it, for every option there is a contingent that supports it, >for every subset there is a group that thinks it is too much to implement. >(heavy sigh). > >The shopping list is: > > sessions, in-line key encrypting keys > sublist for second item above: separate hdr, extensions to ESP/AH hdrs > key determination via PFS or non-PFS > identity protection via PFS or non-PFS > authentication via DH, RSA encryption, RSA signatures, or DSS > (El Gamal hasn't yet been seriously considered) > X.509v3 and DNS KEY/SIG records for PK authentication > certificate inclusion, certificate retrieval > elliptic curve groups > new group definitions via protocol > ISAKMP framework, other framework > (I think that's all) > >Agree whole-heartedly on what you want, set a design team to work, good will >follow. > >Hilarie Orman > > > > > ---------------------------------- Steve Crocker Main: +1 703 620 4200 CyberCash, Inc. Desk: +1 703 716 5214 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com Message-Id: <199609030132.SAA06805@toad.com> To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Patents by Sun? In-Reply-To: <199608302201.AAA07280@kom30.ethz.ch> Date: Mon, 02 Sep 1996 18:32:52 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have updated the "Network Encryption - history and patents" web page at http://www.cygnus.com/~gnu/netcrypt.html to include the full text of Sun's recent patent, as well as their earlier one which has been dedicated to the public. John Gilmore Message-Id: <199609030706.AAA17528@toad.com> To: Hilarie Orman Cc: David_Wheeler-P26179@email.mot.com, ipsec@TIS.COM, gnu@toad.com Subject: Re: Everything degenerates to Key Management In-Reply-To: <199609012107.RAA15389@earth.hpc.org> Date: Tue, 03 Sep 1996 00:06:00 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hilarie, thanks for the list of proposed goals. > The shopping list is: > ... > (I think that's all) Don't forget: Scales cleanly to the entire Internet, not just to small VPN's If all we're standardizing is a protocol for small virtual private networks, we're wasting the IETF's time. Half a dozen companies could get together and do that. Our job is to engineer the Internet. John From: Rich Skrenta Message-Id: <199609031702.KAA02553@miraj.incog.com> Subject: Re: Everything degenerates to Key Management To: John Gilmore Date: Tue, 3 Sep 1996 10:02:51 -0700 (PDT) Cc: ipsec@TIS.COM In-Reply-To: <199609030706.AAA17528@toad.com> from "John Gilmore" at Sep 3, 96 00:06:00 am X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Don't forget: > > Scales cleanly to the entire Internet, not just to small VPN's > > If all we're standardizing is a protocol for small virtual private > networks, we're wasting the IETF's time. Half a dozen companies could > get together and do that. Our job is to engineer the Internet. I'll submit that this has more to do with ACL management, i.e. the "naming problem", than the underlying encryption protocol. Designing crypto exchanges and packet formats is comparatively easy; informing your machine that it's supposed to encrypt with a particular set of modes+algorithms to a particular (possibly randomly assigned) IP address is hard. But insofar as a workable solution is developed, I believe that it should prove fairly independent of the underlying encryption system. This problem is really at a different level than the SKIP vs. Oakley debate, since neither set of drafts speak much to this issue. To: Ashar Aziz Cc: ipsec@TIS.COM Subject: Re: Patents by Sun? In-Reply-To: Your message of "Mon, 02 Sep 1996 17:22:06 -0000." <199609030550.KAA18950@sdnpk.undp.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 03 Sep 1996 13:18:59 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609031321.aa22975@neptune.TIS.COM> Ashar Aziz writes: > My recollection of this patent (the work was done > a few years ago, and isn't fresh in my mind) is that it > isn't a patent on a generic IPSEC mechanism. That might not have been the intent, but the claims easily cover any conceivable IPSEC mechanism. It is entirely possible that this was not your intent, but it does appear to be what has happened in practice. > Rather, this was related to the specific use of key-management and > encryption on devices that were not IP addressable, yet intercepted > IP traffic (hence the "signatureless" title, and the use of the > bridge terminology). 1) The claims speak of the same mechanisms being used without bridges. 2) The "bridge" terminology is probably insufficient to distinguish the fundamental concepts from IPSEC. > Now, I don't have a copy of either the issued patent > or the patent application (and since I am in a remote office, > don't have easy access to these documents), but I > have requested a copy be mailed to me. I will review > the claims section, and send a follow-up message, > if anything changes my recollection of this patent. > (This may take a week or so.) Okay... Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa24594; 3 Sep 96 15:29 EDT Received: by relay.hq.tis.com; id PAA10432; Tue, 3 Sep 1996 15:32:35 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010424; Tue, 3 Sep 96 15:32:11 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02625; Tue, 3 Sep 96 15:31:25 EDT Received: by relay.hq.tis.com; id PAA10413; Tue, 3 Sep 1996 15:32:09 -0400 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1) id xma010394; Tue, 3 Sep 96 15:31:56 -0400 Received: from jupiter.milkyway.com by internet with ESMTP (DuhMail/2.0) id PAA04776; Tue, 3 Sep 1996 15:31:42 -0400 Received: from milkyway.com (rootmcr@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id PAA23719 for ; Tue, 3 Sep 1996 15:29:59 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id PAA27151; Tue, 3 Sep 1996 15:29:11 -0400 Message-Id: <199609031929.PAA27151@milkyway.com> X-Mailer: exmh version 1.6.7 5/3/96 Pgp-Action: none; rfc822=off X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Tue, 03 Sep 1996 10:02:51 PDT." <199609031702.KAA02553@miraj.incog.com> Date: Tue, 03 Sep 1996 15:28:53 -0400 From: Michael Richardson Sender: ipsec-approval@neptune.tis.com Precedence: bulk gnu> If all we're standardizing is a protocol for small virtual private gnu> networks, we're wasting the IETF's time. Half a dozen companies could gnu> get together and do that. Our job is to engineer the Internet. In fact this has already happened! skrenta> I'll submit that this has more to do with ACL management, i.e. the skrenta> "naming problem", than the underlying encryption protocol. I agree with this. But, if we can not decide on what the underlying encryption protocol is, then we can not even deploy the *simple* things that people want to do. Thus the "groundswell" of support on the list for SKIP. It solves these people's problems *now*. The SKIP vs Oakley debate is *not* just a decision of: # tail /etc/rc.local if [ -x /usr/sbin/skipd ]; then /usr/sbin/skipd fi vs # tail /etc/rc.local if [ -x /usr/sbin/ikmpd ]; then /usr/sbin/ikmpd fi Rather, you have to change your kernel unless someone decides to support both, and I do not know how the two systems will interact. I have not seen, for instance extensions to the BSD44 socket API on how SKIP will be available to user processes wishing keying. (Yes, this is Unix specific, but how many TCP/IP capable systems do *not* support some kind of BSD-like socket API?) skrenta> Designing crypto exchanges and packet formats is comparatively easy; skrenta> informing your machine that it's supposed to encrypt with a particular set skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP skrenta> address is hard. But insofar as a workable solution is developed, I skrenta> believe that it should prove fairly independent of the underlying skrenta> encryption system. skrenta> skrenta> This problem is really at a different level than the SKIP vs. Oakley skrenta> debate, since neither set of drafts speak much to this issue. I had hoped that the meetings would come up with a way to incorporate the SKIP header into the IPsec architectural draft (rfc1825). I have some ideas on how to do this, but I do not have enough experience with both SKIP and rfc1825 to do this on my own. If the stuff on the wire could be compatible at the "manual keying" level, and an API similar to PF_KEY could accomodate SKIP keying, then we could solve the other problems later. Some smart person may come up with a hybrid solution that looks like neither solution. -- mcr@milkyway.com | Milkyway Networks Corporation Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: mcr@sandelman.ocunix.on.ca. Received: from relay.hq.tis.com by neptune.TIS.COM id aa11268; 4 Sep 96 18:46 EDT Received: by relay.hq.tis.com; id SAA11622; Wed, 4 Sep 1996 18:49:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma011619; Wed, 4 Sep 96 18:49:18 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07306; Wed, 4 Sep 96 18:48:32 EDT Received: by relay.hq.tis.com; id SAA11613; Wed, 4 Sep 1996 18:49:16 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma011610; Wed, 4 Sep 96 18:49:03 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA02385; Wed, 4 Sep 1996 15:51:20 -0700 (PDT) Date: Wed, 4 Sep 1996 15:51:20 -0700 (PDT) From: Phil Karn Message-Id: <199609042251.PAA02385@servo.qualcomm.com> To: David_Wheeler-P26179@email.mot.com Cc: ipsec@TIS.COM In-Reply-To: (message from David Wheeler-P26179 on Thu, 29 Aug 1996 13:03:36 -0500) Subject: Re: Everything degenerates to Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Internet protocols for future capability. Ignoring the need that is well >voiced for a common, flexible, and extensible key managment protocol would >border on deliquency. The *truly* deliquent action is to spend so much time pursuing total generality that well-defined, near-term and increasingly critical security needs (like securing remote laptop access and virtual private subnetworks) continue to go unmet. Nobody said you can't keep working on as general a scheme as you like even if a more limited IPSEC scheme is deployed. That's the way the Internet works. Anybody can work on anything they like, but acceptance is voluntary. Now if you're concerned that the availability of a scaled-back IPSEC will reduce the demand for a full-blown version, well...what can I say? Perhaps that would simply demonstrate there's no point in doing the full-blown version, eh? In my own sphere of influence, we've begun deploying Network Systems Borderguards in our virtual private network links. I understand these still use proprietary key management protocols and encapsulation formats, yet they seem to work. I've personally begun to use SSH quite heavily. It also seems to satisfy many of my needs despite having no official IETF standing. All other things equal, I'd certainly prefer to use standard protocols. But all other things are NOT equal, because the standards don't exist in a form I can use. And alternatives are rapidly appearing. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa14855; 5 Sep 96 1:39 EDT Received: by relay.hq.tis.com; id BAA15959; Thu, 5 Sep 1996 01:42:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015957; Thu, 5 Sep 96 01:42:18 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16325; Thu, 5 Sep 96 01:41:31 EDT Received: by relay.hq.tis.com; id BAA15952; Thu, 5 Sep 1996 01:42:17 -0400 Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (V3.1.1) id xma015939; Thu, 5 Sep 96 01:41:46 -0400 Received: by big-screw id AA02435; Thu, 5 Sep 96 01:43:43 -0400 Message-Id: <322E6848.42E0@mit.edu> Date: Thu, 05 Sep 1996 01:42:32 -0400 From: "Jeffrey I. Schiller" Reply-To: jis@mit.edu Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 3.0 (Macintosh; U; 68K) Mime-Version: 1.0 To: ipsec@TIS.COM, secdir@mit.edu Cc: The IAB , The IESG Subject: Status of IPSEC Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Standardized security technology is urgently needed on the Internet today. The IPSEC Working Group has been working to provide solutions applicable to the IP Layer of the protocol stack. Over a year ago, consensus was reached on the packet formats necessary to provide data authentication, integrity and confidentiality, however the mechanism to exchange required cryptographic material were not yet ready for standardization. Since then the IPSEC Working Group has been struggling with several competing proposals. To have competing proposals within an IETF working group is neither new nor novel. However the time comes when either the proponents of the various proposals come to consensus (along with the rest of the working group) or a decision among them has to be made. That time is now. In Montreal (at the June IETF meeting) I saw several factions at work in the IPSEC working group. There were people supporting each of the proposed key management solutions and a larger number of people who were looking for a single solution to emerge, but who themselves were not in a position to have a technical opinion one way or the other. But one thing was clear, they wanted a solution and they wanted it then. Shortly after the meeting I was approached by several people offering to have a "design team" meeting with the principals behind the various proposals. The goal being to come up with a compromise that all could live with. I considered this very good news, but I was also cautious. The last thing I wanted was to have a working group meeting at the December IETF and still be where we were in Montreal, namely without a solution! To this end I established a time limit. The charge to the design team was to come up with a compromise solution (or enough progress on a compromise) by September 1. After September 1, if the working group could not decide upon a course of action, then I would step in as Security Area Director and propose one myself. As those of you on the IPSEC list already know, the design team failed in their effort to come up with a compromise. I am both saddened and disappointed by this outcome. This leaves us with the question of where to go. To that end, I am preparing a position paper outlining the direction that I believe we should be going. This paper will be reviewed by the members of the Security Area Directorate and published as an Internet Draft. Expect to see it by the end of next week or early the week following. I know that many of you have been anxious for the IETF to finally settle this issue so that we can move forward and make progress in providing open standard solutions to security at the IP layer. It is my intent that we settle this soon, hopefully within the next few weeks. Sincerely, Jeffrey I. Schiller IESG Area Director for Security -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMi5m78UtR20Nv5BtAQFFnwQAh8BP+FNbXNB9vfdJIqnRtx8DuSCn8vB6 0thzsxs9Xzg1+7d70V9rYQ+HYI0imUwiuwy0jG5WTWCP5MpRfFj4FNaNnicFuAj/ Iaqget7U2BkHpfEpXe2q1lCkRySk+JuoU94aRuqEAZn7pyXCb4lP+BBkuSqXkiU+ w6B6y6hlYaU= =DyuX -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa23677; 5 Sep 96 16:58 EDT Received: by relay.hq.tis.com; id RAA07543; Thu, 5 Sep 1996 17:01:54 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007522; Thu, 5 Sep 96 17:01:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26609; Thu, 5 Sep 96 17:00:40 EDT Received: by relay.hq.tis.com; id RAA07512; Thu, 5 Sep 1996 17:01:24 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma007504; Thu, 5 Sep 96 17:01:21 -0400 Received: from ftp.com by ftp.com ; Thu, 5 Sep 1996 17:03:29 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 5 Sep 1996 17:03:29 -0400 Message-Id: <2.2.32.19960905210839.00b3f4e0@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Sep 1996 17:08:39 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy Subject: Replay protection with Manual keying Sender: ipsec-approval@neptune.tis.com Precedence: bulk We were trying to implement HAMC-SHA with replay protection. We support only manual keying as of now. Are we right in saying that one should not use replay protection with manual keying? We came up with this conclusion because of what happens when either the sender or the receiver crashes. If the sender crashes, when the machine is rebooted the sequence number starts from 1. However, the receiver does not know about this and rejects all packets thinking it is replay attach. In manual keying, the SA'a are static. The only way to avoid this is to keep track of the sequence number and make it persistent. Comments? -Ron Arbo and Naganand Doraswamy Received: from relay.hq.tis.com by neptune.TIS.COM id aa24919; 5 Sep 96 19:14 EDT Received: by relay.hq.tis.com; id TAA10715; Thu, 5 Sep 1996 19:17:44 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010712; Thu, 5 Sep 96 19:17:36 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00994; Thu, 5 Sep 96 19:16:28 EDT Received: by relay.hq.tis.com; id TAA10696; Thu, 5 Sep 1996 19:17:14 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma010694; Thu, 5 Sep 96 19:17:05 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id BAA19595; Fri, 6 Sep 1996 01:19:20 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id BAA15755; Fri, 6 Sep 1996 01:19:19 +0200 (MET DST) Message-Id: <199609052319.BAA15755@kom30.ethz.ch> Subject: Re: Replay protection with Manual keying To: Naganand Doraswamy Date: Fri, 6 Sep 1996 01:19:18 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <2.2.32.19960905210839.00b3f4e0@mailserv-H.ftp.com> from "Naganand Doraswamy" at Sep 5, 96 05:08:39 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Naganand Doraswamy wrote: > Are we right in saying that one should not use > replay protection with manual keying? > > manual keying, the SA'a are static. The only way to avoid this is to keep > track of the sequence number and make it persistent. > > Comments? Right. This problem also appears in esp-stream-01, and we came to the same conclusion. If you use replay protection, you rely on rather frequent (e.g. once every 5 minutes) key changes to allow for resynchronisation. The obvious alternative is not to do replay protection. Friendly greetings, Germano From: Steve Bellovin To: ipsec@TIS.COM Subject: new paper Date: Thu, 05 Sep 1996 19:23:35 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609060729.aa02154@neptune.TIS.COM> Folks on this mailing list may be interested in a new draft paper of mine: Probable Plaintext Cryptanalysis of the IP Security Protocols The Internet Engineering Task Force (IETF) is in the process of adopting standards for IP-layer encryption and authentication (IPSEC). We describe how ``probable plaintext'' can be used to aid in cryptanalytic attacks, and analyze the protocol to show how much probable plaintext is available. We also show how traffic analysis is a powerful aid to the cryptanalyst. We conclude by outlining some likely changes to the underlying protocols that may strengthen them against these attacks. It's available from ftp://ftp.research.att.com/dist/smb/probtxt.ps Received: from relay.hq.tis.com by neptune.TIS.COM id aa03671; 6 Sep 96 9:44 EDT Received: by relay.hq.tis.com; id JAA21162; Fri, 6 Sep 1996 09:47:26 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021155; Fri, 6 Sep 96 09:46:58 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20547; Fri, 6 Sep 96 09:46:09 EDT Received: by relay.hq.tis.com; id JAA21148; Fri, 6 Sep 1996 09:46:56 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma021145; Fri, 6 Sep 96 09:46:53 -0400 Received: from [128.89.30.30] (ARA30.BBN.COM [128.89.30.30]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id JAA07569; Fri, 6 Sep 1996 09:54:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Sep 1996 09:50:21 -0500 To: Germano Caronni From: Stephen Kent Subject: Re: Replay protection with Manual keying Cc: Naganand Doraswamy , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Germano, I'm not sure I would expect rekeying to be nearly as frequent a you suggest (every 5 minutes), but the general thrust of these observations is certainly correct, i.e., anti-reply measures rely on fresh, per-association keys and a means of rekeying within an association that carries enough traffic to cause the counter to cycle. Also, in the face of loss of state at either end, one must be prepared to establish a new association, and that too calls for a fresh traffic key. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa05063; 6 Sep 96 11:49 EDT Received: by relay.hq.tis.com; id LAA26012; Fri, 6 Sep 1996 11:53:06 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026006; Fri, 6 Sep 96 11:52:36 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04296; Fri, 6 Sep 96 11:51:48 EDT Received: by relay.hq.tis.com; id LAA26002; Fri, 6 Sep 1996 11:52:34 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma026000; Fri, 6 Sep 96 11:52:19 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA78284; Fri, 6 Sep 1996 11:55:02 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id LAA505476; Fri, 6 Sep 1996 11:54:35 -0400 Message-Id: <199609061554.LAA505476@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8673; Fri, 06 Sep 96 11:54:33 EDT Date: Fri, 6 Sep 96 11:54:33 EDT To: naganand@ftp.com, ipsec@TIS.COM Subject: Replay protection with Manual keying Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 05 Sep 1996 17:08:39 -0400 (attached) Naganand, > > We were trying to implement HAMC-SHA with replay protection. We support only > manual keying as of now. Are we right in saying that one should not use > replay protection with manual keying? > > We came up with this conclusion because of what happens when either the > sender or the receiver crashes. If the sender crashes, when the machine is > rebooted the sequence number starts from 1. However, the receiver does not > know about this and rejects all packets thinking it is replay attach. In > manual keying, the SA'a are static. The only way to avoid this is to keep > track of the sequence number and make it persistent. > > Comments? Manual keying makes sense in some scenarios for relatively-long lived master keys. Even in that case support for automatic fast key refreshment (for security and re-sync as you note) is necessary. We have been arguing for this need for long time (fortunately, fast re-key is now part of all the major proposals in this group; also see our MKMP paper - usenix'95). > > -Ron Arbo and Naganand Doraswamy > From: Rich Skrenta Message-Id: <199609061817.LAA06333@miraj.incog.com> Subject: SKIP Design & Applicability Statement To: ipsec@TIS.COM Date: Fri, 6 Sep 1996 11:17:23 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Several people, including Paul Lambert, have asked us to provide a list of differentiators between SKIP and other KMP proposals. Ashar has recently expanded his applicability statement for SKIP; I'll include it below. This is also available on our web site at http://skip.incog.com/skip-applic.html ----------------------------------------------------------------------------- Design Issues and Applicability Statement for SKIP Ashar Aziz Distinguished Engineer Sun Microsystems, Internet Commerce Group Introduction ------------ This note describes applications and usage of SKIP in Internet/Intranet environments, and motivations behind the design of SKIP. (A detailed description of the SKIP protocol may be found in the online internet-drafts directories under draft-ietf-ipsec-skip-*.txt). SKIP enables the establishment of keys with no interactive message exchanges required between the principals wishing to establish a secure channel. The base SKIP mode allows the computation of a master key using each principal's certified DH key. Re-keying is performed inline, by encrypting the traffic key using the master key, and sending the encrypted traffic key inline with the packet. The master key computation requires a single DH operation, during the lifetime of communications between two principals, after which it can be cached using the same techniques used to store each principal's long-term private key. An important point is that the master key is non-interactively and independently computed by each principal (host, user, etc.). The other principal neither needs to participate nor even be connected or available on the network at the time of master key computation. Only the other principal's certified DH value need be available and this can be distributed using central servers as through a name service such as secure DNS. This is important for practical reasons to be discussed shortly. SKIP supports an ephemeral DH exchange, which provides Perfect Forward Secrecy (PFS), for situations which require PFS. A protocol has the PFS property when the compromise of long-term keying material does not compromise data encrypted in the past (which may have been recorded), and whose associated transient traffic keys have been deleted from the system. The inline key-update used in SKIP also works for multicast environments. A SKIP extension describes how to set-up and refresh traffic keys for multicast data. We describe some illustrative application and usage scenarios of SKIP and its extensions. The example usage scenarios below is not an exhaustive list of the uses of the SKIP protocol. Rather it is an illustrative list provided in order to present the considerations that motivated the design of the SKIP protocol. Secure Domain Management ------------------------ ipsec protocols will be used in the Internet and Intranet environments not only to establish secure encrypted channels between two nodes, but also to establish and manage the security of critical network elements, e.g. encrypting firewalls, routers etc. There are two essential components of management that impact key-management; traps and alerts from managed devices and set operations from management station to managed devices. Both of these operations are urgent operations. Namely, they need to be processed and dispatched in a timely manner for security management to be effective. The aspect of security that is critical here is authentication of traps/alerts from managed devices and the authentication of the set operation from the management station. Secrecy is typically a secondary concern here, therefore PFS is a moot issue for this application. An example scenario: Assume a large enterprise containing hundreds (possibly thousands) of security critical elements, such as firewalls or routers, at the perimeter of the enterprise. These firewalls might be programmed to detect security events (such as penetration attempts) and inform the management station of such events via network management traps or alerts. In case such an event occurs, it is unlikely that prior security associations will always exist, since security associations are intended to be temporary and will go away on reboot/power up of either management station or managed device. (Trying to re-establish these associations on each re-boot of a management station, where each association could take a second to a few seconds, would result in a hour's worth of security association for a few thousand managed devices, a significant limitation. Another factor making this impractical is that not all managed devices may be powered up or available at the time the management station is re-booting, making interactive key-establishment on each re-boot more problematic). In case intrusion events are detected by the firewall complex (possibly from all over the site), this could result in a few hundred to a thousand traps to the management station(s). Assuming a second (or two) per new association this leads to an overwhelming 1/2 hour to an hour worth of compute time on the management station simply to process the association requests, essentially bringing it down, and rendering it useless to take management action (such as shutting down part of the firewall complex or other such action). One could question if all perimeter devices would be simultaneously attacked. However, if the key-management presents an achilles heel in such situations, where simultaneous attack would result in disabling all management stations, then this is precisely the sort of attack one should expect. Another argument could be that one could use permanent security associations for handling such applications, where the session key is negotiated once and then cached. There are several limitations of this approach: The first is that permanent caching of an association essentially results in freezing the traffic key, an undesirable feature from a cryptographic perspective, where frequent key changes represent the best defense against cryptanalysis. Dynamic key-management is the entire goal of ipsec key management, and permanent security associations are a step back to manual key-management. Another limitation is that in case association state is ever lost on, say, the managed device then *both* the management station and the managed device need to re-compute the key, resulting in the same overhead issues discussed earlier should this need to happen at urgent message time from many managed devices. Cached associations for management are no more elegant or practical than running SNMP over cached TCP connections. If SKIP is used for this application scenario, then the limitations discussed earlier do not exist. A SKIP master key (Kij) is the only expensive part of the base SKIP protocol, and this can be cached. Caching the master key doesn't freeze the traffic key, since the two are independent. Re-keying happens inline, so a single message representing an urgent trap or alert allows key refreshment, without incurring a second per message worth of compute time. This is because only symmetric key operations need to be performed per message. In case the master key is ever lost on a managed device, then only the managed device needs to re-compute it, not the management station, which is the bottleneck in this application scenario. A thousand or so traps can be processed in a total time of a second or so, with no extra messages required for key-management purposes. The management station is able to respond with, say, an authenticated shutdown to the entire firewall complex in a few seconds, not hours. A key-management approach that does not adequately meet the needs of scalable and secure network management is not only incomplete, it represents a serious security vulnerability for the Internet community. Security without effective security management will be difficult, if not impossible, to establish and maintain. Large Scale Servers ------------------- A large scale web, mail or file server is expected to receive many simultaneous connection requests, which can all potentially result in a new security association requests. Several hundred or thousand requests can result in computational overload for servers, even if each new association takes only a second or two. One could question whether a thousand new requests can occur simultaneously to a server. The answer here is yes, probably even frequently, when one considers that they don't all have to occur at the very same instant. Even if 20 requests occur in the same 1-2 second time frame, processing these new associations could take 20-40 seconds, and the rest of the requests could occur in these 20-40 seconds, in order to have the overloading effect of a hundred/thousand simultaneous requests. Another way of looking at this is as follows: if the new association requests come in at a rate faster than they can be processed then this results in a server meltdown situation. For example, if a new association requires 2 seconds to process, then an averaged rate of 1 new request per second is sufficient to completely overload the server. Such a rate is not far-fetched for typical servers in use today, such as web, mail or file servers, and can certainly occur during peak usage times. (Long-term caching of associations is problematic for the reasons noted above.) Servers represent a special issue in the trade-off considerations between performance and security. Servers are typically used to store long-lived information, such as files, mail messages, or web pages. If PFS is being employed to encrypt all traffic to/from the server (and the contents of the secure conversations are stored on the server, e.g. a mail message, or a web page, etc.) then compromise of the principal's long-term key can still result in compromise of encrypted traffic. This is because compromise of a principal's long-term key will always result in authentication failure. The attacker who has compromised the long-term key is able to impersonate the legitimate user, and connect to the server to recover the traffic that was originally encrypted over the channel in PFS mode. There is one (important) aspect in which PFS offers a better defense than a non-PFS solution. Namely, if the key-compromise is discovered, the keys may be revoked, thereby protecting against future impersonation attacks and still preserving the secrecy of past encrypted data. However, there are many circumstances in which long-term key-compromise may not be discovered, and if it is discovered, may be discovered too late. Therefore, the trade-off in such situations is to take the performance penalty imposed by a PFS protocol (such as SKIP PFS), in order to guard against discoverable key-compromise, or to use a lighter-weight protocol without PFS (such as the base SKIP mode). There may not be a single right answer here. Some sites may wish to accept degradation in server performance, and choose the PFS approach because they believe that key-compromises will be discoverable. Other sites may choose a lighter weight protocol without PFS, because they believe that guarding against discoverable key-compromises isn't worth the performance penalty. We believe this is a choice that should be left to the user community. Certainly, if all the ipsec protocol is providing by way of security is authentication, so that the server may perform authenticated access control, then the entire PFS issue is moot, and the overhead entailed by PFS is clearly unnecessary. Low-End devices --------------- IP layer security is being implemented on low-end devices such as computationally constrained CPUs (embedded designs, palm-tops, Internet/Web terminals etc.). The computational overhead of performing even a few public key operations simultaneously is a challenge for such computational platforms. The low computational overhead of the base SKIP mode permits it to be easily implemented on such low-end devices. High Availability of Encrypting Firewalls/Routers ------------------------------------------------- Another sample application usage of SKIP is to enable the set up of a redundant set of intermediate nodes in order to provide failover of encrypted traffic. IP routing provides for failover for unencrypted traffic, and this feature is especially important at enterprise connections to the Internet, where a single point of failure may represent the failure of a mission critical application, requiring secured access to the enterprise from across the Internet. An example of this might be mobile sales people, requiring secured access to corporate information from field locations. If a single firewall or router was handling several hundred or thousand such sales people, then it is highly desirable that failure of either the link or the Intermediate device providing encryption services should not result in a loss of secure connectivity to this large group of users. SKIP permits multiple intermediate nodes (routers, firewalls, etc.) to be configured to share the same long-term DH public/secret value, and the same master key-id. Failover of encrypted traffic is provided by standard dynamic IP routing facilities. As described above, an intermediate device may compute and cache SKIP master keys (Kij) without ever communicating with the end units that may connect through it. At failover time, an encrypted/authenticated packet that was intended for a failed unit may be re-routed to a redundant standby unit and processed without requiring several public key operations per new source of encrypted traffic. Thus failover scales to thousands of encrypted channels, because there is much lower overhead in processing each new source of encrypted traffic. One could argue that failover can still be achieved using an association based approach, by allowing alternate encrypting nodes to detect failover by receiving an ipsec packet for which a local SPI does not exist (for that src, dst IP address pair). In case such a packet is received, the alternate device can negotiate a new session key for that (src, dst) IP address pair. There are two problems with this approach. The first is that there is no requirement that an SPI with a given (src, dst) IP address be unique across nodes. It need only be unique on a given receiving node, since there is no coordination between nodes of SPI values. This means there is a possibility that that same SPI value for the given (src, dst) IP address already exists on the alternate node (with a different session key). In this case, failover would not be detected and therefore no failure recovery would occur. The second problem is that this doesn't scale to failover of thousands of secure channels, since this would require the alternate intermediate node to negotiate (simultaneously) thousands of associations. At the rate of a few seconds per association, this could easily take on the order of hours, which would be an unacceptable delay for end nodes in the field requiring secured access. It is impractical in the association approach for an intermediate node to cache security associations for all possible end or intermediate nodes that may require access through it. This is because a) The end nodes may not be available at the time such caching may need to be performed, b) the location of the end node (in terms of IP address) may not be known, since many of these nodes may be coming through dynamically assigned IP addresses and c) the end node may be connected through a dial-up telephone or ISDN link, involving a monetary expense simply for association caching purposes. High availability of the network is an important practical issue, and was a motivating feature for the design of IP in order to build survivable networks. It is important to preserve this feature, as the networks become secure. High-Speed Links ---------------- An issue for cryptographic security and high speed links is the frequency of key updates. Key-updates need to be related to the amount of data encrypted in a given key and not be a function of time alone. For a given key-update policy (e.g. change the key every 100 Mbytes of encrypted traffic), this translates to a thousand times more frequent key-update rate, when going from a 1 Mbit/s link to a 1 Gbit/s link. This means that a key-update policy that requires a key-update every 15 minutes on a 1 Mbit/s link, translates to a key-update faster than once per second on a 1 Gbits/s link. Using an approach that requires an interactive message exchange for each key-update means that two messages per second will be required for key-updates on a Gbit/s link. If this node is talking to thousands of other such high-speed nodes, the messages required for key-updates increase a thousand fold. (These are not unrealistic scenarios for an Internet that is simultaneously getting bigger and faster.) The node must wait at least a round-trip delay time prior to re-keying. This is simply a fact due to network latency. Each lost key-update message means one of two things. a) either wait for a retransmission of the key-update message and degrade throughput or b) continue transmitting using the old key and violate the local key-update policy. Since SKIP performs inline re-keying, the message exchanges and the latency inherent in a round-trip message exchange are both avoided. Re-keying can be performed as frequently as desired, even once a packet, because no message exchange or round-trip delays are incurred in doing this. The issue here is purely one of inline keying. Inline re-keying can be used in conjunction with an ephemeral master key, and still have fast re-key in conjunction with PFS (e.g. as in the SKIP PFS draft). It could be argued that one could come up with key-update rates that are far less frequent for these high-speed links, since all known attacks on the cryptosystems intended to be used require an impractical amount of known or chosen text. However, this precludes key-update policies that may wish to be more conservative in the amount of data encrypted in a given key. It is entirely possible that future attacks may be discovered that require less plaintext encrypted in a given key (either known text or chosen) and such attacks could compromise past encrypted data which used less conservative key-update rates. A more conservative key-update policy would prevent future discovery of these attacks from compromising past encrypted data. The attacks being defended against here are purely passive attacks, since discovery of a future cryptanalytic attack permits the adversary to take recorded encrypted traffic (and any associated known text) and simply apply the attack techniques to it. This is a far more feasible form of attack than active forms of attack against past encrypted traffic (e.g. compromising a long-term secret key). Multicast IP Issues ------------------- An important part of multicast key-management is scalable re-keying, where the re-key operation needs to scale with the size of the multicast group. A scheme that requires a central Key Distribution Centre (KDC) to supply the multicast traffic keys doesn't scale very well, because this requires key-management traffic proportional to the size of the multicast group and the key-update rate to and from a single entity. Alternative schemes that have been suggested involve encrypting the traffic key in an interchange key that the group members already possess and multicasting the encrypted traffic key to all the group members. This approach has a significant drawback. First, IP multicast is an unreliable operation. There can be no assurance that all the group members in fact have received the new traffic key. Without knowing if and when the group members have received the encrypted multicast traffic key, it is difficult to start using the new key. One could use some reliable multicast transport protocol, but these also represent scaling problems. In any case, it is a limitation to have to introduce a reliable multicast protocol when it may not be necessary for the IP multicast application requiring security. Other drawbacks include some of the drawbacks mentioned above for high speed links. How does one perform rapid re-key for multicast over high speed links, if the re-key operation requires an acknowledgment from all group members? SKIP's use of inline re-keying solves these problems. There is no need to introduce a reliable multicast transport protocol. A multicast group can be re-keyed as rapidly as desired, independent of the size of the multicast group and independent of network latency and round-trip time issues. SKIP multicast inline re-key scales simultaneously to arbitrary size multicast groups and high-speed links, has no synchronization issues associated with the re-key operation, and works in the presence of packet losses. SKIP PFS -------- SKIP PFS is a simple, 2-message exchange that provides authenticated PFS. In addition, it also provides anonymity of the parties involved in the exchange. The exchange does not use non-repudiable signatures. Therefore it also has the desirable property of deniability of an exchange, which is important for privacy considerations. Namely, one doesn't want to provide each party a non-repudiable proof that a secure conversation tool place, because one may wish to later deny that the conversation took place. The overhead of SKIP PFS is comparable to the overhead of other protocols that provide PFS, but significantly greater than the overhead of the base SKIP mode. PFS is highly desirable in many environments which require long-term secrecy of information, even in the presence of the compromise of long-term keying material. Ideal use of PFS is to encrypt ephemeral data (i.e. data that is never stored in the network), because the ephemeral nature of the keys will permanently (assuming high-strength DH) remove the ability to recover the encrypted material from any source, including the recorded ciphertext. Scalability ----------- Any approach that is being considered for use on the Internet needs to be scalable. This scalability has many facets to it. Specific aspects of scalability, and features of SKIP that aid each aspect, are described above. This includes scalability for management of large secure domains containing many devices, large-scale web/mail/file/ servers, low-end devices (e.g. Internet/web terminals), high-speed networks, and large multicast groups. Simplicity ---------- Although the functionality described above is important (and we believe, critical) for a scalable approach to key-management, an important element is the complexity of an approach to achieve its end objectives. Whereas simplicity and complexity are in the end a subjective judgement, we believe that the balance in the SKIP protocol lies towards simplicity. When multiple ways of achieving a cryptographic objective (e.g. PFS or anonymity) exist, a single and most often the simplest approach is specified. This simple approach is not limited to solving only simple problems. For example, inline re-key is a simple mechanism that simultaneously addresses complex key-management issues related to urgent secure messages, encrypted multicast traffic, and high-speed networks. We believe that a simple approach aids in the building of interoperable implementations, and the security analysis of the final systems, both from a protocol and implementation point of view. A simple approach is also quicker to build and deploy. This is an important practical issue, considering the pressing need for security at the network layer of the Internet. Received: from relay.hq.tis.com by neptune.TIS.COM id aa08234; 6 Sep 96 16:14 EDT Received: by relay.hq.tis.com; id QAA07401; Fri, 6 Sep 1996 16:18:01 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007392; Fri, 6 Sep 96 16:17:36 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24175; Fri, 6 Sep 96 16:16:45 EDT Received: by relay.hq.tis.com; id QAA07387; Fri, 6 Sep 1996 16:17:31 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma007377; Fri, 6 Sep 96 16:17:20 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id WAA02965; Fri, 6 Sep 1996 22:19:23 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id WAA16846; Fri, 6 Sep 1996 22:19:20 +0200 (MET DST) Message-Id: <199609062019.WAA16846@kom30.ethz.ch> Subject: draft-caronni-esp-stream-01.txt To: ipsec@TIS.COM Date: Fri, 6 Sep 1996 22:19:19 +0200 (MET DST) Cc: Marcel Waldvogel X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello everybody, Marcel Waldvogel and I updated the Stream Transform lately. Now I would like to ask WG members and chairs whether there is interest in making this a standard transform, or whether this could be made an informational IPSEC RFC. What are your opinions? And yes, there are at least four different implementations using this transform. Germano The announment: A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP Stream Transform Author(s) : G. Caronni, M. Waldvogel Filename : draft-caronni-esp-stream-01.txt Pages : 12 Date : 09/03/1996 This document describes a security transform providing privacy and optional replay protection through Encapsulating Secure Payload (ESP). The transform defines how to use ESP in conjunction with byte-oriented stream ciphers, such as RC4 or SEAL. These stream ciphers offer strong encryption with comparatively low computational demands, and are thus favorable for multimedia bulk data or environments where the computing power needed per packet should be low. Received: from relay.hq.tis.com by neptune.TIS.COM id aa11768; 6 Sep 96 22:53 EDT Received: by relay.hq.tis.com; id WAA13973; Fri, 6 Sep 1996 22:56:30 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma013969; Fri, 6 Sep 96 22:56:01 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03810; Fri, 6 Sep 96 22:55:13 EDT Received: by relay.hq.tis.com; id WAA13965; Fri, 6 Sep 1996 22:56:00 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma013961; Fri, 6 Sep 96 22:55:49 -0400 Received: from [128.89.30.3] (ARA3.BBN.COM [128.89.30.3]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id XAA07954 for ; Fri, 6 Sep 1996 23:03:12 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Sep 1996 22:59:35 -0500 To: ipsec@TIS.COM From: Stephen Kent Subject: Re: Status of IPSEC Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk In reviewing the messages that note the failure to converge on a key management protocol, I was motivated to send this message about some recent experiences that may be relevent to the discussion. Most of my key management experience over the last 18 years has been with protocols designed to establish a traffic key for a security association that would, in turn, last for some time. The duration often might be a day, for an association protecting traffic in bulk between to systems (or between two sites using perimeter-based security) , or it might be on the order of a few minutes, corresponding to the duration of a TCP connection. Under these circusmatnces, a multiple-message exchange required to establish an SA and corresponding key were not a burden, becaue the cost of these messages was amortized over a fair number of subscriber traffic packets. Times have changed, and the range of uses for which we require traffic keys has broadened. For example, in work we have been doing with regard to mobile IP security, there is a desire to have a per-transaction key, but there is no opportunity to perform ANY messages exchanges to put this key in place. Moreover, the frequency of the transactions might be as high as once per second, according to the mobile IP specs, which rules out most public key computations. Under these constraints, a basic SKIP-like key generation approach is appropriate, since it requires no per-transaction exchanges and the precomputation feature of SKIP allows the per-transaction key generation time to be minimal. Thus we have chosen to use the SKIP technique (though not the SKIP syntax) for key management in this context. In another project we have been dealing with secure communication between routers, and among other routing infrastructure components. We have found instances in this program where minimal message exchange key establishment protocols, and fast (minimal computation) public key exchanges are appropriate. here too, SKIP-like functionality is attractive, though not strictly required. Finally, as the use of multicast increases in the Internet, one of the features that was originally advertised for SKIP, support for multi-sender, multicast based on stream ciphers, may become important. I don't know if SKIP is essential for this, but I've yet to see good solutions for this application and it would be nice to keep our options open here. Most of the applications and communication patterns we deal with today are well served by the sorts of key management protocols some of us have dealt with for a number of years, and which ISAKMP represents quite well. However, I do see some applications where SKIP-like key management is attractive, and some contexts for which this form of key management seems uniquely well suited. Thus I would hate to see us lose this facility in a final, single standard for key management. IPSEC may not require this form of key management, or may not require it for most applications that we see today, but it's a tool that would be nice to have available in our arsenal. Moreover, it's availability might allow us to use IPSEC in some circumstances that otherwise would require us to develop other security and.or key management protocols. So, in summary, I'd like to suggest that we try to adopt a key management solution that preserves as many options as possible, in recognition of the constantly evolving nature of the Internet and the applications that drive its evolution. Steve To: Stephen Kent Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Fri, 06 Sep 1996 22:59:35 CDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 07 Sep 1996 11:30:43 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609090724.aa08819@neptune.TIS.COM> Stephen Kent writes: > Moreover, the frequency of the transactions might be as > high as once per second, according to the mobile IP specs, which rules out > most public key computations. Under these constraints, a basic SKIP-like > key generation approach is appropriate, since it requires no > per-transaction exchanges and the precomputation feature of SKIP allows the > per-transaction key generation time to be minimal. Steve; In a large internet, key lookup will be required, the result of which will be that SKIP will have no advantage whatsoever in terms of number of message exchanges compared with other techniques. Perry From: Ran Atkinson Date: Sat, 7 Sep 1996 19:20:56 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Steve Kent's note Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609090726.aa08842@neptune.TIS.COM> I really appreciate Steve Kent's recent note. Its among the most thoughtful and precisely written notes on this list recently. I would urge folks to carefully read his note and consider its points. Ran rja@cisco.com speaking only for myself -- Date: Sun, 8 Sep 1996 07:51:23 -0700 (PDT) From: Aviel Rubin Message-Id: <199609081451.HAA03572@usenix.ORG> To: rubin@bellcore.com Subject: ANNOUNCEMENT AND CALL FOR PAPERS - 1998 USENIX Security Conference Sender: ipsec-approval@neptune.tis.com Precedence: bulk ************************************************************************* ANNOUNCEMENT AND CALL FOR PAPERS 7th USENIX Security Symposium January 26-29, 1998 Marriott Hotel-- San Antonio, Texas Sponsored by the USENIX Association, the UNIX and Advanced Computing Systems Professional and Technical Association In cooperation with: The CERT Coordination Center. Important Dates for Refereed Papers Papers due: September 9, 1997 Author notification: October 8, 1997 Camera-ready final papers due: December 9, 1997 Registration Materials Available: End October, 1997 (Authors, see "How to Submit a Refereed Paper" below.) Program Chair Avi Rubin, Bellcore Program Committee Carlisle Adams, Nortel Dave Balenson, Trusted Information Systems Steve Bellovin, AT&T Research Dan Boneh, Princeton University Diane Coe, Mitre Ed Felten, Princeton University Li Gong, JavaSoft Peter Honeyman, CITI, University of Michigan Hugo Krawczyk, IBM Watson Labs Jack Lacy, AT&T Research Hilarie Orman, DARPA/ITO Mike Reiter, AT&T Research David Wagner, University of California, Berkeley Readers Katherine T. Fithen, CERT Trent Jaeger, IBM Watson Labs Invited talks coordinator: Greg Rose, Qualcomm Conference home page: OVERVIEW The goal of this symposium is to bring together researchers, practitioners, system programmers, and others interested in the latest advances in security and applications of cryptography. This will be a four day symposium with two days of tutorials, followed by two days of refereed paper presentations, invited talks, works-in-progress presentations, and panel discussions. TUTORIALS Monday and Tuesday, January 26-27 Tutorials for both technical staff and managers will provide immediately useful, practical information on topics such as local and network security precautions, what cryptography can and cannot do, security mechanisms and policies, firewalls and monitoring systems. If you are interested in proposing a tutorial, contact the tutorial coordinator, Dan Klein: phone (412)421-2332 email . TECHNICAL SESSIONS Wednesday and Thursday, January 28-29 In addition to the keynote presentation, the technical program includes refereed papers, invited talks, a work in progress session, and panel sessions. There will be Birds-of-a-Feather sessions the last two evenings. You are invited to make suggestions to the program committee via email to . Papers that have been formally reviewed and accepted will be presented during the symposium and published in the symposium proceedings, published by USENIX and provided free to technical session attendees. Additional copies will be available for purchase from USENIX. SYMPOSIUM TOPICS Refereed paper submissions are being solicited in areas including but not limited to: * Adaptive security and system management * Analysis of malicious code * Applications of cryptographic techniques * Attacks against networks/machines * Computer misuse and anomaly detection * Copyright protection (technical solutions) * Cryptographic & other security tools * File and file system security * Network security * New firewall technologies * Security in heterogeneous environments * Security incident investigation and response * Security of Mobile Code * User/system authentication * World Wide Web security Note that this symposium is not about new codes, ciphers, nor cryptanalysis for its own sake. Papers must represent novel scientific contributions in computer security with direct relevance to the engineering of secure systems for the commercial sector. HOW TO SUBMIT A REFEREED PAPER (Please read carefully.) The guidelines for submission are a bit different from previous years. Authors must submit a mature paper in postscript format. Any incomplete sections (there shouldn't be many) should be outlined in enough detail to make it clear that they could be finished easily. Full papers are encouraged, and should be about 8 to 15 typeset pages. Submissions must be received by September 9, 1997. Along with your paper, please submit a separate email message containing the title, all authors, and their complete contact information (phone, fax, postal address, email), including an indication of which author is the contact author. Authors will be notified of acceptance on October 8, 1997. All submissions will be judged on originality, relevance, and correctness. Each accepted submission may be assigned a member of the program committee to act as its shepherd through the preparation of the final paper. The assigned member will act as a conduit for feedback from the committee to the authors. Camera-ready final papers are due on December 9, 1997. If you would like to receive detailed guidelines for submission and examples of extended abstracts, you may send email to: or telephone the USENIX Association office at (510) 528-8649. The Security Symposium, like most conferences and journals, requires that papers not be submitted simultaneously to another conference or publication and that submitted papers not be previously or subsequently published elsewhere. Papers accompanied by non-disclosure agreement forms are not acceptable and will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U.S. Copyright Act of 1976. There will be one or two prizes awarded for best paper(s). WHERE TO SUBMIT For reliability, please send one copy of your paper to the program committee via each of two of the following methods. All submissions will be acknowledged. o Preferred Method: email (Postscript) to: o Alternate Method: postal delivery to Security Symposium USENIX 2560 Ninth St., Ste. #215 Berkeley CA 94710 U.S.A. Phone: (510) 528-8649 o Fax: (510) 548-5738 Vendor Exhibits Demonstrate your security product to our technically astute attendees responsible for security at their sites. We invite you to take part in the Vendor Display. The informal, table-top display allows you to meet with attendees informally and demonstrate in detail your security solutions. Contact CynthiaDeno Email: cynthia@usenix.org Phone: 408.335.9445 Fax 408.335.5327 Works-in-Progress Session (WIPs) The last session of the symposium will be a Works-in-Progress session consisting of five minute presentations. Speakers should provide a one or two paragraph abstract to the program chair by 6:00 pm on January 28, 1998 at the conference. These should be provided in person, not via email. The chair will post the schedule of presentations by noon on the 29th. Experience at other conferences has shown that usually, all of them are accepted. The five minute time limit will be strictly enforced. INVITED TALKS There will be several invited talks at the conference in parallel with the refereed papers. If you have suggestions for possible speakers, please send them to . REGISTRATION MATERIALS Materials containing all details of the technical and tutorial programs, registration fees and forms, and hotel information will be available at the end of October 1997. To receive the registration materials, please contact: USENIX Conference Office 22672 Lambert Street, Suite 613 Lake Forest, CA USA 92630 Phone: (714) 588-8649 Fax: (714) 588-9706 Email: Information can also be found under the Conference home page: . Date: Mon, 09 Sep 1996 07:07:40 -0400 To: Stephen Kent , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Status of IPSEC Key Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609090731.aa08969@neptune.TIS.COM> Interesting. Different strokes for different folks. At 10:59 PM 9/6/96 -0500, Stephen Kent wrote: > > Times have changed, and the range of uses for which we require >traffic keys has broadened. For example, in work we have been doing with >regard to mobile IP security, there is a desire to have a per-transaction >key, but there is no opportunity to perform ANY messages exchanges to put >this key in place. Moreover, the frequency of the transactions might be as >high as once per second, according to the mobile IP specs, which rules out >most public key computations. Under these constraints, a basic SKIP-like >key generation approach is appropriate, since it requires no >per-transaction exchanges and the precomputation feature of SKIP allows the >per-transaction key generation time to be minimal. Thus we have chosen to >use the SKIP technique (though not the SKIP syntax) for key management in >this context. We have a similar application, maybe not quite the frequency, and for various reasons we are working with application level security; most likely S/MIME enveloping each transaction data set. > In another project we have been dealing with secure communication >between routers, and among other routing infrastructure components. We >have found instances in this program where minimal message exchange key >establishment protocols, and fast (minimal computation) public key >exchanges are appropriate. here too, SKIP-like functionality is >attractive, though not strictly required. I have always been intreged with the idea of a SKIP-like functionality for SNMPv2. Of course in our earlier discussions, SNMP usage is typified as an intra-enterprise problem. > Finally, as the use of multicast increases in the Internet, one of >the features that was originally advertised for SKIP, support for >multi-sender, multicast based on stream ciphers, may become important. I >don't know if SKIP is essential for this, but I've yet to see good >solutions for this application and it would be nice to keep our options >open here. What about the GKMP draft, how does that look? I am bothered by the apparant one master key for a multicast group for the SKIP approach. How is it shared? How is someone dis-associated at the proper time? How do you re-key if sync lost? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa11574; 9 Sep 96 10:35 EDT Received: by relay.hq.tis.com; id KAA06804; Mon, 9 Sep 1996 10:39:16 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma006782; Mon, 9 Sep 96 10:38:49 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25049; Mon, 9 Sep 96 10:37:57 EDT Received: by relay.hq.tis.com; id KAA06777; Mon, 9 Sep 1996 10:38:46 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma006759; Mon, 9 Sep 96 10:38:20 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA23377; Mon, 9 Sep 1996 10:45:42 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 10:42:28 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry, In the Mobile IP case, the communication being authenticated (as per the current specs) is between a mobile node and it's home agent, so there is plenty of time to pre-load and pre-compute the D-H value. In later instances one may wish to autnenticate communication between the mobile node and foreign agents, and between home and foreign agents. Even there, caching ought to enable one to avoid fetches on many (most?) communications. I admit that there are other ways to reduce traffic key generation time once you have communicated with the corresponding parties, but staying within the mobile IP protocol specs, there is no easy way to do the initial exchange. However, the fetch of a certificate from some database is outside the mobile IP protocol, and thus fits within the spec (once you make appropriate provisions for routing cert/CRL fetches, e.g., via a foreign agent proxy). Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa11753; 9 Sep 96 10:49 EDT Received: by relay.hq.tis.com; id KAA05996; Mon, 9 Sep 1996 10:19:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma005991; Mon, 9 Sep 96 10:19:20 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23109; Mon, 9 Sep 96 10:18:28 EDT Received: by relay.hq.tis.com; id KAA05982; Mon, 9 Sep 1996 10:19:16 -0400 Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma005957; Mon, 9 Sep 96 10:18:50 -0400 Received: by janus.border.com id <18473-1>; Mon, 9 Sep 1996 10:19:03 -0400 Message-Id: <96Sep9.101903edt.18473-1@janus.border.com> To: perry@piermont.com Cc: Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management References: <9609090724.aa08819@neptune.TIS.COM> In-Reply-To: perry's message of "Sat, 07 Sep 1996 11:30:43 -0400". <9609090724.aa08819@neptune.TIS.COM> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 9 Sep 1996 10:20:26 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <9609090724.aa08819@neptune.TIS.COM>, "Perry E. Metzger" writes: > > In a large internet, key lookup will be required, the result of which > will be that SKIP will have no advantage whatsoever in terms of number > of message exchanges compared with other techniques. Piggy-back the keys in the Additional Records portion of the DNS response to the initial hostname lookup (I believe some SKIP implementations already do this). -- C. Harald Koch | Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. From: Ran Atkinson Date: Mon, 9 Sep 1996 09:52:26 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: FYI: Multicast Key Management documents Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609091253.aa13265@neptune.TIS.COM> There are a number of documented approaches to multicast key management that this group should consider. Ones that have not been marketed very aggressively include: Group Key Management Protocol (GKMP), developed by SPARTA under ARPA sponsorship circa 1994 based on technology that dates back somewhat before 1994. This has some proof-of-concept code written under the ARPA sponsorship. This was presented at the December 1994 IETF in San Jose and has current Internet-Drafts online as: draft-harney-gkmp-arch-01.txt draft-harney-gkmp-spec-01.txt and will be moving to RFC in the near future. Scalable Multicast Key Distribution, developed by Tony Ballardie, and described in RFC-1949. The above have significantly different technology approaches. Both of these approaches will work well not only with multicasting but also with RSVP and are worth careful review and consideration. I'm told that work is underway at several places (e.g. ORNL) on a PF_KEY-based freely distributable implementation of GKMP technology inside the ISAKMP framework. Ran rja@cisco.com -- To: Stephen Kent Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Mon, 09 Sep 1996 10:42:28 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 09 Sep 1996 13:07:35 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609091310.aa13559@neptune.TIS.COM> Stephen Kent writes: > In the Mobile IP case, the communication being authenticated (as > per the current specs) is between a mobile node and it's home agent, so > there is plenty of time to pre-load and pre-compute the D-H value. Then again, there is no reason an Oakley like protocol can't work just fine there as well -- the associations are long lived. > In later instances one may wish to autnenticate communication > between the mobile node and foreign agents, and between home and > foreign agents. Even there, caching ought to enable one to avoid > fetches on many (most?) communications. And again, since the associations are fairly long lived, Oakley or Photuris or what have you works just fine there. BTW, I'm only arguing that SKIP doesn't actually have an advantage in speed here -- not that its worse. Frankly, at this point I'd like to see the working group agree to recess for six months and see what people implement -- move SKIP and Photuris and Oakley to experimental for a while and regroup after we have more field experience that would give us a better idea of what we really want. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa14146; 9 Sep 96 13:49 EDT Received: by relay.hq.tis.com; id NAA14020; Mon, 9 Sep 1996 13:52:22 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014015; Mon, 9 Sep 96 13:51:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08420; Mon, 9 Sep 96 13:51:02 EDT Received: by relay.hq.tis.com; id NAA14012; Mon, 9 Sep 1996 13:51:52 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xmaa13995; Mon, 9 Sep 96 13:51:33 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id NAA14858; Mon, 9 Sep 1996 13:59:08 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 13:55:42 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry, You're right that if one chose to employ long duration SAs, then similar functionality can be had via other key management protocols. However, in general, I think that the booking associated with maintaing an SA is not justified when the keying material is used just once for a brief exchange. This is not a criticism of any specific key management approach, but just an opinion about when it makes sense to create a new SA vs. maintaining and old one. In some instances establishing a very long lived SA is atractive, with key updates on some trigger basis, but other times the flexibility of creating a new key for a transaction is preferable, because there really is no association per se. Niether is the "right' model in all cases, but rather some times each is preferable. Note that mny message was not intended as an endorsement of SKIP. Neither of the examples I gave of work we were doing used SKIP exactly. Instead, we used the underlying concept of SKIP in a particular context, without making use of the SKIP header. So, my point in sending the message was to raise an isse in terms of what functionality the WG believes it needs in a key management porotocol for IPSEC. One possible answer is that the sort of examples I cited are viewed as not within scope for this WG and thus they do not motivate inclusion of a SKIP-like capability in the key management protocol for IPSEC. Steve To: perry@piermont.com Cc: Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management Date: Mon, 09 Sep 1996 15:46:47 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609091546.aa15541@neptune.TIS.COM> Frankly, at this point I'd like to see the working group agree to recess for six months and see what people implement -- move SKIP and Photuris and Oakley to experimental for a while and regroup after we have more field experience that would give us a better idea of what we really want. We can't do that. There are too many implementations of IPSEC out there that can't quite interoperate, because they don't share common key management. If we delay, something will fill the vacuum -- and it may not be something we like. For example, it may be proprietary, lack PFS, and be insecure. My own preference is for ISAKMP/Oakley. But I agree that SKIP has attributes that make it preferable for some applications. As a rough rule of thumb, SKIP works best in applications that are best-suited to UDP: many-to-one or many-to-many applications (i.e., network management and multicast protocols), or casual query/response without prior setup (such as DNS). With the exception of DNS queries -- and it isn't clear if they even need IPSEC, given that they'll have DNSSEC (and yes, I know about traffic analysis) -- I suspect that other uses are among comparatively limited communities of interest, and with some prearrangement. I suggest, therefore, that on the order of 16-32 SPIs be used for SKIP, half with standard D-H exponents and moduli, and half with locally-configured values. The routing tables (or some other static, local table) would define when these SPIs should be used (or accepted). Another way to phrase it is that I like SKIP as a transform, but not as a general key management protocol. As a future work item, we might want to consider a protocol to negotiate SKIP communities, possibly within the ISAKMP framework. Received: from relay.hq.tis.com by neptune.TIS.COM id aa16128; 9 Sep 96 16:37 EDT Received: by relay.hq.tis.com; id QAA21624; Mon, 9 Sep 1996 16:41:23 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021608; Mon, 9 Sep 96 16:40:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02621; Mon, 9 Sep 96 16:40:03 EDT Received: by relay.hq.tis.com; id QAA21605; Mon, 9 Sep 1996 16:40:53 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma021603; Mon, 9 Sep 96 16:40:44 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id QAA36106; Mon, 9 Sep 1996 16:42:11 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id QAA39853; Mon, 9 Sep 1996 16:41:43 -0400 Message-Id: <199609092041.QAA39853@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2785; Mon, 09 Sep 96 16:40:54 EDT Date: Mon, 9 Sep 96 16:40:54 EDT To: kent@bbn.com Cc: ipsec@TIS.COM Subject: Status of IPSEC Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Mon, 9 Sep 1996 13:55:42 -0400 (attached) > Note that mny message was not intended as an endorsement of SKIP. > Neither of the examples I gave of work we were doing used SKIP exactly. > Instead, we used the underlying concept of SKIP in a particular context, > without making use of the SKIP header. So, my point in sending the message > was to raise an isse in terms of what functionality the WG believes it > needs in a key management porotocol for IPSEC. One possible answer is that Steve, can you point out to what functionality of SKIP you are referring to: is that the in-line keying or is it the 0-round key agreement based on DH-certicates? These two aspects are not necessarily bound together. For example, you can use in-line keying based on a key-encrypting-key derived in some other way (Oakley, for example), or you can use DH-certificates as the basis for a hand-shake to derive fresh keys. Also, when you say SKIP you mean plain SKIP or SKIP with PFS? I believe a clarification here will be useful. Thanks, Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa16911; 9 Sep 96 17:46 EDT Received: by relay.hq.tis.com; id RAA22856; Mon, 9 Sep 1996 17:49:54 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022848; Mon, 9 Sep 96 17:49:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05588; Mon, 9 Sep 96 17:48:34 EDT Received: by relay.hq.tis.com; id RAA22845; Mon, 9 Sep 1996 17:49:23 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma022831; Mon, 9 Sep 96 17:49:04 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Mon, 9 Sep 1996 17:51:06 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id RAA00478; Mon, 9 Sep 1996 17:51:03 -0400 Message-Id: <199609092151.RAA00478@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Steven Bellovin Cc: perry@piermont.com, Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: smb's message of Mon, 09 Sep 1996 15:46:47 -0400. <9609091546.aa15541@neptune.TIS.COM> Date: Mon, 09 Sep 1996 17:50:58 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk SKIP-style in-band keying is good because it doesn't add more round-trips. It's bad because it involves extra overhead on each packet.. SKIP's 20-28 bytes/packet (assuming 8-16 byte traffic keys) adds ~50% to the size of a TCP ACK. Has anyone (other than me) considered a scheme whereby in-band messages are used to set up a SA, and thereafter omitted from the packets? One way to do this would be to include fields saying "respond to this on SPI until " in the in-band-keying header; once an explicit SPI had been set up between peers, the in-band header would not be used. This would add ~8 bytes to the in-band keying header (assuming a 4-byte reply SPI, and a 4-byte lifetime). For a typical TCP exchange, the in-band keying headers would piggyback on the SYN and SYN/ACK packets, and then be absent from subsequent traffic. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa17258; 9 Sep 96 18:12 EDT Received: by relay.hq.tis.com; id SAA23421; Mon, 9 Sep 1996 18:15:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023413; Mon, 9 Sep 96 18:14:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06234; Mon, 9 Sep 96 18:14:04 EDT Received: by relay.hq.tis.com; id SAA23408; Mon, 9 Sep 1996 18:14:53 -0400 Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma023406; Mon, 9 Sep 96 18:14:39 -0400 Received: by janus.border.com id <18434-1>; Mon, 9 Sep 1996 18:15:28 -0400 Message-Id: <96Sep9.181528edt.18434-1@janus.border.com> To: Bill Sommerfeld Cc: Steven Bellovin , perry@piermont.com, Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management References: <199609092151.RAA00478@thunk.orchard.medford.ma.us> In-Reply-To: sommerfeld's message of "Mon, 09 Sep 1996 17:50:58 -0400". <199609092151.RAA00478@thunk.orchard.medford.ma.us> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 9 Sep 1996 18:16:35 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199609092151.RAA00478@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > SKIP-style in-band keying is good because it doesn't add more > round-trips. It's bad because it involves extra overhead on each > packet.. SKIP's 20-28 bytes/packet (assuming 8-16 byte traffic keys) > adds ~50% to the size of a TCP ACK. Are there really places in the Internet where this is still a problem? I suppose those asymmetric bandwidth cable modems might be a problem; any others? -- Harald Koch chk@border.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa17572; 9 Sep 96 18:31 EDT Received: by relay.hq.tis.com; id SAA23604; Mon, 9 Sep 1996 18:35:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023602; Mon, 9 Sep 96 18:34:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06693; Mon, 9 Sep 96 18:34:04 EDT Received: by relay.hq.tis.com; id SAA23599; Mon, 9 Sep 1996 18:34:53 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma023593; Mon, 9 Sep 96 18:34:23 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Mon, 9 Sep 1996 18:36:38 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id SAA00539; Mon, 9 Sep 1996 18:36:36 -0400 Message-Id: <199609092236.SAA00539@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "C. Harald Koch" Cc: Steven Bellovin , perry@piermont.com, Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: chk's message of Mon, 09 Sep 1996 18:16:35 -0400. <96Sep9.181528edt.18434-1@janus.border.com> Date: Mon, 09 Sep 1996 18:36:33 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Are there really places in the Internet where this is still a > problem? I'd say that it is a problem for the 99% of end-users out there who have to use analog modems at 28.8 (or slower) to connect. For those of you closer to the bleeding edge, I have this funny feeling that IP+ESP+TCP will fit in 2 ATM cells, but IP+SKIP+ESP+TCP won't. [What's the per-IP-packet ATM framing overhead? It's got to be more than 8 bytes as I thought that a 40-byte minimal IP+TCP packet doesn't fit in a single 48-byte cell] - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa21499; 10 Sep 96 2:24 EDT Received: by relay.hq.tis.com; id CAA29517; Tue, 10 Sep 1996 02:27:38 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma029515; Tue, 10 Sep 96 02:27:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14782; Tue, 10 Sep 96 02:26:19 EDT Received: by relay.hq.tis.com; id CAA29512; Tue, 10 Sep 1996 02:27:08 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma029507; Tue, 10 Sep 96 02:26:47 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id XAA27398; Mon, 9 Sep 1996 23:26:33 -0700 (PDT) Date: Mon, 9 Sep 1996 23:26:33 -0700 (PDT) From: Phil Karn Message-Id: <199609100626.XAA27398@servo.qualcomm.com> To: skrenta@osmosys.incog.com Cc: ipsec@TIS.COM In-Reply-To: <199609061817.LAA06333@miraj.incog.com> (message from Rich Skrenta on Fri, 6 Sep 1996 11:17:23 -0700 (PDT)) Subject: Re: SKIP Design & Applicability Statement Sender: ipsec-approval@neptune.tis.com Precedence: bulk >There is one (important) aspect in which PFS offers a better defense than a >non-PFS solution. Namely, if the key-compromise is discovered, the keys may >be revoked, thereby protecting against future impersonation attacks and >still preserving the secrecy of past encrypted data. Key compromises don't have to be "discoverable" to make PFS worthwhile. The PFS "crank" can be "turned" on a regular basis according to local policy just as symmetric keys are periodically refreshed. This limits the amount of data that can be compromised at once to that sent after the last PFS rekey. It seems to me that with the right protocol, then just having a PFS update policy in place could create a considerable deterrent to the active attack that can occur if a long-term authentication key is compromised. That is, if I steal your long-term authentication key and use it to impersonate you, I should be stuck. I should be required to keep you from ever communicating again with the hosts I'm tricking, because if you do you'll discover the attack and change your keys. I'm not sure, but this does seem to require more state than SKIP provides. Phil From: Rich Skrenta Message-Id: <199609092319.QAA13224@miraj.incog.com> Subject: Re: Status of IPSEC Key Management To: ipsec@TIS.COM Date: Mon, 9 Sep 1996 16:19:00 -0700 (PDT) In-Reply-To: <199609092151.RAA00478@thunk.orchard.medford.ma.us> from "Bill Sommerfeld" at Sep 9, 96 05:50:58 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Has anyone (other than me) considered a scheme whereby in-band > messages are used to set up a SA, and thereafter omitted from the > packets? We've talked about possible optimizations and header compression schemes, but haven't yet pursued these ideas, mostly because the size of SKIP packets hasn't been an issue in our actual deployments. Compared with other impacts on total performance (such as the speed of Triple DES in software), a few extra bytes in each packet are not noticed. Date: Mon, 9 Sep 1996 16:15:23 -0700 From: Ran Atkinson Message-Id: <199609092315.QAA25197@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: bandwidth in the Internet In-Reply-To: <96Sep9.181528edt.18434-1@janus.border.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <96Sep9.181528edt.18434-1@janus.border.com>, Harold Koch wrote: >Are there really places in the Internet where this [bandwidth] is still >a problem? Sure. Lots of places. >I suppose those asymmetric bandwidth cable modems might be a problem; >any others? Other current examples of low-bandwidth links in production TCP/IP use: -- thousands (millions yet ?) of 28.8 modem dialup links from Windows/Macintosh/etc users who go web surfing and exchanging email via their Internet providers. -- Satellite links, which are not that uncommon now and which are growing rapidly. Hughes Network Systems (Gaithersburg, MD) and other VSAT terminal manufacturers are making nice profits selling IP/SATCOM services around the globe. I even saw a VSAT advertisement in this month's Computer Shopper. Emerging technologies such as Iridium (which handles mobility via the link layer, btw) are also fairly low bandwidth. -- IP/AX.25 use by Amateur Radio operators. Rates of 2400 bps are not unusual with IP/AX.25 links, though some are higher. -- IP/HF Radio links are commonly used by various governmental and military organisations both US Government and also other governments. These frequently run at 2400bps. Ran rja@cisco.com From: Dan McDonald Message-Id: <199609092126.OAA28953@kebe.eng.sun.com> Subject: Re: Everything degenerates to Key Management To: ipsec@TIS.COM Date: Mon, 9 Sep 1996 14:26:54 -0800 (PDT) Cc: Dan McDonald X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is in reply to a note sent a bit back by Michael Richardson. > skrenta> I'll submit that this has more to do with ACL management, i.e. the > skrenta> "naming problem", than the underlying encryption protocol. > > I agree with this. But, if we can not decide on what the underlying > encryption protocol is, then we can not even deploy the *simple* things > that people want to do. Thus the "groundswell" of support on the list for > SKIP. It solves these people's problems *now*. SKIP is not an "underlying encryption protocol." It is a method of transmitting the cryptographic keys so that encryption and decryption can take place, hence the term "key management." > Rather, you have to change your kernel unless someone decides to support > both, and I do not know how the two systems will interact. I have not seen, > for instance extensions to the BSD44 socket API on how SKIP will be > available to user processes wishing keying. (Yes, this is Unix specific, > but how many TCP/IP capable systems do *not* support some kind of BSD-like > socket API?) Network API extensions for having users turn on IP-level encryption or IP-level authentication haven't been thought out, from what I've seen. GSS-API may be useful in such a context, but I found the sheer bulk of it intimidating. The NRL IPv6/IPsec code has a _very_ primitive API for requesting security services. The above paragraph and its issues are ORTHOGONAL to what key management strategy is used. It doesn't matter if you implement one, the other, or both (and you CAN implement both, see below), it's still an issue. > skrenta> Designing crypto exchanges and packet formats is comparatively easy; > skrenta> informing your machine that it's supposed to encrypt with a > particular set > skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP > skrenta> address is hard. But insofar as a workable solution is developed, I > skrenta> believe that it should prove fairly independent of the underlying > skrenta> encryption system. > > skrenta> This problem is really at a different level than the SKIP vs. Oakley > skrenta> debate, since neither set of drafts speak much to this issue. By that, if you mean setting up what ESP/AH algorithms are preferred, perhaps what ESP/AH algorithms are REQUIRED for communications on that machine, yes, it's a different level. It's called POLICY, and policy and mechanism are separate. If you mean what ESP/AH algorithms and modes can be used between a (possibly randomly assigned) IP address and me, there are already solutions for this. SKIP has its {Certificate, Algorithm} Discovery protocols, and the whole idea behind ISAKMP is that these very parameters are NEGOTIATED between the two machines before a session begins. Speaking of certificates, and problems orthogonal to key management debates, here's something I have to ask. _Regardless_ of key management, is it not true that each security endpoint is defined by the certificate associated with it? If so, this may answer questions about "user oriented" or whatever buzzwords you want to use to state that IPsec keys should be unique per session. > I had hoped that the meetings would come up with a way to incorporate > the SKIP header into the IPsec architectural draft (rfc1825). I have some > ideas on how to do this, but I do not have enough experience with both SKIP > and rfc1825 to do this on my own. I have plenty of experience with RFC 1825, and being where I am, I am quickly learning about SKIP. Quite frankly, I'm surprised nobody else has thought of the idea of having a "SKIP transform" that fits the relevant SKIP header information INSIDE a vanilla ESP or AH header. Quite frankly, in highly-modular environments (such as my current one), I can win big in implementation, because I have MUCH MORE control over the interface between transforms and ESP/AH, than I do between putting yet another higher-level protocol on top of IP. This control I mention allows better optimization and other code-reuse issues. In a not-so-modular environment (i.e. BSD) it's a wash, 6 one, half dozen the other. > If the stuff on the wire could be compatible at the "manual keying" > level, and an API similar to PF_KEY could accomodate SKIP keying, then we > could solve the other problems later. Some smart person may come up with a > hybrid solution that looks like neither solution. I have thought quite a bit about how PF_KEY could be made to accomodate SKIP keying. Particularly, the SKIP Kij keys could be computed in user-land, and fed into the kernel via PF_KEY, where they are used for the SKIP packets flowing across the wire. This also means you can build {Cert, Alg.} discovery in user-space as daemons. Unless I'm totally wrong about PF_KEY being able to work with SKIP, then it's VERY FEASIBLE to build SKIP, Oakley, and Photuris into the same box. More on this after I explain in-band vs. out-of-band... As for the stuff on the wire being compatible, the big difference between SKIP and your choice of Photuris or Oakley is that SKIP is in-band keying, where the session key is part of the packet (cryptanalysts, take note), and that both Photuris and Oakley are out-of-band keying, where an exchange (authenticated exchange, I hope :) takes place before data squeezes out of the wire. This difference in approach makes compatibility hard. Now that I've explained that, if you have PF_KEY that works, you can build ARBITRARY out-of-band keying systems. And with your favorite in-band keying system being implemented in-kernel (i.e. SKIP), you have a system that addresses ALL of your key management needs. Manual keying, BTW, is part of RFC 1825. I should be able to manually configure an SPI, with the relevant keying information. Tom Markson at Montreal mentioned that the latest SKIP release for {FreeBSD, SunOS 4.1,x} supports manual SPI's per RFC 1825. I hope this adds useful implementation-oriented data to the discussion. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + To: HUGO@watson.ibm.com Cc: kent@bbn.com, ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management Date: Tue, 10 Sep 1996 07:29:31 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609100737.aa24438@neptune.TIS.COM> Steve, can you point out to what functionality of SKIP you are referring to: is that the in-line keying or is it the 0-round key agreement based on DH-certicates? These two aspects are not necessarily bound together. For example, you can use in-line keying based on a key-encrypting-key derived in some other way (Oakley, for example), or you can use DH-certificates as the basis for a hand-shake to derive fresh keys. I'm primarily referring to the in-line keying. The use of D-H is elegant, though not, of course, necessary. (I proposed an in-line keying mechanism in a 1990 paper.) But at this point in the game, there isn't a lot of merit to inventing new protocols that do the exact same thing as old ones. SKIP is fully developed and implemented; without a demonstration of major new functionality, I'd be loathe to pursue another path now. Also, when you say SKIP you mean plain SKIP or SKIP with PFS? Plain SKIP. SKIP with PFS demands negotiation. Let's make SKIP as light-weight as possible, as it originally was, and use it for a few selected applications. ISAKMP/Oakley is the full-fledged, heavy-duty protocol that does everything. Received: from relay.hq.tis.com by neptune.TIS.COM id aa24622; 10 Sep 96 7:55 EDT Received: by relay.hq.tis.com; id HAA02314; Tue, 10 Sep 1996 07:59:08 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma002286; Tue, 10 Sep 96 07:58:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20619; Tue, 10 Sep 96 07:57:49 EDT Received: by relay.hq.tis.com; id HAA02283; Tue, 10 Sep 1996 07:58:38 -0400 Received: from lint.cisco.com(171.68.223.44) by relay.tis.com via smap (V3.1.1) id xma002281; Tue, 10 Sep 96 07:58:36 -0400 Received: from pferguso-pc.cisco.com ([171.68.52.54]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id FAA04159; Tue, 10 Sep 1996 05:00:29 -0700 Message-Id: <2.2.32.19960910120028.0073131c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 08:00:28 -0400 To: Ran Atkinson From: Paul Ferguson Subject: Re: bandwidth in the Internet Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk And although this is drifting far afield of IPSEC (and one would also argue whether or not these locations could be considered part of the Internet-at-large or not, but I digress), there are plenty of places on the planet where getting any bandwidth *at all* is still a major excerise. A lot of the South Pacific islands still have problems getting better than 2400 bps. - paul At 04:15 PM 9/9/96 -0700, Ran Atkinson wrote: >In article <96Sep9.181528edt.18434-1@janus.border.com>, > Harold Koch wrote: >>Are there really places in the Internet where this [bandwidth] is still >>a problem? > >Sure. Lots of places. > >>I suppose those asymmetric bandwidth cable modems might be a problem; >>any others? > >Other current examples of low-bandwidth links in production TCP/IP use: > > -- thousands (millions yet ?) of 28.8 modem dialup links > from Windows/Macintosh/etc users who go web surfing and > exchanging email via their Internet providers. > > -- Satellite links, which are not that uncommon now and > which are growing rapidly. Hughes Network Systems > (Gaithersburg, MD) and other VSAT terminal manufacturers > are making nice profits selling IP/SATCOM services around > the globe. I even saw a VSAT advertisement in this month's > Computer Shopper. Emerging technologies such as Iridium > (which handles mobility via the link layer, btw) are also > fairly low bandwidth. > > -- IP/AX.25 use by Amateur Radio operators. Rates of 2400 bps > are not unusual with IP/AX.25 links, though some are higher. > > -- IP/HF Radio links are commonly used by various governmental > and military organisations both US Government and also other > governments. These frequently run at 2400bps. > >Ran >rja@cisco.com > Received: from relay.hq.tis.com by neptune.TIS.COM id aa24964; 10 Sep 96 8:24 EDT Received: by relay.hq.tis.com; id IAA03246; Tue, 10 Sep 1996 08:27:38 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003241; Tue, 10 Sep 96 08:27:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21886; Tue, 10 Sep 96 08:26:19 EDT Received: by relay.hq.tis.com; id IAA03238; Tue, 10 Sep 1996 08:27:08 -0400 Received: from lint.cisco.com(171.68.223.44) by relay.tis.com via smap (V3.1.1) id xma003231; Tue, 10 Sep 96 08:26:54 -0400 Received: from pferguso-pc.cisco.com ([171.68.52.54]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id FAA15997; Tue, 10 Sep 1996 05:27:02 -0700 Message-Id: <2.2.32.19960910122701.006d4e5c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 08:27:01 -0400 To: Edgar Der-Danieliantz From: Paul Ferguson Subject: Re: bandwidth in the Internet Cc: rja@cisco.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk When I said '...one would argue...', I didn't necessarily mean I would be the one to argue the point. ;-) - paul At 04:22 PM 9/10/96 +0400, Edgar Der-Danieliantz wrote: >> And although this is drifting far afield of IPSEC (and one would >> also argue whether or not these locations could be considered part >> of the Internet-at-large or not, but I digress), there are plenty >> of places on the planet where getting any bandwidth *at all* is >> still a major excerise. A lot of the South Pacific islands still >> have problems getting better than 2400 bps. > >You mean satellite-connected networks aren't Internet? 70% of non-US >networks are connected via satellite links, with speeds ranging from 56k >to 8mbps. Only small percent of networks connected via fiber, etc. > >Just my 5c, IMHO, > > >-edgar > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s Subject: Re: bandwidth in the Internet To: Paul Ferguson Date: Tue, 10 Sep 1996 16:22:26 +0400 (AMT) Cc: rja@cisco.com, ipsec@TIS.COM In-Reply-To: <2.2.32.19960910120028.0073131c@lint.cisco.com> from "Paul Ferguson" at Sep 10, 96 08:00:28 am Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: ipsec-approval@neptune.tis.com Message-ID: <9609100839.aa25147@neptune.TIS.COM> > And although this is drifting far afield of IPSEC (and one would > also argue whether or not these locations could be considered part > of the Internet-at-large or not, but I digress), there are plenty > of places on the planet where getting any bandwidth *at all* is > still a major excerise. A lot of the South Pacific islands still > have problems getting better than 2400 bps. You mean satellite-connected networks aren't Internet? 70% of non-US networks are connected via satellite links, with speeds ranging from 56k to 8mbps. Only small percent of networks connected via fiber, etc. Just my 5c, IMHO, -edgar From: Edgar Der-Danieliantz Message-Id: <199609101234.QAA00689@aic.net> Subject: Re: bandwidth in the Internet To: Paul Ferguson Date: Tue, 10 Sep 1996 16:34:24 +0400 (AMT) Cc: edd@aic.net, rja@cisco.com, ipsec@TIS.COM In-Reply-To: <2.2.32.19960910122701.006d4e5c@lint.cisco.com> from "Paul Ferguson" at Sep 10, 96 08:27:01 am Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > When I said '...one would argue...', I didn't necessarily mean I > would be the one to argue the point. ;-) > > - paul Okay, pardon me, I missed it :o) -edd Received: from relay.hq.tis.com by neptune.TIS.COM id aa26997; 10 Sep 96 10:42 EDT Received: by relay.hq.tis.com; id KAA07991; Tue, 10 Sep 1996 10:46:19 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007974; Tue, 10 Sep 96 10:45:50 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29528; Tue, 10 Sep 96 10:44:59 EDT Received: by relay.hq.tis.com; id KAA07968; Tue, 10 Sep 1996 10:45:48 -0400 Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma007951; Tue, 10 Sep 96 10:45:16 -0400 Received: by janus.border.com id <18492-1>; Tue, 10 Sep 1996 10:46:04 -0400 Message-Id: <96Sep10.104604edt.18492-1@janus.border.com> To: ipsec@TIS.COM Subject: Re: bandwidth in the Internet References: <199609092315.QAA25197@puli.cisco.com> In-Reply-To: Your message of "Mon, 09 Sep 1996 19:15:23 -0400". <199609092315.QAA25197@puli.cisco.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 10 Sep 1996 10:47:25 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ok, let me rephrase my question. How many places in the Internet is an extra 20-30 bytes of overhead *really* a problem? We've already inflated packet sizes with IPv6, remember? How many of these environments simply couldn't live with the extra overhead in exchange for the security benefits? Just for fun, Here is an example of packet overhead causing problems (cable modems): At least one cable modem I've heard about has 10Mbps in one direction, and 28.8Kbps in the backchannel. Assuming 45 bytes/ACK (40 + ~5 for PPP), you can get a maximum of 80 ACK/sec through the backchannel. This means 160 packets/sec in the forward direction (TCP acks every second segment); this yields a maximum bandwidth usage of 1.92Mbps (using 1500 byte MTU). Only 1/5th the available bandwidth. Increasing the ACK size to 65 bytes (20 for SKIP+ESP?) yields 660Kbps throughput on the forward channel; even worse. Are there others? I don't see a problem with 28.8, for example; usage is highly asymmetric, and V.34 modems have much higher problems with internal latency than we would be adding with IPsec overhead. Any others? -- Harald Message-Id: <199609101531.LAA29366@jekyll.piermont.com> To: Rich Skrenta Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Mon, 09 Sep 1996 16:19:00 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 10 Sep 1996 11:31:44 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rich Skrenta writes: > We've talked about possible optimizations and header compression schemes, > but haven't yet pursued these ideas, mostly because the size of SKIP > packets hasn't been an issue in our actual deployments. Compared with > other impacts on total performance (such as the speed of Triple DES in > software), a few extra bytes in each packet are not noticed. That is comparing apples and oranges. Almost any machine can keep up with the speed needed to run 3DES at 28.8, so at dialup speeds the overhead there is ignorable -- on the other hand, extra overhead on a dialup line slows your real performance considerably, and it is true that most of the world still is on dialup modems. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa27884; 10 Sep 96 11:57 EDT Received: by relay.hq.tis.com; id MAA10738; Tue, 10 Sep 1996 12:00:50 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010732; Tue, 10 Sep 96 12:00:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04538; Tue, 10 Sep 96 11:59:31 EDT Received: by relay.hq.tis.com; id MAA10726; Tue, 10 Sep 1996 12:00:20 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma010717; Tue, 10 Sep 96 11:59:52 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id JAA14608; Tue, 10 Sep 1996 09:05:47 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA23001; Tue, 10 Sep 1996 09:02:20 -0700 Message-Id: <199609101602.JAA23001@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Bill Sommerfeld Cc: Steven Bellovin , perry@piermont.com, Stephen Kent , ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Mon, 09 Sep 1996 17:50:58 EDT." <199609092151.RAA00478@thunk.orchard.medford.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 09:02:19 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <199609092151.RAA00478@thunk.orchard.medford.ma.us> you write: >SKIP-style in-band keying is good because it doesn't add more >round-trips. That's not necessarily true. The general SKIP case requires: 1) Certificate Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two messages; and, if PFS is desired, 3) the PFS extension, two more messages. A total of 6 messages required-- 4 if PFS is not desired. (Also note that CDP is UDP-based, and ADP is ICMP-based requiring key managment in three places). Oddly enough, ISAKMP+Oakley with PFS using "Aggressive Mode" also requires 6 messages; "Main Mode" with PFS requires 9 messages. Since certificates can be piggybacked onto a normal ISAKMP payload no discovery is necessary; ISAKMP+Oakley is one single key managment solution, not three. It should also be noted that SKIP PFS and no pre-cached state requires 2 Diffie-Hellman exponentiations-- once to compute g^xj and again to compute g^ij. The expense of these (in CPU as well as wall clock terms) will greatly outweigh the cost of a few messages. And, as you noted earlier, SKIP PFS does not provide PFS for identities. Just as SKIP implementations can cache state for optimization (for example, cut down the number of D-H exponentiations for PFS), so can ISAKMP+Oakley. An ISAKMP+Oakley implementation can create N SAs with a single key management session and cache these for future use in the Key Engine. When a new SA is needed, one of these "larval" SAs can be used directly. Since locality holds for most IP traffic this optimization will be quite practical. The ability to reserve a block of SPI-space at a time will also work well with RSVP. > It's bad because it involves extra overhead on each >packet.. SKIP's 20-28 bytes/packet (assuming 8-16 byte traffic keys) >adds ~50% to the size of a TCP ACK. It also renders the SPI useless which makes RSVP support difficult (and calls into question full compliance with RFC1826 and RFC1827 since it is the MKID + IP address, not the SPI + IP address, that identifies state). The multicast extension also doesn't scale well to highly dynamic multicast groups (unicast request/response for every member to group owner to obtain GIK). > Has anyone (other than me) considered a scheme whereby in-band > messages are used to set up a SA, and thereafter omitted from the > packets? > > One way to do this would be to include fields saying "respond to this > on SPI until " in the in-band-keying header; once an > explicit SPI had been set up between peers, the in-band header would > not be used. > > This would add ~8 bytes to the in-band keying header (assuming a > 4-byte reply SPI, and a 4-byte lifetime). > > For a typical TCP exchange, the in-band keying headers would piggyback > on the SYN and SYN/ACK packets, and then be absent from subsequent > traffic. This is a very interesting idea. I floated a variant on this scheme in the key management design group. It lacked the "respond to this on SPI " though and instead just established a SA for SPI one. Your idea seems much more practical. Dan. Message-Id: <199609101550.LAA29430@jekyll.piermont.com> To: "C. Harald Koch" Cc: ipsec@TIS.COM Subject: Re: bandwidth in the Internet In-Reply-To: Your message of "Tue, 10 Sep 1996 10:47:25 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 10 Sep 1996 11:50:19 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk "C. Harald Koch" writes: > Ok, let me rephrase my question. > > How many places in the Internet is an extra 20-30 bytes of overhead *really* > a problem? We've already inflated packet sizes with IPv6, remember? How many > of these environments simply couldn't live with the extra overhead in > exchange for the security benefits? Van J's header compression takes out most of the expanded IP address size and all the rest on slow links. It is unclear that you can do that with the SKIP header. And yes, when you are already talking about several hundred milliseconds RTT for an ICMP Echo Request, every byte counts. Dialup modem pools are big business. Perry From: Rich Skrenta Message-Id: <199609101556.IAA13738@miraj.incog.com> Subject: Re: Status of IPSEC Key Management To: ipsec@TIS.COM Date: Tue, 10 Sep 1996 08:56:17 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > -- on the other hand, extra overhead on a > dialup line slows your real performance considerably, and it is true > that most of the world still is on dialup modems. By "considerably", you mean the extra 10ms needed to send 28 bytes at 28.8k? I said it hadn't been an issue in our actual deployments, because we're actually using this stuff over slow links, and the people who are using it aren't ranking "make it faster" highly on their feedback to us. We have a pilot with 40 employees coming into our network over Ricochet radio modems through a SKIP encrypting gateway. The performance loss from encryption tends to get lost in the natural slowness of the Ricochet. Lots of folks have been bemoaning the poor, slow-bound Internet peon. I've actually been using SKIP over a Ricochet modem for my sole access to the inet and work from home for the past six months. I can't tell the difference between SKIP-on and SKIP-off. I do have lots of things on my wish-list for our current software, but optimizing bytes out of the SKIP packet doesn't even make the list. From: Dermot Tynan Message-Id: <9609101621.AA11693@karpov.fws.ilo.dec.com> Subject: Re: bandwidth in the Internet To: "C. Harald Koch" Date: Tue, 10 Sep 1996 17:21:12 +0000 (BST) Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk C. Harald Koch wrote: > > How many places in the Internet is an extra 20-30 bytes of overhead *really* > a problem? We've already inflated packet sizes with IPv6, remember? How many > of these environments simply couldn't live with the extra overhead in > exchange for the security benefits? Well, one of the big areas (IMHO) for security is telnet. While an extra 20 bytes isn't too bad over FTP with a high packet size, the average typist can end up with around 40 bytes per keystroke (in each direction). Now add an extra 20-30 bytes and you've effectively halved the throughput. OK, I know that no single session would notice the loss of bandwidth if they're typing that slowly. However, attach enough people to the network, each one sending a packet per keystroke, and you're talking real bandwidth killers. - Der -- Dermot Tynan +353 91 754608 dtynan@ilo.dec.com DTN: 822-4608 Digital Equipment International BV, Galway, Ireland Received: from relay.hq.tis.com by neptune.TIS.COM id aa29356; 10 Sep 96 13:52 EDT Received: by relay.hq.tis.com; id NAA14170; Tue, 10 Sep 1996 13:55:39 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014161; Tue, 10 Sep 96 13:55:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11360; Tue, 10 Sep 96 13:54:24 EDT Received: by relay.hq.tis.com; id NAA14146; Tue, 10 Sep 1996 13:55:12 -0400 Received: from ns.gte.com(132.197.8.9) by relay.tis.com via smap (V3.1.1) id xma014133; Tue, 10 Sep 96 13:54:57 -0400 Received: from rcmppc2 by ns.gte.com (8.7.5/) Message-Id: <2.2.32.19960910175517.0034cff0@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 13:55:17 -0400 To: Stephen Kent From: Stuart Jacobs Subject: Re: Status of IPSEC Key Management Cc: perry@piermont.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, Let me introduce myself. I am looking into ways to provide secure route optimized mobile IP support for tactical battlefields and large commercial network deployments. I have been following the mobile ip wp and ipsec wp lists for a while and have come to believe that your point below is valid >but staying within the mobile IP protocol specs, there is no easy way to do >the initial exchange. However, the fetch of a certificate from some >database is outside the mobile IP protocol, and thus fits within the spec I also believe that the current mobile IP approaches, using a shared secret keyed MD5 authentication, just will not scale up to 1000s of mobile hosts and mobile routers. I am looking into using an RSA digital signature approach for authentication with caching of public keys by HAs, FAs and MHs. I know that MD5 is much faster to compute and verify than RSA digital signatures but when you weigh the fewer network exchanges of fetching certs from CAs against the DH exchanges I think the time difference will diminish. I've yet to construct a simulation to verify this point. The key distribution problem of the current mobile IP drafts seem adequate for small network deployments. But what will happen when 10,000 mobile hosts and mobile routers are roaming around in a hostile combat environment? I also think that security associations Must exist between MHs and FAs as well as FAs and HAs in both the military and commercial areas. The commercial area needs this for non-reputable billing and the military for network integrity. I would appreciate your thoughts on these points? Stuart At 10:42 AM 9/9/96 -0400, Stephen Kent wrote: >Perry, > > In the Mobile IP case, the communication being authenticated (as >per the current specs) is between a mobile node and it's home agent, so >there is plenty of time to pre-load and pre-compute the D-H value. In >later instances one may wish to autnenticate communication between the >mobile node and foreign agents, and between home and foreign agents. Even >there, caching ought to enable one to avoid fetches on many (most?) >communications. I admit that there are other ways to reduce traffic key >generation time once you have communicated with the corresponding parties, >but staying within the mobile IP protocol specs, there is no easy way to do >the initial exchange. However, the fetch of a certificate from some >database is outside the mobile IP protocol, and thus fits within the spec >(once you make appropriate provisions for routing cert/CRL fetches, e.g., >via a foreign agent proxy). > >Steve > > > > ========================== Stuart Jacobs Secure Systems Department GTE Labs, Room 3-198 40 Sylvan Road Waltham, MA 02254 (617)466-3076 ========================== From: Rich Skrenta Message-Id: <199609101823.LAA13815@miraj.incog.com> Subject: Re: Status of IPSEC Key Management To: perry@piermont.com Date: Tue, 10 Sep 1996 11:23:13 -0700 (PDT) Cc: ipsec@TIS.COM X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Not to mention the fact that Ricochets send packets at well above > 50kbps, don't they? 100kbps, but I have my serial port locked at 19.2... To: "C. Harald Koch" Cc: ipsec@TIS.COM Subject: Re: bandwidth in the Internet Date: Tue, 10 Sep 1996 13:57:17 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609101441.aa00519@neptune.TIS.COM> Ok, let me rephrase my question. How many places in the Internet is an extra 20-30 bytes of overhead *really* a problem? We've already inflated packet sizes with IPv6, remember? How many of these environments simply couldn't live with the extra overhead in exchange for the security benefits? Just for fun, Here is an example of packet overhead causing problems (cable modems): At least one cable modem I've heard about has 10Mbps in one direction, and 28.8Kbps in the backchannel. Yup, I use one. Assuming 45 bytes/ACK (40 + ~5 for PPP), you can get a maximum of 80 ACK/sec through the backchannel. This means 160 packets/sec in the forward direction (TCP acks every second segment); this yields a maximum bandwidth usage of 1.92Mbps (using 1500 byte MTU). Only 1/5th the available bandwidth. Empirically, I get about a quarter of that -- modems have a moderately high fixed delay per packet. Increasing my TCP window size ups throughput, I'm told. Increasing the ACK size to 65 bytes (20 for SKIP+ESP?) yields 660Kbps throughput on the forward channel; even worse. Are there others? I don't see a problem with 28.8, for example; usage is highly asymmetric, and V.34 modems have much higher problems with internal latency than we would be adding with IPsec overhead. Any others? -- Harald To: Ran Atkinson Cc: ipsec@TIS.COM Subject: Re: bandwidth in the Internet Date: Tue, 10 Sep 1996 14:44:57 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609101449.aa00735@neptune.TIS.COM> Just for fun, I decided to look at some actual numbers. I used http://www.nlanr.net/NA/Learn/packetsizes.html as a source of packet size distributions. Using the Hughes combined transform, with an overhead of 24 bytes plus the padding length (and I calculated the exact amount of padding for each packet size), the total bandwidth hit is about 10%. The SKIP header is another 12 bytes (and isn't a multiple of 8, which will cause problems for IPv6); this brought the overhead to 15%. Frankly, that's just not that much; those of us who used to use slow modems will recall that it takes a factor of at least two, and more often four, in line speed to have a strong human effect. (The jump from 300 bps to 1200 was more important than the jump from 1200 to 2400... And I don't think I noticed much when I switched from 134.5 bps to 300.) Clearly, links with a high percentage of small packets -- TCP ACKs come to mind -- will take a bigger percentage hit. Similarly, small MTUs will increase the overhead percentage. In reality, though I suspect that the real hit will come from the loss of modem compression and the loss of VJ header compression. And given the current standards (any of them!), we're going to lose those no matter what. Received: from relay.hq.tis.com by neptune.TIS.COM id aa01240; 10 Sep 96 15:18 EDT Received: by relay.hq.tis.com; id PAA17113; Tue, 10 Sep 1996 15:22:13 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017104; Tue, 10 Sep 96 15:21:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16775; Tue, 10 Sep 96 15:19:45 EDT Received: by relay.hq.tis.com; id PAA16993; Tue, 10 Sep 1996 15:20:29 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma016904; Tue, 10 Sep 96 15:19:36 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id VAA14158; Tue, 10 Sep 1996 21:21:33 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id VAA19453; Tue, 10 Sep 1996 21:21:30 +0200 (MET DST) Message-Id: <199609101921.VAA19453@kom30.ethz.ch> Subject: Re: Status of IPSEC Key Management To: Bill Sommerfeld Date: Tue, 10 Sep 1996 21:21:29 +0200 (MET DST) Cc: chk@border.com, smb@research.att.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM In-Reply-To: <199609092236.SAA00539@thunk.orchard.medford.ma.us> from "Bill Sommerfeld" at Sep 9, 96 06:36:33 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bill Sommerfeld wrote: > For those of you closer to the bleeding edge, I have this funny > feeling that IP+ESP+TCP will fit in 2 ATM cells, but IP+SKIP+ESP+TCP > won't. [What's the per-IP-packet ATM framing overhead? It's got to > be more than 8 bytes as I thought that a 40-byte minimal IP+TCP packet > doesn't fit in a single 48-byte cell] AFAIK a minimal TCP packet fits into a cell of 48 bytes. Just add another 4 bytes overhead for the AAL5 trailer, and you will have 4 bytes of payload left. IP+ESP(encryption only)+TCP fits into two ATM cells, but as soon as you add authentication, it will not fit anymore. (Assuming e.g. RFC1829 ESP is of length 16) The typical SKIP header has a length of 20 bytes. So you are certainly right, 3 cells are needed for the minimal SKIP+ESP TCP packet. But then, if you are going to use ATM, you do not care very much about this issue. If you have low bandwith sparse traffic, the establishment of the VC will cost you much more than sending 2 or 3 or 10 cells. If you have high volume traffic, you do not care much about the +20 bytes per e.g. 4kB AAL5 frame you are sending out. Oh yes, in an earlier mail you raised the issue of header compression. Certainly this is a viable approach to 'save' the inband keying information, and I agree fully that it might be nice to have. This is an optional add-on that has been extensively discussed... But then, at the moment it is not of paramount importance. It is an optional mode of operation that can be explored later. My 2 cents worth Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa01377; 10 Sep 96 15:24 EDT Received: by relay.hq.tis.com; id PAA17320; Tue, 10 Sep 1996 15:28:07 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017312; Tue, 10 Sep 96 15:27:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA17323; Tue, 10 Sep 96 15:26:55 EDT Received: by relay.hq.tis.com; id PAA17291; Tue, 10 Sep 1996 15:27:40 -0400 Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma017265; Tue, 10 Sep 96 15:27:11 -0400 Received: by janus.border.com id <18454-2>; Tue, 10 Sep 1996 15:27:29 -0400 Date: Tue, 10 Sep 1996 15:28:47 -0400 From: Norman Shulman To: "C. Harald Koch" Cc: ipsec@TIS.COM Subject: Re: bandwidth in the Internet In-Reply-To: <96Sep10.104604edt.18492-1@janus.border.com> Message-Id: <96Sep10.152729edt.18454-2@janus.border.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Tue, 10 Sep 1996, C. Harald Koch wrote: > Increasing the ACK size to 65 bytes (20 for SKIP+ESP?) yields 660Kbps > throughput on the forward channel; even worse. I figure a throughput of 1.32 Mbps; not so bad. Norm Norman Shulman Border Network Technologies Inc. Software Engineer Tel 1 416 368 7157 ext 304 norm@border.com Fax 1 416 368 7178 Date: Tue, 10 Sep 1996 15:21:08 -0400 From: Hilarie Orman Message-Id: <199609101921.PAA29199@earth.hpc.org> To: skrenta@osmosys.incog.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609101907.MAA25521@baskerville.CS.Arizona.EDU> Subject: Re: Status of IPSEC Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk In the past Phil Karn made a compelling case for supporting 2400 baud connections, and header minimization is a significant concern there. Though such slow connections seemed humorous initially, it now seems that ubiquitous wireless connections over low power, low speed links might become a major component of the future Internet universe. To: Stuart Jacobs Cc: Stephen Kent , perry@piermont.com, ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Tue, 10 Sep 1996 13:55:17 EDT." <2.2.32.19960910175517.0034cff0@pophost.gte.com> Date: Tue, 10 Sep 1996 15:31:28 EDT From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609101532.aa01618@neptune.TIS.COM> -----BEGIN PGP SIGNED MESSAGE----- In message <2.2.32.19960910175517.0034cff0@pophost.gte.com>, Stuart Jacobs writ es: > >The key distribution problem of the current mobile IP drafts seem adequate >for small network deployments. But what will happen when 10,000 mobile >hosts and mobile routers are roaming around in a hostile combat environment? >I also think that security associations Must exist between MHs and FAs as >well as FAs and HAs in both the military and commercial areas. The >commercial area needs this for non-reputable billing and the military for >network integrity. > This means you would compute an RSA signature over each and every packet exchanged ? Besides, the shared secret key is established on a need-to-have basis; clearly, not everybody needs to communicate with everybody at the same time. And you still don't have N^2 secret keys, just N RSA keys which you use to authenticate your public DH value. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBMjXCC70pBjh2h1kFAQHOigP8CFyhc0Ah9WTkiDsb29P49cdn6Sfaukfg DMOXxLLNubUwoAu9d47SrBOHxz7hP+d83exkcds4+UZyEs0ULIzHCWVi9n3wjovY tZeiQafT+9eTE43VxSKcV/Ge+8Kw8A7kBg8oqUt0zTMmEDbGm3BAc/K2n0oupEvY lU5AJGtc1U0= =+3so -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa01799; 10 Sep 96 15:40 EDT Received: by relay.hq.tis.com; id PAA18078; Tue, 10 Sep 1996 15:43:32 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018068; Tue, 10 Sep 96 15:43:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18757; Tue, 10 Sep 96 15:42:17 EDT Received: by relay.hq.tis.com; id PAA18059; Tue, 10 Sep 1996 15:43:03 -0400 Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma018049; Tue, 10 Sep 96 15:42:58 -0400 Received: by janus.border.com id <18443-1>; Tue, 10 Sep 1996 15:43:43 -0400 Message-Id: <96Sep10.154343edt.18443-1@janus.border.com> To: Norman Shulman Cc: ipsec@TIS.COM Subject: Re: bandwidth in the Internet References: In-Reply-To: norm's message of "Tue, 10 Sep 1996 15:28:47 -0400". From: "C. Harald Koch" Date: Tue, 10 Sep 1996 15:45:04 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message , Norman Shulman writes: > On Tue, 10 Sep 1996, C. Harald Koch wrote: > > > Increasing the ACK size to 65 bytes (20 for SKIP+ESP?) yields 660Kbps > > throughput on the forward channel; even worse. > > I figure a throughput of 1.32 Mbps; not so bad. Oops, forgot to multiply by 2 for acking every *second* segment. I guess that destroys what's left of my credibility... -- Harald Koch chk@border.com From: Dan McDonald Message-Id: <199609102010.NAA04270@kebe.eng.sun.com> Subject: Re: Everything degenerates to Key Management To: ipsec@TIS.COM Date: Tue, 10 Sep 1996 13:10:06 -0800 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is in reply to a note sent a bit back by Michael Richardson. > skrenta> I'll submit that this has more to do with ACL management, i.e. the > skrenta> "naming problem", than the underlying encryption protocol. > > I agree with this. But, if we can not decide on what the underlying > encryption protocol is, then we can not even deploy the *simple* things > that people want to do. Thus the "groundswell" of support on the list for > SKIP. It solves these people's problems *now*. SKIP is not an "underlying encryption protocol." It is a method of transmitting the cryptographic keys so that encryption and decryption can take place, hence the term "key management." > Rather, you have to change your kernel unless someone decides to support > both, and I do not know how the two systems will interact. I have not seen, > for instance extensions to the BSD44 socket API on how SKIP will be > available to user processes wishing keying. (Yes, this is Unix specific, > but how many TCP/IP capable systems do *not* support some kind of BSD-like > socket API?) Network API extensions for having users turn on IP-level encryption or IP-level authentication haven't been thought out, from what I've seen. GSS-API may be useful in such a context, but I found the sheer bulk of it intimidating. The NRL IPv6/IPsec code has a _very_ primitive API for requesting security services. The above paragraph and its issues are ORTHOGONAL to what key management strategy is used. It doesn't matter if you implement one, the other, or both (and you CAN implement both, see below), it's still an issue. > skrenta> Designing crypto exchanges and packet formats is comparatively easy; > skrenta> informing your machine that it's supposed to encrypt with a > particular set > skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP > skrenta> address is hard. But insofar as a workable solution is developed, I > skrenta> believe that it should prove fairly independent of the underlying > skrenta> encryption system. > > skrenta> This problem is really at a different level than the SKIP vs. Oakley > skrenta> debate, since neither set of drafts speak much to this issue. By that, if you mean setting up what ESP/AH algorithms are preferred, perhaps what ESP/AH algorithms are REQUIRED for communications on that machine, yes, it's a different level. It's called POLICY, and policy and mechanism are separate. If you mean what ESP/AH algorithms and modes can be used between a (possibly randomly assigned) IP address and me, there are already solutions for this. SKIP has its {Certificate, Algorithm} Discovery protocols, and the whole idea behind ISAKMP is that these very parameters are NEGOTIATED between the two machines before a session begins. Speaking of certificates, and problems orthogonal to key management debates, here's something I have to ask. _Regardless_ of key management, is it not true that each security endpoint is defined by the certificate associated with it? If so, this may answer questions about "user oriented" or whatever buzzwords you want to use to state that IPsec keys should be unique per session. > I had hoped that the meetings would come up with a way to incorporate > the SKIP header into the IPsec architectural draft (rfc1825). I have some > ideas on how to do this, but I do not have enough experience with both SKIP > and rfc1825 to do this on my own. I have plenty of experience with RFC 1825, and being where I am, I am quickly learning about SKIP. Quite frankly, I'm surprised nobody else has thought of the idea of having a "SKIP transform" that fits the relevant SKIP header information INSIDE a vanilla ESP or AH header. Quite frankly, in highly-modular environments (such as my current one), I can win big in implementation, because I have MUCH MORE control over the interface between transforms and ESP/AH, than I do between putting yet another higher-level protocol on top of IP. This control I mention allows better optimization and other code-reuse issues. In a not-so-modular environment (i.e. BSD) it's a wash, 6 one, half dozen the other. > If the stuff on the wire could be compatible at the "manual keying" > level, and an API similar to PF_KEY could accomodate SKIP keying, then we > could solve the other problems later. Some smart person may come up with a > hybrid solution that looks like neither solution. I have thought quite a bit about how PF_KEY could be made to accomodate SKIP keying. Particularly, the SKIP Kij keys could be computed in user-land, and fed into the kernel via PF_KEY, where they are used for the SKIP packets flowing across the wire. This also means you can build {Cert, Alg.} discovery in user-space as daemons. Unless I'm totally wrong about PF_KEY being able to work with SKIP, then it's VERY FEASIBLE to build SKIP, Oakley, and Photuris into the same box. More on this after I explain in-band vs. out-of-band... As for the stuff on the wire being compatible, the big difference between SKIP and your choice of Photuris or Oakley is that SKIP is in-band keying, where the session key is part of the packet (cryptanalysts, take note), and that both Photuris and Oakley are out-of-band keying, where an exchange (authenticated exchange, I hope :) takes place before data squeezes out of the wire. This difference in approach makes compatibility hard. Now that I've explained that, if you have PF_KEY that works, you can build ARBITRARY out-of-band keying systems. And with your favorite in-band keying system being implemented in-kernel (i.e. SKIP), you have a system that addresses ALL of your key management needs. Manual keying, BTW, is part of RFC 1825. I should be able to manually configure an SPI, with the relevant keying information. Tom Markson at Montreal mentioned that the latest SKIP release for {FreeBSD, SunOS 4.1,x} supports manual SPI's per RFC 1825. I hope this adds useful implementation-oriented data to the discussion. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + Received: from relay.hq.tis.com by neptune.TIS.COM id aa04307; 10 Sep 96 18:12 EDT Received: by relay.hq.tis.com; id SAA24115; Tue, 10 Sep 1996 18:16:13 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma024110; Tue, 10 Sep 96 18:16:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27608; Tue, 10 Sep 96 18:14:56 EDT Received: by relay.hq.tis.com; id SAA24104; Tue, 10 Sep 1996 18:15:45 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma024096; Tue, 10 Sep 96 18:15:24 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id AAA15554; Wed, 11 Sep 1996 00:17:37 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id AAA19797; Wed, 11 Sep 1996 00:17:35 +0200 (MET DST) Message-Id: <199609102217.AAA19797@kom30.ethz.ch> Subject: Re: Status of IPSEC Key Management To: Stuart Jacobs Date: Wed, 11 Sep 1996 00:17:34 +0200 (MET DST) Cc: kent@bbn.com, perry@piermont.com, ipsec@TIS.COM In-Reply-To: <2.2.32.19960910175517.0034cff0@pophost.gte.com> from "Stuart Jacobs" at Sep 10, 96 01:55:17 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Stuart Jacobs wrote: > I also believe that the current mobile IP approaches, using a shared secret > keyed MD5 authentication, just will not scale up to 1000s of mobile hosts > and mobile routers. I am looking into using an RSA digital signature > approach for authentication with caching of public keys by HAs, FAs and MHs. > I know that MD5 is much faster to compute and verify than RSA digital > signatures but when you weigh the fewer network exchanges of fetching certs > from CAs against the DH exchanges I think the time difference will diminish. > I've yet to construct a simulation to verify this point. Asymmetric authentication (for non repudiation purposes etc.) really would be a good thing to have. But doing RSA for each packet (or a small bunch of packets) is IMHO too costly. I expect each RSA computation to take e.g. 1/10 of a second, and produce AH headers ~ 40-50 Bytes which is a bit on the heavy side. Size is (as we have recently read :-) considered an issue in certain instances, but the computation time is much to high. The proceedings of Crypto'96 (Springer 1109) contain an article where asymmetric signatures with a size in the order of 64 bits are done. (pg. 45, Jaques Patarin, asymmetric cryptography using a hidden monomial). If this scheme could be made efficient, it would be very interesting for asymmetric sigantures - I think. I would like to raise a related issue. Current cryptographic mechanisms tend to go towards perfection. This is very well for privacy, and authentication of long lived storage, but do we really need a cryptographically strong hashing algorithm for TCP packets? Wouldn't it be sufficent to have have a keyed hashing algorithm which e.g. 'just' needs 100000 CPU years to be reversed? Or even just a few hundred CPU years? The strength of the algorithm should be appropriate to the lifetime of the data. I really would not care for the authentication session key to be retrieved by the NSA one week after the TCP connection has been closed. Or for somebody to be able to forge packets under a certain key if I already have changed to a new session key. Perhaps finding a *fast* hashing algorithm with reasonable security would be a good first step to make authentication overhead attractive to people too? Comments on this issue would be greatly appreciated... Germano Germano Caronni Received: from relay.hq.tis.com by neptune.TIS.COM id aa04616; 10 Sep 96 18:29 EDT Received: by relay.hq.tis.com; id SAA24526; Tue, 10 Sep 1996 18:32:43 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma024519; Tue, 10 Sep 96 18:32:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28074; Tue, 10 Sep 96 18:31:25 EDT Received: by relay.hq.tis.com; id SAA24511; Tue, 10 Sep 1996 18:32:13 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma024505; Tue, 10 Sep 96 18:31:57 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA07433; Tue, 10 Sep 1996 15:34:01 -0700 (PDT) Date: Tue, 10 Sep 1996 15:34:01 -0700 (PDT) From: Phil Karn Message-Id: <199609102234.PAA07433@servo.qualcomm.com> To: chk@border.com Cc: sommerfeld@apollo.hp.com, smb@research.att.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM In-Reply-To: <96Sep9.181528edt.18434-1@janus.border.com> (chk@border.com) Subject: Re: Status of IPSEC Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Are there really places in the Internet where this is still a problem? I >suppose those asymmetric bandwidth cable modems might be a problem; any >others? Cellular telephony, e.g., CDPD and CDMA packet data. Data rates are typically 9.6-14.4 kb/s at best, and per-bit charges (at least for CDPD) are relatively high. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa05579; 10 Sep 96 19:48 EDT Received: by relay.hq.tis.com; id TAA26096; Tue, 10 Sep 1996 19:52:13 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026092; Tue, 10 Sep 96 19:51:49 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29687; Tue, 10 Sep 96 19:50:55 EDT Received: by relay.hq.tis.com; id TAA26089; Tue, 10 Sep 1996 19:51:43 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma026070; Tue, 10 Sep 96 19:51:31 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Tue, 10 Sep 1996 19:53:38 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id TAA00832; Tue, 10 Sep 1996 19:53:37 -0400 Message-Id: <199609102353.TAA00832@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Tom Markson Cc: Daniel Harkins , smb@research.att.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: markson's message of Tue, 10 Sep 1996 15:25:06 -0700. <199609102225.PAA15843@monster.incog.com> Date: Tue, 10 Sep 1996 19:53:32 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > > One way to do this would be to include fields saying "respond to this > > > on SPI until " in the in-band-keying header; once an > > > explicit SPI had been set up between peers, the in-band header would > > > not be used. > > So would a message be sent back acknowleging this key change? Use of the reply-SPI by the peer would (implicitly) acknowledge the key change. > What would you do if the key change packet was dropped? Keep sending in-band keying messages (with the same reply SPI) until the peer shows evidence of having "gotten it". This would just be piggybacked on the retransmissions (if any) of the upper-level protocol. When sending a packet, if there isn't a valid outbound SPI we want to use to reach the peer, we look up the inbound SPI we want our peer to use (or create it if it's nonexistant) and insert an in-band keying header in the outbound packet. On the other hand, if there is a valid outbound SPI, we use it. If there isn't a valid inbound SPI for a response, we create the inbound SPI we want to receive replies on and insert an in-band-keying header in the outbound packet, then send it to the outbound SPI. If an inbound packet contains a valid in-band-keying header with a reply SPI in it, we create the outbound SPI with the appropriate TTL. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa05613; 10 Sep 96 19:50 EDT Received: by relay.hq.tis.com; id TAA26136; Tue, 10 Sep 1996 19:53:43 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026119; Tue, 10 Sep 96 19:53:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29711; Tue, 10 Sep 96 19:52:25 EDT Received: by relay.hq.tis.com; id TAA26116; Tue, 10 Sep 1996 19:53:13 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma026111; Tue, 10 Sep 96 19:52:48 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id QAA24298; Tue, 10 Sep 1996 16:55:06 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id QAA23346; Tue, 10 Sep 1996 16:55:30 -0700 Message-Id: <199609102355.QAA23346@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tom Markson Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Tue, 10 Sep 1996 15:25:06 PDT." <199609102225.PAA15843@monster.incog.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 16:55:30 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <199609102225.PAA15843@monster.incog.com> you write: > > [ Dan Harkins writes ] > > > > That's not necessarily true. The general SKIP case requires: 1) Certificate > > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > > A total of 6 messages required-- 4 if PFS is not desired. > > Not true. SKIP requires that communicating parties have each other's > certificates (keys). SKIP does not specify how this happens. We > tried to solve this key distribution problem by creating another protocol > which is not specific to SKIP. People naively assume this is a SKIP > exchange. Base SKIP allows you to talk without any exchanges if you > have a way to distribute keys and algorithm information. This could > be done via hardware tokens, CDP, floppies, Directory Servers, Secure > DNS or whatever. It is important to understand that once you have this > certificate, you do not need to get it again. Algorithm information can > be handled in the same way. You forgot SneakerNet :-). But seriously, floppies, hardware tokens, pre-configuration, and SneakerNet don't scale too well. And, I don't think Secure DNS is well suited for algorithm discovery. Granted, base SKIP does not require round-trips because it assumes you have some shared information already. But the general case, where we've never exchanged floppies or phone calls, does. My point was that to get to the point where base SKIP works without round-trips requires some round-trips. > > The multicast extension also doesn't scale well to highly dynamic multicast > > groups (unicast request/response for every member to group owner to obtain > > GIK). > > Ashar described a scheme in Montreal in which GIKs are distributed by > an expanding ring multicast scheme. I believe this solves this problem. That would be great! I hope to see this as an Internet-Draft soon since I don't remember the specifics of how this scheme works. > > > One way to do this would be to include fields saying "respond to this > > > on SPI until " in the in-band-keying header; once an > > > explicit SPI had been set up between peers, the in-band header would > > > not be used. > > So would a message be sent back acknowleging this key change? What would > you do if the key change packet was dropped? SKIP sends the key in each > packet to avoid the problem with lost and out of order packets (one of > the original goals of IP). This would also preclude the one-way > Satellite environment I described above. This is for negotiation-less SA establishment. You create an inbound SA with SPI NNN and send me the aforementioned packet. I create a similar outbound one upon receipt. No ack necessary since this just describes how I will be communicating with you in the future. If the packet was dropped you would, presumably, send another until your inbound SA went active (meaning I actually sent you something with SPI NNN) or the application requesting security timed out. This is to establish a single unidirectional SA. You could, I guess, continue to send me vanilla SKIP but I would reply with standard IPsec, Practically, though, I would imagine me setting up an inbound SA with SPI JJJ, sending you that packet, etc. You're right, this wouldn't work in the Satellite environment you described (since it implies that I don't respond to you and this whole idea is predicated on just the opposite) but it is still an interesting idea. It requires just as many roundtrips as SKIP-- the general case-- but loses the in-band header after SA establishment. Dan. Received: from relay.hq.tis.com by neptune.TIS.COM id aa00171; 10 Sep 96 20:11 EDT Received: by relay.hq.tis.com; id UAA26464; Tue, 10 Sep 1996 20:15:14 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026456; Tue, 10 Sep 96 20:14:45 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00304; Tue, 10 Sep 96 20:13:55 EDT Received: by relay.hq.tis.com; id UAA26453; Tue, 10 Sep 1996 20:14:43 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma026450; Tue, 10 Sep 96 20:14:42 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 10 Sep 1996 17:17:00 -0700 Date: Tue, 10 Sep 1996 17:16:52 -0700 Posted-Date: Tue, 10 Sep 1996 17:16:52 -0700 Message-Id: <199609110016.AA03343@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Tue, 10 Sep 1996 17:16:52 -0700 To: sjj0@gte.com, caronni@tik.ee.ethz.ch Subject: Re: Status of IPSEC Key Management Cc: kent@bbn.com, perry@piermont.com, ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I would like to raise a related issue. Current cryptographic mechanisms tend > to go towards perfection. This is very well for privacy, and authentication > of long lived storage, but do we really need a cryptographically strong > hashing algorithm for TCP packets? Wouldn't it be sufficent to have have a > keyed hashing algorithm which e.g. 'just' needs 100000 CPU years to be > reversed? Or even just a few hundred CPU years? The strength of the > algorithm should be appropriate to the lifetime of the data. > I really would not care for the authentication session key to be retrieved > by the NSA one week after the TCP connection has been closed. Or for > somebody to be able to forge packets under a certain key if I already have > changed to a new session key. > > Perhaps finding a *fast* hashing algorithm with reasonable security would > be a good first step to make authentication overhead attractive to people > too? > > Comments on this issue would be greatly appreciated... > > Germano > > Germano Caronni We agree that there is a use for a (potentially weaker) fast hash algorithm, and have been working on its development. A similar issue was raised earlier in this group, when we were evaluating the performance of MD5. The results of stand-alone MD5 performance were published at Sigcomm 95 in our paper "Performance Analysis of MD5". Phil Rogaway's 1996 RSA Data Security Conference presentation describes some algorithms, and their speeds. One algorithm, co-developed by Phil and our group, has performance of about 3-5x faster when run "stand-alone." However, our current work measuring in-situ performance of these algorithms in IPv4, is that TCP/MD5 tops out at around 37 Mbps on a Sun SPARC 20/71 (which can do TCP with null authentication at 100 Mbps). This alternate hash (AH) runs around 1.6x as fast, at 60 Mbps. For 1KB packets. This algorithm appears to be a resonable upper-bound for authentication, since it uses a very simple table-lookup only (from http://wwwcsif.cs.ucdavis.edu/~fishkin/md5/ ) (see code below). void ah(unsigned long* string, unsigned long* hash, int stringlen){ unsigned long temp,A,B,C,D; int i, bytetmp=0,tmp; temp=A=B=C=D=0; for(i=0; i<(stringlen/4); i +=4){ tmp=A^string[i]; A ^= htable[BYTE0(tmp)]; B ^= htable[BYTE1(tmp)]; C ^= htable[BYTE2(tmp)]; D ^= htable[BYTE3(tmp)]; tmp=B^string[i+1]; B ^= htable[BYTE0(tmp)]; C ^= htable[BYTE1(tmp)]; D ^= htable[BYTE2(tmp)]; A ^= htable[BYTE3(tmp)]; tmp=C^string[i+2]; C ^= htable[BYTE0(tmp)]; D ^= htable[BYTE1(tmp)]; A ^= htable[BYTE2(tmp)]; B ^= htable[BYTE3(tmp)]; tmp= D^string[i+3]; D ^= htable[BYTE0(tmp)]; A ^= htable[BYTE1(tmp)]; B ^= htable[BYTE2(tmp)]; C ^= htable[BYTE3(tmp)]; } hash[0] = A; hash[1] = B; hash[2] = C; hash[3] = D; /*return hash;*/ } FYI. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa00929; 10 Sep 96 22:58 EDT Received: by relay.hq.tis.com; id TAA25384; Tue, 10 Sep 1996 19:12:43 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma025373; Tue, 10 Sep 96 19:12:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28984; Tue, 10 Sep 96 19:11:25 EDT Received: by relay.hq.tis.com; id TAA25366; Tue, 10 Sep 1996 19:12:13 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma025360; Tue, 10 Sep 96 19:12:12 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA07520; Tue, 10 Sep 1996 16:14:25 -0700 (PDT) Date: Tue, 10 Sep 1996 16:14:25 -0700 (PDT) From: Phil Karn Message-Id: <199609102314.QAA07520@servo.qualcomm.com> To: chk@border.com Cc: ipsec@TIS.COM In-Reply-To: <96Sep10.104604edt.18492-1@janus.border.com> (chk@border.com) Subject: Re: bandwidth in the Internet Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Assuming 45 bytes/ACK (40 + ~5 for PPP), you can get a maximum of 80 ACK/sec >through the backchannel. This means 160 packets/sec in the forward direction >(TCP acks every second segment); this yields a maximum bandwidth usage of >1.92Mbps (using 1500 byte MTU). Only 1/5th the available bandwidth. TCP acks on slow reverse links need not limit forward link throughput as long as the flow control window is big enough in the forward direction. I've suggested an "ack dropping" scheme at the router driving the reverse link that drops a queued TCP ack whenever another TCP ack for the same connection comes along that supersedes it. Because TCP acks are cumulative, the older ack is not really needed. This has been simulated, and the improvement is dramatic. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa06711; 11 Sep 96 7:33 EDT Received: by relay.hq.tis.com; id HAA04028; Wed, 11 Sep 1996 07:37:24 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004011; Wed, 11 Sep 96 07:37:00 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12562; Wed, 11 Sep 96 07:36:06 EDT Received: by relay.hq.tis.com; id HAA04007; Wed, 11 Sep 1996 07:36:54 -0400 Received: from dde.dde.dk(152.95.32.2) by relay.tis.com via smap (V3.1.1) id xma003941; Wed, 11 Sep 96 07:34:10 -0400 Received: by dde.dde.dk (5.61/9.3) id AA04210; Wed, 11 Sep 96 13:36:21 +0200 Received: from Knud.dde.dk by dde.dde.dk (5.61/9.3) with SMTP id AA26790; Wed, 11 Sep 96 13:36:21 +0200 Received: by Knud.dde.dk (4.1/9.7) id AA16864; Wed, 11 Sep 96 13:35:50 +0200 Message-Id: <9609111135.AA16864@Knud.dde.dk> X-Mailer: exmh version 1.6.6 3/24/96 To: Firewalls@greatcircle.com, ipsec@TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: Re: SecurID White Paper - A Comment In-Reply-To: vin's message of Tue, 10 Sep 1996 13:37:06 -0400. Date: Wed, 11 Sep 1996 13:35:49 +0200 From: "Frederik H. Andersen" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi! Have anybody tried or considered to implement encrypted or secure-hashed TCP-checksums of OTP validated connections? This should prevent TCP connection hijacking with a minimum of per packet overhead . The OTP validation phase should be enough for "synchronizing" the endpoints? I heard somebody suggest this once but I've forgotten whom. -- ------------------------------------------------------------------ Frederik H. Andersen Phone: +45 42 84 50 11 Dansk Data Elektronik A/S Fax: +45 42 84 52 20 Herlev Hovedgade 199 Email: fha@dde.dk (MIME accepted) DK-2730 Herlev, DENMARK ------------------------------------------------------------------ To: Tom Markson Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 11 Sep 1996 06:53:55 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609110804.aa07041@neptune.TIS.COM> Tom Markson writes: > > [ Dan Harkins writes ] > > > > That's not necessarily true. The general SKIP case requires: 1) Certificate > > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > > A total of 6 messages required-- 4 if PFS is not desired. > > Not true. SKIP requires that communicating parties have each other's > certificates (keys). SKIP does not specify how this happens. > We tried to solve this key distribution problem by creating another > protocol which is not specific to SKIP. True enough. However, let us not pretend it isn't necessary. In most cases, it is necessary, and you have to count it in the overhead. > It is important to understand that once you have this certificate, > you do not need to get it again. Of course you do. Certificates don't exist forever, and you have to check CRLs and such. > > It also renders the SPI useless which makes RSVP support difficult (and > > calls into question full compliance with RFC1826 and RFC1827 since it is > > the MKID + IP address, not the SPI + IP address, that identifies state). > > This is only if you do RSVP based on SPIs. You can do RSVP based > on Master key IDs. I believe that the RSVP wanted a general mechanism, and not one tied to SKIP. Could you please accept that everyone on earth will not be using one key management facility and that the protocols must support this? Perry Date: Tue, 10 Sep 1996 15:01:38 -0700 (PDT) From: Dan McDonald Message-Id: <199609102201.PAA21461@lazlo.steam.com> To: ipsec@TIS.COM Subject: Re: Everything degenerates to Key Management Cc: danmcd@kebe.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is really strange. This is my third retransmit of this note. I'm using another account, just for exhaustiveness's sake. ANYWAY... ------------------ This is in reply to a note sent a bit back by Michael Richardson. > skrenta> I'll submit that this has more to do with ACL management, i.e. the > skrenta> "naming problem", than the underlying encryption protocol. > > I agree with this. But, if we can not decide on what the underlying > encryption protocol is, then we can not even deploy the *simple* things > that people want to do. Thus the "groundswell" of support on the list for > SKIP. It solves these people's problems *now*. SKIP is not an "underlying encryption protocol." It is a method of transmitting the cryptographic keys so that encryption and decryption can take place, hence the term "key management." > Rather, you have to change your kernel unless someone decides to support > both, and I do not know how the two systems will interact. I have not seen, > for instance extensions to the BSD44 socket API on how SKIP will be > available to user processes wishing keying. (Yes, this is Unix specific, > but how many TCP/IP capable systems do *not* support some kind of BSD-like > socket API?) Network API extensions for having users turn on IP-level encryption or IP-level authentication haven't been thought out, from what I've seen. GSS-API may be useful in such a context, but I found the sheer bulk of it intimidating. The NRL IPv6/IPsec code has a _very_ primitive API for requesting security services. The above paragraph and its issues are ORTHOGONAL to what key management strategy is used. It doesn't matter if you implement one, the other, or both (and you CAN implement both, see below), it's still an issue. > skrenta> Designing crypto exchanges and packet formats is comparatively easy; > skrenta> informing your machine that it's supposed to encrypt with a > particular set > skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP > skrenta> address is hard. But insofar as a workable solution is developed, I > skrenta> believe that it should prove fairly independent of the underlying > skrenta> encryption system. > > skrenta> This problem is really at a different level than the SKIP vs. Oakley > skrenta> debate, since neither set of drafts speak much to this issue. By that, if you mean setting up what ESP/AH algorithms are preferred, perhaps what ESP/AH algorithms are REQUIRED for communications on that machine, yes, it's a different level. It's called POLICY, and policy and mechanism are separate. If you mean what ESP/AH algorithms and modes can be used between a (possibly randomly assigned) IP address and me, there are already solutions for this. SKIP has its {Certificate, Algorithm} Discovery protocols, and the whole idea behind ISAKMP is that these very parameters are NEGOTIATED between the two machines before a session begins. Speaking of certificates, and problems orthogonal to key management debates, here's something I have to ask. _Regardless_ of key management, is it not true that each security endpoint is defined by the certificate associated with it? If so, this may answer questions about "user oriented" or whatever buzzwords you want to use to state that IPsec keys should be unique per session. > I had hoped that the meetings would come up with a way to incorporate > the SKIP header into the IPsec architectural draft (rfc1825). I have some > ideas on how to do this, but I do not have enough experience with both SKIP > and rfc1825 to do this on my own. I have plenty of experience with RFC 1825, and being where I am, I am quickly learning about SKIP. Quite frankly, I'm surprised nobody else has thought of the idea of having a "SKIP transform" that fits the relevant SKIP header information INSIDE a vanilla ESP or AH header. Quite frankly, in highly-modular environments (such as my current one), I can win big in implementation, because I have MUCH MORE control over the interface between transforms and ESP/AH, than I do between putting yet another higher-level protocol on top of IP. This control I mention allows better optimization and other code-reuse issues. In a not-so-modular environment (i.e. BSD) it's a wash, 6 one, half dozen the other. > If the stuff on the wire could be compatible at the "manual keying" > level, and an API similar to PF_KEY could accomodate SKIP keying, then we > could solve the other problems later. Some smart person may come up with a > hybrid solution that looks like neither solution. I have thought quite a bit about how PF_KEY could be made to accomodate SKIP keying. Particularly, the SKIP Kij keys could be computed in user-land, and fed into the kernel via PF_KEY, where they are used for the SKIP packets flowing across the wire. This also means you can build {Cert, Alg.} discovery in user-space as daemons. Unless I'm totally wrong about PF_KEY being able to work with SKIP, then it's VERY FEASIBLE to build SKIP, Oakley, and Photuris into the same box. More on this after I explain in-band vs. out-of-band... As for the stuff on the wire being compatible, the big difference between SKIP and your choice of Photuris or Oakley is that SKIP is in-band keying, where the session key is part of the packet (cryptanalysts, take note), and that both Photuris and Oakley are out-of-band keying, where an exchange (authenticated exchange, I hope :) takes place before data squeezes out of the wire. This difference in approach makes compatibility hard. Now that I've explained that, if you have PF_KEY that works, you can build ARBITRARY out-of-band keying systems. And with your favorite in-band keying system being implemented in-kernel (i.e. SKIP), you have a system that addresses ALL of your key management needs. Manual keying, BTW, is part of RFC 1825. I should be able to manually configure an SPI, with the relevant keying information. Tom Markson at Montreal mentioned that the latest SKIP release for {FreeBSD, SunOS 4.1,x} supports manual SPI's per RFC 1825. I hope this adds useful implementation-oriented data to the discussion. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From: Rich Skrenta Message-Id: <199609102216.PAA14468@miraj.incog.com> Subject: Re: Status of IPSEC Key Management To: ipsec@TIS.COM Date: Tue, 10 Sep 1996 15:16:59 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > That's not necessarily true. The general SKIP case requires: 1) Certificate > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > A total of 6 messages required-- 4 if PFS is not desired. CDP is only needed once for the lifetime of the key to obtain the long term certificate. And if DNSSEC is used, CDP isn't even necessary. ADP isn't needed if one has ACLs configured to choose the desired encryption algorithms. I send a triple-DES SKIP packet, if the other side is happy with that, the packet is accepted, and no ADP comes back. It is even possible to achieve PFS with SKIP without a "PFS exchange", by using short-lived keys certified with a long-term secret. One can thus "turn the PFS crank" at an administratively configurable interval. > ISAKMP+Oakley is one single key managment solution, not three. This is some creative line-drawing which lets SKIP be labeled as three separate key management solutions. However, I don't think the union of two independent (by themselves each quite complex) protocols is going to run away with the Simple moniker any time soon. One can of course draw a box around any arbitrarily high stack of paper. > It should also be noted that SKIP PFS and no pre-cached state requires > 2 Diffie-Hellman exponentiations-- once to compute g^xj and again to compute > g^ij. g^xj is only necessary if one is not doing host-host keying, and principal anonymity is desired. From: Tom Markson Message-Id: <199609102225.PAA15843@monster.incog.com> Subject: Re: Status of IPSEC Key Management To: Daniel Harkins Date: Tue, 10 Sep 1996 15:25:06 -0700 (PDT) Cc: sommerfeld@apollo.hp.com, smb@research.att.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > [ Dan Harkins writes ] > > That's not necessarily true. The general SKIP case requires: 1) Certificate > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > A total of 6 messages required-- 4 if PFS is not desired. Not true. SKIP requires that communicating parties have each other's certificates (keys). SKIP does not specify how this happens. We tried to solve this key distribution problem by creating another protocol which is not specific to SKIP. People naively assume this is a SKIP exchange. Base SKIP allows you to talk without any exchanges if you have a way to distribute keys and algorithm information. This could be done via hardware tokens, CDP, floppies, Directory Servers, Secure DNS or whatever. It is important to understand that once you have this certificate, you do not need to get it again. Algorithm information can be handled in the same way. This is why SKIP works in difficult environments such as one-way satellite broadcasts (where no exchanges are possible). > It also renders the SPI useless which makes RSVP support difficult (and > calls into question full compliance with RFC1826 and RFC1827 since it is > the MKID + IP address, not the SPI + IP address, that identifies state). This is only if you do RSVP based on SPIs. You can do RSVP based on Master key IDs. The master Key ID solves many of the limitations of the 32bit SPI by allowing more flexible naming schemes. > The multicast extension also doesn't scale well to highly dynamic multicast > groups (unicast request/response for every member to group owner to obtain > GIK). Ashar described a scheme in Montreal in which GIKs are distributed by an expanding ring multicast scheme. I believe this solves this problem. > > One way to do this would be to include fields saying "respond to this > > on SPI until " in the in-band-keying header; once an > > explicit SPI had been set up between peers, the in-band header would > > not be used. So would a message be sent back acknowleging this key change? What would you do if the key change packet was dropped? SKIP sends the key in each packet to avoid the problem with lost and out of order packets (one of the original goals of IP). This would also preclude the one-way Satellite environment I described above. --tom From: Charlie Perkins Message-Id: <9609111321.AA30717@hawpub1.watson.ibm.com> To: Stuart Jacobs Cc: ipsec@TIS.COM, dbj@cs.cmu.edu Subject: Re: Status of IPSEC Key Management Date: Wed, 11 Sep 96 09:21:26 -0500 Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> == Steve Kent > == Stuart Jacobs > Let me introduce myself. I am looking into ways to provide secure route > optimized mobile IP support for tactical battlefields and large commercial > network deployments. I have been following the mobile ip wp and ipsec wp > lists for a while and have come to believe that your point below is valid > >> but staying within the mobile IP protocol specs, there is no easy way to do >> the initial exchange. However, the fetch of a certificate from some >> database is outside the mobile IP protocol, and thus fits within the spec It's certainly true that mobile IP doesn't provide for fetching certificates. I hope that is viewed as a feature, since within the working group everyone generally felt that doing so was plainly another protocol, not mobile IP. > I also believe that the current mobile IP approaches, using a shared secret > keyed MD5 authentication, just will not scale up to 1000s of mobile hosts > and mobile routers. I don't understand this. Our intention was exactly that the protocol should be scalable to that point and beyond. We only specified that digital signatures be attached to control messages -- not to random data traffic that happens to pass through the home agent. A problem would result if the mobile node was trying to move to new care-of addresses too often, but the protocol is specified to be applicable when such movements occur no more often than once per second. My feeling is that it would generally work even if the registrations resulting from such movements were coming in at several times that rate -- it certainly works at greater speeds in our lab systems. If there are a LOT of mobile nodes, all registering very often, then mobile IP allows them to all use different home agents. We felt that this would enhance the scalability of the protocol. For further enhancements to scalability, I suggest a look at the proposed route optimization methods which would eventually relegate the home agent to a backup role. > The key distribution problem of the current mobile IP drafts seem adequate > for small network deployments. But what will happen when 10,000 mobile > hosts and mobile routers are roaming around in a hostile combat environment? That's a good question. But you have to do _something_ to make sure that those care-of addresses aren't forged, because the alternative problem is a lot worse. And, I would suggest that mobile IP can use whatever key distribution is eventually standardized within the IPsec working group. If not, then we had a serious misunderstanding of how key distribution would eventually work. > I also think that security associations Must exist between MHs and FAs as > well as FAs and HAs in both the military and commercial areas. The > commercial area needs this for non-reputable billing and the military for > network integrity. I'm interested in finding out more details about each of your assertions in the last sentence above. Our philosophy for the foreign agents has been that if an entity does the things that foreign agents are supposed to do, then that's good enough for the operation of the protocol, even if the entity is an intruder. Additional security requirements were supposed to be solved by additional security (or access control) mechanisms outside the mobile IP protocol. Moreover, the existing protocol does seem to provide for the operation you suggest, and if a security association exists between a MH and an FA, it MUST be used to authenticate registration messages. I think the idea was that no one would go to all the trouble of setting up such a security association unless it was really needed. > Stuart Charlie P. Received: from relay.hq.tis.com by neptune.TIS.COM id aa09370; 11 Sep 96 10:24 EDT Received: by relay.hq.tis.com; id KAA09606; Wed, 11 Sep 1996 10:27:25 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009602; Wed, 11 Sep 96 10:27:21 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22770; Wed, 11 Sep 96 10:26:07 EDT Received: by relay.hq.tis.com; id KAA09570; Wed, 11 Sep 1996 10:26:55 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma009532; Wed, 11 Sep 96 10:26:35 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id QAA24761; Wed, 11 Sep 1996 16:28:52 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id QAA20554; Wed, 11 Sep 1996 16:28:47 +0200 (MET DST) Message-Id: <199609111428.QAA20554@kom30.ethz.ch> Subject: Re: Status of IPSEC Key Management To: perry@piermont.com Date: Wed, 11 Sep 1996 16:28:46 +0200 (MET DST) Cc: markson@osmosys.incog.com, ipsec@TIS.COM In-Reply-To: <9609110804.aa07041@neptune.TIS.COM> from "Perry E. Metzger" at Sep 11, 96 06:53:55 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry E. Metzger wrote: > > This is only if you do RSVP based on SPIs. You can do RSVP based > > on Master key IDs. > I believe that the RSVP wanted a general mechanism, and not one tied > to SKIP. Could you please accept that everyone on earth will not be > using one key management facility and that the protocols must support > this? > Perry Well, then let's get ahead with the current proposals, and move them on! IMNSHO there are enough advocats for all of the current proposals, so lets deploy the stuff and see what works. I do not remember SKIP as being declared as the global solution to key management ever, quite on the contrary. Others utter this claim much more readily. And yes, I know we are all waiting for Jeff Schillers resolution on this issue to appear. Altough this is a difficult task, I hope this will happen soon. Germano Message-Id: <3.0b15.32.19960911130321.00a00e68@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 11 Sep 1996 13:05:05 -0400 To: Hilarie Orman , skrenta@osmosys.incog.com From: Robert Moskowitz Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 03:21 PM 9/10/96 -0400, Hilarie Orman wrote: >In the past Phil Karn made a compelling case for supporting 2400 baud >connections, and header minimization is a significant concern there. >Though such slow connections seemed humorous initially, it now seems that >ubiquitous wireless connections over low power, low speed links might >become a major component of the future Internet universe. You would not be happening to be thinking about PDAs, would you? And what about something that Phil's CEO said about a full IPsec capable processor in the new Qualcomm cellular phones? Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b15.32.19960911125801.00b03008@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 11 Sep 1996 13:05:03 -0400 To: Steven Bellovin , "C. Harald Koch" From: Robert Moskowitz Subject: Re: bandwidth in the Internet Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 01:57 PM 9/10/96 -0400, Steven Bellovin wrote: > > Assuming 45 bytes/ACK (40 + ~5 for PPP), you can get a maximum > of 80 ACK/sec through the backchannel. This means 160 > packets/sec in the forward direction (TCP acks every second > segment); this yields a maximum bandwidth usage of 1.92Mbps > (using 1500 byte MTU). Only 1/5th the available bandwidth. > >Empirically, I get about a quarter of that -- modems have a moderately >high fixed delay per packet. Increasing my TCP window size ups >throughput, I'm told. Much of this is in the V.42bis logic. Well since we are encrypting, modem compression does not buy much. Turn it off and check out the difference. Of course if you do this, non-encrypted compressable data suffers conciderably (unless you have a PPP level compression). Of course the delay in the V.42 logic cannot be helped. My experience is you never want to run without V.42, even if you risk the 12 naks of death. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b15.32.19960911125851.00b272e8@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 11 Sep 1996 13:05:04 -0400 To: Rich Skrenta , perry@piermont.com From: Robert Moskowitz Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 11:23 AM 9/10/96 -0700, Rich Skrenta wrote: >> Not to mention the fact that Ricochets send packets at well above >> 50kbps, don't they? > >100kbps, but I have my serial port locked at 19.2... But it is half duplex, so you are back to 50kps in real usage.... Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b15.32.19960911131055.00b03008@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 11 Sep 1996 13:16:00 -0400 To: Germano Caronni , "Bill Sommerfeld"@TIS.COM From: Robert Moskowitz Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 09:21 PM 9/10/96 +0200, Germano Caronni wrote: > >But then, if you are going to use ATM, you do not care very much about this >issue. If you have low bandwith sparse traffic, the establishment of the VC >will cost you much more than sending 2 or 3 or 10 cells. If you have high >volume traffic, you do not care much about the +20 bytes per e.g. 4kB AAL5 >frame you are sending out. But your DAVIDC (or whatever the name is) friends have reserved a PPP protocol # for ATM over PPP so that ATM can go anywhere! ;) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa12278; 11 Sep 96 13:48 EDT Received: by relay.hq.tis.com; id NAA17149; Wed, 11 Sep 1996 13:52:16 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017128; Wed, 11 Sep 96 13:51:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06014; Wed, 11 Sep 96 13:50:57 EDT Received: by relay.hq.tis.com; id NAA17122; Wed, 11 Sep 1996 13:51:45 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma017101; Wed, 11 Sep 96 13:51:14 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id NAA46205; Wed, 11 Sep 1996 13:51:29 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id NAA734524; Wed, 11 Sep 1996 13:51:01 -0400 Message-Id: <199609111751.NAA734524@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8166; Wed, 11 Sep 96 13:50:58 EDT Date: Wed, 11 Sep 96 10:51:36 EDT To: skrenta@osmosys.incog.com, ipsec@TIS.COM Subject: SKIP in IPSEC: is it really simple? Sender: ipsec-approval@neptune.tis.com Precedence: bulk skrenta at osmosys.incog.com writes > > CDP is only needed once for the lifetime of the key to obtain the long > term certificate. And if DNSSEC is used, CDP isn't even necessary. > > ADP isn't needed if one has ACLs configured to choose the desired > encryption algorithms. I send a triple-DES SKIP packet, if the other > side is happy with that, the packet is accepted, and no ADP comes back. > > It is even possible to achieve PFS with SKIP without a "PFS exchange", > by using short-lived keys certified with a long-term secret. One can > thus "turn the PFS crank" at an administratively configurable interval. How can you say in paragraph 1 that certificate discovery is no problem since it's needed only once to obtain the long term certificate, and in paragraph 3 to say that even "PFS exchange" is not needed since you can change your certificate each day (hour?) Isn't this a highly misleading argument?? Plain SKIP (no pfs, no CDP, no ADP) is simple. With all these additions it is not that simple (not SKIP's fault but the inevitable complexity of our requirements/applications). If in addition you start considering all the "submodes": yes PFS/no PFS, long term certificates/ short term cerificiates, yes algorithm discovery/ no algorithm discovery, yes anonymity/no anonymity (with/without PFS), per-packet SKIP header/ per-session SKIP header, etc. then SKIP is COMPLEX (not SKIP's fault: I've heard voices in this list for almost every possible combination of these submodes!). In ISAKMP/Oakley these complexities appear explicitly instead of blurred over different Internet drafts. But let's not lie to ourselves FULL SKIP (as needed to support those requirements on which there is already WG consensus: PFS, certificate-based key mgmt, anonymity) is COMPLEX. ISAKMP/Oakley, on the other hand, has several security advantages over SKIP (hand-shakes for key exchange/refreshment, freshness proof in each exchange, randomness contributed by both parties to the key, no reliance on shared time, explicit framework to analyze security, no reliance in universal DH group, explicit negotiation and authentication of key attributes). Let's choose the most desirable subset of Oakley exchanges and make them mandatory (ie, basis for inter-operability). ISAKMP and the other Oakley exchanges give the basis for optional/future extensions. And if in-band keying is desirable let's decide on it as an extension too (in my opinion: combined as a transform into AH and ESP rather than via a separate header). Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa16778; 11 Sep 96 21:07 EDT Received: by relay.hq.tis.com; id VAA29307; Wed, 11 Sep 1996 21:11:12 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma029305; Wed, 11 Sep 96 21:10:45 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24411; Wed, 11 Sep 96 21:09:54 EDT Received: by relay.hq.tis.com; id VAA29293; Wed, 11 Sep 1996 21:10:42 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma029283; Wed, 11 Sep 96 21:10:15 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id SAA12494; Wed, 11 Sep 1996 18:12:30 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA09070; Wed, 11 Sep 1996 18:12:27 -0700 Message-Id: <9609120112.AA09070@maildig1.us.oracle.com> Date: 11 Sep 96 18:11:32 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: SKIP Design & Applicability Statement Cc: asdf@osmosys.incog.com, skrenta@osmosys.incog.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 06-Sep-96 11:17 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_25469420_0_11919609111913280" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_25469420_0_11919609111913280 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Rich, >Several people, including Paul Lambert, have asked us >to provide a list of differentiators between SKIP >and other KMP proposals. I did not ask for a posting off your "applicability statement for SKIP". I did call Glenn Scott (of Sun) and strongly encouraged the posting of a statement from Sun on the licensing and applicability of the "new" Sun patent that makes broad claims on IPsec related technology. This patent was filed after the start of the IPsec working group and directly covers prior art that was documented by the working group and other international standards bodies. In the discussions with Glenn, I did describe how early in the year I encouraged Sun to either document how SKIP met the IPsec requirements or to differentiate the mechanism. This was not a request for more SKIP information to be posted. While I do understand Sun's investment in SKIP, please be cautious in the posting of material that might be misconstrued as marketing material. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_25469420_0_11919609111913280 Content-Type:message/rfc822 Date: 06 Sep 96 11:17:23 From:"Rich Skrenta " To:ipsec@tis.com Subject:SKIP Design & Applicability Statement X-Mailer:ELM [version 2.4 PL24 PGP5] Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Several people, including Paul Lambert, have asked us to provide a list of differentiators between SKIP and other KMP proposals. Ashar has recently expanded his applicability statement for SKIP; I'll include it below. This is also available on our web site at http://skip.incog.com/skip-applic.html ----------------------------------------------------------------------------- Design Issues and Applicability Statement for SKIP Ashar Aziz Distinguished Engineer Sun Microsystems, Internet Commerce Group Introduction ------------ This note describes applications and usage of SKIP in Internet/Intranet environments, and motivations behind the design of SKIP. (A detailed description of the SKIP protocol may be found in the online internet-drafts directories under draft-ietf-ipsec-skip-*.txt). SKIP enables the establishment of keys with no interactive message exchanges required between the principals wishing to establish a secure channel. The base SKIP mode allows the computation of a master key using each principal's certified DH key. Re-keying is performed inline, by encrypting the traffic key using the master key, and sending the encrypted traffic key inline with the packet. The master key computation requires a single DH operation, during the lifetime of communications between two principals, after which it can be cached using the same techniques used to store each principal's long-term private key. An important point is that the master key is non-interactively and independently computed by each principal (host, user, etc.). The other principal neither needs to participate nor even be connected or available on the network at the time of master key computation. Only the other principal's certified DH value need be available and this can be distributed using central servers as through a name service such as secure DNS. This is important for practical reasons to be discussed shortly. SKIP supports an ephemeral DH exchange, which provides Perfect Forward Secrecy (PFS), for situations which require PFS. A protocol has the PFS property when the compromise of long-term keying material does not compromise data encrypted in the past (which may have been recorded), and whose associated transient traffic keys have been deleted from the system. The inline key-update used in SKIP also works for multicast environments. A SKIP extension describes how to set-up and refresh traffic keys for multicast data. We describe some illustrative application and usage scenarios of SKIP and its extensions. The example usage scenarios below is not an exhaustive list of the uses of the SKIP protocol. Rather it is an illustrative list provided in order to present the considerations that motivated the design of the SKIP protocol. Secure Domain Management ------------------------ ipsec protocols will be used in the Internet and Intranet environments not only to establish secure encrypted channels between two nodes, but also to establish and manage the security of critical network elements, e.g. encrypting firewalls, routers etc. There are two essential components of management that impact key-management; traps and alerts from managed devices and set operations from management station to managed devices. Both of these operations are urgent operations. Namely, they need to be processed and dispatched in a timely manner for security management to be effective. The aspect of security that is critical here is authentication of traps/alerts from managed devices and the authentication of the set operation from the management station. Secrecy is typically a secondary concern here, therefore PFS is a moot issue for this application. An example scenario: Assume a large enterprise containing hundreds (possibly thousands) of security critical elements, such as firewalls or routers, at the perimeter of the enterprise. These firewalls might be programmed to detect security events (such as penetration attempts) and inform the management station of such events via network management traps or alerts. In case such an event occurs, it is unlikely that prior security associations will always exist, since security associations are intended to be temporary and will go away on reboot/power up of either management station or managed device. (Trying to re-establish these associations on each re-boot of a management station, where each association could take a second to a few seconds, would result in a hour's worth of security association for a few thousand managed devices, a significant limitation. Another factor making this impractical is that not all managed devices may be powered up or available at the time the management station is re-booting, making interactive key-establishment on each re-boot more problematic). In case intrusion events are detected by the firewall complex (possibly from all over the site), this could result in a few hundred to a thousand traps to the management station(s). Assuming a second (or two) per new association this leads to an overwhelming 1/2 hour to an hour worth of compute time on the management station simply to process the association requests, essentially bringing it down, and rendering it useless to take management action (such as shutting down part of the firewall complex or other such action). One could question if all perimeter devices would be simultaneously attacked. However, if the key-management presents an achilles heel in such situations, where simultaneous attack would result in disabling all management stations, then this is precisely the sort of attack one should expect. Another argument could be that one could use permanent security associations for handling such applications, where the session key is negotiated once and then cached. There are several limitations of this approach: The first is that permanent caching of an association essentially results in freezing the traffic key, an undesirable feature from a cryptographic perspective, where frequent key changes represent the best defense against cryptanalysis. Dynamic key-management is the entire goal of ipsec key management, and permanent security associations are a step back to manual key-management. Another limitation is that in case association state is ever lost on, say, the managed device then *both* the management station and the managed device need to re-compute the key, resulting in the same overhead issues discussed earlier should this need to happen at urgent message time from many managed devices. Cached associations for management are no more elegant or practical than running SNMP over cached TCP connections. If SKIP is used for this application scenario, then the limitations discussed earlier do not exist. A SKIP master key (Kij) is the only expensive part of the base SKIP protocol, and this can be cached. Caching the master key doesn't freeze the traffic key, since the two are independent. Re-keying happens inline, so a single message representing an urgent trap or alert allows key refreshment, without incurring a second per message worth of compute time. This is because only symmetric key operations need to be performed per message. In case the master key is ever lost on a managed device, then only the managed device needs to re-compute it, not the management station, which is the bottleneck in this application scenario. A thousand or so traps can be processed in a total time of a second or so, with no extra messages required for key-management purposes. The management station is able to respond with, say, an authenticated shutdown to the entire firewall complex in a few seconds, not hours. A key-management approach that does not adequately meet the needs of scalable and secure network management is not only incomplete, it represents a serious security vulnerability for the Internet community. Security without effective security management will be difficult, if not impossible, to establish and maintain. Large Scale Servers ------------------- A large scale web, mail or file server is expected to receive many simultaneous connection requests, which can all potentially result in a new security association requests. Several hundred or thousand requests can result in computational overload for servers, even if each new association takes only a second or two. One could question whether a thousand new requests can occur simultaneously to a server. The answer here is yes, probably even frequently, when one considers that they don't all have to occur at the very same instant. Even if 20 requests occur in the same 1-2 second time frame, processing these new associations could take 20-40 seconds, and the rest of the requests could occur in these 20-40 seconds, in order to have the overloading effect of a hundred/thousand simultaneous requests. Another way of looking at this is as follows: if the new association requests come in at a rate faster than they can be processed then this results in a server meltdown situation. For example, if a new association requires 2 seconds to process, then an averaged rate of 1 new request per second is sufficient to completely overload the server. Such a rate is not far-fetched for typical servers in use today, such as web, mail or file servers, and can certainly occur during peak usage times. (Long-term caching of associations is problematic for the reasons noted above.) Servers represent a special issue in the trade-off considerations between performance and security. Servers are typically used to store long-lived information, such as files, mail messages, or web pages. If PFS is being employed to encrypt all traffic to/from the server (and the contents of the secure conversations are stored on the server, e.g. a mail message, or a web page, etc.) then compromise of the principal's long-term key can still result in compromise of encrypted traffic. This is because compromise of a principal's long-term key will always result in authentication failure. The attacker who has compromised the long-term key is able to impersonate the legitimate user, and connect to the server to recover the traffic that was originally encrypted over the channel in PFS mode. There is one (important) aspect in which PFS offers a better defense than a non-PFS solution. Namely, if the key-compromise is discovered, the keys may be revoked, thereby protecting against future impersonation attacks and still preserving the secrecy of past encrypted data. However, there are many circumstances in which long-term key-compromise may not be discovered, and if it is discovered, may be discovered too late. Therefore, the trade-off in such situations is to take the performance penalty imposed by a PFS protocol (such as SKIP PFS), in order to guard against discoverable key-compromise, or to use a lighter-weight protocol without PFS (such as the base SKIP mode). There may not be a single right answer here. Some sites may wish to accept degradation in server performance, and choose the PFS approach because they believe that key-compromises will be discoverable. Other sites may choose a lighter weight protocol without PFS, because they believe that guarding against discoverable key-compromises isn't worth the performance penalty. We believe this is a choice that should be left to the user community. Certainly, if all the ipsec protocol is providing by way of security is authentication, so that the server may perform authenticated access control, then the entire PFS issue is moot, and the overhead entailed by PFS is clearly unnecessary. Low-End devices --------------- IP layer security is being implemented on low-end devices such as computationally constrained CPUs (embedded designs, palm-tops, Internet/Web terminals etc.). The computational overhead of performing even a few public key operations simultaneously is a challenge for such computational platforms. The low computational overhead of the base SKIP mode permits it to be easily implemented on such low-end devices. High Availability of Encrypting Firewalls/Routers ------------------------------------------------- Another sample application usage of SKIP is to enable the set up of a redundant set of intermediate nodes in order to provide failover of encrypted traffic. IP routing provides for failover for unencrypted traffic, and this feature is especially important at enterprise connections to the Internet, where a single point of failure may represent the failure of a mission critical application, requiring secured access to the enterprise from across the Internet. An example of this might be mobile sales people, requiring secured access to corporate information from field locations. If a single firewall or router was handling several hundred or thousand such sales people, then it is highly desirable that failure of either the link or the Intermediate device providing encryption services should not result in a loss of secure connectivity to this large group of users. SKIP permits multiple intermediate nodes (routers, firewalls, etc.) to be configured to share the same long-term DH public/secret value, and the same master key-id. Failover of encrypted traffic is provided by standard dynamic IP routing facilities. As described above, an intermediate device may compute and cache SKIP master keys (Kij) without ever communicating with the end units that may connect through it. At failover time, an encrypted/authenticated packet that was intended for a failed unit may be re-routed to a redundant standby unit and processed without requiring several public key operations per new source of encrypted traffic. Thus failover scales to thousands of encrypted channels, because there is much lower overhead in processing each new source of encrypted traffic. One could argue that failover can still be achieved using an association based approach, by allowing alternate encrypting nodes to detect failover by receiving an ipsec packet for which a local SPI does not exist (for that src, dst IP address pair). In case such a packet is received, the alternate device can negotiate a new session key for that (src, dst) IP address pair. There are two problems with this approach. The first is that there is no requirement that an SPI with a given (src, dst) IP address be unique across nodes. It need only be unique on a given receiving node, since there is no coordination between nodes of SPI values. This means there is a possibility that that same SPI value for the given (src, dst) IP address already exists on the alternate node (with a different session key). In this case, failover would not be detected and therefore no failure recovery would occur. The second problem is that this doesn't scale to failover of thousands of secure channels, since this would require the alternate intermediate node to negotiate (simultaneously) thousands of associations. At the rate of a few seconds per association, this could easily take on the order of hours, which would be an unacceptable delay for end nodes in the field requiring secured access. It is impractical in the association approach for an intermediate node to cache security associations for all possible end or intermediate nodes that may require access through it. This is because a) The end nodes may not be available at the time such caching may need to be performed, b) the location of the end node (in terms of IP address) may not be known, since many of these nodes may be coming through dynamically assigned IP addresses and c) the end node may be connected through a dial-up telephone or ISDN link, involving a monetary expense simply for association caching purposes. High availability of the network is an important practical issue, and was a motivating feature for the design of IP in order to build survivable networks. It is important to preserve this feature, as the networks become secure. High-Speed Links ---------------- An issue for cryptographic security and high speed links is the frequency of key updates. Key-updates need to be related to the amount of data encrypted in a given key and not be a function of time alone. For a given key-update policy (e.g. change the key every 100 Mbytes of encrypted traffic), this translates to a thousand times more frequent key-update rate, when going from a 1 Mbit/s link to a 1 Gbit/s link. This means that a key-update policy that requires a key-update every 15 minutes on a 1 Mbit/s link, translates to a key-update faster than once per second on a 1 Gbits/s link. Using an approach that requires an interactive message exchange for each key-update means that two messages per second will be required for key-updates on a Gbit/s link. If this node is talking to thousands of other such high-speed nodes, the messages required for key-updates increase a thousand fold. (These are not unrealistic scenarios for an Internet that is simultaneously getting bigger and faster.) The node must wait at least a round-trip delay time prior to re-keying. This is simply a fact due to network latency. Each lost key-update message means one of two things. a) either wait for a retransmission of the key-update message and degrade throughput or b) continue transmitting using the old key and violate the local key-update policy. Since SKIP performs inline re-keying, the message exchanges and the latency inherent in a round-trip message exchange are both avoided. Re-keying can be performed as frequently as desired, even once a packet, because no message exchange or round-trip delays are incurred in doing this. The issue here is purely one of inline keying. Inline re-keying can be used in conjunction with an ephemeral master key, and still have fast re-key in conjunction with PFS (e.g. as in the SKIP PFS draft). It could be argued that one could come up with key-update rates that are far less frequent for these high-speed links, since all known attacks on the cryptosystems intended to be used require an impractical amount of known or chosen text. However, this precludes key-update policies that may wish to be more conservative in the amount of data encrypted in a given key. It is entirely possible that future attacks may be discovered that require less plaintext encrypted in a given key (either known text or chosen) and such attacks could compromise past encrypted data which used less conservative key-update rates. A more conservative key-update policy would prevent future discovery of these attacks from compromising past encrypted data. The attacks being defended against here are purely passive attacks, since discovery of a future cryptanalytic attack permits the adversary to take recorded encrypted traffic (and any associated known text) and simply apply the attack techniques to it. This is a far more feasible form of attack than active forms of attack against past encrypted traffic (e.g. compromising a long-term secret key). Multicast IP Issues ------------------- An important part of multicast key-management is scalable re-keying, where the re-key operation needs to scale with the size of the multicast group. A scheme that requires a central Key Distribution Centre (KDC) to supply the multicast traffic keys doesn't scale very well, because this requires key-management traffic proportional to the size of the multicast group and the key-update rate to and from a single entity. Alternative schemes that have been suggested involve encrypting the traffic key in an interchange key that the group members already possess and multicasting the encrypted traffic key to all the group members. This approach has a significant drawback. First, IP multicast is an unreliable operation. There can be no assurance that all the group members in fact have received the new traffic key. Without knowing if and when the group members have received the encrypted multicast traffic key, it is difficult to start using the new key. One could use some reliable multicast transport protocol, but these also represent scaling problems. In any case, it is a limitation to have to introduce a reliable multicast protocol when it may not be necessary for the IP multicast application requiring security. Other drawbacks include some of the drawbacks mentioned above for high speed links. How does one perform rapid re-key for multicast over high speed links, if the re-key operation requires an acknowledgment from all group members? SKIP's use of inline re-keying solves these problems. There is no need to introduce a reliable multicast transport protocol. A multicast group can be re-keyed as rapidly as desired, independent of the size of the multicast group and independent of network latency and round-trip time issues. SKIP multicast inline re-key scales simultaneously to arbitrary size multicast groups and high-speed links, has no synchronization issues associated with the re-key operation, and works in the presence of packet losses. SKIP PFS -------- SKIP PFS is a simple, 2-message exchange that provides authenticated PFS. In addition, it also provides anonymity of the parties involved in the exchange. The exchange does not use non-repudiable signatures. Therefore it also has the desirable property of deniability of an exchange, which is important for privacy considerations. Namely, one doesn't want to provide each party a non-repudiable proof that a secure conversation tool place, because one may wish to later deny that the conversation took place. The overhead of SKIP PFS is comparable to the overhead of other protocols that provide PFS, but significantly greater than the overhead of the base SKIP mode. PFS is highly desirable in many environments which require long-term secrecy of information, even in the presence of the compromise of long-term keying material. Ideal use of PFS is to encrypt ephemeral data (i.e. data that is never stored in the network), because the ephemeral nature of the keys will permanently (assuming high-strength DH) remove the ability to recover the encrypted material from any source, including the recorded ciphertext. Scalability ----------- Any approach that is being considered for use on the Internet needs to be scalable. This scalability has many facets to it. Specific aspects of scalability, and features of SKIP that aid each aspect, are described above. This includes scalability for management of large secure domains containing many devices, large-scale web/mail/file/ servers, low-end devices (e.g. Internet/web terminals), high-speed networks, and large multicast groups. Simplicity ---------- Although the functionality described above is important (and we believe, critical) for a scalable approach to key-management, an important element is the complexity of an approach to achieve its end objectives. Whereas simplicity and complexity are in the end a subjective judgement, we believe that the balance in the SKIP protocol lies towards simplicity. When multiple ways of achieving a cryptographic objective (e.g. PFS or anonymity) exist, a single and most often the simplest approach is specified. This simple approach is not limited to solving only simple problems. For example, inline re-key is a simple mechanism that simultaneously addresses complex key-management issues related to urgent secure messages, encrypted multicast traffic, and high-speed networks. We believe that a simple approach aids in the building of interoperable implementations, and the security analysis of the final systems, both from a protocol and implementation point of view. A simple approach is also quicker to build and deploy. This is an important practical issue, considering the pressing need for security at the network layer of the Internet. --=_ORCL_25469420_0_11919609111913280-- From: Rich Skrenta Message-Id: <199609120042.RAA17690@miraj.incog.com> Subject: Re: SKIP in IPSEC: is it really simple? To: ipsec@TIS.COM Date: Wed, 11 Sep 1996 17:42:53 -0700 (PDT) In-Reply-To: <199609111751.NAA734524@mailhub1.watson.ibm.com> from "HUGO@watson.ibm.com" at Sep 11, 96 10:51:36 am X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > How can you say in paragraph 1 that certificate discovery is no problem > since it's needed only once to obtain the long term certificate, and in > paragraph 3 to say that even "PFS exchange" is not needed since you can > change your certificate each day (hour?) If one is using DNSSEC, keys can be rolled forward with the DNS refresh interval. If CDP is used, a response with multiple certificates to be used for N future intervals can be returned. > Isn't this a highly misleading argument?? What is misleading to say is that SKIP has as high an overhead at startup as an Oakley exchange, when the overhead in practice is considerably less. It is also misleading to say that one can't have PFS in SKIP without throwing out all of SKIP's advantages; this isn't true. > In ISAKMP/Oakley these complexities appear explicitly instead of blurred > over different Internet drafts. Is not ISAKMP/Oakley also "blurred" among several different Internet drafts? SKIP was originally contained in a single draft. It was split into the current series of documents at the request of the WG chairs. > But let's not lie to ourselves FULL SKIP > (as needed to support those requirements on which there is already > WG consensus: PFS, certificate-based key mgmt, anonymity) > is COMPLEX. SKIP is a remarkably simple base protocol, as evidenced by the many implementations which have been rapidly developed. And yet the ease with which additional desired features may be layered onto it speaks to its versatility. This may well be a matter of religion, and not technical merit. Some will choose to start with a simple protocol, and build upon that. Others advocate designing a large, heavyweight protocol which offers every conceivable feature (except statelessness, that is) from the start. > ISAKMP/Oakley, on the other hand, has several security advantages > over SKIP Having to stop and renegotiate a session to change the traffic key is not an advantage. It is also incorrect to say that SKIP forces the Internet to standardize on a single g and p; this is once again an administrative issue. Our implementation currently supports as many local (g, p, i) identities as the administrator cares to configure. It must, in order to support simultaneous interoperability with products deployed to the different rings of the US export law hell (2048 US, 1024 Swiss banks, 512 non-US). > Let's choose the most desirable subset of Oakley exchanges > and make them mandatory (ie, basis for inter-operability). > ISAKMP and the other Oakley exchanges give the basis for > optional/future extensions. Those who want to wait for ISAKMP/Oakley to mature are welcome to do so. However, SKIP should not be forced to wait for other protocols to catch up any longer. I think that IPsec has already done the Internet a disservice by needlessly stalling this decision for so long. SKIP has been in the IETF for over 2 years and is by far the most mature existing key management protocol. Perhaps those who are uncomfortable with letting the market decide between KMPs fear that an IETF edict is necessary to guarantee that the "right" choice is made. In any event, it's clear that there hasn't been, and won't be, consensus to back one KMP exclusively. Continuing to delay further is pointless. Let's have all existing KMPs proceed within the WG with the same status as soon as possible. From: Rich Skrenta Message-Id: <199609120129.SAA17930@miraj.incog.com> Subject: Re: SKIP Design & Applicability Statement To: "PALAMBER.US.ORACLE.COM" Date: Wed, 11 Sep 1996 18:29:13 -0700 (PDT) Cc: ipsec@TIS.COM, asdf@osmosys.incog.com In-Reply-To: <199609120116.SAA12420@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Sep 11, 96 06:11:32 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > This was not a request for more SKIP information to be posted. Apologies for the misunderstanding; as the request made its way to me, I understood it to mean that you had never seen the applicability statement that Ashar had written (at your request), and that we should provide this. Since Ashar had recently added to his statement, it seemed like a good time to send it out. > While I do understand Sun's investment in SKIP, please be cautious in the > posting of material that might be misconstrued as marketing material. No one that I'm aware of has misconstrued the new applicability statement as marketing material. It has, after all, nothing to do with our current product offerings, but is solely about the SKIP protocol itself. It should apply to any implementation of SKIP, whether developed by Sun or by any of our competitors. > I did call Glenn Scott (of Sun) and strongly encouraged the posting of a > statement from Sun on the licensing and applicability of the "new" Sun > patent that makes broad claims on IPsec related technology. I believe that an official statement regarding this new patent is working its way through legal here and should be forthcoming. To: ipsec@TIS.COM, gnu@toad.com Subject: Using SKIP as inspiration, not as gospel In-Reply-To: <199609102010.NAA04270@kebe.eng.sun.com> Date: Thu, 12 Sep 1996 01:35:34 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609120746.aa22647@neptune.TIS.COM> > ... I'm surprised nobody else has thought of > the idea of having a "SKIP transform" that fits the relevant SKIP header > information INSIDE a vanilla ESP or AH header. I'm glad that people are looking at SKIP more as a set of capabilities than as a fixed protocol. The SKIP camp has been hamstrung by its religious attachment to "one packet in, one packet out" operation, despite ongoing evolution that makes that mode effectively moot (certificate discovery, PFS, etc). For example, it should be possible to send the information currently carried in "a SKIP header" in the payload of a UDP packet sent to a "key exchange" port number. The receiver of such a packet would set up an SPI (not SPI #1!), like in any other key exchange protocol. Future data packets could use standard IPSEC packet formats, specifying the SPI and not using any SKIP headers. A new UDP packet would be sent (and possibly a new SPI assigned) when the session key needed to be updated. This would have some slightly different tradeoffs from today's SKIP, making it much more like every other key management protocol, while using the same underlying algorithms and data formats. Alternatively "a SKIP header" could indeed be carried in a transform, though that seems a bit peculiar. A transform that sets up new SPI's? Or that doesn't use any existing SPI? Was this what Steve Bellovin was suggesting when he proposed setting aside some reserved, statically configured SPI's for SKIP with various parameters? E.g. could we standardize on SPI #1 to be the "SKIP transform SPI", requiring no prior key management protocol to set up this SPI? One problem is that this "transform" would actually be several transforms (one for SKIP-with-DES, another for SKIP-with-3DES, etc); by moving the key management into the transform spec, we lose the modularity that we gained by having a separate transform spec for each packet-encryption algorithm. The SKIP certificate discovery protocol (CDP) is silent on a big question: *where* to send a certificate discovery request. Using Secure DNS instead for key retrieval at least answers that question. The CDP also hand-waves some key issues for interoperability, like the exact format of responses. E.g. it specifies "Secure DNS certificates" as a valid response, but references a Secure DNS I-D that never defines a certificate format. Secure DNS maintains separate KEY and SIG records, and the SIG is computed over all KEY records for a given name; each one is not individually signed, and there is no specific format for putting this info together into a "certificate". Perfect Forward Secrecy is what will give any key management protocol the resilience to defeat mass surveillance following government-imposed key escrow. This is true even assuming compromise of the long-term private keys associated with nodes or users; PFS when implemented well requires an active attack which has access to the private keys of both parties. Active attacks are much harder to mount on a mass scale than today's common "vacuum-cleaner" passive monitoring; and access to the private keys of all citizens in realtime without warrants is something even Louis Freeh would think twice about. If we fail to require PFS in our infrastructure, we make it liable to complete privacy failure, via administrative or legislative fiat imposed on a small number of key certification sites. Ashar may feel that the overhead of PFS is too high; in reality, the lack of PFS renders a data privacy protocol pointless in today's political climate -- at least if you want to keep your information private from any government anywhere in the world. If France wants your keys to do industrial espionage, the US would be happy to sign a treaty that hands your escrowed keys to the French government. All France has to do is to allege that you've committed a crime -- and in France, you are guilty until proven innocent. The complicated and unimplemented SKIP PFS design (abuse the certificate discovery protocol to exchange certs for ephemeral D-H keys, then use SKIP protocol headers to produce session keys) makes it hard to take SKIP seriously as "the" protocol to deploy for the secure Internet of 1997. But perhaps many of its best ideas can live in a variant protocol. John To: "C. Harald Koch" Cc: perry@piermont.com, Stephen Kent , ipsec@TIS.COM, gnu@toad.com Cc: paul@vix.com, dee@cybercash.com Subject: DNSSEC can't retrieve "A" and "KEY" records in the same query In-Reply-To: <96Sep9.101903edt.18473-1@janus.border.com> Date: Thu, 12 Sep 1996 01:56:09 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609120748.aa22699@neptune.TIS.COM> > > In a large internet, key lookup will be required, the result of which > > will be that SKIP will have no advantage whatsoever in terms of number > > of message exchanges compared with other techniques. > > Piggy-back the keys in the Additional Records portion of the DNS response to > the initial hostname lookup (I believe some SKIP implementations already do > this). This is a DNSSEC implementation issue, not a SKIP issue. DNSSEC does not currently require this. It piggybacks SIG records in the additional records portion even if you didn't ask for them, but only provides KEY records if you ask for them. The DNS specs permit several questions to be asked in a single DNS query. Unfortunately the widespread implementation, BIND, only answers queries that contain a single question. If it implemented the full spec, the resolver could send in a DNS query that asked: Send me all the "IN A" records for foo.com. Send me all the "IN KEY" records for foo.com. and get the response back in a single packet exchange. One could ask for "ALL" records, but that would probably end up returning enough data to require a TCP connection, which already involves a multi-packet exchange. We could conceivably require DNSSEC-conforming implementations to handle multiple questions in a query, but the resolver library would still have to be able to fall back to asking one question at a time it got a FORMERR (format error) from an old server in response to a multi-question query. This fallback would also require multiple packets. John Date: Thu, 12 Sep 1996 07:48:09 -0400 To: HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM From: Robert Moskowitz Subject: Re: SKIP in IPSEC: is it really simple? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609120752.aa22838@neptune.TIS.COM> At 10:51 AM 9/11/96 EDT, HUGO@watson.ibm.com wrote: Let me give you my 'take' on how this will effect the auto industry: > >Plain SKIP (no pfs, no CDP, no ADP) is simple. >With all these additions it is not that simple (not SKIP's >fault but the inevitable complexity of our requirements/applications). >If in addition you start considering all the "submodes": > yes PFS/no PFS, Needed > long term certificates/ short term cerificiates, > yes algorithm discovery/ no algorithm discovery, Needed > yes anonymity/no anonymity (with/without PFS), Needed > per-packet SKIP header/ per-session SKIP header, etc. >then SKIP is COMPLEX (not SKIP's fault: I've heard voices in this list >for almost every possible combination of these submodes!). Our use of SKIP would be at least COMPLEX, not simple. > >In ISAKMP/Oakley these complexities appear explicitly instead of blurred >over different Internet drafts. But let's not lie to ourselves FULL SKIP >(as needed to support those requirements on which there is already >WG consensus: PFS, certificate-based key mgmt, anonymity) >is COMPLEX. > >ISAKMP/Oakley, on the other hand, has several security advantages >over SKIP >(hand-shakes for key exchange/refreshment, goodness >freshness proof in each exchange, goodness >randomness contributed by both parties to the key, goodness >no reliance on shared time, very goodness >explicit framework to analyze security, goodness >no reliance in universal DH group, goodness >explicit negotiation and authentication >of key attributes). goodness > >Let's choose the most desirable subset of Oakley exchanges >and make them mandatory (ie, basis for inter-operability). >ISAKMP and the other Oakley exchanges give the basis for >optional/future extensions. These, plus other differentiators that have been covered over the past many months, makes Oakley/ISAKMP the only alternative for the auto industry's interoperability needs. Of course on company can choose to use SKIP for internal uses, we are not claiming otherwise. Just that you will need Oakley for trading partner communication. > Robert Moskowitz Chrysler Corporation (810) 758-8212 Date: Thu, 12 Sep 1996 07:48:09 -0400 To: HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM From: Robert Moskowitz Subject: Re: SKIP in IPSEC: is it really simple? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609120800.aa22965@neptune.TIS.COM> At 10:51 AM 9/11/96 EDT, HUGO@watson.ibm.com wrote: Let me give you my 'take' on how this will effect the auto industry: > >Plain SKIP (no pfs, no CDP, no ADP) is simple. >With all these additions it is not that simple (not SKIP's >fault but the inevitable complexity of our requirements/applications). >If in addition you start considering all the "submodes": > yes PFS/no PFS, Needed > long term certificates/ short term cerificiates, > yes algorithm discovery/ no algorithm discovery, Needed > yes anonymity/no anonymity (with/without PFS), Needed > per-packet SKIP header/ per-session SKIP header, etc. >then SKIP is COMPLEX (not SKIP's fault: I've heard voices in this list >for almost every possible combination of these submodes!). Our use of SKIP would be at least COMPLEX, not simple. > >In ISAKMP/Oakley these complexities appear explicitly instead of blurred >over different Internet drafts. But let's not lie to ourselves FULL SKIP >(as needed to support those requirements on which there is already >WG consensus: PFS, certificate-based key mgmt, anonymity) >is COMPLEX. > >ISAKMP/Oakley, on the other hand, has several security advantages >over SKIP >(hand-shakes for key exchange/refreshment, goodness >freshness proof in each exchange, goodness >randomness contributed by both parties to the key, goodness >no reliance on shared time, very goodness >explicit framework to analyze security, goodness >no reliance in universal DH group, goodness >explicit negotiation and authentication >of key attributes). goodness > >Let's choose the most desirable subset of Oakley exchanges >and make them mandatory (ie, basis for inter-operability). >ISAKMP and the other Oakley exchanges give the basis for >optional/future extensions. These, plus other differentiators that have been covered over the past many months, makes Oakley/ISAKMP the only alternative for the auto industry's interoperability needs. Of course on company can choose to use SKIP for internal uses, we are not claiming otherwise. Just that you will need Oakley for trading partner communication. > Robert Moskowitz Chrysler Corporation (810) 758-8212 Date: Thu, 12 Sep 1996 08:23:56 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: "C. Harald Koch" , perry@piermont.com, Stephen Kent , ipsec@TIS.COM, gnu@toad.com, paul@vix.com Subject: Re: DNSSEC can't retrieve "A" and "KEY" records in the same query In-Reply-To: <199609120856.BAA26979@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk See part of draft-ietf-dnssec-secext-10.txt, which has been approved as a Proposed Standard, appended at the end of this message. Automatic inclusion of KEY RR's, if there is space in a UDP response, is mandatory. Donald (on the ipsec list but way behind and not currently following stuff there...) On Thu, 12 Sep 1996, John Gilmore wrote: > Date: Thu, 12 Sep 1996 01:56:09 -0700 > From: John Gilmore > To: "C. Harald Koch" > Cc: perry@piermont.com, Stephen Kent , ipsec@TIS.COM, > gnu@toad.com, paul@vix.com, dee@cybercash.com > Subject: DNSSEC can't retrieve "A" and "KEY" records in the same query > > > > In a large internet, key lookup will be required, the result of which > > > will be that SKIP will have no advantage whatsoever in terms of number > > > of message exchanges compared with other techniques. > > > > Piggy-back the keys in the Additional Records portion of the DNS response to > > the initial hostname lookup (I believe some SKIP implementations already do > > this). > > This is a DNSSEC implementation issue, not a SKIP issue. DNSSEC does > not currently require this. It piggybacks SIG records in the > additional records portion even if you didn't ask for them, but only > provides KEY records if you ask for them. > > The DNS specs permit several questions to be asked in a single DNS > query. Unfortunately the widespread implementation, BIND, only > answers queries that contain a single question. If it implemented the > full spec, the resolver could send in a DNS query that asked: > > Send me all the "IN A" records for foo.com. > Send me all the "IN KEY" records for foo.com. > > and get the response back in a single packet exchange. > > One could ask for "ALL" records, but that would probably end up > returning enough data to require a TCP connection, which already > involves a multi-packet exchange. > > We could conceivably require DNSSEC-conforming implementations to > handle multiple questions in a query, but the resolver library would > still have to be able to fall back to asking one question at a time it > got a FORMERR (format error) from an old server in response to a > multi-question query. This fallback would also require multiple > packets. > > John Extract from draft-ietf-dnssec-secext-10.txt: 3.7 KEY RRs in the Construction of Responses An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server. Security aware DNS servers MUST include KEY RRs as additional information in responses where appropriate including the following: (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers MUST be included as additional information if space is avilable. There will always be at least one such KEY RR in a secure zone, even if it has the no-key type value to indicate that the subzone is insecure. If not all additional information will fit, the KEY RR(s) have higher priority than type A or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the retrieval must be considered truncated. (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST be included if space is available. On inclusion of A or AAAA RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A or AAAA RRs. ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.hq.tis.com by neptune.TIS.COM id aa25140; 12 Sep 96 10:31 EDT Received: by relay.hq.tis.com; id KAA09397; Thu, 12 Sep 1996 10:34:47 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009381; Thu, 12 Sep 96 10:34:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14742; Thu, 12 Sep 96 10:33:28 EDT Received: by relay.hq.tis.com; id KAA09375; Thu, 12 Sep 1996 10:34:17 -0400 Received: from dns.sprintcorp.com(144.230.1.35) by relay.tis.com via smap (V3.1.1) id xma009338; Thu, 12 Sep 96 10:33:16 -0400 Received: from firewall by dns.sprintcorp.com (5.4R3.10/200.2.1.5) id AA03654; Thu, 12 Sep 1996 09:01:19 -0500 Message-Id: <323817B0.3D4@sprintcorp.com> Date: Thu, 12 Sep 1996 09:01:20 -0500 From: "Ashraf Madoukh - Sprint (913)534.3137" Organization: Sprint X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5 sun4u) Mime-Version: 1.0 To: ipsec@TIS.COM Subject: SKIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm new in SKIP topic and I wonder where I can find documentation on SKIP. Thanks, Ashraf Madoukh Sprint Received: from relay.hq.tis.com by neptune.TIS.COM id aa25333; 12 Sep 96 10:45 EDT Received: by relay.hq.tis.com; id KAA09756; Thu, 12 Sep 1996 10:48:48 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009734; Thu, 12 Sep 96 10:48:20 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16036; Thu, 12 Sep 96 10:47:29 EDT Received: by relay.hq.tis.com; id KAA09725; Thu, 12 Sep 1996 10:48:18 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma009657; Thu, 12 Sep 96 10:47:19 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id KAA40149; Thu, 12 Sep 1996 10:49:50 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id KAA695444; Thu, 12 Sep 1996 10:49:22 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22100; Thu, 12 Sep 1996 10:50:34 -0400 Date: Thu, 12 Sep 1996 10:50:34 -0400 Message-Id: <9609121450.AA22100@secpwr.watson.ibm.com> To: ipsec@TIS.COM, skrenta@osmosys.incog.com Subject: Re: SKIP in IPSEC: is it really simple? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: w0S5CRbwe8Der8qQIO9oMA== Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.hq.tis.com Thu Sep 12 09:58:58 1996 > From: Rich Skrenta > Message-Id: <199609120042.RAA17690@miraj.incog.com> > Subject: Re: SKIP in IPSEC: is it really simple? > To: ipsec@TIS.COM > Date: Wed, 11 Sep 1996 17:42:53 -0700 (PDT) > In-Reply-To: <199609111751.NAA734524@mailhub1.watson.ibm.com> from > Content-Length: 3621 > Status: RO ............................... =20 >=20 > > Isn't this a highly misleading argument?? >=20 > What is misleading to say is that SKIP has as high an overhead at = startup > as an Oakley exchange, when the overhead in practice is considerably = less. > It is also misleading to say that one can't have PFS in SKIP without > throwing out all of SKIP's advantages; this isn't true. If you run SKIP PFS extension, then the start up cost is about as high as any other interactive KMP. ............... > > ISAKMP/Oakley, on the other hand, has several security advantages > > over SKIP >=20 > Having to stop and renegotiate a session to change the traffic key is = not > an advantage. Why stop ? Just negotiate a new key before the old key expires. =20 >=20 > It is also incorrect to say that SKIP forces the Internet to = standardize > on a single g and p; this is once again an administrative issue. Our > implementation currently supports as many local (g, p, i) identities = as > the administrator cares to configure. It must, in order to support > simultaneous interoperability with products deployed to the different > rings of the US export law hell (2048 US, 1024 Swiss banks, 512 = non-US). I am sure your product can do that but I fail to see where such flexibility is mentioned in the SKIP draft. You are actually enhancing SKIP to address a practical concern. I think this is = another example of the complexity of the KMP issue. There are so many = concenrs and many requirements that it is hard to find a one-size-fit-all solution. =20 =20 =20 Pau-Chen Received: from relay.hq.tis.com by neptune.TIS.COM id aa26383; 12 Sep 96 12:17 EDT Received: by relay.hq.tis.com; id MAA11823; Thu, 12 Sep 1996 12:20:48 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma011816; Thu, 12 Sep 96 12:20:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21113; Thu, 12 Sep 96 12:19:32 EDT Received: by relay.hq.tis.com; id MAA11809; Thu, 12 Sep 1996 12:20:19 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma011800; Thu, 12 Sep 96 12:20:05 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id MAA79107; Thu, 12 Sep 1996 12:20:18 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id MAA529798; Thu, 12 Sep 1996 12:19:44 -0400 Message-Id: <199609121619.MAA529798@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5799; Thu, 12 Sep 96 12:19:42 EDT Date: Thu, 12 Sep 96 12:03:11 EDT To: skrenta@osmosys.incog.com, ipsec@TIS.COM Subject: SKIP in IPSEC: is it really simple? Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Wed, 11 Sep 1996 17:42:53 -0700 (PDT) (attached) > > What is misleading to say is that SKIP has as high an overhead at startup > as an Oakley exchange, when the overhead in practice is considerably less. > It is also misleading to say that one can't have PFS in SKIP without > throwing out all of SKIP's advantages; this isn't true. I haven't said or implied that. Any real advantages of SKIP can be added into the ISAKMP/Oakley framework (in particular, I was personally all for a convergence of all these protocols which is technically feasible, but unfortunately failed). > > This may well be a matter of religion, and not technical merit. > Some will choose to start with a simple protocol, and build upon that. > Others advocate designing a large, heavyweight protocol which offers > every conceivable feature (except statelessness, that is) from the start. The point is not to start with a heavyweight protocol that gives you every conceivable feature (and even statelessness if you want) but to start with a set of required features (eg PFS and anonymity as WG requirements, and secure/fresh handshakes as my *personal* requirement :) and have the right framework to build more features into it in the future. > > > ISAKMP/Oakley, on the other hand, has several security advantages > > over SKIP > > Having to stop and renegotiate a session to change the traffic key is not > an advantage. You do not have to stop to renegotiate a key, For example we have continouous encrypted/authenticated video running with key refreshments in between. > > It is also incorrect to say that SKIP forces the Internet to standardize > on a single g and p; this is once again an administrative issue. Our > implementation currently supports as many local (g, p, i) identities as Notice the word *local*: I meant a solution that scales to the whole Internet where not only *local parties* can communicate and inter-operate. > the administrator cares to configure. It must, in order to support > simultaneous interoperability with products deployed to the different > rings of the US export law hell (2048 US, 1024 Swiss banks, 512 non-US). > > > In any event, it's clear that there hasn't been, and won't be, consensus > to back one KMP exclusively. Continuing to delay further is pointless. > Let's have all existing KMPs proceed within the WG with the same status > as soon as possible. > My personal vote here is against co-existence. That will postpone global success (inter-operability) even more. There will be time to tune the one chosen protocol later with experience. But there should be one basis for all. Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa26817; 12 Sep 96 12:58 EDT Received: by relay.hq.tis.com; id NAA13332; Thu, 12 Sep 1996 13:01:48 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma013320; Thu, 12 Sep 96 13:01:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23662; Thu, 12 Sep 96 13:00:29 EDT Received: by relay.hq.tis.com; id NAA13315; Thu, 12 Sep 1996 13:01:18 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma013311; Thu, 12 Sep 96 13:00:55 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id TAA08939; Thu, 12 Sep 1996 19:03:06 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id TAA22432; Thu, 12 Sep 1996 19:03:03 +0200 (MET DST) Message-Id: <199609121703.TAA22432@kom30.ethz.ch> Subject: Re: SKIP in IPSEC: is it really simple? To: Robert Moskowitz Date: Thu, 12 Sep 1996 19:03:02 +0200 (MET DST) Cc: HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM In-Reply-To: <9609120752.aa22838@neptune.TIS.COM> from "Robert Moskowitz" at Sep 12, 96 07:48:09 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Robert Moskowitz wrote: > >no reliance on shared time, > very goodness How do you plan to handle certificate expiry without shared time? Germano Message-Id: <9609121610.AA07855@wisdom.home.vix.com> To: John Gilmore Cc: "C. Harald Koch" , perry@piermont.com, Stephen Kent , ipsec@TIS.COM, dee@cybercash.com Subject: Re: DNSSEC can't retrieve "A" and "KEY" records in the same query In-Reply-To: Your message of "Thu, 12 Sep 1996 01:56:09 PDT." <199609120856.BAA26979@toad.com> Date: Thu, 12 Sep 1996 09:10:12 -0700 From: Paul A Vixie Sender: ipsec-approval@neptune.tis.com Precedence: bulk > This is a DNSSEC implementation issue, not a SKIP issue. DNSSEC does > not currently require this. It piggybacks SIG records in the > additional records portion even if you didn't ask for them, but only > provides KEY records if you ask for them. i think donald says this isn't an accurate story. > The DNS specs permit several questions to be asked in a single DNS > query. Unfortunately the widespread implementation, BIND, only > answers queries that contain a single question. If it implemented the > full spec, the resolver could send in a DNS query that asked: > > Send me all the "IN A" records for foo.com. > Send me all the "IN KEY" records for foo.com. > > and get the response back in a single packet exchange. the full spec does not answer some of the important questions that come up if qdcount>1, like how can you tell which answer goes with which query if the queries generate similar answers? consider wildcard RRs and CNAMEs. rather than answer this off the cuff, BIND (correctly) considers it a format error to have more than one question. the only _real_ or intended (i asked PVM) reason why qdcount could ever be >1 is for IQUERY, which BIND deprecated a while ago and will shortly remove. multiple questions would be nice but it will take a completely different encoding, probably one that allows multiple DNS Messages per datagram so that the question and answer and additional and authority stuff doesn't get mixed, but compression pointers will work fine so we can save a lot of name bytes. > One could ask for "ALL" records, but that would probably end up > returning enough data to require a TCP connection, which already > involves a multi-packet exchange. this won't work -- we couldn't do it for AAAA/A RRs either, since if your question goes to a nonauthoritative server (like a LAN's caching forwarder) it will give you "ALL" of what it has, which might be nothing or everything or something in betwixt. > We could conceivably require DNSSEC-conforming implementations to > handle multiple questions in a query, but the resolver library would > still have to be able to fall back to asking one question at a time it > got a FORMERR (format error) from an old server in response to a > multi-question query. This fallback would also require multiple > packets. this is a slippery slope, let's not solve it as part of DNSSEC. what i'm proposing for AAAA is that it be a metaquery -- retrieving AAAA RRs if any exist, or A RRs if any exist, or NXDOMAIN if neither exist. it sounds like donald solved the similar problem in KEY via additional data. From: Rich Skrenta Message-Id: <199609121717.KAA18752@miraj.incog.com> Subject: Re: Using SKIP as inspiration, not as gospel To: ipsec@TIS.COM Date: Thu, 12 Sep 1996 10:17:32 -0700 (PDT) In-Reply-To: <9609120746.aa22647@neptune.TIS.COM> from "John Gilmore" at Sep 12, 96 01:35:34 am X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk John, The fact that the SKIP camp is not willing to open up a solidified, mature design to rewhack it into something that looks just like Photurus does not make us "hamstrung". To suggest that we change SKIP to make it "more like every other key management protocol" misses the point of this entire debate. > The SKIP certificate discovery protocol (CDP) is silent on a big > question: *where* to send a certificate discovery request. To the host you're trying to send encrypted packets to. This works quite well in practice, as the remote side (be it an endpoint or a site gateway) generally has their own certificate. Received: from relay.hq.tis.com by neptune.TIS.COM id aa28434; 12 Sep 96 14:53 EDT Received: by relay.hq.tis.com; id OAA19703; Thu, 12 Sep 1996 14:57:19 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma019696; Thu, 12 Sep 96 14:56:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00760; Thu, 12 Sep 96 14:56:01 EDT Received: by relay.hq.tis.com; id OAA19688; Thu, 12 Sep 1996 14:56:49 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma019682; Thu, 12 Sep 96 14:56:46 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA96341; Thu, 12 Sep 1996 14:56:49 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id OAA648240; Thu, 12 Sep 1996 14:55:11 -0400 Message-Id: <199609121855.OAA648240@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9137; Thu, 12 Sep 96 14:55:09 EDT Date: Thu, 12 Sep 96 14:52:47 EDT To: caronni@tik.ee.ethz.ch, rgm3@chrysler.com Cc: skrenta@osmosys.incog.com, ipsec@TIS.COM Subject: SKIP in IPSEC: is it really simple? Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 12 Sep 1996 19:03:02 +0200 (MET DST) > how do you plan to handle certificate expiry without shared time? time for certificate expiration and time for freshness/anti-reply in key exchange protocols are two very different issues. The need for the first doesn't justify its use when generating fresh session keys. Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa28675; 12 Sep 96 15:04 EDT Received: by relay.hq.tis.com; id PAA20147; Thu, 12 Sep 1996 15:07:49 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020136; Thu, 12 Sep 96 15:07:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01681; Thu, 12 Sep 96 15:06:30 EDT Received: by relay.hq.tis.com; id PAA20127; Thu, 12 Sep 1996 15:07:19 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma020121; Thu, 12 Sep 96 15:07:14 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 12 Sep 1996 15:09:21 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA00602; Thu, 12 Sep 1996 15:08:54 -0400 Message-Id: <199609121908.PAA00602@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Germano Caronni Cc: Robert Moskowitz , HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM Subject: Re: SKIP in IPSEC: is it really simple? In-Reply-To: caronni's message of Thu, 12 Sep 1996 19:03:02 +0200. <199609121703.TAA22432@kom30.ethz.ch> Date: Thu, 12 Sep 1996 15:08:42 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > How do you plan to handle certificate expiry without shared time? There are many different grades of shared time out there. I don't think you need NTP-grade shared time (or even kerberos-grade shared time -- ~5minute accuracy) to enforce expirations of certificates which last over a month ... getting the day right is probably good enough. By the way, when engineering timeouts and grace periods, you also have to think about clock frequency errors, network latency, and processing latency in addition to absolute accuracy. I butted heads with this issue when doing the DCE RPC security protocol (though for that, we do require shared time). In the general case, you don't *ever* want to send a packet which the reciever will reject because the SPI just expired. SPI timeouts should probably be expressed with a relative TTL after which the sender should not send to the SPI; the receiver should continue to honor packets received on the SPI for a (short) grace period after the published TTL expires, the grace period being a function of the TTL (to allow for clock frequency errors) and the worst-case end-to-end latency between the systems.. - Bill To: Rich Skrenta Cc: ipsec@TIS.COM Subject: Re: Using SKIP as inspiration, not as gospel In-Reply-To: Your message of "Thu, 12 Sep 1996 10:17:32 PDT." <199609121717.KAA18752@miraj.incog.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 12 Sep 1996 14:54:34 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609121513.aa28910@neptune.TIS.COM> Rich Skrenta writes: > The fact that the SKIP camp is not willing to open up a solidified, mature > design to rewhack it into something that looks just like Photurus does not > make us "hamstrung". To suggest that we change SKIP to make it "more like > every other key management protocol" misses the point of this entire > debate. Rich; Other people don't think of SKIP as a solidified, mature design. To many of the rest of us, it is very unclear that SKIP has any advantages over other protocols -- the claims to the effect that it is lower overhead are illusory. Some of us don't like the fact that SKIP does not play nicely with the IPSec model. It has improved in certain respects with respect to the requirements, but the fact remains that it just isn't, to many of us, what the doctor ordered. You and everyone else at Sun's Internet Commerce group are necessarily going to disagree, I'm sure. I don't think this is going to be resolved by discussion. I believe that intransigence has definitively set in. Perry Message-Id: <199609121907.MAA21082@denwa.incog.com> X-Mailer: exmh version 1.6.4 10/10/95 To: HUGO@watson.ibm.com Cc: skrenta@osmosys.incog.com, ipsec@TIS.COM Subject: Re: SKIP in IPSEC: is it really simple? In-Reply-To: Your message of "Thu, 12 Sep 1996 12:03:11 EDT." <199609121619.MAA529798@mailhub1.watson.ibm.com> X-Url: http://www.incog.com/~stoltz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Sep 1996 12:07:26 -0700 From: Ben Stoltz Sender: ipsec-approval@neptune.tis.com Precedence: bulk HUGO@watson.ibm.com said: > My personal vote here is against co-existence. That will postpone > global success (inter-operability) even more. There will be time to > tune the one chosen protocol later with experience. But there should > be one basis for all. > > Hugo Although the decision of IPSEC is important, I don't think it will have the effect that you desire. IMHO, each of the IPSEC proposals have gone past the point of being buried or marginalized. Additional IPSEC requirements are going to come into being through evolution of the existing implementations. Even if IPSEC completely drops one proposal, the installed customer base will need to be migrated to the final IPSEC implementation and many existing and new customers will find substantial value in the original product offerings. People seem to be burning a lot more calories arguing and fretting over these "issues" than is healthy. What if the argument were "Should we implement TCP or UDP?", "Should we implement IPX or IP?", "Should we manufacture cargo planes or box cars?", "Run Windows NT or MVS or maybe even Unix?" For any single customer there might very well be a correct answer, but would be a real feat if it applied to all. A single standard is a beguiling goal, but it is not always relevant or as economical as it may seem. Swiss army knifes are great, but if I spend all my time driving nails, I don't need one. Ben Received: from relay.hq.tis.com by neptune.TIS.COM id aa05175; 13 Sep 96 1:27 EDT Received: by relay.hq.tis.com; id BAA00567; Fri, 13 Sep 1996 01:31:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000562; Fri, 13 Sep 96 01:30:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20189; Fri, 13 Sep 96 01:30:04 EDT Received: by relay.hq.tis.com; id BAA00556; Fri, 13 Sep 1996 01:30:53 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma000552; Fri, 13 Sep 96 01:30:36 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id WAA05493; Thu, 12 Sep 1996 22:29:37 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id WAA10380; Thu, 12 Sep 1996 22:33:20 -0700 Message-Id: <199609130533.WAA10380@mailsun2.us.oracle.com> Date: 12 Sep 96 22:28:15 -0700 From: "PALAMBER.US.ORACLE.COM" To: skrenta@osmosys.incog.com Subject: Re: SKIP Design & Applicability Statement Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:skrenta@osmosys.incog.com's message of 11-Sep-96 18:29 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_7455469_0_11919609122334200" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_7455469_0_11919609122334200 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Rich, >From: Rich Skrenta >> While I do understand Sun's investment in SKIP, please be cautious in the >> posting of material that might be misconstrued as marketing material. > >No one that I'm aware of has misconstrued the new applicability statement >as marketing material. It has, after all, nothing to do with our current >product offerings, but is solely about the SKIP protocol itself. It >should apply to any implementation of SKIP, whether developed by Sun or >by any of our competitors. Perhaps, but so many postings on the "benefits" of a proposal could appear self serving. >From: Rich Skrenta >The fact that the SKIP camp is not willing to open up ... Your many postings to this list may not be helping to advocate SKIP. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_7455469_0_11919609122334200 Content-Type:message/rfc822 Date: 11 Sep 96 18:29:13 From:"skrenta@osmosys.incog.com (Rich Skrenta)" To:PALAMBER@us.oracle.com,(PALAMBER.US.ORACLE.COM) Subject:Re: SKIP Design & Applicability Statement Cc:ipsec@tis.com,asdf@osmosys.incog.com In-Reply-To:<199609120116.SAA12420@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Sep 11, 96 06:11:32 pm X-Mailer:ELM [version 2.4 PL24 PGP5] MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" > This was not a request for more SKIP information to be posted. Apologies for the misunderstanding; as the request made its way to me, I understood it to mean that you had never seen the applicability statement that Ashar had written (at your request), and that we should provide this. Since Ashar had recently added to his statement, it seemed like a good time to send it out. > While I do understand Sun's investment in SKIP, please be cautious in the > posting of material that might be misconstrued as marketing material. No one that I'm aware of has misconstrued the new applicability statement as marketing material. It has, after all, nothing to do with our current product offerings, but is solely about the SKIP protocol itself. It should apply to any implementation of SKIP, whether developed by Sun or by any of our competitors. > I did call Glenn Scott (of Sun) and strongly encouraged the posting of a > statement from Sun on the licensing and applicability of the "new" Sun > patent that makes broad claims on IPsec related technology. I believe that an official statement regarding this new patent is working its way through legal here and should be forthcoming. --=_ORCL_7455469_0_11919609122334200-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa05281; 13 Sep 96 1:37 EDT Received: by relay.hq.tis.com; id BAA00676; Fri, 13 Sep 1996 01:41:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000673; Fri, 13 Sep 96 01:40:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20374; Fri, 13 Sep 96 01:40:04 EDT Received: by relay.hq.tis.com; id BAA00668; Fri, 13 Sep 1996 01:40:54 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma000664; Fri, 13 Sep 96 01:40:42 -0400 Received: from [128.89.30.29] (ARA29.BBN.COM [128.89.30.29]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id BAA01456; Fri, 13 Sep 1996 01:48:12 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Sep 1996 01:44:45 -0500 To: Stuart Jacobs From: Stephen Kent Subject: Re: Status of IPSEC Key Management Cc: perry@piermont.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Stuart, I believe that the current mobile IP specs talk only about shared secrets between the mobile nodes (MNs) and home agents (HAs), but are silent on how these values are established and maintained. Some folks at BBN have been working on certificate-based support for creation and management of the shared secrets, to help address the scaling issues. We adopted D-H certificates and a SKIP-variant computation to create per-transaction keys. I expect an MN to have cached the certificate (public key) for his HA (or HAs if there are a few) before leaving home. Similarly, the HA(s) should have no trouble caching (or quickly accessing from a local directory) certs and the CRL(s) for all of the MNs it serves. Thus, for these sorts of interactions, the only possible retrieval requirement would be for an MN to get the CRL for his HA(s). It may not be necessary to fetch this CRL very frequently, since the HA(s) can be made fairly secure (there are fewer of them and they ought to use hardware to protect keying material and for increased performance). Moreover, if you look at the implications of a disclosed HA private key used in this context, it isn't clear that the MN has a lot to lose if it is spoofed in this exchange. So, I think this approach can scale well. I agree that HA-FA secure communication is appropriate, and we anticipate establishing long duration SAs between these entities, probably muxing all forwarded traffic between these agents on a single SA. This strategy ought to minimize the need for lots of cert/CRL fetches, especially since the number of HA-FA parirs is much, much smaller than the number of MNs. Admittedly, though, there may be more situation here where one needs to fetch the certs and CRL from directories, if the HA-FA pairs are diverse and cachhing doesn't help as much. Our view has been that while signing of registration messages would be conceptually simple, the costs for signature generation and validation are high enough to deter use of this technique. For RSA signing, the amount of data transferred is also much larger, comparsed to a key hash value, which may be an issue in some instances. Finally, I would expect the cert/CRL caching requirements to be equivalent for the signed message approach vs. the keyed hash approach that we are pursuing, so there ought not any savings there. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa05298; 13 Sep 96 1:38 EDT Received: by relay.hq.tis.com; id BAA00687; Fri, 13 Sep 1996 01:42:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000685; Fri, 13 Sep 96 01:41:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20397; Fri, 13 Sep 96 01:41:03 EDT Received: by relay.hq.tis.com; id BAA00682; Fri, 13 Sep 1996 01:41:53 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma000679; Fri, 13 Sep 96 01:41:42 -0400 Received: from [128.89.30.29] (ARA29.BBN.COM [128.89.30.29]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id BAA01453; Fri, 13 Sep 1996 01:48:06 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Sep 1996 01:44:39 -0500 To: HUGO@watson.ibm.com From: Stephen Kent Subject: Re: Status of IPSEC Key Management Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hugo, Good questions. When I say "SKIP" I mean the version of SKIP without PFS, using long term D-H certificates. The 0-exchange key generation nature of this version of SKIP is attractive, and the fact that the traffic key is identified by crypto header information is important as well. Admittedly, the 0-exchange feature is something of a misnomer, in that each communicating party much have acquired the long term certificate of the other in advance, and may also need to have acquired a recent CRL too. However, these retrieval operations are outside the key management protocol per se, and they need not involve communication with the other party. Hence there is a difference between this approach and approaches based on updated traffic keys generated from shared secrets created by previous exchanges between the parties. Does that help clarify my comments? Steve Message-Id: <199609130501.WAA07611@toad.com> To: "Donald E. Eastlake 3rd" Cc: chk@border.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM Subject: Re: DNSSEC *can* retrieve "A" and "KEY" records in the same query In-Reply-To: Date: Thu, 12 Sep 1996 22:01:50 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I stand corrected. I hadn't closely read the latest (-10) DNSSEC draft yet. The ability to retrieve keys along with A and NS records reduces long-haul round trips, because the keys will be cached and can be retrieved from the local cache. There are currently no applications which ask for both A and KEY records. The app (typically) asks for A records with gethostbyname to open a TCP connection. When the first TCP packet comes out, a key management daemon (on the same host, or on a S/WAN gateway) asks for the KEY records. John Received: by gw.home.vix.com id WAA06099; Thu, 12 Sep 1996 22:20:59 -0700 (PDT) Received: by wisdom.home.vix.com id AA08661; Thu, 12 Sep 1996 22:20:59 -0700 Message-Id: <9609130520.AA08661@wisdom.home.vix.com> To: John Gilmore Cc: dee@cybercash.com, chk@border.com, perry@piermont.com, ipsec@TIS.COM Subject: Re: DNSSEC *can* retrieve "A" and "KEY" records in the same query Date: Thu, 12 Sep 1996 22:20:54 -0700 From: Paul A Vixie Sender: ipsec-approval@neptune.tis.com Precedence: bulk > The ability to retrieve keys along with A and NS records reduces > long-haul round trips, because the keys will be cached and can be > retrieved from the local cache. There are currently no applications > which ask for both A and KEY records. The app (typically) asks for A > records with gethostbyname to open a TCP connection. When the first > TCP packet comes out, a key management daemon (on the same host, or on > a S/WAN gateway) asks for the KEY records. The DNS caching model calls for each resolver to have a cache. BIND implements this with a stub resolver and a statically configured list of caching forwarders. Windows and the other DNS clients emulate BIND in is regard. If the KEY RR comes in as additional data from the authority server when it answers someone's caching forwarder, the KEY will be cached and the stub resolver will be able to retrieve it "locally." In other words this isn't ideal or pretty but it should work without massive performance problems. Message-Id: <3.0b16.32.19960913111912.00a46008@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b16 (32) Date: Fri, 13 Sep 1996 11:23:40 -0400 To: caronni@tik.ee.ethz.ch, Robert Moskowitz From: Robert Moskowitz Subject: Re: SKIP in IPSEC: is it really simple? Cc: HUGO@watson.ibm.com, skrenta@osmosys.incog.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:03 PM 9/12/96 +0200, Germano Caronni wrote: >Robert Moskowitz wrote: >> >no reliance on shared time, >> very goodness > >How do you plan to handle certificate expiry without shared time? When you factor in proper business practices (not those that verisign practices), the slew for cert expiry is much greater than for secure hand shakes. In fact, a business goal for a registery is to reissue a cert n months before expiry unless there is a REAL business reason (chapter 11 or worst) to totally trash their cert. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa12804; 13 Sep 96 12:46 EDT Received: by relay.hq.tis.com; id MAA12922; Fri, 13 Sep 1996 12:50:09 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma012865; Fri, 13 Sep 96 12:49:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19571; Fri, 13 Sep 96 12:48:50 EDT Received: by relay.hq.tis.com; id MAA12860; Fri, 13 Sep 1996 12:49:40 -0400 Received: from chimay.mach.cs.cmu.edu(128.2.222.167) by relay.tis.com via smap (V3.1.1) id xma012838; Fri, 13 Sep 96 12:49:14 -0400 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa13968; 13 Sep 96 12:50:22 EDT To: Stephen Kent Cc: Stuart Jacobs , perry@piermont.com, ipsec@TIS.COM In-Reply-To: Your message of "Fri, 13 Sep 96 01:44:45 CDT" From: Dave Johnson Subject: Re: Status of IPSEC Key Management Date: Fri, 13 Sep 96 12:47:29 -0400 Message-Id: <13957.842633249@CHIMAY.MACH.CS.CMU.EDU> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve Kent said: > I believe that the current mobile IP specs talk only about shared >secrets between the mobile nodes (MNs) and home agents (HAs), but are >silent on how these values are established and maintained. This is mostly correct. Mobile IP does not say where the security association comes from, but we do require that a security association must exist between a mobile node and its home agent, and that it must be used for authentication on all Registration Request and Registration Reply messages. Mobile IP also allows for a security association between a mobile node and its foreign agent and/or between a foreign agent and the home agent, but we do not require these to exist. If they do exist, though, we require that they be used for authentication on the registration messages, along with the authentication between the mobile node and its home agent that always must be there. We assume (and hope) that IPsec key management and key management from research like that you mentioned at BBN will help provide the necessary keys and security associations in the future, but for deployment now, manual configuration of security associations can be used. Dave Received: from relay.hq.tis.com by neptune.TIS.COM id aa15776; 13 Sep 96 17:33 EDT Received: by relay.hq.tis.com; id RAA04571; Fri, 13 Sep 1996 17:36:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004544; Fri, 13 Sep 96 17:36:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06360; Fri, 13 Sep 96 17:35:27 EDT Received: by relay.hq.tis.com; id RAA04539; Fri, 13 Sep 1996 17:36:16 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma004535; Fri, 13 Sep 96 17:36:15 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA14317; Fri, 13 Sep 1996 14:38:30 -0700 (PDT) Date: Fri, 13 Sep 1996 14:38:30 -0700 (PDT) From: Phil Karn Message-Id: <199609132138.OAA14317@servo.qualcomm.com> To: rgm3@chrysler.com Cc: smb@research.att.com, chk@border.com, ipsec@TIS.COM In-Reply-To: <3.0b15.32.19960911125801.00b03008@pop3hub.is.chrysler.com> (message from Robert Moskowitz on Wed, 11 Sep 1996 13:05:03 -0400) Subject: Re: bandwidth in the Internet Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Much of this is in the V.42bis logic. Well since we are encrypting, modem >compression does not buy much. Turn it off and check out the difference. >Of course if you do this, non-encrypted compressable data suffers >conciderably (unless you have a PPP level compression). >Of course the delay in the V.42 logic cannot be helped. My experience is >you never want to run without V.42, even if you risk the 12 naks of death. A few years ago I investigated propagation delay in V.32bis modems and came to a different conclusion. Turning off V.42bis (no compression and no error control) only slightly reduced the delay. It was even present in synchronous mode where there's a direct connection between the serial port and the data pump (this was an older and fairly expensive Motorola/Codex modem that still supported sync mode). Remote loopback measurements with a Fireberd bit error rate test set in synchronous mode showed the round trip delay over a local call to be in the range of 80-90 ms. That's about 1200 bits at 14.4 kb/s. That's way too many bits to be accounted for by the modulator, scrambler or the Viterbi (trellis) decoder. The only possible place were that many bits could be stored is in the receive equalizer. This is a finite impulse response filter (a tapped delay line) that corrects for nonflat group delay (aka nonlinear phase response) in the phone line that causes propagation delay to vary with audio frequency. This filter is pretty long to allow for worst case group delay distortion. An adaptive algorithm sets the taps on this delay line when the modem trains, so the exact amount of delay can change from call to call. Apparently no attempt is made in these algorithms to push the equalizer taps as far forward as possible, i.e., to use the minimum delay necessary to correct the actual amount of delay dispersion on the line. The echo canceller in my modem indicated a far end echo less than 1 ms away, as expected for a local call, yet the peak equalizer tap was still being set in the 40 ms range (2x40ms = 80ms). So the bottom line is that the lion's share of delay in a modern dialup modem is almost certainly the receive equalizer. Better algorithms could be devised to reduce the equalizer delay to the bare minimum for each call, but in today's modem market it may be difficult to convince a manufacturer to do something about it unless a whole lot of people complain. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa17993; 13 Sep 96 21:44 EDT Received: by relay.hq.tis.com; id VAA08018; Fri, 13 Sep 1996 21:47:47 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008011; Fri, 13 Sep 96 21:47:18 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12996; Fri, 13 Sep 96 21:46:28 EDT Received: by relay.hq.tis.com; id VAA08008; Fri, 13 Sep 1996 21:47:17 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma008005; Fri, 13 Sep 96 21:46:59 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id SAA02946; Fri, 13 Sep 1996 18:47:24 -0700 Received: from miraj.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id SAA20003; Fri, 13 Sep 1996 18:49:38 -0700 Received: by miraj.incog.com (SMI-8.6/SMI-SVR4) id SAA19955; Fri, 13 Sep 1996 18:48:08 -0700 From: Ashar Aziz Message-Id: <199609140148.SAA19955@miraj.incog.com> Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Fri, 13 Sep 1996 18:48:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk About two weeks ago I sent the following protest regarding the Montreal meeting minutes to the IPsec chairs. I haven't seen a correction posted or received any response to my message. Since the minutes went out on the ipsec mailing list, I would like to make my objections known here also. -----------(Begin Forwarded Message)-------------------------- From: To: palamber@us.oracle.com, rja@cisco.com, jis@mit.edu Subject: Re: IPsec Minutes from Montreal Date sent: Tue, 3 Sep 1996 17:07:12 Folks, I would like to protest at the way the meeting minutes were reported for the ipsec Montreal meeting. Although these were published a few weeks ago, I have only recently had a chance to catch up to the postings on the ipsec list. IMHO the meeting minutes should reflect what transpired, and not be editorialized with the minute writer's personal views of the various proposals. Also, when there are competing proposals, I believe some consideration should be given to fairness in the way the various proposals are described. I refer specifically to the use of adjectives such as "significant overhead", "hard to implement and scale" and "claimed" support of multicast when describing SKIP. By contrast, adjectives used for ISAKMP/Oakley are "very general", "very flexible", etc. In addition, I have the following very specific objections to the minutes, which I am submitting for the record. > From ipsec-request@neptune.tis.com Mon Aug 5 16:56 PDT 1996 > The minutes of the last IPsec Working Group were posted to the IETF weeks ago > and have yet to appear in the official archive. For those of you that missed > attending the meeting in Montreal the minutes are attached below. > > > Regards, > > Paul > -------------------------------------------------------------- > Ashar Aziz presented SKIP. Note the use of the SKIP header > between IP header and AH or ESP. Two modes of use: the first mode has no > setup messages once the master keys are in place, no Perfect Forward Secrecy, > and has significant per-message overhead. This mode relies on pre-positioned > D-H master keys from which unicast keys are derived. The second mode uses > ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with > approximate PFS, anonymity, etc. Claimed multicast mode support is based on a > group co-ordinator creating a group key (distribution of the private key to > group members is not described here and is potentially hard to implement or > scale) which the sender uses as the target for Diffie-Hellman computation. > Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, > based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and > are being fixed in the next draft. Ashar pushed for adoption of the > certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs > as well as certificates, not just X.509 certificates, but PGP too. > First, the SKIP PFS exchange requires 2 messages, not 4-6. This is what I presented at the talk, and is present in the SKIP PFS I-D. Second, I don't understand what "approximate PFS" means. Is this a new term? If so, I would like to be enlightened, with perhaps some reference to the relevant literature. In any case, this is not a term that I used, and not something that come up during the discussion. Third, wrt "claimed" multicast support, distribution of group private key WAS described at the meeting. In fact more than one way of distributing the group private key was described. One of these used an exanding ring multicast search, which gets around the single node responsible for distributing the group private key. In any case, there were no comments about "difficult to implement" or "scaling" at the meeting, and therefore it would have been more pleasant to not find these in the meeting minutes (which I assume are the minute writer's personal views). Same comment wrt "significant per message overhead" description. This was not something that came up at the meeting, and is a subjective evaluation. Again, I assume this is a personal opinion of the minute writer and not something that should be part of the meeting minutes. Also, the group private key is not used as the target for any Diffie-Hellman computation. This is simply a misunderstanding of the protocol on the part of the minute writer. > Doug Maughan reported on ISAKMP. Free software is available via MIT > server at http://web.mit.edu/network/isakmp. And finally, we also have free software which we mentioned at the meeting, and gave the URL to. In fairness, perhaps it too should have been in the meeting minutes for the benefit of those who couldn't attend? I can understand that the minute writers (I assume that this included the chairs) have personal opinions about the competing proposals. May I request, however, that the meeting minutes not be used as the forum to promulgate these opinions, when they don't correspond to events that transpired at the meeting? Ashar. From: Ashar Aziz Message-Id: <199609132352.QAA19686@miraj.incog.com> Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Fri, 13 Sep 1996 16:52:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk About two weeks ago I sent the following protest regarding the Montreal meeting minutes to the IPsec chairs. I haven't seen a correction posted or received any response to my message. Since the minutes went out on the ipsec mailing list, I would like to make my objections known here also. -----------(Begin Forwarded Message)-------------------------- From: To: palamber@us.oracle.com, rja@cisco.com, jis@mit.edu Subject: Re: IPsec Minutes from Montreal Date sent: Tue, 3 Sep 1996 17:07:12 Folks, I would like to protest at the way the meeting minutes were reported for the ipsec Montreal meeting. Although these were published a few weeks ago, I have only recently had a chance to catch up to the postings on the ipsec list. IMHO the meeting minutes should reflect what transpired, and not be editorialized with the minute writer's personal views of the various proposals. Also, when there are competing proposals, I believe some consideration should be given to fairness in the way the various proposals are described. I refer specifically to the use of adjectives such as "significant overhead", "hard to implement and scale" and "claimed" support of multicast when describing SKIP. By contrast, adjectives used for ISAKMP/Oakley are "very general", "very flexible", etc. In addition, I have the following very specific objections to the minutes, which I am submitting for the record. > From ipsec-request@neptune.tis.com Mon Aug 5 16:56 PDT 1996 > The minutes of the last IPsec Working Group were posted to the IETF weeks ago > and have yet to appear in the official archive. For those of you that missed > attending the meeting in Montreal the minutes are attached below. > > > Regards, > > Paul > -------------------------------------------------------------- > Ashar Aziz presented SKIP. Note the use of the SKIP header > between IP header and AH or ESP. Two modes of use: the first mode has no > setup messages once the master keys are in place, no Perfect Forward Secrecy, > and has significant per-message overhead. This mode relies on pre-positioned > D-H master keys from which unicast keys are derived. The second mode uses > ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with > approximate PFS, anonymity, etc. Claimed multicast mode support is based on a > group co-ordinator creating a group key (distribution of the private key to > group members is not described here and is potentially hard to implement or > scale) which the sender uses as the target for Diffie-Hellman computation. > Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, > based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and > are being fixed in the next draft. Ashar pushed for adoption of the > certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs > as well as certificates, not just X.509 certificates, but PGP too. > First, the SKIP PFS exchange requires 2 messages, not 4-6. This is what I presented at the talk, and is present in the SKIP PFS I-D. Second, I don't understand what "approximate PFS" means. Is this a new term? If so, I would like to be enlightened, with perhaps some reference to the relevant literature. In any case, this is not a term that I used, and not something that come up during the discussion. Third, wrt "claimed" multicast support, distribution of group private key WAS described at the meeting. In fact more than one way of distributing the group private key was described. One of these used an exanding ring multicast search, which gets around the single node responsible for distributing the group private key. In any case, there were no comments about "difficult to implement" or "scaling" at the meeting, and therefore it would have been more pleasant to not find these in the meeting minutes (which I assume are the minute writer's personal views). Same comment wrt "significant per message overhead" description. This was not something that came up at the meeting, and is a subjective evaluation. Again, I assume this is a personal opinion of the minute writer and not something that should be part of the meeting minutes. Also, the group private key is not used as the target for any Diffie-Hellman computation. This is simply a misunderstanding of the protocol on the part of the minute writer. > Doug Maughan reported on ISAKMP. Free software is available via MIT > server at http://web.mit.edu/network/isakmp. And finally, we also have free software which we mentioned at the meeting, and gave the URL to. In fairness, perhaps it too should have been in the meeting minutes for the benefit of those who couldn't attend? I can understand that the minute writers (I assume that this included the chairs) have personal opinions about the competing proposals. May I request, however, that the meeting minutes not be used as the forum to promulgate these opinions, when they don't correspond to events that transpired at the meeting? Ashar. Message-Id: <199609132140.OAA05500@cornpuffs.cisco.com> From: Ran Atkinson Date: Fri, 13 Sep 1996 14:40:39 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Mobile IP background data Sender: ipsec-approval@neptune.tis.com Precedence: bulk I was one of several people directly involved with the addition of cryptographic authentication to the Mobile IP specification. So perhaps I can provide some additional background context and perspective. Historical Background: The reason that Mobile IP talks concretely about the Mobile Node (MN) to Home Agent (HA) control messages being authenticated is that it is _entirely_ practical to preconfigure the Mobile-IP SA before the MN goes mobile. The reason that the other Mobile IP control messages are indicated as items that might be authenticated is that it was much less clear that preconfiguring a Mobile-IP SA with the Foreign Agent (FA) would be practical for either the MN or the HA. During the time period when this authentication mechanism was added to Mobile IP, there was active discussion of future use of an application-layer authenticated D-H exchange protocol to establish the Mobile-IP SAs to/from the FA. At that time, this technical approach was generally believed to be reasonable and feasible to deploy and use. Commentary: I believe that most folks still believe that it is reasonable and feasible to deploy and use such a technology approach for establishing and maintaining Mobile-IP SAs, in part because most folks seem to believe that Mobile-IP sessions in the near term are not likely to have extremely short IP-layer location lifetimes. In many cases that I'm familiar with, mobility support can be provided at the link-layer or through a combination of link-layer and Mobile-IP mechanisms. The use of link-layer mechanisms (e.g. cellular telephones, CDPD, PCS, Iridium, INMARSAT) can significantly increase the lifetime of a location as perceived by the IP-layer. Ran rja@cisco.com -- Message-Id: <323B06F1.3617@network.com> Date: Sat, 14 Sep 1996 03:59:56 -0400 From: Jim Hughes Reply-To: hughes@nsco.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b8Gold (Macintosh; I; PPC) Mime-Version: 1.0 To: ipsec@TIS.COM, internet-drafts@cnri.reston.va.us Subject: ietf-ipsec-esp-des-md5-03.txt Content-Type: multipart/mixed; boundary="------------7E8465AB58A2" Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------7E8465AB58A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is draft -03 for the combined DES/HMAC. (When I sent the previous draft to the working group I called it 03, but I was mistaken, it was 02. This draft is indeed number 03. Sorry for the confusion.) These changes are relatively minor, mostly optional modes and some key schedule changes. Editorially, there are changes to the words MUST, SHOULD and MAY to make the document in line with other IPSEC documents. Section numbers have been added. References to SwIPe have also been added. Clarification that IV_key_ does not change during the life of the key has been added. At the request of Steven Kent and approved by the working group: An optional explicit IV has been added so that hardware that can not support a constant IV_key_ can be used. Use of this feature will be negotiated by the key exchange. (This is over the objection of Steven Bellovan.) At the request of the working group: The replay window size now is negotiated. At the suggestion of Steven Bellovan: The keys are now fully differentiated for direction. DES, HMAC, IV, and replay start values are all different for each direction. The pad now SHOULD be random. At the suggestion of Anton Elin: The code (1< Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. 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 draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major con- tributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Hughes September 14, 1996 [Page 1] RFC DRAFT September 1996 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is tru- ly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. For the purpose of this RFC, the terms conformance and compliance are synonymous. 1. Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. The claims of privacy, integrity, authentication, and replay preven- tion are made in this draft. A good general text describing the methods and algorithm are in [Schneier95]. Privacy is provided by DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74] [FIPS-81]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source. Hughes September 14, 1996 [Page 2] RFC DRAFT September 1996 Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. 2. Packet Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | + Initialization Vector (Optional) + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | Replay Prevention Field (count) | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | ~ Payload Data ~ | | | |HMAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DES | | Padding (0-7 bytes) | | CBC +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | ~ HMAC digest ~ | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2.1. Security Parameters Index This field is negotiated at key setup and MUST not be 0 [RFC-1825] 2.2. Initialization Vector The use of an explicit Initialization Vector MAY be negotiated. The purpose of this mode is to support devices that automatically gen- erate IVs and can not operate using a constant IV_key_. This field is optional and is only used when an explicit IV is nego- tiated during key exchange. This field is contains random data or contains the last cyphertext block of a previous packet sent or received. For the packet which the explicit IV is received, the explicit IV is Hughes September 14, 1996 [Page 3] RFC DRAFT September 1996 used in place of the constant IV_key_ described later in this docu- ment. 2.3. Replay Prevention Replay Prevention is an unsigned 32 bit incrementing counter starting at a mutual agreed upon value (see Key Material) and is enforced to be within a mutually negotiated window size. The key (K, as described in a later section) MUST be changed fre- quently enough so that the counter is not allowed to return to the initial value; in other words, the key MUST be changed before 2^32 packets are transmitted using this key. For a given SPI, counter wrapping MUST be considered to be a replay attack. (While a wrap is a replay attack, there is always the possibility that a packet can get duplicated, so the presence of a single or small number of duplicate packets is not an absolute indication of a replay attack.) The receiver MUST verify that for a given SPI the packets received have non-repeating (non-duplicate) counter values. This can be imple- mented as a simple increasing count test or the receiver MAY choose to accept out-of-order packets as long as it is guaranteed that pack- ets can be received only once. For example, an implementation can use a sliding receive window. If such a receive window is supported, the receiver MUST ensure that it will accept packets within the current window only once, and reject any packets it receives with a value that is less than the lower bound of the window. Negotiated window sizes of 1 and 32 are suggested and larger multi- ples of 32 are allowed. 1 indicates that only constantly increasing replay numbers are allowed and packets which have replay values less than the highest received are always rejected. 32 indicates that are within 32 of the highest received, and are guaranteed not to have been received before, are allowed. A window size of 1 MUST be supported. A value of 32 SHOULD be sup- ported. If a value of 32 is negotiated, then the most recent 32 packets are allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Appendix A has actual code that implement a 32 packet replay window and a test routine. The purpose of this routine is to show how it could be implemented. 2.4. Payload The payload contains data that is described by the payload type Hughes September 14, 1996 [Page 4] RFC DRAFT September 1996 field. This field is an integral number of bytes in length; the fol- lowing padding and pad length fields will help provide alignment to a double word boundary. 2.5. Padding The padding (pad bytes and pad length field) is used to align the following "payload type" field to end on a double word boundary (when counting from the start of the replay field). Padding bytes SHOULD be initialized with random data. At a minimum, the number of pad bytes added MUST be enough to align the payload type field on the next appropriate boundary. However, the sender MAY choose to include additional padding, provided that the alignment is maintained. In total, the sender can add 0-255 bytes of padding. 2.6. Pad Length The pad length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. 2.7. Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 2.8. HMAC Digest The HMAC digest is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm, where both directions are keyed separately. The implementation MUST use the HMAC_key_ as described in the section on keys. 3. Encryption Transform Procedure CBC chaining with an constant IV_key_ is used (IV_key_I for the ini- tiator -> responder direction and IV_key_R for the responder -> ini- tiator direction). The IV_key_ remains constant for all packets send in this direction. Hughes September 14, 1996 [Page 5] RFC DRAFT September 1996 If an explicit IV is negotiated, 64 bits of random or the last cyphertext block of a previous packet send or receive can be used. IV or IV_key_ count|x1 x2 x3 | | | | |-------(+) --------(+) --------(+) | | | | | ------- | ------- | -------- k--| DES | | k--| DES | | k--| DES | ------- | ------- | -------- | | | | | |-----| |-----| |----... | | | y1 y2 y3 Where count is the Replay counter. x1, x2, x3 are the plaintext (x1 is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext. This transformation is comprised of the following 3 steps. 1. Taking the data and encapsulating it with the SPI, IV (if present), count, pad, pad length, and payload type. 2. Calculating the HMAC using the HMAC_key_ and creating the dig- est from the SPI, IV (if present), count, data, pad, pad length, and payload type and placing the result into the HMAC digest field. 3. Encrypting the count, data, pad, pad length, payload type, and HMAC digest using DES and the appropriate DES_key_ and IV_key_. (Note that the first DES block is a combination of the count and the first word of plaintext.) 4. Decryption Transform Procedure CBC chaining with an constant IV_key_ is used. if an IV is present in the packet, then the IV_key_ is not used and is replaced by the IV. Hughes September 14, 1996 [Page 6] RFC DRAFT September 1996 IV or IV_key_ y1 y2 y3 | | | | | |------ |------ |----... | | | | | | | ------- | ------- | -------- | k--| DES | | k--| DES | | k--| DES | | ------- | ------- | -------- | | | | | | |-------(+) |-------(+) |-------(+) | | | (count|x1) x2 x3 Decryption is comprised of the following 4 steps. 1. (Optional step) Decrypt the first bock of data using the appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- ity check" of the count. If the count has decreased below the win- dow or has increased by more than 65k, then it is safe to discard this packet as either a replay, non-authentic or too old. If the count is within 65K, then the probability that the packet is authentic is 65535/65536. (The following replay check and HMAC check are both still required). 2. Decrypt the count (if not already done), data, pad, pad length, and payload type using DES and the appropriate DES_key_ and IV_key_ (or IV). 3. Calculate the HMAC using the HMAC_key_ and create the digest from the SPI, IV (if present) count, data, pad, pad length, and payload type and checking the result at digest at the end of the packet. If the digest is incorrect, discard the packet. 4. Check the count using the window algorithm discussed above. If the packet is duplicate or too old, discard the packet. 5. Key Material The key K is provided by the key management layer. This key is used to derive the symmetric keys, they are: DES_Key_I is the DES key for traffic from the initiator -> responder. Hughes September 14, 1996 [Page 7] RFC DRAFT September 1996 DES_Key_R is the DES key for traffic from the responder -> initia- tor. HMAC_Key_I is the key for the HMAC Algorithm for traffic from the initiator -> responder. HMAC_Key_R is the key for the HMAC Algorithm for traffic from the responder -> initiator. IV_key_I is used to stop code book attacks on the first block for traffic from the initiator -> responder. IV_key_R is used to stop code book attacks on the first block for traffic from the responder -> initiator. RP_key_I is the initial value and wrap point for the replay prevention field for traffic from the initiator -> responder. RP_key_R is the initial value and wrap point for the replay prevention field for traffic from the responder -> initiator. The vertical bar symbol "|" is used to denote concatenation of bit strings. MD5(x|y) denotes the result of applying the MD5 function to the con- catenated bit strings x and y. Truncate(x,n) denotes the result of truncating x to its first n bits. Hughes September 14, 1996 [Page 8] RFC DRAFT September 1996 DES_Key_I = Truncate(MD5( D_Pad_I | K ),64) DES_Key_R = Truncate(MD5( D_Pad_R | K ),64) IV_Key_I = Truncate(MD5( I_Pad_I | K ),64) IV_Key_R = Truncate(MD5( I_Pad_R | K ),64) HMAC_Key_I = MD5( H_Pad_I | K ) HMAC_Key_R = MD5( H_Pad_R | K ) RP_Key_I = Truncate(MD5( R_Pad_I | K ),32) RP_Key_R = Truncate(MD5( R_Pad_R | K ),32) where each _Pad_is 512 bit string. D_Pad_I = 0x5C repeated 64 times. D_Pad_R = 0x3A repeated 64 times. I_Pad_I = 0xAC repeated 64 times. I_Pad_R = 0x55 repeated 64 times. H_Pad_I = 0x53 repeated 64 times. H_Pad_R = 0x3C repeated 64 times. R_Pad_I = 0x35 repeated 64 times. R_Pad_R = 0xCC repeated 64 times. (Implementation note, The 16 byte intermediate residuals can be pre- calculated from these constants and stored to reduce processing over- head). 6. Security Considerations The ESP-DES-HMAC-RP transform described in this draft is immune to the [Bellovin96] attacks. (AH [RFC-1826], in some modes, can also provide immunity to these attack.) The implications of the size of K can be found in [Blaze96]. 7. References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Proto- cols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- dard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. Hughes September 14, 1996 [Page 9] RFC DRAFT September 1996 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- dard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implement- ing and Using the Data Encryption Standard", Federal Information Pro- cessing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP), work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", work- in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft- ietf-ipsec-oakley-00.txt, February, 1996. [RFC-1825] Atkinson, R, "Security Architecture for the Internet Pro- tocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January, 1996 [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementa- tion of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. Hughes September 14, 1996 [Page 10] RFC DRAFT September 1996 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. 8. Acknowledgements This document is the result of significant work by several major con- tributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Phil Rogaway University of California at Davis Bill Simpson Computer Systems Consulting Services David A Wagner University of California at Berkeley In addition, the contributions of the entire IPSEC Working Group are acknowledged. Additional thanks for finding the missing "l"s in the window code to: Anton Elin Ankey Engineering Hughes September 14, 1996 [Page 11] RFC DRAFT September 1996 The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation 9. Editor's Address James P. Hughes Network Systems Corporation Hughes September 14, 1996 [Page 12] RFC DRAFT September 1996 Appendix A This is a routine that implements a 32 packet window. This is intend- ed on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap = (bitmap << diff) | 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1l << diff)) return 0; /* this packet already seen */ bitmap |= (1l << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes September 14, 1996 [Page 13] RFC DRAFT September 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Hughes September 14, 1996 [Page 14] --------------7E8465AB58A2-- Date: Sun, 15 Sep 1996 15:02:10 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 5th Inter Conf on Telecommunication Systems To: list2: ;, tis.com@TIS.COM Message-Id: <01I9IFSD0E2A8WX6ZK@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"list2" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk TSM97CFP C A L L for P A P E R S 5th International Conference on Telecommunication Systems Modelling and Analysis March 20-23, 1997 Nashville, TN Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modelling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems The 5th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville on March 20-23, 1997. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. The Program Committee has been divided along geographical regions with a separate Program Subcommittee assigned to each region. Abstracts and papers should be submitted directly to the Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1997 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tenessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Union Station hotel (see description at the end of the message). Lead Speakers and Keynote speakers include: Erol Gelenbe, Andrew Viterbi, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology 723 Swanston Street Carlton, Victoria Australia, 3001 Phone : 61 3 9282 2450 (CATT), 61 3 9660 2457 (RMIT) Fax : 61 3 9282 2490 (CATT), 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au ---Europe: (except Scandinavia and Baltic states) Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr ---Europe: (Scandinavia and Baltic states) Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se ---North America: Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : jpark@scout-po.biz.uiowa.edu ---North East Asia: Prof. Yutaka Takahashi Graduate School of Information Science Nara Institute of Science and Technology Nara 630-01, Japan Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : yutaka@is.aist-nara.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl ---Chairman of the Economics track: Prof. William W. Sharkey Federal Communications Commission 1919 M Street Washington, DC 20554 USA Phone : 202-418-2743 Fax : 202-418-1413 E-Mail : wsharkey@fcc.gov ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its Impact on Commerce -- Internet and Intranet -- Standards -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Group Decision Support Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is whenever possible, to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, enabling participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early conference and hotel registration is recommended. The Union Station Hotel is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1996, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the forms at the end of this message to preregister for the conference and the hotal. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1996, which abstract/s have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1997, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fifth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Dates: March 20, 1997 (afternoon) to March 23, 1997 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applica- Academic Industry Corporate ble Date Rate Rate Rate --------------- -------- -------- -------- 1. Preregistration Until Dec. 9, 1996 $ 400 $ 500 $1,300 2. Registration Until Jan. 15, 1997 $ 500 $ 600 $1,300 3. On Site Registration After Jan. 15, 1997 $ 600 $ 750 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association" . Please mark an X in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I don't wish to become an ATSMA member. Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be endorsed to: ATSMA, Inc. Refund Policy: Half refund, for requests received by February 1, 1997. No refund after February 1, 1997. ----------------------------------------------------------------------------- If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. Hotel Reservation A block of rooms has been reserved at Union Station Hotel for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the Telecommunication Systems Conference to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference blocks on February 15, 1997, so please be sure and reserve your rooms before February 15th. Union Station Hotel 1001 Broadway Nashville, TN 37203 Phone: 615-726-1001 or 1-800-331-2123 Fax: 615-742-3084 $99.00 Single or Double Occupancy Room $109.00 Triple or Quad Occupancy Room - Rates are subject to state and local tax, which is now 12.25 percent. ------------------------------------------------------------------------- Union Station Hotel Reservation Request Form Name of Conference: Telecommunication Systems Conference Arrival Date _________________ Departure Date __________________ Guest Name:__________________________________________________ Address :__________________________________________________ :__________________________________________________ Phone No. :__________________________________________________ A one night deposit should be enclosed to guarantee the reservation Payment Method: Check Check No.______________ Amount____________ Credit Card Type______________ No.____________________ Expiration Date____________ Type of Room: King or 2 Double Beds Smoking or Nonsmoking -------------------------------------------------------------------------- Union Station Hotel Description A Grand Heritage Hotel Features and Amenities In the heart of "Music City" stands a hotel with the personality of an intimate friend...Union Station Hotel. The heartbeat of Nashville has always been strongest at the Union Station. >From the grand opening in 1890 until the decline of rail travel in the 50s no other building in the city has been the site of more commercial activity and human drama. Nearly a century later, the Union Station Hotel, a National Historic Landmark, is again an integral part of life in Music City 124 guest rooms including 13 suites on seven levels are architecturally distinctive and capture the historic elegance of a bygone era. Stained glass, glittering gold leaf and newly silvered mirrors scatter reflections of an era which has endured for nearly a century. 4 conference rooms with over 10,000 square feet of flexible meeting and banquet space to accommodate groups of 5 to 200. * Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel Holiday Award. * Broadway Bistro - casual dining open for lunch and dinner. Selected in the 1996 Zagat Survey as the city's best overall and best dining hotel. Heritage Executive Level with enhanced amenities ideal for the business and leisure traveler including concierge service, continental breakfast and evening cocktails Monday through Friday. * Valet parking. * Complimentary limo service in downtown Nashville. * Complimentary newspaper. * Blocks from downtown area, famed Music Row, Vanderbilt University and Convention Center. Recommended Airport: Nashville Metro Airport, 7 miles to the East. Transportation: Grayline Shuttle to the hotel. $8.00 one way, $14.00 round trip. Complimentary shuttle service within three mile radius of hotel for conference guests.  ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa16277; 16 Sep 96 11:40 EDT Received: by relay.hq.tis.com; id LAA04971; Mon, 16 Sep 1996 11:43:13 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004968; Mon, 16 Sep 96 11:42:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08498; Mon, 16 Sep 96 11:41:59 EDT Received: by relay.hq.tis.com; id LAA04965; Mon, 16 Sep 1996 11:42:43 -0400 Received: from wicked.neato.org(198.70.96.252) by relay.tis.com via smap (V3.1.1) id xma004963; Mon, 16 Sep 96 11:42:21 -0400 Received: (from rs@localhost) by wicked.neato.org (8.7.2/8.6.12) id IAA05983 for ipsec@tis.com; Mon, 16 Sep 1996 08:46:39 -0700 (PDT) From: Rich Skrenta Message-Id: <199609161546.IAA05983@wicked.neato.org> Subject: Re: SKIP Design & Applicability Statement To: ipsec@TIS.COM Date: Mon, 16 Sep 1996 08:46:39 -0700 (PDT) In-Reply-To: <199609130533.WAA10380@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Sep 12, 96 10:28:15 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk [ I'm having problems receiving ipsec at incog.com, so I'm posting this from another account -- rjs ] Paul, I'm sorry you haven't found value in my recent contributions to the discussion on IPsec. I've done my best to keep my replies focused on technical issues, and to avoid as much as possible getting sucked into personal exchanges or unnecessarily replying to messages. Indeed, the quote of mine you selected was taken from a post which included a response from me to John Gilmore's issue about CDP endpoints. This sort of discussion seems entirely appropriate to this forum. I was quite frankly amazed when you characterized Ashar's technical and rather dry applicability statement as "marketing material". I'm certain that if I actually posted anything with the slightest whiff of real marketing hype to this list, my mailbox would quickly be consumed with flames. But indeed, in the week since I sent that message, I haven't received a single personal reply (other than yours), and the only list reply was a response from Phil Karn regarding a technical point about PFS. > Perhaps, but so many postings on the "benefits" of a proposal could appear > self serving. Why is "benefits" in quotes? I am rather upset at being censured in this way by one of the co-chairs. I feel I have acted in good faith to respond to technical discussions on this list. It does not seem fair that others may point out negatives in SKIP, but we are admonished when we respond to these points. This only adds to our concerns about the openness and impartiality of this process. > Your many postings to this list may not be helping to advocate SKIP. For the record, over the past 14 days I have been responsible for 9 of the 116 messages to ipsec. This includes my posting of Ashar's applicability statement. This puts me in third place; Bob Moskowitz and Perry Metzger tied for first, with 10 posts each. Fri, 13 Sep 1996 14:40:39 -0700 Message-Id: <199609132140.OAA05500@cornpuffs.cisco.com> From: Ran Atkinson Date: Fri, 13 Sep 1996 14:40:39 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Mobile IP background data Sender: ipsec-approval@neptune.tis.com Precedence: bulk I was one of several people directly involved with the addition of cryptographic authentication to the Mobile IP specification. So perhaps I can provide some additional background context and perspective. Historical Background: The reason that Mobile IP talks concretely about the Mobile Node (MN) to Home Agent (HA) control messages being authenticated is that it is _entirely_ practical to preconfigure the Mobile-IP SA before the MN goes mobile. The reason that the other Mobile IP control messages are indicated as items that might be authenticated is that it was much less clear that preconfiguring a Mobile-IP SA with the Foreign Agent (FA) would be practical for either the MN or the HA. During the time period when this authentication mechanism was added to Mobile IP, there was active discussion of future use of an application-layer authenticated D-H exchange protocol to establish the Mobile-IP SAs to/from the FA. At that time, this technical approach was generally believed to be reasonable and feasible to deploy and use. Commentary: I believe that most folks still believe that it is reasonable and feasible to deploy and use such a technology approach for establishing and maintaining Mobile-IP SAs, in part because most folks seem to believe that Mobile-IP sessions in the near term are not likely to have extremely short IP-layer location lifetimes. In many cases that I'm familiar with, mobility support can be provided at the link-layer or through a combination of link-layer and Mobile-IP mechanisms. The use of link-layer mechanisms (e.g. cellular telephones, CDPD, PCS, Iridium, INMARSAT) can significantly increase the lifetime of a location as perceived by the IP-layer. Ran rja@cisco.com -- From: Ashar Aziz Message-Id: <199609132352.QAA19686@miraj.incog.com> Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Fri, 13 Sep 1996 16:52:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk About two weeks ago I sent the following protest regarding the Montreal meeting minutes to the IPsec chairs. I haven't seen a correction posted or received any response to my message. Since the minutes went out on the ipsec mailing list, I would like to make my objections known here also. -----------(Begin Forwarded Message)-------------------------- From: To: palamber@us.oracle.com, rja@cisco.com, jis@mit.edu Subject: Re: IPsec Minutes from Montreal Date sent: Tue, 3 Sep 1996 17:07:12 Folks, I would like to protest at the way the meeting minutes were reported for the ipsec Montreal meeting. Although these were published a few weeks ago, I have only recently had a chance to catch up to the postings on the ipsec list. IMHO the meeting minutes should reflect what transpired, and not be editorialized with the minute writer's personal views of the various proposals. Also, when there are competing proposals, I believe some consideration should be given to fairness in the way the various proposals are described. I refer specifically to the use of adjectives such as "significant overhead", "hard to implement and scale" and "claimed" support of multicast when describing SKIP. By contrast, adjectives used for ISAKMP/Oakley are "very general", "very flexible", etc. In addition, I have the following very specific objections to the minutes, which I am submitting for the record. > From ipsec-request@neptune.tis.com Mon Aug 5 16:56 PDT 1996 > The minutes of the last IPsec Working Group were posted to the IETF weeks ago > and have yet to appear in the official archive. For those of you that missed > attending the meeting in Montreal the minutes are attached below. > > > Regards, > > Paul > -------------------------------------------------------------- > Ashar Aziz presented SKIP. Note the use of the SKIP header > between IP header and AH or ESP. Two modes of use: the first mode has no > setup messages once the master keys are in place, no Perfect Forward Secrecy, > and has significant per-message overhead. This mode relies on pre-positioned > D-H master keys from which unicast keys are derived. The second mode uses > ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with > approximate PFS, anonymity, etc. Claimed multicast mode support is based on a > group co-ordinator creating a group key (distribution of the private key to > group members is not described here and is potentially hard to implement or > scale) which the sender uses as the target for Diffie-Hellman computation. > Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, > based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and > are being fixed in the next draft. Ashar pushed for adoption of the > certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs > as well as certificates, not just X.509 certificates, but PGP too. > First, the SKIP PFS exchange requires 2 messages, not 4-6. This is what I presented at the talk, and is present in the SKIP PFS I-D. Second, I don't understand what "approximate PFS" means. Is this a new term? If so, I would like to be enlightened, with perhaps some reference to the relevant literature. In any case, this is not a term that I used, and not something that come up during the discussion. Third, wrt "claimed" multicast support, distribution of group private key WAS described at the meeting. In fact more than one way of distributing the group private key was described. One of these used an exanding ring multicast search, which gets around the single node responsible for distributing the group private key. In any case, there were no comments about "difficult to implement" or "scaling" at the meeting, and therefore it would have been more pleasant to not find these in the meeting minutes (which I assume are the minute writer's personal views). Same comment wrt "significant per message overhead" description. This was not something that came up at the meeting, and is a subjective evaluation. Again, I assume this is a personal opinion of the minute writer and not something that should be part of the meeting minutes. Also, the group private key is not used as the target for any Diffie-Hellman computation. This is simply a misunderstanding of the protocol on the part of the minute writer. > Doug Maughan reported on ISAKMP. Free software is available via MIT > server at http://web.mit.edu/network/isakmp. And finally, we also have free software which we mentioned at the meeting, and gave the URL to. In fairness, perhaps it too should have been in the meeting minutes for the benefit of those who couldn't attend? I can understand that the minute writers (I assume that this included the chairs) have personal opinions about the competing proposals. May I request, however, that the meeting minutes not be used as the forum to promulgate these opinions, when they don't correspond to events that transpired at the meeting? Ashar. Message-Id: <323B06F1.3617@network.com> Date: Sat, 14 Sep 1996 03:59:56 -0400 From: Jim Hughes Reply-To: hughes@nsco.network.com Organization: Network Systems Corporation X-Mailer: Mozilla 3.0b8Gold (Macintosh; I; PPC) Mime-Version: 1.0 To: ipsec@TIS.COM, internet-drafts@cnri.reston.va.us Cc: hughes@nsco.network.com, Steven Bellovin , Bill Simpson , "D. A. Wagner" , Steven Keny , Harry Varnis , James Hughes , Ken Hardwick , Paul Lambert , Perry Metzger , Ran Atkinson , Robert Baldwin Subject: ietf-ipsec-esp-des-md5-03.txt Content-Type: multipart/mixed; boundary="------------7E8465AB58A2" Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------7E8465AB58A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is draft -03 for the combined DES/HMAC. (When I sent the previous draft to the working group I called it 03, but I was mistaken, it was 02. This draft is indeed number 03. Sorry for the confusion.) These changes are relatively minor, mostly optional modes and some key schedule changes. Editorially, there are changes to the words MUST, SHOULD and MAY to make the document in line with other IPSEC documents. Section numbers have been added. References to SwIPe have also been added. Clarification that IV_key_ does not change during the life of the key has been added. At the request of Steven Kent and approved by the working group: An optional explicit IV has been added so that hardware that can not support a constant IV_key_ can be used. Use of this feature will be negotiated by the key exchange. (This is over the objection of Steven Bellovan.) At the request of the working group: The replay window size now is negotiated. At the suggestion of Steven Bellovan: The keys are now fully differentiated for direction. DES, HMAC, IV, and replay start values are all different for each direction. The pad now SHOULD be random. At the suggestion of Anton Elin: The code (1< Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. 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 draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major con- tributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Hughes September 14, 1996 [Page 1] RFC DRAFT September 1996 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is tru- ly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. For the purpose of this RFC, the terms conformance and compliance are synonymous. 1. Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. The claims of privacy, integrity, authentication, and replay preven- tion are made in this draft. A good general text describing the methods and algorithm are in [Schneier95]. Privacy is provided by DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74] [FIPS-81]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source. Hughes September 14, 1996 [Page 2] RFC DRAFT September 1996 Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. 2. Packet Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | + Initialization Vector (Optional) + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | Replay Prevention Field (count) | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | ~ Payload Data ~ | | | |HMAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DES | | Padding (0-7 bytes) | | CBC +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | ~ HMAC digest ~ | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2.1. Security Parameters Index This field is negotiated at key setup and MUST not be 0 [RFC-1825] 2.2. Initialization Vector The use of an explicit Initialization Vector MAY be negotiated. The purpose of this mode is to support devices that automatically gen- erate IVs and can not operate using a constant IV_key_. This field is optional and is only used when an explicit IV is nego- tiated during key exchange. This field is contains random data or contains the last cyphertext block of a previous packet sent or received. For the packet which the explicit IV is received, the explicit IV is Hughes September 14, 1996 [Page 3] RFC DRAFT September 1996 used in place of the constant IV_key_ described later in this docu- ment. 2.3. Replay Prevention Replay Prevention is an unsigned 32 bit incrementing counter starting at a mutual agreed upon value (see Key Material) and is enforced to be within a mutually negotiated window size. The key (K, as described in a later section) MUST be changed fre- quently enough so that the counter is not allowed to return to the initial value; in other words, the key MUST be changed before 2^32 packets are transmitted using this key. For a given SPI, counter wrapping MUST be considered to be a replay attack. (While a wrap is a replay attack, there is always the possibility that a packet can get duplicated, so the presence of a single or small number of duplicate packets is not an absolute indication of a replay attack.) The receiver MUST verify that for a given SPI the packets received have non-repeating (non-duplicate) counter values. This can be imple- mented as a simple increasing count test or the receiver MAY choose to accept out-of-order packets as long as it is guaranteed that pack- ets can be received only once. For example, an implementation can use a sliding receive window. If such a receive window is supported, the receiver MUST ensure that it will accept packets within the current window only once, and reject any packets it receives with a value that is less than the lower bound of the window. Negotiated window sizes of 1 and 32 are suggested and larger multi- ples of 32 are allowed. 1 indicates that only constantly increasing replay numbers are allowed and packets which have replay values less than the highest received are always rejected. 32 indicates that are within 32 of the highest received, and are guaranteed not to have been received before, are allowed. A window size of 1 MUST be supported. A value of 32 SHOULD be sup- ported. If a value of 32 is negotiated, then the most recent 32 packets are allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Appendix A has actual code that implement a 32 packet replay window and a test routine. The purpose of this routine is to show how it could be implemented. 2.4. Payload The payload contains data that is described by the payload type Hughes September 14, 1996 [Page 4] RFC DRAFT September 1996 field. This field is an integral number of bytes in length; the fol- lowing padding and pad length fields will help provide alignment to a double word boundary. 2.5. Padding The padding (pad bytes and pad length field) is used to align the following "payload type" field to end on a double word boundary (when counting from the start of the replay field). Padding bytes SHOULD be initialized with random data. At a minimum, the number of pad bytes added MUST be enough to align the payload type field on the next appropriate boundary. However, the sender MAY choose to include additional padding, provided that the alignment is maintained. In total, the sender can add 0-255 bytes of padding. 2.6. Pad Length The pad length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. 2.7. Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 2.8. HMAC Digest The HMAC digest is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm, where both directions are keyed separately. The implementation MUST use the HMAC_key_ as described in the section on keys. 3. Encryption Transform Procedure CBC chaining with an constant IV_key_ is used (IV_key_I for the ini- tiator -> responder direction and IV_key_R for the responder -> ini- tiator direction). The IV_key_ remains constant for all packets send in this direction. Hughes September 14, 1996 [Page 5] RFC DRAFT September 1996 If an explicit IV is negotiated, 64 bits of random or the last cyphertext block of a previous packet send or receive can be used. IV or IV_key_ count|x1 x2 x3 | | | | |-------(+) --------(+) --------(+) | | | | | ------- | ------- | -------- k--| DES | | k--| DES | | k--| DES | ------- | ------- | -------- | | | | | |-----| |-----| |----... | | | y1 y2 y3 Where count is the Replay counter. x1, x2, x3 are the plaintext (x1 is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext. This transformation is comprised of the following 3 steps. 1. Taking the data and encapsulating it with the SPI, IV (if present), count, pad, pad length, and payload type. 2. Calculating the HMAC using the HMAC_key_ and creating the dig- est from the SPI, IV (if present), count, data, pad, pad length, and payload type and placing the result into the HMAC digest field. 3. Encrypting the count, data, pad, pad length, payload type, and HMAC digest using DES and the appropriate DES_key_ and IV_key_. (Note that the first DES block is a combination of the count and the first word of plaintext.) 4. Decryption Transform Procedure CBC chaining with an constant IV_key_ is used. if an IV is present in the packet, then the IV_key_ is not used and is replaced by the IV. Hughes September 14, 1996 [Page 6] RFC DRAFT September 1996 IV or IV_key_ y1 y2 y3 | | | | | |------ |------ |----... | | | | | | | ------- | ------- | -------- | k--| DES | | k--| DES | | k--| DES | | ------- | ------- | -------- | | | | | | |-------(+) |-------(+) |-------(+) | | | (count|x1) x2 x3 Decryption is comprised of the following 4 steps. 1. (Optional step) Decrypt the first bock of data using the appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- ity check" of the count. If the count has decreased below the win- dow or has increased by more than 65k, then it is safe to discard this packet as either a replay, non-authentic or too old. If the count is within 65K, then the probability that the packet is authentic is 65535/65536. (The following replay check and HMAC check are both still required). 2. Decrypt the count (if not already done), data, pad, pad length, and payload type using DES and the appropriate DES_key_ and IV_key_ (or IV). 3. Calculate the HMAC using the HMAC_key_ and create the digest from the SPI, IV (if present) count, data, pad, pad length, and payload type and checking the result at digest at the end of the packet. If the digest is incorrect, discard the packet. 4. Check the count using the window algorithm discussed above. If the packet is duplicate or too old, discard the packet. 5. Key Material The key K is provided by the key management layer. This key is used to derive the symmetric keys, they are: DES_Key_I is the DES key for traffic from the initiator -> responder. Hughes September 14, 1996 [Page 7] RFC DRAFT September 1996 DES_Key_R is the DES key for traffic from the responder -> initia- tor. HMAC_Key_I is the key for the HMAC Algorithm for traffic from the initiator -> responder. HMAC_Key_R is the key for the HMAC Algorithm for traffic from the responder -> initiator. IV_key_I is used to stop code book attacks on the first block for traffic from the initiator -> responder. IV_key_R is used to stop code book attacks on the first block for traffic from the responder -> initiator. RP_key_I is the initial value and wrap point for the replay prevention field for traffic from the initiator -> responder. RP_key_R is the initial value and wrap point for the replay prevention field for traffic from the responder -> initiator. The vertical bar symbol "|" is used to denote concatenation of bit strings. MD5(x|y) denotes the result of applying the MD5 function to the con- catenated bit strings x and y. Truncate(x,n) denotes the result of truncating x to its first n bits. Hughes September 14, 1996 [Page 8] RFC DRAFT September 1996 DES_Key_I = Truncate(MD5( D_Pad_I | K ),64) DES_Key_R = Truncate(MD5( D_Pad_R | K ),64) IV_Key_I = Truncate(MD5( I_Pad_I | K ),64) IV_Key_R = Truncate(MD5( I_Pad_R | K ),64) HMAC_Key_I = MD5( H_Pad_I | K ) HMAC_Key_R = MD5( H_Pad_R | K ) RP_Key_I = Truncate(MD5( R_Pad_I | K ),32) RP_Key_R = Truncate(MD5( R_Pad_R | K ),32) where each _Pad_is 512 bit string. D_Pad_I = 0x5C repeated 64 times. D_Pad_R = 0x3A repeated 64 times. I_Pad_I = 0xAC repeated 64 times. I_Pad_R = 0x55 repeated 64 times. H_Pad_I = 0x53 repeated 64 times. H_Pad_R = 0x3C repeated 64 times. R_Pad_I = 0x35 repeated 64 times. R_Pad_R = 0xCC repeated 64 times. (Implementation note, The 16 byte intermediate residuals can be pre- calculated from these constants and stored to reduce processing over- head). 6. Security Considerations The ESP-DES-HMAC-RP transform described in this draft is immune to the [Bellovin96] attacks. (AH [RFC-1826], in some modes, can also provide immunity to these attack.) The implications of the size of K can be found in [Blaze96]. 7. References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Proto- cols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- dard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. Hughes September 14, 1996 [Page 9] RFC DRAFT September 1996 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- dard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implement- ing and Using the Data Encryption Standard", Federal Information Pro- cessing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP), work-in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", work- in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft- ietf-ipsec-oakley-00.txt, February, 1996. [RFC-1825] Atkinson, R, "Security Architecture for the Internet Pro- tocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January, 1996 [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementa- tion of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. Hughes September 14, 1996 [Page 10] RFC DRAFT September 1996 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. 8. Acknowledgements This document is the result of significant work by several major con- tributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Phil Rogaway University of California at Davis Bill Simpson Computer Systems Consulting Services David A Wagner University of California at Berkeley In addition, the contributions of the entire IPSEC Working Group are acknowledged. Additional thanks for finding the missing "l"s in the window code to: Anton Elin Ankey Engineering Hughes September 14, 1996 [Page 11] RFC DRAFT September 1996 The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation 9. Editor's Address James P. Hughes Network Systems Corporation Hughes September 14, 1996 [Page 12] RFC DRAFT September 1996 Appendix A This is a routine that implements a 32 packet window. This is intend- ed on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap = (bitmap << diff) | 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1l << diff)) return 0; /* this packet already seen */ bitmap |= (1l << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes September 14, 1996 [Page 13] RFC DRAFT September 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Hughes September 14, 1996 [Page 14] --------------7E8465AB58A2-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa18748; 16 Sep 96 14:12 EDT Received: by relay.hq.tis.com; id OAA09958; Mon, 16 Sep 1996 14:15:56 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009953; Mon, 16 Sep 96 14:15:29 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19032; Mon, 16 Sep 96 14:14:42 EDT Received: by relay.hq.tis.com; id OAA09950; Mon, 16 Sep 1996 14:15:26 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma009948; Mon, 16 Sep 96 14:15:14 -0400 Received: by janus.border.com id <18437-2>; Mon, 16 Sep 1996 14:16:29 -0400 Message-Id: <96Sep16.141629edt.18437-2@janus.border.com> X-Mailer: exmh version 1.6.2 7/18/95 To: perry@piermont.com Cc: Rich Skrenta , ipsec@TIS.COM Subject: Re: Using SKIP as inspiration, not as gospel In-Reply-To: Your message of "Thu, 12 Sep 1996 14:54:34 EDT." <9609121513.aa28910@neptune.TIS.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Sep 1996 14:17:31 -0400 From: "ozan s. yigit" Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Some of us don't like the fact that SKIP does not play nicely with the > IPSec model. i have no idea what this means. i am a relative newcomer to the IPSec forum, so perhaps you could clarify... thanks. oz --- If you can't understand it, you | electric: oz@border.com certainly can't trust it. - D. McIlroy | ph: [416] 368 0074 x294 Received: from relay.hq.tis.com by neptune.TIS.COM id aa19527; 16 Sep 96 14:47 EDT Received: by relay.hq.tis.com; id OAA10985; Mon, 16 Sep 1996 14:50:57 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010965; Mon, 16 Sep 96 14:50:30 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21638; Mon, 16 Sep 96 14:49:43 EDT Received: by relay.hq.tis.com; id OAA10951; Mon, 16 Sep 1996 14:50:26 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma010939; Mon, 16 Sep 96 14:50:00 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id LAA04395; Mon, 16 Sep 1996 11:52:23 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA04438; Mon, 16 Sep 1996 11:52:20 -0700 Message-Id: <9609161852.AA04438@maildig1.us.oracle.com> Date: 16 Sep 96 11:51:58 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: IPsec Minutes from Montreal X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 13-Sep-96 16:52 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_25726407_0_11919609161253200" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_25726407_0_11919609161253200 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Ashar, Your constructive comments on the minutes were received and an updated set of minutes reflecting your clarifications have been prepared (last week actually). They will be posted soon. >I can understand that the minute writers (I assume that this >included the chairs) have personal opinions about the competing >proposals. May I request, however, that the meeting minutes not >be used as the forum to promulgate these opinions, when they >don't correspond to events that transpired at the meeting? As one of the chairs, I can honestly say that we do not use the minutes to promulgate opinions. We are quite lucky to have various contributions of notes each meeting to capture the events. We are lucky just to get minutes out. IPsec has been having some very "eventful" meetings, so it is likely that all of the details may not have been captured. There are also differences of opinion that can be hard to capture. For example: >First, the SKIP PFS exchange requires 2 messages, not 4-6. >This is what I presented at the talk, and is present in >the SKIP PFS I-D. It is true that your presentation claimed that SKIP PFS exchange takes 2 messages. It is also true that other members of the working group claim that SKIP PFS takes 4 to 6 messages. So depending on who you ask the answer is 2 to 6 messages. I am sure that this confusion will be resolved by the working group, but it is difficult to document in the minutes this type of difference in opinion. >About two weeks ago I sent the following protest ... The chairs (Ran and myself) appreciate contributions and comments, but please calm done and quite complaining. The minutes have been improved by the clarifications you recommended and "protesting" is unnecessary. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_25726407_0_11919609161253200 Content-Type:message/rfc822 Date: 13 Sep 96 16:52:16 From:"Ashar Aziz " To:ipsec@tis.com Subject:Re: IPsec Minutes from Montreal X-Mailer:ELM [version 2.4 PL24 PGP5] Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" About two weeks ago I sent the following protest regarding the Montreal meeting minutes to the IPsec chairs. I haven't seen a correction posted or received any response to my message. Since the minutes went out on the ipsec mailing list, I would like to make my objections known here also. -----------(Begin Forwarded Message)-------------------------- From: To: palamber@us.oracle.com, rja@cisco.com, jis@mit.edu Subject: Re: IPsec Minutes from Montreal Date sent: Tue, 3 Sep 1996 17:07:12 Folks, I would like to protest at the way the meeting minutes were reported for the ipsec Montreal meeting. Although these were published a few weeks ago, I have only recently had a chance to catch up to the postings on the ipsec list. IMHO the meeting minutes should reflect what transpired, and not be editorialized with the minute writer's personal views of the various proposals. Also, when there are competing proposals, I believe some consideration should be given to fairness in the way the various proposals are described. I refer specifically to the use of adjectives such as "significant overhead", "hard to implement and scale" and "claimed" support of multicast when describing SKIP. By contrast, adjectives used for ISAKMP/Oakley are "very general", "very flexible", etc. In addition, I have the following very specific objections to the minutes, which I am submitting for the record. > From ipsec-request@neptune.tis.com Mon Aug 5 16:56 PDT 1996 > The minutes of the last IPsec Working Group were posted to the IETF weeks ago > and have yet to appear in the official archive. For those of you that missed > attending the meeting in Montreal the minutes are attached below. > > > Regards, > > Paul > -------------------------------------------------------------- > Ashar Aziz presented SKIP. Note the use of the SKIP header > between IP header and AH or ESP. Two modes of use: the first mode has no > setup messages once the master keys are in place, no Perfect Forward Secrecy, > and has significant per-message overhead. This mode relies on pre-positioned > D-H master keys from which unicast keys are derived. The second mode uses > ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with > approximate PFS, anonymity, etc. Claimed multicast mode support is based on a > group co-ordinator creating a group key (distribution of the private key to > group members is not described here and is potentially hard to implement or > scale) which the sender uses as the target for Diffie-Hellman computation. > Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, > based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and > are being fixed in the next draft. Ashar pushed for adoption of the > certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs > as well as certificates, not just X.509 certificates, but PGP too. > First, the SKIP PFS exchange requires 2 messages, not 4-6. This is what I presented at the talk, and is present in the SKIP PFS I-D. Second, I don't understand what "approximate PFS" means. Is this a new term? If so, I would like to be enlightened, with perhaps some reference to the relevant literature. In any case, this is not a term that I used, and not something that come up during the discussion. Third, wrt "claimed" multicast support, distribution of group private key WAS described at the meeting. In fact more than one way of distributing the group private key was described. One of these used an exanding ring multicast search, which gets around the single node responsible for distributing the group private key. In any case, there were no comments about "difficult to implement" or "scaling" at the meeting, and therefore it would have been more pleasant to not find these in the meeting minutes (which I assume are the minute writer's personal views). Same comment wrt "significant per message overhead" description. This was not something that came up at the meeting, and is a subjective evaluation. Again, I assume this is a personal opinion of the minute writer and not something that should be part of the meeting minutes. Also, the group private key is not used as the target for any Diffie-Hellman computation. This is simply a misunderstanding of the protocol on the part of the minute writer. > Doug Maughan reported on ISAKMP. Free software is available via MIT > server at http://web.mit.edu/network/isakmp. And finally, we also have free software which we mentioned at the meeting, and gave the URL to. In fairness, perhaps it too should have been in the meeting minutes for the benefit of those who couldn't attend? I can understand that the minute writers (I assume that this included the chairs) have personal opinions about the competing proposals. May I request, however, that the meeting minutes not be used as the forum to promulgate these opinions, when they don't correspond to events that transpired at the meeting? Ashar. --=_ORCL_25726407_0_11919609161253200-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa19852; 16 Sep 96 15:00 EDT Received: by relay.hq.tis.com; id PAA11651; Mon, 16 Sep 1996 15:03:56 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma011604; Mon, 16 Sep 96 15:03:29 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22659; Mon, 16 Sep 96 15:02:43 EDT Received: by relay.hq.tis.com; id PAA11585; Mon, 16 Sep 1996 15:03:27 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap Message-ID: <9609161525.aa20342@neptune.TIS.COM> (V3.1.1) id xma011572; Mon, 16 Sep 96 15:03:15 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id PAA23198; Mon, 16 Sep 1996 15:05:21 -0400 (EDT) Message-Id: <199609161905.PAA23198@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "ozan s. yigit" Cc: ipsec@TIS.COM Subject: Re: Using SKIP as inspiration, not as gospel In-Reply-To: Your message of "Mon, 16 Sep 1996 14:17:31 EDT." <96Sep16.141629edt.18437-2@janus.border.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 16 Sep 1996 15:05:21 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk "ozan s. yigit" writes: > > Some of us don't like the fact that SKIP does not play nicely with the > > IPSec model. > > i have no idea what this means. i am a relative newcomer to the IPSec > forum, so perhaps you could clarify... I don't want to get in to the whole thing, but as just one part, SKIP does not operate in a model that permits multiple associations between two hosts, which is needed if you have mutually suspicious users on different transport connections. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa21566; 16 Sep 96 16:26 EDT Received: by relay.hq.tis.com; id QAA14986; Mon, 16 Sep 1996 16:30:01 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014981; Mon, 16 Sep 96 16:29:35 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29120; Mon, 16 Sep 96 16:28:45 EDT Received: by relay.hq.tis.com; id QAA14974; Mon, 16 Sep 1996 16:29:29 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma014962; Mon, 16 Sep 96 16:29:05 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id NAA16417; Mon, 16 Sep 1996 13:31:30 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id NAA06638; Mon, 16 Sep 1996 13:35:35 -0700 Message-Id: <199609162035.NAA06638@mailsun2.us.oracle.com> Date: 16 Sep 96 12:34:42 -0700 From: "PALAMBER.US.ORACLE.COM" To: ashar@osmosys.incog.com Subject: Fwd: revised IPsec minutes for Montreal Cc: ipsec@TIS.COM Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_7531045_0_11919609161436350" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_7531045_0_11919609161436350 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Ashar, >Received: SEPTEMBER 16, 1996 08:04 >Sent: SEPTEMBER 13, 1996 16:52 >From: Ashar Aziz > >About two weeks ago I sent the following protest regarding the >Montreal meeting minutes to the IPsec chairs. I haven't seen >a correction posted or received any response to my message. >Since the minutes went out on the ipsec mailing list, I would >like to make my objections known here also. The minutes were updated and sent out directly to the IETF yesterday (September 15). They should be updated on the web site soon. Since you seem anxious to accurately capture and relive the excitement of the Montreal meeting the updated minutes are attached. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_7531045_0_11919609161436350 Content-Type:message/rfc822 Date: 15 Sep 96 21:50:52 From:"rja@cisco.com (Ran Atkinson)" To:scoya@ietf.org Subject:revised IPsec minutes for Montreal Cc:palamber@us.oracle.com,jis@mit.edu,fred@cisco.com,rja@cisco.com X-Mailer:Mail User's Shell (7.2.5 10/14/92) MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Steve, Please replace the currently online meeting minutes for Montreal's IPsec meeting with those attached below. Editorial changes were made per request from Ashar Aziz. These revised minutes have been specifically reviewed and approved by Paul Lamber (IPsec co-chair) and Jeff Schiller (Security AD). Thanks, Ran rja@inet.org IPSEC WG Meeting Notes, Montreal IETF, June 1996 The co-chairs would like to thank Steve Kent for contributing his personal notes on the meeting, which were used as the basis for these minutes. The co-chairs edited the notes somewhat, so any errors are their responsibility. SESSION 1, Tuesday: AH/ESP and existing IPsec documents Jim Hughes presented his Combined ESP transform with HMAC and anti-replay. Steve Kent suggested changing the proposal to rely on a negotiated anti-replay window size, to accept all packets within the window unless they are replays, and to not try to reduce the overhead by relying on a constructed IV. All three suggestions were adopted. Note that this protocol requires distinct simplex channel keys, derived from a master key for the SA. RSA reported on their S/WAN interoperability testing: TIS, NSA, Raptor, SCC, and others worked well together. The next test session will require Oakley/ISAKMP, and optionally SKIP, for key management, in support of AH and ESP. John Gilmore argued for widespread, near term deployment to protect against passive wiretapping. His goal is 5% of Internet traffic by the end of 1996. His personal agenda is to counter government (not just US Government) efforts for key-escrow initiatives. His proposal is to put crypto-walls in place (devices that don't even do packet filtering and don't rely on authenticated keys). His tactic is to leverage freely available software in order to build such crypto-walls, define new DNS records for unauthenticated key storage, avoid export controls by developing software outside of the US. A firewall vendor gave a talk on using IPSEC with firewalls, as a followup to mobile IP problem of getting mobile IP traffic out of a foreign domain. Asssume a model where presence of valid AH is required for firewall traversal, in either direction. The initially presented model looks at traversing a single firewall, nominally at the home agent permieter. The second model presented shows foreign and home firewalls. The talk points out the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between firewalls, then from HA to firewall-2, and eventually one SA above these to carry forwarded traffic from HA to MN. Speaker notes the problems of being able to transmit the mobile IP messages, ICMP messages, and key management messages through firewalls as a precursor to establishing SAs in this complex environment. The bottom line is that one has to look carefully at the rules that firewalls employ to determine what traffic will be allowed across, as this might cause serious problems for SA establishment, especially for mobile IP case. However, the proposed solution is pretty complex and there are easier approaches to dealing with this problem in the mobile IP case, e.g., co-locating FAs and HAs with firewalls, or establishing long term SAs, between HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP traffic. Ran Atkinson spoke about the standards process and it's applicability to the IPSEC RFCs. Because some of the 1825-29 RFCs are being replaced, and because all of them cross reference one another, the group cannot be advanced from Proposed Standard to Draft Standard until 6 months elapses after the last of the inter-related documents have been updated. Ran also discussed his revised IPSEC Security Architecture document, a replacement for RFC-1825. Steve Kent suggested that the WG revisit AH to remove its two-different modes of use, given the new ESP options that incorporate authentication and thus obviate the need for the embedded AH mode (ESP followed directly by AH). Steve also suggested that the WG revise ESP to add in optional, variable length fields for IVs, integrity checks, etc. so that the transform documents are independent of one another and don't grow geometrically as new algorithms are added. The WG adopted both suggestions and Steve Kent agreed to work with the WG co-chairs to provide suitable text for the revised RFCs. Session 2, Wednesday: Key Management Issues Bob Moskowitz (Chrysler) challenged the group to solve a network layer security problem for communication among automotive parts suppliers and manufacturers, but with a lot of nasty residual problems, e.g., misuse of net numbers by particiants, diverse set of existing firewalls, etc. Bob's goal is to start deploying IPsec by the end of 1996. Ashar Aziz presented SKIP. Note the use of the SKIP header between IP header and AH or ESP. Two modes of use: the first mode has no setup messages once the master keys are in place, no Perfect Forward Secrecy, and has significant per-message overhead. This mode relies on pre-positioned D-H master keys from which unicast keys are derived. The second mode uses ephemeral Diffie-Hellman, with certificates, in a 2-6 message exchange depending on how much state already exists in the end nodes (specifically: 2 messages for Certificate Discovery Protocol, 2 messages for Algorithm Discovery Protocol, plus 2 messages for PFS before the first data packet can be sent) with PFS (though SKIP's PFS is different from others in that it does not provide PFS for identities), anonymity, etc. SKIP's multicast approach is based on a group co-ordinator creating a group key which the sender can then use (though the SKIP multicast proposal explicitly does not specify how the group owner is determined nor how knowledge of the group owner's identity is communicated scalably and authentically to the members of the group nor how the group key is created). Use of an expanding ring search to find the information was discussed as one approach to distributing the group private key. Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and are being fixed in the next draft. Ashar pushed for adoption of the certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs as well as certificates, not just X.509 certificates, but PGP too. Doug Maughan reported on ISAKMP. Free software is available via MIT server. cisco has also worked on an ISAKMP with Oakley implementation, also freely available from cisco and MIT web sites. There is also an implementation by the UK Defence Research Agency. ISAKMP provides general KMP framework, capable of supporting various key exchange algorithms, authentication, security association management, and denial of service protection. Recent I-D changes: moved from request/response to chained payload format (for better performance and/or more flexible for multi-exchange protocols), can negotiate multiple SPIs at the same time (for greater efficiency and flexibility), and an expanded set of authentication payload types (for better support of more exchnage types). Format is more complex now, because of support of multiple paylodas per message, negotiating multiple protocols at one time, etc. See version 5 specification I-D for details. Jon Millen's analysis notes that cookies don't buy much Denial-of-Service protection, and that authentication and key exchange is sufficiently decoupled to require further analysis. Interoperability testing, using Oakley, is now going on between cisco and DRA. Work will continue to add other key exchange algorithms, commercial and government. Hilarie Orman described Oakley briefly. Oakley is quite flexible: can use Diffie-Hellman exchange and/or pre-positioned keys or Public Key (RSA) encryption ; authentication via RSA encryption, signatures or predistributed shared secrets; integrity is available but can be omitted, and Perfect Forward Secrecy is available but can be omitted. Minimal message exchange is 3 messages, though more round-trips can also occur. She has also published the group paramaters for several bases, yielding 90-bit strength key outputs. ISAKMP integration is almost complete. She suggested having the ESP and AH transforms define how the necessary key bits are extracted from the output of the Oakley computation. Basically, a general collection of modules that can meet lots of different requirements, using a consistent syntax. Dan Harkins reported on the status of the ISAKMP-Oakley integration effort. A new Internet-Draft is out with a coherent profile of ISAKMP and Oakley when used together. The first two ISAKMP messages establish an SA, then the parties negotiate SAs for their clients. Four modes of Oakley are specified: Main Mode (for ISAKMP phase 1 exchange, four messages); Agressive Mode (quick, but no identity protection, an alternate phase 1 exchange in 3 messages); Quick Mode (a phase 2 exchange, in 3 messages, but can be repeated multiple times after a phase 1 exchange); Group Mode (for changing from one group to another, over time). cisco's free ISAKMP+Oakley code will be implementing this specification. Hugo made some comments on Oakley/ISAKMP. He likes the overall framework, but sees a need to refine the specs to remove some ambiguity and facilitate interoperability. From a cryptographic standpoint he has some suggestions, but lacked time to go into details. From a capability perspective, he would like to see a support for pre-positioned or centrally-distributed symetric keys, with PFS, which Oakley does allow. cisco has indicated that they would accommodate that request. Hugo doesn't like the reliance on Diffie-Hellman in the new Oakley/ISAKMP profile, relative to the broader capabilities of Oakley. Finally, Hugo expressed some concerns about the differences in types of attacks one might mount in the public key vs. symmetric key arena. The bottom line is that the ISAKMP and Oakley protocols accommodate all of these suggestions, it's just an issue of of getting the cisco implementation to incorporate these features. Very brief, surprizing comments from John Gilmore, announcing that he has purchased all of Bill Simpson's rights, including copyright, for Photuris, to ensure that it is considered as a viable contender in the key management protocol sweepstakes. However, he has not obtained any rights to Photuris from Phil Karn. Further, there is no new draft available addressing the previously discussed deficiencies of Photuris. There was no evidence of broad support for Photuris at this meeting. There was a short talk on Eliptical Curve Cryptography (ECC) technology, for both Diffie-Hellman exchanges and DSA- & RSA-equivalent (signature with recovery, but not excatly RSA) signautues. A major benefit is that shorter key lengths are security equivalent to larger key lengths. The IEEE P1363 specifications were mentioned and there was some discussion of patents relative to the use of ECC. There are some ECC-related patents, in addition to the general public key patent, but they relate mostly to implementations not to the basic math. The speaker is from Certicom, which holds some of these implementation patents. Closing discussions were process oriented, i.e., how will the WG decide what will become the default key management standard for IPSEC ? Jeff Schiller conducted straw polls which showed significant differences of opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick resolution to the issue! Jeff suggests having a special committee come back with a justifiable resolution. -- --=_ORCL_7531045_0_11919609161436350-- Date: Mon, 16 Sep 1996 16:29:15 -0400 (EDT) Message-Id: <199609162029.QAA23433@jekyll.piermont.com> From: "Perry E. Metzger" To: ipsec@TIS.COM Subject: Ashar's patent Reply-To: perry@piermont.com X-Reposting-Policy: please ask before redistributing Sender: ipsec-approval@neptune.tis.com Precedence: bulk I was wondering if Ashar had anything more to add about the patent that Sun has apparently been granted which appears to covers all of IPSEC under its claims. Ashar stated at the time that I first mentioned this that he was not in possession of the actual patent documents at the time, but that when he again had them in his possession he would comment. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa21945; 16 Sep 96 16:56 EDT Received: by relay.hq.tis.com; id QAA15950; Mon, 16 Sep 1996 17:00:00 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015946; Mon, 16 Sep 96 16:59:37 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01162; Mon, 16 Sep 96 16:58:46 EDT Received: by relay.hq.tis.com; id QAA15940; Mon, 16 Sep 1996 16:59:31 -0400 Received: from dns2.noc.best.net(206.86.0.21) by relay.tis.com via smap (V3.1.1) id xma015936; Mon, 16 Sep 96 16:59:13 -0400 Received: from info-10.noc.interop.net ([45.9.1.8]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id OAA02687 for ; Mon, 16 Sep 1996 14:01:37 -0700 Message-Id: <2.2.32.19960916235953.0067ec80@206.86.0.21> X-Sender: jlawler@206.86.0.21 (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Sep 1996 16:59:53 -0700 To: ipsec@TIS.COM From: John Lawler Subject: Concerns Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have been reading and rereading this list's traffic for several days and am becoming increasingly concerned at the way this process is, or more appropriately, isn't working. A few comments: 1) Paul, your remarks to Rich Skrenta were inappropriate. While YOU may not have asked for his "SKIP Summary", other people on this list had. There was nothing "market-ey" about the posting and I believe it was a perfectly reasonable thing to add to the discussion. In fact, I have been waiting for a similar docuement from the ISAKMP group. 2) Paul, you made a comment (uncalled for, I believe) about Sun's intransigence over SKIP. I must say thay I have not found the ISAKMP supporters to be any less intransigent. In seems very clear to me that pretty much everyone has settled into one camp or another--if there is any intransigence, there seems to be more than enough blame to go around on BOTH sides. 3) I have been subscribed to this list for longer than I can remember, but I still have yet to see a formal list of *agreed upon* characteristics the group is looking for in a key management system. What "lists" do exist seem to be strongly held personal preferences, but I have yet to see a list of criteria developed by and approved through concensus. Some people like in-band keying, some don't. Some people think the world will stop orbiting the sun without PFS, and others don't. Based on that, I do not see how anyone can possibly accuse ANY of the proposals as being either in or out of compliance with a non-existant list of criteria. 4) I am extremely concerned that we seem to have started yet another round of "let's reexamine what we're trying to do here." While a good idea in principle, we keep seem to do this, resulting in a constant moving of the goal posts. It is no wonder that we are having such difficulty reaching concensus! ***** It is rather clear from the recent traffic and from the votes in Montreal that people are split down the middle over SKIP vs ISAKMP. At this point I believe pretty much everyone is talking past each other. Based on this rather deeply entrenched split, I honestly do not believe this issue is going to be resolved now or even in San Jose. Therefore, I will make the same proposal I made in Montreal: Let *BOTH* SKIP and ISAKMP move ahead in the standards process, and let the marketplace decide which is better. If the IETF does not get something out NOW, then the market will come up with something of their own and all of your debating will be moot. I will reiterate the statement I made several weeks ago: WE CAN NO LONGER AFFORD TO DELAY THE GROWTH OF THIS INDUSTRY. People need solutions today, and if they cannot get them through the IETF, they will get them elsewhere. -John Lawler Received: from relay.hq.tis.com by neptune.TIS.COM id aa22175; 16 Sep 96 17:08 EDT Received: by relay.hq.tis.com; id RAA16402; Mon, 16 Sep 1996 17:12:00 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma016361; Mon, 16 Sep 96 17:11:31 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02052; Mon, 16 Sep 96 17:10:45 EDT Received: by relay.hq.tis.com; id RAA16354; Mon, 16 Sep 1996 17:11:30 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma016340; Mon, 16 Sep 96 17:11:18 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id OAA18117; Mon, 16 Sep 1996 14:13:34 -0700 Received: from info-10.noc.interop.net ([45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA08920; Mon, 16 Sep 1996 13:40:26 -0700 Message-Id: <2.2.32.19960916233847.00673b14@206.86.0.11> X-Sender: jlawler@206.86.0.11 (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Sep 1996 16:38:47 -0700 To: ipsec@TIS.COM From: John Lawler Subject: Concerns Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have been reading and rereading this list's traffic for several days and am becoming increasingly concerned at the way this process is, or more appropriately, isn't working. A few comments: 1) Paul, your remarks to Rich Skrenta were inappropriate. While YOU may not have asked for his "SKIP Summary", other people on this list had. There was nothing "market-ey" about the posting and I believe it was a perfectly reasonable thing to add to the discussion. In fact, I have been waiting for a similar docuement from the ISAKMP group. 2) Paul, you made a comment (uncalled for, I believe) about Sun's intransigence over SKIP. I must say thay I have not found the ISAKMP supporters to be any less intransigent. In seems very clear to me that pretty much everyone has settled into one camp or another--if there is any intransigence, there seems to be more than enough blame to go around on BOTH sides. 3) I have been subscribed to this list for longer than I can remember, but I still have yet to see a formal list of *agreed upon* characteristics the group is looking for in a key management system. What "lists" do exist seem to be strongly held personal preferences, but I have yet to see a list of criteria developed by and approved through concensus. Some people like in-band keying, some don't. Some people think the world will stop orbiting the sun without PFS, and others don't. Based on that, I do not see how anyone can possibly accuse ANY of the proposals as being either in or out of compliance with a non-existant list of criteria. 4) I am extremely concerned that we seem to have started yet another round of "let's reexamine what we're trying to do here." While a good idea in principle, we keep seem to do this, resulting in a constant moving of the goal posts. It is no wonder that we are having such difficulty reaching concensus! ***** It is rather clear from the recent traffic and from the votes in Montreal that people are split down the middle over SKIP vs ISAKMP. At this point I believe pretty much everyone is talking past each other. Based on this rather deeply entrenched split, I honestly do not believe this issue is going to be resolved now or even in San Jose. Therefore, I will make the same proposal I made in Montreal: Let *BOTH* SKIP and ISAKMP move ahead in the standards process, and let the marketplace decide which is better. If the IETF does not get something out NOW, then the market will come up with something of their own and all of your debating will be moot. I will reiterate the statement I made several weeks ago: WE CAN NO LONGER AFFORD TO DELAY THE GROWTH OF THIS INDUSTRY. People need solutions today, and if they cannot get them through the IETF, they will get them elsewhere. -John Lawler Received: from relay.hq.tis.com by neptune.TIS.COM id aa23212; 16 Sep 96 18:07 EDT Received: by relay.hq.tis.com; id SAA17808; Mon, 16 Sep 1996 18:10:30 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017801; Mon, 16 Sep 96 18:10:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05101; Mon, 16 Sep 96 18:09:16 EDT Received: by relay.hq.tis.com; id SAA17794; Mon, 16 Sep 1996 18:10:00 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma017779; Mon, 16 Sep 96 18:09:41 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Mon, 16 Sep 1996 18:12:05 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id SAA00641; Mon, 16 Sep 1996 18:11:58 -0400 Message-Id: <199609162211.SAA00641@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: John Lawler Cc: ipsec@TIS.COM Subject: Re: Concerns In-Reply-To: jlawler's message of Mon, 16 Sep 1996 16:38:47 -0700. <2.2.32.19960916233847.00673b14@206.86.0.11> Date: Mon, 16 Sep 1996 18:11:51 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I must say thay I have not found the ISAKMP supporters to be any > less intransigent. Hmm. I got positive feedback about my inband-keying protocol fragment from several people who you might expect are fairly firmly entrenched in the ISAKMP camp. > 3) I have been subscribed to this list for longer than I can remember, but I > still have yet to see a formal list of *agreed upon* characteristics the > group is looking for in a key management system. ... > 4) I am extremely concerned that we seem to have started yet another round > of "let's reexamine what we're trying to do here." While a good idea in > principle, we keep seem to do this, resulting in a constant moving of the > goal posts. It is no wonder that we are having such difficulty reaching > concensus! These two items are in conflict. I don't see how you can assemble a concrete list of requirements *without* reexamining the goal of the working group. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa24596; 16 Sep 96 19:44 EDT Received: by relay.hq.tis.com; id TAA19530; Mon, 16 Sep 1996 19:47:30 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma019528; Mon, 16 Sep 96 19:47:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA09292; Mon, 16 Sep 96 19:46:16 EDT Received: by relay.hq.tis.com; id TAA19520; Mon, 16 Sep 1996 19:47:01 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma019514; Mon, 16 Sep 96 19:46:43 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id QAA13524; Mon, 16 Sep 1996 16:47:11 -0700 Received: from miraj.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id QAA17464; Mon, 16 Sep 1996 16:49:17 -0700 Received: by miraj.incog.com (SMI-8.6/SMI-SVR4) id QAA23612; Mon, 16 Sep 1996 16:47:47 -0700 From: Ashar Aziz Message-Id: <199609162347.QAA23612@miraj.incog.com> Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Mon, 16 Sep 1996 16:47:47 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > and an updated set of minutes reflecting your clarifications have been > prepared (last week actually). No doubt. Paul, if you recall I also complained about the minutes you published for the Dec '95, San Jose meeting, where you said that "SKIP was designed to solve a specific multicast problem". That was how you characterized my presentation, and I thought it a somewhat slanted view of my presentation and protocol. I complained privately to you then. That was over a year and a half ago, and I never saw revised minutes. Now, it is entirely possible that this time revised minutes were going to be published, but you didn't acknowledge receipt of my message, and it's a coincidence that they came out just after I made my comments public. > >First, the SKIP PFS exchange requires 2 messages, not 4-6. > >This is what I presented at the talk, and is present in > >the SKIP PFS I-D. > > It is true that your presentation claimed that SKIP PFS exchange takes 2 > messages. It is also true that other members of the working group claim that > SKIP PFS takes 4 to 6 messages. So depending on who you ask the answer is 2 > to 6 messages. The meeting minutes should reflect what transpired at the meeting. They should not be a place where differences of opinion on the protocols are somehow reconciled. > I am sure that this confusion will be resolved by the working > group, but it is difficult to document in the minutes this type of difference > in opinion. If the difference of opinion is voiced at the meeting, it is fair to mention it. It is unfair to take someone else's views on my protocol, and publish it as "minutes" of my presentation when they don't correspond to my presentation or to what happened at the meeting. Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa25936; 16 Sep 96 21:35 EDT Received: by relay.hq.tis.com; id VAA21036; Mon, 16 Sep 1996 21:38:21 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021033; Mon, 16 Sep 96 21:37:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11347; Mon, 16 Sep 96 21:37:06 EDT Received: by relay.hq.tis.com; id VAA21030; Mon, 16 Sep 1996 21:37:51 -0400 Received: from wicked.neato.org(198.70.96.252) by relay.tis.com via smap (V3.1.1) id xma021026; Mon, 16 Sep 96 21:37:41 -0400 Received: (from rs@localhost) by wicked.neato.org (8.7.2/8.6.12) id SAA21063; Mon, 16 Sep 1996 18:41:56 -0700 (PDT) From: Rich Skrenta Message-Id: <199609170141.SAA21063@wicked.neato.org> Subject: Re: Using SKIP as inspiration, not as gospel To: ipsec@TIS.COM Date: Mon, 16 Sep 1996 18:41:56 -0700 (PDT) In-Reply-To: <9609161525.aa20342@neptune.TIS.COM> from "ipsec-request@neptune.hq.tis.com" at Sep 16, 96 02:39:34 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I don't want to get in to the whole thing, but as just one part, SKIP > does not operate in a model that permits multiple associations between > two hosts, which is needed if you have mutually suspicious users on > different transport connections. Perry, I don't know when you last read the drafts, but it's clear that you aren't very familiar with SKIP. Given this fact, it would be nice if you would stop spreading misinformation about it. > I was wondering if Ashar had anything more to add about the patent > that Sun has apparently been granted which appears to covers all of > IPSEC under its claims. Since an official response has been demanded, our legal department is now involved. You will hear from them next on this issue, not Ashar. I said before that their statement will be forthcoming. Please be patient, these are lawyers. Received: from relay.hq.tis.com by neptune.TIS.COM id aa27800; 17 Sep 96 0:41 EDT Received: by relay.hq.tis.com; id AAA22453; Tue, 17 Sep 1996 00:45:22 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022442; Tue, 17 Sep 96 00:44:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14406; Tue, 17 Sep 96 00:44:07 EDT Received: by relay.hq.tis.com; id AAA22439; Tue, 17 Sep 1996 00:44:52 -0400 Received: from nsco.network.com(129.191.1.1) by relay.tis.com via smap (V3.1.1) id xma022437; Tue, 17 Sep 96 00:44:42 -0400 Received: from mnbp.network.com (ushub.network.com) by nsco.network.com (4.1/1.34) id AA20050; Mon, 16 Sep 96 23:54:18 CDT Received: by mnbp.network.com with Microsoft Mail id <323E2C49@mnbp.network.com>; Mon, 16 Sep 96 23:42:49 CDT From: "Jeff D. Hayes" To: ipsec Subject: RE: Concerns Date: Mon, 16 Sep 96 23:42:00 CDT Message-Id: <323E2C49@mnbp.network.com> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk [snip] let the marketplace decide which is better. If the IETF does not get something out NOW, then the market will come up with something of their own and all of your debating will be moot. I will reiterate the statement I made several weeks ago: WE CAN NO LONGER AFFORD TO DELAY THE GROWTH OF THIS INDUSTRY. People need solutions today, and if they cannot get them through the IETF, they will get them elsewhere. **Horray John Lawler! The opportunity for all of us is too great to be mired in techno squabble. The show must go on! The question is who should lead it? Why not co-leaders? jeff.hayes@network.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa27894; 17 Sep 96 0:48 EDT Received: by relay.hq.tis.com; id AAA22523; Tue, 17 Sep 1996 00:52:22 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022521; Tue, 17 Sep 96 00:51:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14515; Tue, 17 Sep 96 00:51:07 EDT Received: by relay.hq.tis.com; id AAA22512; Tue, 17 Sep 1996 00:51:52 -0400 Received: from freya.cs.umass.edu(128.119.40.195) by relay.tis.com via smap (V3.1.1) id xma022506; Tue, 17 Sep 96 00:51:23 -0400 Received: from thor.cs.umass.edu by cs.umass.edu (5.65/Ultrix3.0-C) id AA28320; Tue, 17 Sep 1996 00:53:26 -0400 Message-Id: <323E2EC5.41C6@cs.umass.edu> Date: Tue, 17 Sep 1996 00:53:25 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) Mime-Version: 1.0 To: ipsec@TIS.COM Subject: Re: Fwd: revised IPsec minutes for Montreal References: <199609162035.NAA06638@mailsun2.us.oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > IPSEC WG Meeting Notes, Montreal IETF, June 1996 [...] > Doug Maughan reported on ISAKMP. [...] > Jon Millen's analysis notes that cookies don't buy much > Denial-of-Service protection, and that authentication and key > exchange is sufficiently decoupled to require further analysis. Could someone give me a reference for this analysis ? Thanks -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "He said, `You are as constant as a northern star,' and I said, `Constantly in the darkness ? Where's that at ?'" -- Joni Mitchell Received: from relay.hq.tis.com by neptune.TIS.COM id aa28141; 17 Sep 96 1:05 EDT Received: by relay.hq.tis.com; id BAA22703; Tue, 17 Sep 1996 01:08:52 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022701; Tue, 17 Sep 96 01:08:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14846; Tue, 17 Sep 96 01:07:36 EDT Received: by relay.hq.tis.com; id BAA22698; Tue, 17 Sep 1996 01:08:22 -0400 Received: from freya.cs.umass.edu(128.119.40.195) by relay.tis.com via smap (V3.1.1) id xma022696; Tue, 17 Sep 96 01:08:09 -0400 Received: from thor.cs.umass.edu by cs.umass.edu (5.65/Ultrix3.0-C) id AA28575; Tue, 17 Sep 1996 01:10:31 -0400 Message-Id: <323E32C7.167E@cs.umass.edu> Date: Tue, 17 Sep 1996 01:10:31 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) Mime-Version: 1.0 To: ipsec@TIS.COM Subject: where is draft-ietf-ipsec-oakley-02.txt ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk The ISAKMP/Oakley resolution draft (draft-ietf-ipsec-isakmp-oakley-00.txt) refers to a draft-ietf-ipsec-oakley-02.txt. All I've been able to find in the usual ID directories is -01.txt. Is the -02 a typo or is the new version just remarkably hard to locate ? -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "He said, `You are as constant as a northern star,' and I said, `Constantly in the darkness ? Where's that at ?'" -- Joni Mitchell Received: by dcl.MIT.EDU (5.x/4.7) id AA16163; Mon, 16 Sep 1996 17:31:56 -0400 Date: Mon, 16 Sep 1996 17:31:56 -0400 Message-Id: <9609162131.AA16163@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: John Lawler Cc: ipsec@TIS.COM Subject: Re: Concerns Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 16 Sep 1996 16:59:53 -0700 From: John Lawler It is rather clear from the recent traffic and from the votes in Montreal that people are split down the middle over SKIP vs ISAKMP. At this point I believe pretty much everyone is talking past each other. Based on this rather deeply entrenched split, I honestly do not believe this issue is going to be resolved now or even in San Jose. Well, at the IPSEC wg, what I saw was a small group of people who wanted SKIP, a small group of people who wanted ISAKMP (and I won't try to characterize which of the two small groups were bigger, more technically comptentent, or has better-substantiated paternity), but the vast majority of the room were from vendor-types who said, "we don't care which one you choose; we're not competent to make that choice. But we don't have to implement two solutions. Pick one." So, I think we have to do that; granted, the wg consensus process isn't well suited for that. But that's why we have an Area Director, an IESG, and an IAB. If you recall, the chartering of a design team to try to come to one solution had a fallback solution if that design team did not come to consensus. - Ted Date: Mon, 16 Sep 1996 18:17:53 -0400 From: Hilarie Orman Message-Id: <199609162217.SAA19385@earth.hpc.org> To: jlawler@vpnet.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609162133.OAA19723@baskerville.CS.Arizona.EDU> Subject: Re: Concerns Sender: ipsec-approval@neptune.tis.com Precedence: bulk There has been consensus on PFS for over a year, at least. There has been general agreement on out-of-band keying for longer than that. This doesn't preclude expanding the points of consensus, of course. > In seems very clear to me that > pretty much everyone has settled into one camp or another-- There's a contingent that would like to see an inclusive solution -- a contingent that believes it's easier to code than argue, that we can have it all for little additional cost. Message-Id: <199609162302.TAA23968@jekyll.piermont.com> To: John Lawler Cc: ipsec@TIS.COM Subject: Re: Concerns Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 16 Sep 1996 19:02:05 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Lawler writes: > 2) Paul, you made a comment (uncalled for, I believe) about Sun's > intransigence over SKIP. I must say thay I have not found the ISAKMP > supporters to be any less intransigent. I believe that what you call the ISAKMP camp is not a camp and in fact didn't support ISAKMP before recently when it emerged as a result of consensus. People in this "camp" are equally happy with any of a variety of negotiation protocol solutions -- Photuris, Oakley, etc. Generally, what is desired is a protocol that plays well with the IPSec model. I'm still not entirely happy with what we have. I'm just pretty sure SKIP isn't as close as things following the general model of Photuris and Oakley. > Therefore, I will make the same proposal I made in Montreal: Let > *BOTH* SKIP and ISAKMP move ahead in the standards process, and let > the marketplace decide which is better. If the IETF does not get > something out NOW, then the market will come up with something of > their own and all of your debating will be moot. I would suggest that they both go forward as experimental, but, thats a matter of taste. I agree we should be developing and deploying without delay. Perry From: Dan McDonald Message-Id: <199609170303.UAA25153@kebe.eng.sun.com> Subject: Re: Using SKIP as inspiration, not a To: oz@border.com, ipsec@TIS.COM Date: Mon, 16 Sep 1996 20:03:51 -0800 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk For reasons very similar to Rich Skrenta's earlier note about mail not reaching various places, I didn't get a chance to get this note out until now. Hopefully it will clear up some things. -- Dan McD. ---- > > Some of us don't like the fact that SKIP does not play nicely with the > > IPSec model. > > i have no idea what this means. i am a relative newcomer to the IPSec > forum, so perhaps you could clarify... I _think_ (and I don't claim to speak for Perry here) that what he means by, "not playing nice with the IPsec model," is something like the following example. According to RFC 1825 (IP Security Architecture): > 4. KEY MANAGEMENT > > The Key Management protocol that will be used with IP layer security > is not specified in this document. However, because the key > management protocol is coupled to AH and ESP only via the Security > Parameters Index (SPI), we can meaningfully define AH and ESP without > having to fully specify how key management is performed. As this implementor reads it, the way I tell what key(s) to use is to look at the SPI, and parse the rest of the packet accordingly. This would mean packets look like: <--- cleartext ---><--- Possibly encrypted text, depending ---> +-------+---------+============================================ | IP or | ESP | Encrypted data (maybe in-line keys, too) | IPv6 | SPI = n | which I can parse by using SPI value n to | | | lookup in my table what this data is. +-------+---------+============================================ >From what I understand about SKIP, SKIP does not include its in-line keys, etc. after the ESP header. Rather, it _prepends_ this data in its own header. Packets then look like: <--- mostly cleartext -----><--- ciphertext ----------------> (save the SKIP sess. key) +-------+---------+---------+================================== | IP or | SKIP | ESP | Encrypted data. | IPv6 | header | SPI = 1 | | | w/sec. | | | | parms. | | +-------+---------+---------+================================== Some people (including Perry, I'd imagine :) consider this a violation of RFC 1825. Other people have wondered if a header that looked like this could happen: <--- mostly cleartext -----><--- ciphertext ----------------> (save the SKIP sess. key) +-------+---------+---------+================================== | IP or | ESP | SKIP as | Encrypted data. | IPv6 | SPI = 1 | an ESP | | | or some | x-form | | | range. | data | +-------+---------+---------+================================== These people argue that it accomodates SKIP's in-line keying advantages, while not violating RFC 1825. If I'm missing any relevant data, please feel free to fill in the blanks, folks. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + Date: Tue, 17 Sep 1996 09:47:13 -0400 From: Hilarie Orman Message-Id: <199609171347.JAA13751@earth.hpc.org> To: danmcd@pacific-86.eng.sun.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609171254.FAA01320@baskerville.CS.Arizona.EDU> Subject: Re: Using SKIP as inspiration, not a Sender: ipsec-approval@neptune.tis.com Precedence: bulk Is there then consensus for including in-line keys with a non-PFS key determination mode as a required component of a key distribution protocol? Received: from [192.94.214.100] by neptune.TIS.COM id aa03823; 17 Sep 96 9:55 EDT Received: by relay.hq.tis.com; id JAA00191; Tue, 17 Sep 1996 09:59:14 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000180; Tue, 17 Sep 96 09:58:45 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28130; Tue, 17 Sep 96 09:57:58 EDT Received: by relay.hq.tis.com; id JAA00177; Tue, 17 Sep 1996 09:58:43 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma000174; Tue, 17 Sep 96 09:58:26 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id HAA18430; Tue, 17 Sep 1996 07:00:49 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id HAA26960; Tue, 17 Sep 1996 07:01:12 -0700 Message-Id: <199609171401.HAA26960@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Lewis McCarthy Cc: ipsec@TIS.COM Subject: Re: where is draft-ietf-ipsec-oakley-02.txt ? In-Reply-To: Your message of "Tue, 17 Sep 1996 01:10:31 EDT." <323E32C7.167E@cs.umass.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 1996 07:01:12 -0700 From: Daniel Harkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk Lewis McCarthy wrote: > The ISAKMP/Oakley resolution draft > (draft-ietf-ipsec-isakmp-oakley-00.txt) refers to a > draft-ietf-ipsec-oakley-02.txt. All I've been able to find in the > usual ID directories is -01.txt. Is the -02 a typo or is the new > version just remarkably hard to locate ? Oops. It's a typo. Thanks for pointing that out. Dan. ----------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: (408) 526-5905 170 W. Tasman Drive | fax: (408) 526-4952 San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W ----------------------------------------------------------------------------- For your safety and the safety of others: concealed carry, and strong crypto ----------------------------------------------------------------------------- Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Cc: mobile-ip@smallworks.com, ipsec@TIS.COM Subject: I-D ACTION:draft-montenegro-firewall-sup-00.txt Date: Tue, 17 Sep 1996 09:21:38 -0400 Message-Id: <9609170921.aa10707@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Firewall Support for Mobile IP Author(s) : G. Montenegro, V. Gupta Filename : draft-montenegro-firewall-sup-00.txt Pages : 22 Date : 09/16/1996 The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification uses cryptographic techniques to authenticate the parties involved in the registration protocol. However, it makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the network to negotiate ccess past a SKIP firewall, and construct a secure channel into its home network. 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-montenegro-firewall-sup-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-montenegro-firewall-sup-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) 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-montenegro-firewall-sup-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@ietf.org 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: <19960916100728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-firewall-sup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-firewall-sup-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960916100728.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost by ietf.org id aa10751; 17 Sep 96 9:22 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-des-md5-03.txt Date: Tue, 17 Sep 1996 09:22:05 -0400 Message-Id: <9609170922.aa10751@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : J. Hughes Filename : draft-ietf-ipsec-esp-des-md5-03.txt Pages : 14 Date : 09/16/1996 This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-des-md5-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) 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-ietf-ipsec-esp-des-md5-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@ietf.org 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: <19960917091751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-md5-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960917091751.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from [192.94.214.100] by neptune.TIS.COM id aa04874; 17 Sep 96 10:54 EDT Received: by relay.hq.tis.com; id KAA01505; Tue, 17 Sep 1996 10:58:14 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma001495; Tue, 17 Sep 96 10:57:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03063; Tue, 17 Sep 96 10:57:01 EDT Received: by relay.hq.tis.com; id KAA01486; Tue, 17 Sep 1996 10:57:44 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma001470; Tue, 17 Sep 96 10:57:15 -0400 Received: from munin.fnal.gov ("port 3230"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I9KXTLUESQ002K6R@FNAL.FNAL.GOV>; Tue, 17 Sep 1996 09:59:33 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA10216; Tue, 17 Sep 1996 09:57:28 -0500 (CDT) Date: Tue, 17 Sep 1996 09:57:27 -0500 From: Matt Crawford Subject: Re: Concerns In-Reply-To: "16 Sep 1996 17:31:56 EDT." <"9609162131.AA16163"@dcl.MIT.EDU> To: "Theodore Y. Ts'o" Cc: ipsec@TIS.COM Message-Id: <199609171457.JAA10216@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Well, at the IPSEC wg, [...] the vast > majority of the room were from vendor-types who said, "we don't care > which one you choose; we're not competent to make that choice. But we > don't have to implement two solutions. Pick one." When Jeff Schiller asked how many had no preference, the number who raised their hands was a very very small fraction -- perhaps 15 to 20 people in all. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Message-Id: <199609171500.LAA27735@jekyll.piermont.com> To: Hilarie Orman Cc: danmcd@pacific-86.eng.sun.com, ipsec@TIS.COM Subject: Re: Using SKIP as inspiration, not a Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 17 Sep 1996 11:00:53 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hilarie Orman writes: > Is there then consensus for including in-line keys with a non-PFS key > determination mode as a required component of a key distribution > protocol? I don't think so, but I suspect the folks from the Sun Internet Commerce Group will differ. :) Perry Received: from [192.94.214.100] by neptune.TIS.COM id aa05915; 17 Sep 96 11:41 EDT Received: by relay.hq.tis.com; id LAA03485; Tue, 17 Sep 1996 11:44:44 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003456; Tue, 17 Sep 96 11:44:18 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07367; Tue, 17 Sep 96 11:43:30 EDT Received: by relay.hq.tis.com; id LAA03440; Tue, 17 Sep 1996 11:44:14 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma003431; Tue, 17 Sep 96 11:43:59 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA07831; Tue, 17 Sep 1996 11:46:51 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id LAA10776; Tue, 17 Sep 1996 11:46:22 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA28484; Tue, 17 Sep 1996 11:46:21 -0400 From: Uri Blumenthal Message-Id: <9609171546.AA28484@hawpub.watson.ibm.com> Subject: Re: Using SKIP as inspiration, not a To: Hilarie Orman Date: Tue, 17 Sep 1996 11:46:21 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199609171347.JAA13751@earth.hpc.org> from "Hilarie Orman" at Sep 17, 96 09:47:13 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hilarie Orman says: > Is there then consensus for including in-line keys with a non-PFS key > determination mode as a required component of a key distribution > protocol? I sure hope so. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from [192.94.214.100] by neptune.TIS.COM id aa06915; 17 Sep 96 12:37 EDT Received: by relay.hq.tis.com; id MAA05116; Tue, 17 Sep 1996 12:41:15 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma005113; Tue, 17 Sep 96 12:40:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA10482; Tue, 17 Sep 96 12:40:00 EDT Received: by relay.hq.tis.com; id MAA05107; Tue, 17 Sep 1996 12:40:45 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma005100; Tue, 17 Sep 96 12:40:26 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA15080; Tue, 17 Sep 1996 12:42:48 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma014868; Tue Sep 17 12:42:14 1996 Received: from tsntsrv1.timestep.com ([192.168.219.190]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id MAA05679; Tue, 17 Sep 1996 12:42:13 -0400 Received: from Microsoft Mail (PU Serial #1121) by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Sep17.122500.1121.46518; Tue, 17 Sep 1996 12:40:38 -0400 From: Roy Pereira To: Lewis McCarthy , 'IPSEC' Message-Id: <1996Sep17.122500.1121.46518@tsntsrv1.timestep.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: TimeStep Corporation Date: Tue, 17 Sep 1996 12:40:38 -0400 Subject: RE: where is draft-ietf-ipsec-oakley-02. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Actually, the OAKLEY draft (draft-ietf-ipsec-oakley-01.txt) expired on August 24th. Does anyone know if or when it will be revised? ---------- From: Lewis McCarthy[SMTP:lmccarth@cs.umass.edu] Sent: Tuesday, September 17, 1996 3:10 AM To: ipsec Subject: where is draft-ietf-ipsec-oakley-02.txt The ISAKMP/Oakley resolution draft (draft-ietf-ipsec-isakmp-oakley-00.txt) refers to a draft-ietf-ipsec-oakley-02.txt. All I've been able to find in the usual ID directories is -01.txt. Is the -02 a typo or is the new version just remarkably hard to locate ? -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "He said, `You are as constant as a northern star,' and I said, `Constantly in the darkness ? Where's that at ?'" -- Joni Mitchell Date: Tue, 17 Sep 1996 12:55:09 -0400 From: Hilarie Orman Message-Id: <199609171655.MAA18700@earth.hpc.org> To: danmcd@pacific-86.eng.sun.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609171541.IAA25888@kebe.eng.sun.com> Subject: Re: Using SKIP as inspiration, not a Sender: ipsec-approval@neptune.tis.com Precedence: bulk > REQURING more than one thing splits us vendors (especially those of us in > politically hairy environments where I don't see eye-to-eye with others in a > different part of said environment) into camps, and LOWERS interoperability > and SLOWS deployment. How much extra effort is required to add SKIP non-PFS support to an IPSEC+some_kind_of_DH_key_mgmt_interface base? I'd think it should be fairly trivial, under 100 lines of code (blithely said by someone who hasn't written a line in some months). How can this be a serious impediment? Date: Tue, 17 Sep 1996 13:45:38 -0400 From: Hilarie Orman Message-Id: <199609171745.NAA20113@earth.hpc.org> To: rpereira@timestep.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199609171717.KAA17319@baskerville.CS.Arizona.EDU> Subject: Re: "RE: where is draft-ietf-ipsec-oakley-02." Sender: ipsec-approval@neptune.tis.com Precedence: bulk There is an Oakley 02 draft in progress but languishing; I'd like the next draft to be completely coordinated with related drafts, so I've viewed my procrastination as a useful artifact. Plans for OAKLEY are to add DH certificates to the list of OAKLEY authentication mechanisms, clarify the use of signatures, standardize the use of ISAKMP formats, and add the last elliptic curve group definition (EC group available separately on request). There are issues with respect to naming the transforms for the required encryption and keyed hash mechanisms that remain open, and I'm not sure they can be resolved by December. The details of how an algorithm key is derived from an OAKLEY raw key are also open; this should be part of the encryption and keyed hash transform interface specifications. Received: by dcl.MIT.EDU (5.x/4.7) id AA16683; Tue, 17 Sep 1996 14:31:22 -0400 Date: Tue, 17 Sep 1996 14:31:22 -0400 Message-Id: <9609171831.AA16683@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Matt Crawford Cc: "Theodore Y. Ts'o" , ipsec@TIS.COM Subject: Re: Concerns Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Tue, 17 Sep 1996 09:57:27 -0500 From: Matt Crawford When Jeff Schiller asked how many had no preference, the number who raised their hands was a very very small fraction -- perhaps 15 to 20 people in all. As usual, the number of people who didn't raise their hands at all was in the vast majority..... - Ted Received: from [192.94.214.100] by neptune.TIS.COM id aa10748; 17 Sep 96 16:42 EDT Received: by relay.hq.tis.com; id QAA14254; Tue, 17 Sep 1996 16:45:47 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014223; Tue, 17 Sep 96 16:45:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28414; Tue, 17 Sep 96 16:44:35 EDT Received: by relay.hq.tis.com; id QAA14192; Tue, 17 Sep 1996 16:45:18 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma014167; Tue, 17 Sep 96 16:44:51 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA02897; Tue, 17 Sep 1996 13:47:05 -0700 Received: from info-10.noc.interop.net ([45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA26427; Tue, 17 Sep 1996 13:34:48 -0700 Message-Id: <2.2.32.19960917233306.006894c4@best.com> X-Sender: jlawler@best.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 1996 16:33:06 -0700 To: ipsec@TIS.COM From: John Lawler Subject: A proposal Cc: Hilarie Orman Sender: ipsec-approval@neptune.tis.com Precedence: bulk >There has been consensus on PFS for over a year, at least. There has >been general agreement on out-of-band keying for longer than that. This >doesn't preclude expanding the points of consensus, of course. That may very well be, but I think it would still be a good idea to know what that list is, and have everything in one place. The semi-anecdotal messages saying "well, there seems to be agreement on XXX" that we see a lot in this group (especially when it's feature XXX vs YYY, and when at that moment the tide is turning towards YYY) does not speak well for this WG effort. Moreover, even if we come to a directional agreement on a feature, then people squabble over the details--to take PFS as an example, we recently had a fight about whose PFS is "perfect" enough. Not only do I not recall a resolution to that debate--it just seemed to die out after a while--but that really isn't the issue. What is the issue is that at this late date in the process, we're still trying to do such basic things as level setting on overall goals! Given that, I am concerned that we will not make progress in anything resembling the kind of timeframe needed to address immediate market requirements if we continue with the current way of doing things. >There's a contingent that would like to see an inclusive solution -- a >contingent that believes it's easier to code than argue, that we can >have it all for little additional cost. IMHO, there has been a lot of people, on all sides, who have contributed to the gridlock we're experiencing. I would like to make it clear that Hilarie is NOT one of them--she has been one of the people whom I genuinely believe has made a concerted and good-faith effort to accomodate the strengths of the two approaches. Unfortunately, she is only one woman. I would personally love to see a single solution, but at this point, this is not likely to happen if we continue on the same course: the current process has gotten too politicized, too personal (between both individuals and companies), too many people who are supposed to be neutral and objective are often not, market events have overtaken us, and just generally, the process has broken down. There is more than enough blame to go around, but let's not kind ourselves that things are working as they should. So, here is my proposal: I would recommend that we make one last good faith attempt to merge the proposals prior to the December IETF. From what I understand, the last attempt started off as a small group which got larger and more contentious as time went on. Since too many cooks spoil the soup, I recommend that Ashar and Hilarie sit down *alone* and see what they can come up with (SKIP/Oakley :-) ). I have faith that in such an environment, much of the politics, etc. can be set aside and perhaps we might end up with a proposal based on the best aspects of both systems. Frankly, if the two of them cannot pound something out, then IMHO it will never happen within the larger group, in which case, we should let both proposals move ahead. -John Received: from [192.94.214.100] by neptune.TIS.COM id aa10744; 17 Sep 96 16:42 EDT Received: by relay.hq.tis.com; id QAA14253; Tue, 17 Sep 1996 16:45:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014219; Tue, 17 Sep 96 16:45:21 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28411; Tue, 17 Sep 96 16:44:32 EDT Received: by relay.hq.tis.com; id QAA14195; Tue, 17 Sep 1996 16:45:18 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma014169; Tue, 17 Sep 96 16:44:55 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA02887; Tue, 17 Sep 1996 13:47:03 -0700 Received: from info-10.noc.interop.net ([45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA26402; Tue, 17 Sep 1996 13:34:47 -0700 Message-Id: <2.2.32.19960917233304.00687780@best.com> X-Sender: jlawler@best.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 1996 16:33:04 -0700 To: ipsec@TIS.COM From: John Lawler Subject: Re: Concerns Cc: "Theodore Y. Ts'o" Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Well, at the IPSEC wg, what I saw was a small group of people who wanted >SKIP, a small group of people who wanted ISAKMP (and I won't try to >characterize which of the two small groups were bigger, more technically >comptentent, or has better-substantiated paternity), but the vast >majority of the room were from vendor-types who said, "we don't care >which one you choose; we're not competent to make that choice. But we >don't have to implement two solutions. Pick one." That is not the case. I estimated the attendance for the votes at about 250-300 people (almost all of whom said they had read both specs, BTW), and each vote showed half the hands in the room voting yes, and half the room voting no, for each question asked. There seemed to be very few abstentions at all, so I cannot agree with your characterization of either SKIP or ISAKMP having the support of only a small group. As to the particular vote you mention, I believe that only perhaps 12-15 people raised their hands as having no preference (which shocked me, by the way--I also expected small core groups and lots of abstentions). I bring this up not for petty contridiction but to point out that the support for *both* SKIP and ISAKMP seems rather strong and deep, and I do not feel that those results are going to change significantly in the near future. Since the world will not wait forever for us to resolve these differences, since an "ex cathedra" decision one way or the other will only serve to alienate fully half the group, and since there are good features in both, I recommend that we 1) one last attempt at unification where everyone makes a *good faith effort* to accomodate the other (see my reply to Hilarie for details), or 2) let them both leave the nest and see which one thrives. -John Received: from [192.94.214.100] by neptune.TIS.COM id aa10785; 17 Sep 96 16:46 EDT Received: by relay.hq.tis.com; id QAA14582; Tue, 17 Sep 1996 16:50:17 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014546; Tue, 17 Sep 96 16:49:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28586; Tue, 17 Sep 96 16:49:01 EDT Received: by relay.hq.tis.com; id QAA14543; Tue, 17 Sep 1996 16:49:46 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma014526; Tue, 17 Sep 96 16:49:26 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA03292; Tue, 17 Sep 1996 13:50:34 -0700 Received: from info-10.noc.interop.net ([45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA26299; Tue, 17 Sep 1996 13:34:42 -0700 Message-Id: <2.2.32.19960917233303.00685998@best.com> X-Sender: jlawler@best.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 1996 16:33:03 -0700 To: ipsec@TIS.COM From: John Lawler Subject: Re: Concerns Cc: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk >These two items are in conflict. I don't see how you can assemble a >concrete list of requirements *without* reexamining the goal of the >working group. My point is that if we are still at this stage of the game at this late date, then something is seriously wrong with the process. And in any case, without such a list, or without a serious chnage in the way things are handled within the WG, the only decision that can reasonably be made is to let both specs advance through the process. *Neither* spec should be chosen or killed because they are allegedly in or out of compliance with a non-existant and still-evolving set of criteria. I still would much prefer to see a unified proposal--please see the separate message I've posted with a proposal towards that end. -John Received: from relay.hq.tis.com by neptune.TIS.COM id aa15494; 18 Sep 96 1:30 EDT Received: by relay.hq.tis.com; id BAA22397; Wed, 18 Sep 1996 01:33:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022395; Wed, 18 Sep 96 01:33:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11583; Wed, 18 Sep 96 01:32:25 EDT Received: by relay.hq.tis.com; id BAA22390; Wed, 18 Sep 1996 01:33:11 -0400 Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (V3.1.1) id xma022385; Wed, 18 Sep 96 01:32:48 -0400 Received: by big-screw id AA03194; Wed, 18 Sep 96 01:34:53 -0400 Message-Id: <323F7BA9.2DF@mit.edu> Date: Wed, 18 Sep 1996 00:33:44 -0400 From: "Jeffrey I. Schiller" Reply-To: jis@mit.edu Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 3.0 (Macintosh; U; 68K) Mime-Version: 1.0 To: ipsec@TIS.COM Subject: Re: Concerns References: <2.2.32.19960917233304.00687780@best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am working on a solution. Expect to hear from me late on Thursday. -Jeff Schiller IESG Area Director for Security Date: Tue, 17 Sep 1996 17:51:42 -0400 Message-Id: <9609172151.AA16998@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: John Lawler Cc: ipsec@TIS.COM, "Theodore Y. Ts'o" In-Reply-To: John Lawler's message of Tue, 17 Sep 1996 16:33:04 -0700, <2.2.32.19960917233304.00687780@best.com> Subject: Re: Concerns Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Tue, 17 Sep 1996 16:33:04 -0700 From: John Lawler That is not the case. I estimated the attendance for the votes at about 250-300 people (almost all of whom said they had read both specs, BTW), and each vote showed half the hands in the room voting yes, and half the room voting no, for each question asked. There seemed to be very few abstentions at all, so I cannot agree with your characterization of either SKIP or ISAKMP having the support of only a small group. As to the particular vote you mention, I believe that only perhaps 12-15 people raised their hands as having no preference (which shocked me, by the way--I also expected small core groups and lots of abstentions). Hmm... my recollection of the IETF montreal straw poll was about 25-30 people saying that they wanted SKIP, and about the same number wanting ISAKMP, with the rest abstaining. I talked to Jeff about this earlier last week, and that was his recollection as well..... - Ted Date: Tue, 17 Sep 1996 22:39:18 GMT Message-Id: <199609172239.WAA14168@carp.morningstar.com> From: Karl Fox To: John Lawler Cc: ipsec@TIS.COM, "Theodore Y. Ts'o" Subject: Re: Concerns In-Reply-To: <2.2.32.19960917233304.00687780@best.com> References: <2.2.32.19960917233304.00687780@best.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Lawler writes: > >Well, at the IPSEC wg, what I saw was a small group of people who wanted > >SKIP, a small group of people who wanted ISAKMP (and I won't try to > >characterize which of the two small groups were bigger, more technically > >comptentent, or has better-substantiated paternity), but the vast > >majority of the room were from vendor-types who said, "we don't care > >which one you choose; we're not competent to make that choice. > > That is not the case. I estimated the attendance for the votes at about > 250-300 people (almost all of whom said they had read both specs, BTW), and > each vote showed half the hands in the room voting yes, and half the room > voting no, for each question asked. There seemed to be very few abstentions > at all, so I cannot agree with your characterization of either SKIP or > ISAKMP having the support of only a small group. This is not what I saw. I saw only a handful voting for SKIP, a few more for ISAKMP/Oakley, and the vast majority with their hands down. > As to the particular vote you mention, I believe that only perhaps > 12-15 people raised their hands as having no preference This is also true. Most of the people didn't raise their hand for anything. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa21529; 18 Sep 96 11:25 EDT Received: by relay.hq.tis.com; id LAA04445; Wed, 18 Sep 1996 11:28:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004427; Wed, 18 Sep 96 11:28:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00741; Wed, 18 Sep 96 11:27:17 EDT Received: by relay.hq.tis.com; id LAA04411; Wed, 18 Sep 1996 11:28:03 -0400 Received: from wicked.neato.org(198.70.96.252) by relay.tis.com via smap (V3.1.1) id xma004401; Wed, 18 Sep 96 11:27:52 -0400 Received: (from rs@localhost) by wicked.neato.org (8.7.2/8.6.12) id IAA17934 for ipsec@tis.com; Wed, 18 Sep 1996 08:32:06 -0700 (PDT) From: Rich Skrenta Message-Id: <199609181532.IAA17934@wicked.neato.org> Subject: Re: Concerns To: ipsec@TIS.COM Date: Wed, 18 Sep 1996 08:32:06 -0700 (PDT) In-Reply-To: <199609172239.WAA14168@carp.morningstar.com> from "Karl Fox" at Sep 17, 96 10:39:18 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > This is not what I saw. I saw only a handful voting for SKIP, a few > more for ISAKMP/Oakley, and the vast majority with their hands down. This is remarkable, since there wasn't a vote on SKIP vs. ISAKMP at the Montreal meeting. The only time there has been a vote on whether ISAKMP had consensus by itself was in March at LA, and I saw four hands go up for it then. > This is also true. Most of the people didn't raise their hand for > anything. That's not the way I remember it... John Gimore posted his recollections of the votes some time ago. The only conclusion which can be drawn from them is that there wasn't consensus on any issue, except whether a small group of people with nothing to do with either protocol should pick a winner -- no one thought that was a good idea. Here again is what John wrote about the votes: > Jeff Schiller's closing discussions in the second meeting included > these "straw poll" questions, with my rough estimations of the > audience reaction. He said he deliberately structured the questions > to avoid a straw-poll on particular algorithms, but instead focused on > our goals or process. > > Should we let the marketplace decide on a key managment standard, > or should we pick one and move forward? > > Marketplace - 2/5 > Pick one - 3/5 > > Should we favor generality, or simplicity? > > Generality - 2/5 > Simplicity - 3/5 > > Do we have to have a plan by the next IETF? > > On this we have consensus -- YES. > > Should Jeff grab a few of the WG people who are known not to be committed > to any proposal, and together decide? > > Strong consensus that this was not the way to go. > > This was when he suggested convening a small group, largely composed of > the authors/proponents of existing proposals, to try to hammer out a > compromise proposal. He also said that if this group didn't come up with > anything by September, Jeff would personally choose one as the standard, > though he did not want to be forced to do that. Received: from relay.hq.tis.com by neptune.TIS.COM id aa22314; 18 Sep 96 12:42 EDT Received: by relay.hq.tis.com; id MAA07297; Wed, 18 Sep 1996 12:44:58 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007268; Wed, 18 Sep 96 12:44:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05309; Wed, 18 Sep 96 12:43:49 EDT Received: by relay.hq.tis.com; id MAA07253; Wed, 18 Sep 1996 12:44:28 -0400 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1) id xma006870; Wed, 18 Sep 96 12:40:05 -0400 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/3.0) id MAA21320; Wed, 18 Sep 1996 12:34:52 -0400 Received: from milkyway.com (rootmcr@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id MAA13781 for ; Wed, 18 Sep 1996 12:31:16 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id MAA09035; Wed, 18 Sep 1996 12:30:13 -0400 Message-Id: <199609181630.MAA09035@milkyway.com> X-Mailer: exmh version 1.6.7 5/3/96 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Tue, 17 Sep 1996 16:33:04 PDT." <2.2.32.19960917233304.00687780@best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Sep 1996 12:30:02 -0400 From: Michael Richardson Sender: ipsec-approval@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Tue, 17 Sep 1996 16:33:04 PDT > That is not the case. I estimated the attendance for the votes at about > 250-300 people (almost all of whom said they had read both specs, BTW), and > each vote showed half the hands in the room voting yes, and half the room And how many raised their hands when asked if they read the list? Or been to an IPsec meeting? My marketing people in San Jose were after us to bus down engineers from HQ (in Ottawa, two hours from Montreal) to help "stack" the meeting. I won't say which side they wanted support for. But, they had "heard" that both Sun and Cisco were stacking the meeting. I think the chairs were well aware of this. I also won't say what I told my marketing people. I agree that we can find some common ground. I see replacing key managers on things like Win95 platforms and Macs as being relatively easy. You'll notice how silent Microsoft is. I'd prefer the remained silent and just provided something on which others to build (I know this is counter to what they traditionally do. But they didn't traditionally provide people to help chair IETF working groups either...) -- mcr@milkyway.com | Milkyway Networks Corporation Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: mcr@sandelman.ocunix.on.ca. Received: from relay.hq.tis.com by neptune.TIS.COM id aa22672; 18 Sep 96 13:14 EDT Received: by relay.hq.tis.com; id NAA08679; Wed, 18 Sep 1996 13:17:58 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008671; Wed, 18 Sep 96 13:17:31 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07523; Wed, 18 Sep 96 13:16:43 EDT Received: by relay.hq.tis.com; id NAA08660; Wed, 18 Sep 1996 13:17:29 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma008648; Wed, 18 Sep 96 13:16:59 -0400 Received: from munin.fnal.gov ("port 3965"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I9MH0AFCT8002DFU@FNAL.FNAL.GOV> for ipsec@tis.com; Wed, 18 Sep 1996 12:19:22 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id MAA17639; Wed, 18 Sep 1996 12:17:16 -0500 (CDT) Date: Wed, 18 Sep 1996 12:17:15 -0500 From: Matt Crawford Subject: Re: Concerns In-Reply-To: "18 Sep 1996 08:32:06 PDT." <"199609181532.IAA17934"@wicked.neato.org> To: ipsec@TIS.COM Message-Id: <199609181717.MAA17639@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ That's not the way I remember it... Maybe it isn't important whether we all agree on whether a show of hands was asked on each KMP proposal, or on the absolute magnitude of the number of hands that went up. Let's all chill out for a day and see what the AD has to say tomorrow. Date: Wed, 18 Sep 1996 13:01:18 -0400 To: Hilarie Orman , danmcd@pacific-86.eng.sun.com From: Robert Moskowitz Subject: Re: Using SKIP as inspiration, not a Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609181350.aa23182@neptune.TIS.COM> At 09:47 AM 9/17/96 -0400, Hilarie Orman wrote: >Is there then consensus for including in-line keys with a non-PFS key >determination mode as a required component of a key distribution >protocol? There are many uses of this within an organization. Accessing PLCs (those robot controllers on the assembly line), hubs, and some router things like stat collection. I have often felt that such an approach is just what SNMPv2 needs. But in the total universe of needs this is juct an important use. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa23590; 18 Sep 96 14:18 EDT Received: by relay.hq.tis.com; id OAA11203; Wed, 18 Sep 1996 14:22:01 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma011197; Wed, 18 Sep 96 14:21:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11822; Wed, 18 Sep 96 14:20:54 EDT Received: by relay.hq.tis.com; id OAA11181; Wed, 18 Sep 1996 14:21:38 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma011157; Wed, 18 Sep 96 14:21:13 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA23855 for ; Wed, 18 Sep 1996 14:23:31 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma023740; Wed Sep 18 14:23:05 1996 Received: from tsntsrv1.timestep.com ([192.168.219.190]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id OAA27887 for ; Wed, 18 Sep 1996 14:23:02 -0400 Received: from Microsoft Mail (PU Serial #1121) by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Sep18.141000.1121.46736; Wed, 18 Sep 1996 14:21:38 -0400 From: Roy Pereira To: 'IPSEC' Message-Id: <1996Sep18.141000.1121.46736@tsntsrv1.timestep.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: TimeStep Corporation Date: Wed, 18 Sep 1996 14:21:38 -0400 Subject: RE: Concerns Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> This is not what I saw. I saw only a handful voting for SKIP, a few >> more for ISAKMP/Oakley, and the vast majority with their hands down. >This is remarkable, since there wasn't a vote on SKIP vs. ISAKMP >at the Montreal meeting. A quick way to solve this small (and irrelevant) discussion is to have an online vote by having everyone email one person with an answer to the following question: Pick one: a) SKIP b) ISAKMP/OAKLEY c) Don't care Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Wed, 18 Sep 1996 11:33:52 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: ipsec-approval@neptune.tis.com Message-ID: <9609181440.aa23915@neptune.TIS.COM> Paul, The revised minutes still do not describe the presentations and followup discussions which took place at the Montreal meeting. Rather, they appear to draw on recent discussions on the ipsec mailing list to introduce an anti-SKIP bias. > The second mode uses ephemeral Diffie-Hellman, > with certificates, in a 2-6 message exchange depending on how much state > already exists in the end nodes (specifically: 2 messages for Certificate > Discovery Protocol, 2 messages for Algorithm Discovery Protocol, plus 2 > messages for PFS before the first data packet can be sent) This is editorializing. If you insist on counting one-time messages, then the next time someone says that an SNMP trap is a one message protocol, please be sure to point out that it's actually a 5 message protocol, "depending on how much state already exists in the end nodes": 1 for the trap, 2 for the DNS lookup, and 2 for the ARP request-response. > (though SKIP's PFS is different from others in that it does not > provide PFS for identities), This is more editorializing. PFS and anonymity are orthogonal issues. A protocol may provide PFS with no anonymity, or anonymity with no PFS. This also ignores the issue that SKIP PFS provides anonymity protection against man-in-the- middle attacks. This is a tradeoff which you are ignoring in your slanted commentary. > and has significant per-message overhead. This is more anti-SKIP editorializing. There has been substantial discussion on the mailing list regarding protocol overhead. Simply taking the opinion of the anti-SKIP camp and passing this off as "minutes" reeks of unfairness. Other have told us in private that they were amazed at the anti-SKIP bias in the meeting minutes. Some of these comments even came from ISAKMP/Oakley advocates. > (though the > SKIP multicast proposal explicitly does not specify how the group owner is > determined nor how knowledge of the group owner's identity is communicated > scalably and authentically to the members of the group nor how the group key > is created). We welcome any criticism you might have on our multicast draft. If there are points which can be made more clear, we'll be happy to do this. But the meeting minutes is not an appropriate forum for editorializing by the chairs. > [ISAKMP] is available via MIT server. Again, we also have free software which is available and the URL was mentioned at the meeting. It is too much to ask that the minutes accurately and fairly record what took place at the meeting? --tom Received: from relay.hq.tis.com by neptune.TIS.COM id aa26587; 18 Sep 96 17:37 EDT Received: by relay.hq.tis.com; id RAA19067; Wed, 18 Sep 1996 17:41:02 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma019059; Wed, 18 Sep 96 17:40:34 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25131; Wed, 18 Sep 96 17:39:46 EDT Received: by relay.hq.tis.com; id RAA19055; Wed, 18 Sep 1996 17:40:32 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma019051; Wed, 18 Sep 96 17:40:07 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id OAA31454; Wed, 18 Sep 1996 14:42:23 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA22075; Wed, 18 Sep 1996 14:42:06 -0700 Message-Id: <9609182142.AA22075@maildig1.us.oracle.com> Date: 18 Sep 96 14:41:58 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: RE: Concerns Cc: rpereira@timestep.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 18-Sep-96 11:21 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_25923443_0_11919609181543060" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_25923443_0_11919609181543060 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Please no voting! The IETF does not vote, it runs on rough consensous and running code. Given that most of the work is on a mailing list there is much room for abuse of e-mail votes. Any straw polls (or ballots) now will only ignite additional unproductive debate. A decision is being made by the Security Area Director and will be announced very soon. >Let's all chill out for a day and see what the AD has to say tomorrow. Yes! Regards, Paul A. Lambert co-chair of IPsec ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_25923443_0_11919609181543060 Content-Type:message/rfc822 Date: 18 Sep 96 11:21:38 From:"Roy Pereira " To: IPSEC , Subject:RE: Concerns X-Mailer:Microsoft Mail via PostalUnion/SMTP for Windows NT Organization:TimeStep Corporation Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >> This is not what I saw. I saw only a handful voting for SKIP, a few >> more for ISAKMP/Oakley, and the vast majority with their hands down. >This is remarkable, since there wasn't a vote on SKIP vs. ISAKMP >at the Montreal meeting. A quick way to solve this small (and irrelevant) discussion is to have an online vote by having everyone email one person with an answer to the following question: Pick one: a) SKIP b) ISAKMP/OAKLEY c) Don't care --=_ORCL_25923443_0_11919609181543060-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa26926; 18 Sep 96 17:52 EDT Received: by relay.hq.tis.com; id RAA18134; Wed, 18 Sep 1996 17:10:25 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018122; Wed, 18 Sep 96 17:09:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23792; Wed, 18 Sep 96 17:09:09 EDT Received: by relay.hq.tis.com; id RAA18111; Wed, 18 Sep 1996 17:09:55 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma018092; Wed, 18 Sep 96 17:09:25 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id RAA03066; Wed, 18 Sep 1996 17:11:44 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma002893; Wed Sep 18 17:11:05 1996 Received: from tsntsrv1.timestep.com ([192.168.219.190]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id RAA03810; Wed, 18 Sep 1996 17:11:02 -0400 Received: from Microsoft Mail (PU Serial #1121) by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Sep18.165500.1121.46786; Wed, 18 Sep 1996 17:09:38 -0400 From: Roy Pereira To: Lewis McCarthy , 'IPSEC' Message-Id: <1996Sep18.165500.1121.46786@tsntsrv1.timestep.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: TimeStep Corporation Date: Wed, 18 Sep 1996 17:09:38 -0400 Subject: RE: Concerns Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> A quick way to solve this small (and irrelevant) discussion is to have an >> online vote by having everyone email one person with an answer to the >> following question: >Are you volunteering ? :) It would be best if we had an impartial, responsible and trustworthy person to keep track of the vote, like perhaps tke mailing list admin, so there wouldn't be any dispute over the vote results. >> Pick one: >> >> b) ISAKMP/OAKLEY ~~~~~~~~~~~~~ >(No Photuris ?) Of course, we could include any number of KMPs, but ISAKMP and SKIP seem to be the most popular at this time. Received: from relay.hq.tis.com by neptune.TIS.COM id aa28161; 18 Sep 96 19:01 EDT Received: by relay.hq.tis.com; id TAA20441; Wed, 18 Sep 1996 19:04:32 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020438; Wed, 18 Sep 96 19:04:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28368; Wed, 18 Sep 96 19:03:20 EDT Received: by relay.hq.tis.com; id TAA20423; Wed, 18 Sep 1996 19:04:05 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma020401; Wed, 18 Sep 96 19:03:34 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id QAA28234; Wed, 18 Sep 1996 16:03:59 -0700 Received: from monster.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id QAA20845; Wed, 18 Sep 1996 16:06:09 -0700 Received: by monster.incog.com (SMI-8.6/SMI-SVR4) id QAA27262; Wed, 18 Sep 1996 16:05:56 -0700 Date: Wed, 18 Sep 1996 16:05:56 -0700 From: Ashar Aziz Message-Id: <199609182305.QAA27262@monster.incog.com> To: karn@qualcomm.com Subject: Re: SKIP Design & Applicability Statement Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk [Phil Karn wrote:] >> There is one (important) aspect in which PFS offers a better defense than a >> non-PFS solution. Namely, if the key-compromise is discovered, the keys may >> be revoked, thereby protecting against future impersonation attacks and >> still preserving the secrecy of past encrypted data. > > Key compromises don't have to be "discoverable" to make PFS > worthwhile. The PFS "crank" can be "turned" on a regular basis > according to local policy just as symmetric keys are periodically > refreshed. This limits the amount of data that can be compromised at > once to that sent after the last PFS rekey. Phil, That quote of mine is taken from a section that was describing issues related to servers that contain long-term data. Yes, in general PFS provides defense against non-discovered key compromises. However, in case of servers that store long-term data, there are two sources of the original plaintext. One is the recorded ciphertext (with capture of the associated traffic key) and the second is the stored plaintext data on the server's disk. For example, let's say that the PFS channel transmitted mail messages from a mail server, which stay stored on the server's disk. A few months later, your long-term key is compromised. Of course, the recorded cipher-text is no longer a fruitful source of the plaintext, given the PFS channel and destruction of the associated traffic keys. However, the long-term key compromise allows an attacker to impersonate you, connect to the mail server, and recover the plaintext from the original source of the plaintext; namely your mail folder on the server. If the key-compromise is undiscovered, nothing prevents the attacker from using this second source of plaintext, and this is the case I was pointing out as the distinction between discovered and non-discovered key compromise. If the data transmitted on the channel is ephemeral data, e.g. audio/video conferencing etc., then this kind of attack wouldn't work. But from a server perspective, this is an important distinction. Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa29465; 18 Sep 96 20:41 EDT Received: by relay.hq.tis.com; id UAA21466; Wed, 18 Sep 1996 20:45:02 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021459; Wed, 18 Sep 96 20:44:34 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00547; Wed, 18 Sep 96 20:43:46 EDT Received: by relay.hq.tis.com; id UAA21456; Wed, 18 Sep 1996 20:44:32 -0400 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1) id xma021454; Wed, 18 Sep 96 20:44:25 -0400 Received: by mercury.Sun.COM (Sun.COM) id RAA15480; Wed, 18 Sep 1996 17:46:49 -0700 Received: from iplaw.Corp.Sun.COM by Corp.Sun.COM (5.x/SMI-5.3) id AA27556; Wed, 18 Sep 1996 17:46:46 -0700 Received: by iplaw.Corp.Sun.COM (SMI-8.6/SMI-SVR4) id RAA10525; Wed, 18 Sep 1996 17:47:14 -0700 Date: Wed, 18 Sep 1996 17:47:14 -0700 From: Tim Crean Message-Id: <199609190047.RAA10525@iplaw.Corp.Sun.COM> To: ipsec@TIS.COM Subject: Request For Prior Art For U.S. Patent Number 5,548,646 X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk There have been recent Internet discussions relating to U.S. Patent No. 5,548,646 (the '646 patent) assigned to Sun Microsystems, Inc. ("Sun"). In particular, there have been suggestions that there is prior art that would bring into question the validity of the claims of the '646 patent. Sun strongly believes in obtaining and maintaining only those patent rights that are proper in light of any prior art that may exist. Sun does not have any interest in enforcing any patent claims having a scope beyond that to which it is properly and legally entitled. In keeping with this approach, if anyone is aware of prior art relevant to the '646 patent, please send information about the prior art to Sun in care of: Sun Patent Department 2550 Garcia Avenue, MS-UPAL01-521 Mountain View, CA 94043-1100 If any prior art turns up that is more relevant than the art that was before the Patent Office during prosecution of the '646 patent, Sun will take the appropriate steps to bring that art before the Patent Office so that the Patent Office can reconsider the claims of the '646 patent in light of the new art. The Patent Office considered two patent documents during prosecution of the '646 patent: U.S. Patent No. 5,416,842 and U.S. Patent No. 5,204,961. Sun suggests that those interested in this issue should first obtain and review both the '842 patent and the '961 patent before submitting additional art to Sun. Uncertified copies of patents can be obtained from the U.S. Patent and Trademark Office in Washington, D.C. by contacting USPTO Copy Sales at: Internet Site... http://www.uspto.gov/web/uspto/patsales/patsales.html Telephone Number...703-305-8716 Facsimile Number...703-305-8759 Mailing Address ...Commissioner Of Patents And Trademarks U.S. Patent and Trademark Office Box 9 Washington, D.C. 20231 Sincerely, Sun Microsystems, Inc. Received: from relay.hq.tis.com by neptune.TIS.COM id aa29894; 18 Sep 96 21:21 EDT Received: by relay.hq.tis.com; id VAA22161; Wed, 18 Sep 1996 21:24:49 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022158; Wed, 18 Sep 96 21:24:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02538; Wed, 18 Sep 96 21:23:34 EDT Received: by relay.hq.tis.com; id VAA22148; Wed, 18 Sep 1996 21:24:20 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma022140; Wed, 18 Sep 96 21:24:15 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id SAA15727; Wed, 18 Sep 1996 18:24:08 -0700 (PDT) Date: Wed, 18 Sep 1996 18:24:08 -0700 (PDT) From: Phil Karn Message-Id: <199609190124.SAA15727@servo.qualcomm.com> To: ashar@osmosys.incog.com Cc: ipsec@TIS.COM In-Reply-To: <199609182305.QAA27262@monster.incog.com> (ashar@osmosys.incog.com) Subject: Re: SKIP Design & Applicability Statement Sender: ipsec-approval@neptune.tis.com Precedence: bulk >If the key-compromise is undiscovered, nothing prevents the >attacker from using this second source of plaintext, and >this is the case I was pointing out as the distinction >between discovered and non-discovered key compromise. Points well taken. Of course, having to use a stolen key to log into a machine to retrieve plaintext carries a far greater risk of detection than using a stolen key to decrypt some surreptitiously intercepted ciphertext. I'm sure that NSA, for example, is far more likely to do the latter than the former. :-) Phil To: "PALAMBER.US.ORACLE.COM" , ipsec@TIS.COM To: jis@mit.edu, gnu@toad.com To: iesg@ietf.org Subject: IPSEC WG chairs unresponsive, disruptive, and biased In-Reply-To: <199609162035.NAA06638@mailsun2.us.oracle.com> Date: Wed, 18 Sep 1996 17:01:10 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609190719.aa05577@neptune.TIS.COM> I too submitted revisions to the draft Montreal minutes, to provide a web pointer for my "rapid IPSEC deployment" proposal, and to record what specific questions were asked by Jeff Schiller at the end of the "key managment" meeting, and what the rough votes in response were. None of these revisions were reflected in the minutes posted this week by the co-chairs. I have heard complaints from a wide variety of people about the conduct of the IP Security working group co-chairs. A certain amount of it I could attribute to general grousing. But I continue to see examples of how the co-chairs act to disrupt and skew, rather than to foster, the process of reaching rough consensus. I will refrain from speculation on whether this is intentional on their part, or whether they are merely not suited to the task of managing a complex and contentious working group. I would welcome input from the Working Group and from IESG members on how to handle this situation. I think it has been swept under the rug for far too long. IESG readers may not have seen Ashar Asiz's recent messages regarding how the coverage of his SKIP proposal in the minutes has been highly biased for the last two working group meetings. I'll be glad to forward them to interested parties, or they can be found in this week's ipsec@tis.com mailing list archives. Here is an excerpt: > Also, when there are competing proposals, I believe some > consideration should be given to fairness in the way the various > proposals are described. I refer specifically to the use of > adjectives such as "significant overhead", "hard to implement > and scale" and "claimed" support of multicast when describing > SKIP. By contrast, adjectives used for ISAKMP/Oakley are > "very general", "very flexible", etc. In my particular case, the minutes report that Jeff's straw polls "showed significant differences of opinion between Oakley/ISAKMP and SKIP", when in fact, as Jeff had told me in advance, he had deliberately structured his questions to avoid doing straw-polls on particular algorithms. Here's the minutes coverage, followed by my unaccepted revisions to the minutes. Jeff should have notes that confirm which description is more complete and more accurate. > Closing discussions were process oriented, i.e., how will the WG decide > what will become the default key management standard for IPSEC ? Jeff > Schiller conducted straw polls which showed significant differences of > opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick > resolution to the issue! Jeff suggests having a special committee come back > with a justifiable resolution. Message-Id: <199608060655.XAA10933@toad.com> To: "PALAMBER.US.ORACLE.COM" cc: ipsec@TIS.COM, gnu Subject: Re: IPsec Minutes from Montreal In-reply-to: <199608052345.QAA16081@mailsun2.us.oracle.com> Date: Mon, 05 Aug 1996 23:55:26 -0700 From: John Gilmore Some minutes additions from my own notes: Details on my presentation on rapid deployment of IPSEC in the first meeting are available at http://www.cygnus.com/~gnu/swan.html. Jeff Schiller's closing discussions in the second meeting included these "straw poll" questions, with my rough estimations of the audience reaction. He said he deliberately structured the questions to avoid a straw-poll on particular algorithms, but instead focused on our goals or process. Should we let the marketplace decide on a key managment standard, or should we pick one and move forward? Marketplace - 2/5 Pick one - 3/5 Should we favor generality, or simplicity? Generality - 2/5 Simplicity - 3/5 Do we have to have a plan by the next IETF? On this we have consensus -- YES. Should Jeff grab a few of the WG people who are known not to be committed to any proposal, and together decide? Strong consensus that this was not the way to go. This was when he suggested convening a small group, largely composed of the authors/proponents of existing proposals, to try to hammer out a compromise proposal. He also said that if this group didn't come up with anything by September, Jeff would personally choose one as the standard, though he did not want to be forced to do that. John To: John Lawler Cc: ipsec@TIS.COM, Bill Sommerfeld , gnu@toad.com Subject: The WG's inability to choose is good in this case. In-Reply-To: <2.2.32.19960917233303.00685998@best.com> Date: Wed, 18 Sep 1996 18:21:43 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609190719.aa05593@neptune.TIS.COM> > My point is that if we are still at this stage of the game at this late > date, then something is seriously wrong with the process. Someone else suggested something similar to me: that the WG was seriously stuck and that nobody had the guts to fix it. My insight was that the WG is having a largely correct response to the set of technical proposals placed in front of it. We, the working group, are showing good sense, actually. It's not a guts issue. If we had a credible alternative we'd head toward it like lemmings. The problem is that none of the alternatives is credible. Each has strengths and weaknesses; each has problems; none solves the entire problem we're trying to solve. We are stuck for a good reason; we don't want to make a good political decision. We want to make a good technical decision, and there is no good technical choice for securing the Internet right now. The IPSEC process is working. It looks too slow because the technical proposals and implementations need to evolve faster than they have been, not because the consensus process has failed. John Received: from relay.hq.tis.com by neptune.TIS.COM id aa08114; 19 Sep 96 11:26 EDT Received: by relay.hq.tis.com; id LAA07358; Thu, 19 Sep 1996 11:30:21 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma007345; Thu, 19 Sep 96 11:29:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24898; Thu, 19 Sep 96 11:29:03 EDT Received: by relay.hq.tis.com; id LAA07338; Thu, 19 Sep 1996 11:29:50 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma007330; Thu, 19 Sep 96 11:29:45 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA16665; Thu, 19 Sep 1996 11:32:36 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id LAA567568; Thu, 19 Sep 1996 11:32:06 -0400 Message-Id: <199609191532.LAA567568@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8048; Thu, 19 Sep 96 11:31:49 EDT Date: Thu, 19 Sep 96 10:29:34 EDT To: ipsec@TIS.COM Cc: gnu@toad.com, jlawler@vpnet.com Subject: The WG's inability to choose is good in this case. Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Gilmore says: > We are stuck for a good reason; we don't want to make a good political > decision. We want to make a good technical decision, and there is no > good technical choice for securing the Internet right now. The IPSEC > process is working. It looks too slow because the technical proposals > and implementations need to evolve faster than they have been, not > because the consensus process has failed. > There is NO strong technical reason that impedes the convergence of ISAKMP, Oakley and SKIP. There is nothing essentially contradictory between these protocols. Technically, they can be merged at not much cost. (Of course, the resultant protocol will not be as simple as the basic SKIP, but the latter is in any case not an IPSEC-acceptable stand-alone solution as it does not provide PFS). Therefore, I conclude, the difficulties in finding a common ground are purely political. In order to accomodate SKIP functionality into Oakley there are two issues to decide on: (1) Support of DH-certificates (2) Support of in-line keying These two issues are mostly independent (ie, the decision on one does not depend on the other). Support for (2) can be added to Oakley with no implication to the rest of the protocol (some issues are: (a) mandatory-vs-optional to implement, (b) separate header for carrrying the packet key or combined into the existing ESP and AH transforms, (c) SPI allocation) Support for (1), especially if mandatory, is more delicate. It would mean that each IPSEC-compliant host will need a DH certificate. (As opposed to, say, an RSA or DSS certificate). It means also that we'll need to define a universal DH group (e.g. prime p and generator g) on which to work. I am personally not enthusiastic about the latter but was (and am) willing to accept it in order to resolve the WG deadlock. In particular, I have suggested particular ways to accomodate DH-certificates for key derivation in Oakley (actually this is part of my suggestions in my SKEME proposal from a year ago). One personal clarification regarding (2): in my opinion, there is a strong technical basis to require key exchange/refreshment via authenticated handshakes as supported by Oakley (even if in-line keying is also supported by the protocol). And I believe (hope) that SUN (in particular, Ashar) would not oppose that. Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa08852; 19 Sep 96 12:25 EDT Received: by relay.hq.tis.com; id MAA08983; Thu, 19 Sep 1996 12:29:16 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008977; Thu, 19 Sep 96 12:28:49 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28147; Thu, 19 Sep 96 12:28:00 EDT Received: by relay.hq.tis.com; id MAA08969; Thu, 19 Sep 1996 12:28:46 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma008945; Thu, 19 Sep 96 12:28:24 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 19 Sep 1996 12:30:30 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA00380 for ; Thu, 19 Sep 1996 12:30:29 -0400 Message-Id: <199609191630.MAA00380@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: ipsec@TIS.COM Subject: resistance to swamping attacks. Date: Thu, 19 Sep 1996 12:30:27 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk at the last IETF meeting, there was a presentation about how cookies don't necessarily help all that much. There have been a number of press reports about swamping attacks on TCP using forged source addresses. Some of these press reports have suggested that IPv6 will solve all this by requiring authentication. I'd like this to be the truth, not just optimism.. I think that one of the not-well-stated requirements of ipsec is that it resist such attacks -- most importantly, that a system be able to continue to communicate with legitimate peers in the face of a packet-storm, including peers it did not have any shared state with prior to the start of the storm. Here's a more specific goal: If a system has a normal communications bandwidth of X, and recieves an incoming storm from forged source addresses with a bandwidth of Y (less than X), it should be able to continue to use at least half of the remaining bandwith (X-Y) constructively to communicate with arbitrary legitimate peers, including peers which had never before communicated with it. Now, at some level, this is a property of the implementation, but nothing in the *protocol* should preclude this. Any objections? - Bill To: Roy Pereira Cc: Lewis McCarthy , 'IPSEC' Subject: Re: Concerns In-Reply-To: Your message of "Wed, 18 Sep 1996 17:09:38 EDT." <1996Sep18.165500.1121.46786@tsntsrv1.timestep.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Sep 1996 12:11:40 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609191242.aa09079@neptune.TIS.COM> Need I point out, folks, that this is the IETF? We do not vote. .pm Roy Pereira writes: > > >> A quick way to solve this small (and irrelevant) discussion is to have > an > >> online vote by having everyone email one person with an answer to the > >> following question: > > >Are you volunteering ? :) > > It would be best if we had an impartial, responsible and trustworthy > person to keep track of the vote, like perhaps tke mailing list admin, so > there wouldn't be any dispute over the vote results. > > >> Pick one: > >> > >> b) ISAKMP/OAKLEY > ~~~~~~~~~~~~~ > > >(No Photuris ?) > > Of course, we could include any number of KMPs, but ISAKMP and SKIP seem > to be the most popular at this time. > > > Received: from relay.hq.tis.com by neptune.TIS.COM id aa11387; 19 Sep 96 16:20 EDT Received: by relay.hq.tis.com; id QAA17783; Thu, 19 Sep 1996 16:24:11 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017762; Thu, 19 Sep 96 16:23:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13008; Thu, 19 Sep 96 16:22:53 EDT Received: by relay.hq.tis.com; id QAA17759; Thu, 19 Sep 1996 16:23:40 -0400 Received: from xenon.chromatic.com(199.5.224.1) by relay.tis.com via smap (V3.1.1) id xma017742; Thu, 19 Sep 96 16:23:14 -0400 Received: from server1.chromatic.com (server1.chromatic.com [199.5.224.120]) by xenon.chromatic.com (8.7.5/8.7.3) with ESMTP id NAA12406; Thu, 19 Sep 1996 13:25:33 -0700 (PDT) Received: from localhost (hua@localhost) by server1.chromatic.com (8.7.5/8.7.3) with SMTP id NAA00316; Thu, 19 Sep 1996 13:25:04 -0700 (PDT) Message-Id: <199609192025.NAA00316@server1.chromatic.com> X-Authentication-Warning: server1.chromatic.com: hua owned process doing -bs X-Authentication-Warning: server1.chromatic.com: Host hua@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.8 8/21/96 To: ipsec@TIS.COM Cc: srctran@world.std.com, hua@chromatic.com Subject: Re: Be careful - Sun Microsystems asks for prior art for '646 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 1996 13:25:03 -0700 From: Ernest Hua Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hmm ... a good point (from Greg below) ... anyone care to comment? Ern ------- Forwarded Message Date: Thu, 19 Sep 1996 15:50:04 -0400 From: srctran@world.std.com (Gregory Aharonian) To: patent-news@world.std.com Subject: PATNEWS: Be careful - Sun Microsystems asks for prior art for '646 !19960919 Be careful - Sun Microsystems asks for prior art for '646 A short while ago I sent out a news item reporting that some people in the encryption community were accusing Sun of doing a Dell - that is, applying for patents on technology discussed/developed by a standards committee. Sun is denying that it did so, to the extent that they posted the following message on some of the Internet discussion groups: ==================== There have been recent Internet discussions relating to U.S. Patent No. 5,548,646 (the '646 patent) assigned to Sun Microsystems, Inc. ("Sun"). In particular, there have been suggestions that there is prior art that would bring into question the validity of the claims of the '646 patent. Sun strongly believes in obtaining and maintaining only those patent rights that are proper in light of any prior art that may exist. Sun does not have any interest in enforcing any patent claims having a scope beyond that to which it is properly and legally entitled. In keeping with this approach, if anyone is aware of prior art relevant to the '646 patent, please send information about the prior art to Sun in care of: Sun Patent Department 2550 Garcia Avenue, MS-UPAL01-521 Mountain View, CA 94043-1100 If any prior art turns up that is more relevant than the art that was before the Patent Office during prosecution of the '646 patent, Sun will take the appropriate steps to bring that art before the Patent Office so that the Patent Office can reconsider the claims of the '646 patent in light of the new art. The Patent Office considered two patent documents during prosecution of the '646 patent: U.S. Patent No. 5,416,842 and U.S. Patent No. 5,204,961. Sun suggests that those interested in this issue should first obtain and review both the '842 patent and the '961 patent before submitting additional art to Sun. Sincerely, Sun Microsystems, Inc. ==================== This is a nice publicity stunt by Sun, and I say stunt, because Sun is not as serious about prior art as it states in this message, ".... in light of any prior art that exists". It is as serious as most others in the industry, which is to say, not that serious. Indeed the tone of the above request reflects the typical attitude that prior art means patent prior art. In my database of software patents, I pulled out about 25 software patents awarded to Sun in the 1995/1996 time period. On the average, each patent cited on the front page 3 non-patent prior art items, half of which cited 0 or 1 non-patent prior art items (for example, 5,379,426 - "Method and apparatus for object oriented interprocess message switching"). This record doesn't reflect a real serious commitment by a company with a lot of money to find much of the relevant prior art. Maybe Sun doesn't know that Stanford University has libraries. Sun's request is also disingenous for another reason. The Sun lawyers know that no potential infringer trusts the current third party reexamination system, where only the PTO examiner and Sun lawyers would be present to discuss the newly revealed prior art. It is the same reason few heeded the PTO's call to submit prior art for the Compton's patent - they wanted to save the good stuff for any future court action where they could participate. So if in fact you have any good killer prior art, you might want to consider saving it for any future court actions, where you control how it is used, not Sun's lawyers. Know that you have no say in the discussions between the PTO and Sun during the reexamination - know that Sun's lawyers know this. Greg Aharonian Internet Patent News Service ------- End of Forwarded Message Date: Thu, 19 Sep 1996 13:51:59 -0400 Message-Id: <9609191751.AA18970@dcl.MIT.EDU> From: "Theodore Y. Ts'o" Cc: ipsec@TIS.COM In-Reply-To: ipsec-approval@neptune.hq.tis.com's message of Wed, 18 Sep 1996 11:33:52 -0700 (PDT), <9609181440.aa23915@neptune.TIS.COM> Subject: Re: IPsec Minutes from Montreal Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Wed, 18 Sep 1996 11:33:52 -0700 (PDT) From: ipsec-approval@neptune.hq.tis.com Really-from: I'm not sure, since the ipsec list seems mildly broken, but the message was signed "--tom" > The second mode uses ephemeral Diffie-Hellman, > with certificates, in a 2-6 message exchange depending on how much state > already exists in the end nodes (specifically: 2 messages for Certificate > Discovery Protocol, 2 messages for Algorithm Discovery Protocol, plus 2 > messages for PFS before the first data packet can be sent) This is editorializing. If you insist on counting one-time messages, then the next time someone says that an SNMP trap is a one message protocol, please be sure to point out that it's actually a 5 message protocol, "depending on how much state already exists in the end nodes": 1 for the trap, 2 for the DNS lookup, and 2 for the ARP request-response. Actually, no, this is the key part of the difference between SKIP and ISAKMP. A large part of the dispute centers around how one does the "counting" of packets. So saying "2-6 messages" is in fact quite fair. The ISAKMP partisans are claiming that it's not fair to say that SKIP only takes 2 messages, because using the requirements set up by the wg, it's not clear that you can always skip these "one-time" messages. According to this camp, Sun has traditionally architected solutions which work well for the small LAN case (remember NFS and 8192 byte packets, with checksumming turned OFF?) that didn't necessarily work well in the Real World Internet. Hence, if you are going to be talking to a lot of different sites, it's not clear that you can *always* cache the all of the certificates, results of the algorithm negotiation, etc. What's the cache hit ratio? How big do you let your caches grow to? etc. In addition, if CDP and ADP are optional and not implemented by all implementations, then you have really large interoperability problems, which may not surface on the a small work-group sized LAN, but do on the greater Internet. It is too much to ask that the minutes accurately and fairly record what took place at the meeting? Well, the problem is that any time the minutes say anything good or bad about either protocol, people are going to claim that the minutes aren't "fair". According to the ISAKMP camp, saying that SKIP "only" takes 2 messages is a skewed, slanted view. So, it works both ways. Unfortunately. - Ted To: John Gilmore Cc: ipsec@TIS.COM Subject: Re: The WG's inability to choose is good in this case. In-Reply-To: Your message of "Wed, 18 Sep 1996 18:21:43 PDT." <9609190719.aa05593@neptune.TIS.COM> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Sep 1996 14:20:31 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609191635.aa11629@neptune.TIS.COM> I believe John has put his finger on something important. John Gilmore writes: > We are stuck for a good reason; we don't want to make a good political > decision. We want to make a good technical decision, and there is no > good technical choice for securing the Internet right now. The IPSEC > process is working. It looks too slow because the technical proposals > and implementations need to evolve faster than they have been, not > because the consensus process has failed. I tend to agree. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa12589; 19 Sep 96 17:49 EDT Received: by relay.hq.tis.com; id RAA20234; Thu, 19 Sep 1996 17:53:11 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020223; Thu, 19 Sep 96 17:52:43 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16844; Thu, 19 Sep 96 17:51:54 EDT Received: by relay.hq.tis.com; id RAA20218; Thu, 19 Sep 1996 17:52:41 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma020214; Thu, 19 Sep 96 17:52:37 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id OAA23998; Thu, 19 Sep 1996 14:54:58 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA06801; Thu, 19 Sep 1996 14:54:33 -0700 Message-Id: <9609192154.AA06801@maildig1.us.oracle.com> Date: 19 Sep 96 14:52:25 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: SKIP Design & Applicability Statement X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 16-Sep-96 08:46 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_26009646_0_11919609191555330" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_26009646_0_11919609191555330 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Rich, I apologize for my objections to your posting. I became a little too irritable when you used my name directly as the reason for the posting. I'll share half the blame for any confusion on this issue. If statements were to be posted, to be fair I would have asked representatives from each of the factions to post positions. It is now too late for position papers. >Received: SEPTEMBER 16, 1996 10:47 >From: Rich Skrenta >I was quite frankly amazed when you characterized Ashar's technical >and rather dry applicability statement as "marketing material". Rich, please reread my note, it said "misconstrued as marketing material". >Paul >> While I do understand Sun's investment in SKIP, please be cautious in the >> posting of material that might be misconstrued as marketing material. There were complaints made to me on the posting of the "applicability statement". The complaints were based largely on the timing of this re-posting. While technical information on the three key management proposals may be interesting to new members of this mailing list, we are now in a very sensitive period. The decisions on SKIP versus Photuris versus ISAKMP/Oakley are now being made by the Security Area Director and the "secdir". Please note that there have not been postings of the "benefits" of ISAKMP and Photuris. We need to stop beating the drums on our favorite acronym (Photuris, ISAKMP, Oakley, SKIP) and move on as a working group. >> Perhaps, but so many postings on the "benefits" of a proposal could appear >> self serving. > >Why is "benefits" in quotes? The group has been polarized on the comparison of very different proposal bundles. The benefits for one person are not the same as another. I hold to my opinion that numerous postings from any single individual on a single subject detracts from the effectiveness of the e-mail based working group. I do complement the many members who succulently express their opinions (like Phil Karn or Dave Wheeler) and hope that our working group as a whole will learn to communicate more effectively. I consider it self serving when an individual continues to blast a working group with opinions that are already well known. >I am rather upset at being censured in this way by one of the co-chairs. Your one posting was slightly out of line. As co-chair, it is my job to attempt to direct the discussions on this list. I should attempt to pound my virtual gavel more often. >I feel I have acted in good faith to respond to technical discussions on >this list. It does not seem fair that others may point out negatives in >SKIP, but we are admonished when we respond to these points. I only admonished your single posting of old material. When you say "we" it seems that you must be making these complaints and postings in collaboration with others. I hope this not the case (I don't subscribe to alt.conspiracy). The single objection that I made was to you and has no relation to others on the list or any technical ideas or proposal that you are advocating. We need to lower the level of rhetoric on this mailing list. Please relax and wait for the for the Area Directors position document. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_26009646_0_11919609191555330 Content-Type:message/rfc822 Date: 16 Sep 96 08:46:39 From:"Rich Skrenta " To:ipsec@tis.com Subject:Re: SKIP Design & Applicability Statement In-Reply-To:<199609130533.WAA10380@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Sep 12, 96 10:28:15 pm X-Mailer:ELM [version 2.4 PL24 PGP5] Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" [ I'm having problems receiving ipsec at incog.com, so I'm posting this from another account -- rjs ] Paul, I'm sorry you haven't found value in my recent contributions to the discussion on IPsec. I've done my best to keep my replies focused on technical issues, and to avoid as much as possible getting sucked into personal exchanges or unnecessarily replying to messages. Indeed, the quote of mine you selected was taken from a post which included a response from me to John Gilmore's issue about CDP endpoints. This sort of discussion seems entirely appropriate to this forum. I was quite frankly amazed when you characterized Ashar's technical and rather dry applicability statement as "marketing material". I'm certain that if I actually posted anything with the slightest whiff of real marketing hype to this list, my mailbox would quickly be consumed with flames. But indeed, in the week since I sent that message, I haven't received a single personal reply (other than yours), and the only list reply was a response from Phil Karn regarding a technical point about PFS. > Perhaps, but so many postings on the "benefits" of a proposal could appear > self serving. Why is "benefits" in quotes? I am rather upset at being censured in this way by one of the co-chairs. I feel I have acted in good faith to respond to technical discussions on this list. It does not seem fair that others may point out negatives in SKIP, but we are admonished when we respond to these points. This only adds to our concerns about the openness and impartiality of this process. > Your many postings to this list may not be helping to advocate SKIP. For the record, over the past 14 days I have been responsible for 9 of the 116 messages to ipsec. This includes my posting of Ashar's applicability statement. This puts me in third place; Bob Moskowitz and Perry Metzger tied for first, with 10 posts each. --=_ORCL_26009646_0_11919609191555330-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa13371; 19 Sep 96 18:46 EDT Received: by relay.hq.tis.com; id SAA21264; Thu, 19 Sep 1996 18:49:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021252; Thu, 19 Sep 96 18:49:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18100; Thu, 19 Sep 96 18:48:23 EDT Received: by relay.hq.tis.com; id SAA21249; Thu, 19 Sep 1996 18:49:11 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma021247; Thu, 19 Sep 96 18:48:56 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id PAA26683; Thu, 19 Sep 1996 15:51:14 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id PAA08750; Thu, 19 Sep 1996 15:55:21 -0700 Message-Id: <199609192255.PAA08750@mailsun2.us.oracle.com> Date: 19 Sep 96 14:54:06 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: Concerns X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 16-Sep-96 16:38 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_7730941_0_11919609191656190" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_7730941_0_11919609191656190 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" John, >1) Paul, your remarks to Rich Skrenta were inappropriate. Please see my earlier note to Rich. We are in a delicate period where a decision is being made and the working group cannot afford to bicker. Applicability statements are not useful this week since the working group has not reached consensus. A decision will be mandated. >4) I am extremely concerned that we seem to have started >yet another round of "let's reexamine what we're trying to do here." No. It is too late. A decision is being made and will be posted very soon by Jeff Schiller. To the group as a whole - please lighten up on the rhetoric. The group has been polarized and now needs to move forward in a unified manner. I suggest we call a truce in the key management protocol debate and wait for the IETF decision on this topic. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_7730941_0_11919609191656190 Content-Type:message/rfc822 Date: 16 Sep 96 16:38:47 From:"John Lawler " To:ipsec@tis.com Subject:Concerns X-Sender:jlawler@206.86.0.11 (Unverified) X-Mailer:Windows Eudora Pro Version 2.2 (32) Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" I have been reading and rereading this list's traffic for several days and am becoming increasingly concerned at the way this process is, or more appropriately, isn't working. A few comments: 1) Paul, your remarks to Rich Skrenta were inappropriate. While YOU may not have asked for his "SKIP Summary", other people on this list had. There was nothing "market-ey" about the posting and I believe it was a perfectly reasonable thing to add to the discussion. In fact, I have been waiting for a similar docuement from the ISAKMP group. 2) Paul, you made a comment (uncalled for, I believe) about Sun's intransigence over SKIP. I must say thay I have not found the ISAKMP supporters to be any less intransigent. In seems very clear to me that pretty much everyone has settled into one camp or another--if there is any intransigence, there seems to be more than enough blame to go around on BOTH sides. 3) I have been subscribed to this list for longer than I can remember, but I still have yet to see a formal list of *agreed upon* characteristics the group is looking for in a key management system. What "lists" do exist seem to be strongly held personal preferences, but I have yet to see a list of criteria developed by and approved through concensus. Some people like in-band keying, some don't. Some people think the world will stop orbiting the sun without PFS, and others don't. Based on that, I do not see how anyone can possibly accuse ANY of the proposals as being either in or out of compliance with a non-existant list of criteria. 4) I am extremely concerned that we seem to have started yet another round of "let's reexamine what we're trying to do here." While a good idea in principle, we keep seem to do this, resulting in a constant moving of the goal posts. It is no wonder that we are having such difficulty reaching concensus! ***** It is rather clear from the recent traffic and from the votes in Montreal that people are split down the middle over SKIP vs ISAKMP. At this point I believe pretty much everyone is talking past each other. Based on this rather deeply entrenched split, I honestly do not believe this issue is going to be resolved now or even in San Jose. Therefore, I will make the same proposal I made in Montreal: Let *BOTH* SKIP and ISAKMP move ahead in the standards process, and let the marketplace decide which is better. If the IETF does not get something out NOW, then the market will come up with something of their own and all of your debating will be moot. I will reiterate the statement I made several weeks ago: WE CAN NO LONGER AFFORD TO DELAY THE GROWTH OF THIS INDUSTRY. People need solutions today, and if they cannot get them through the IETF, they will get them elsewhere. -John Lawler --=_ORCL_7730941_0_11919609191656190-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa14323; 19 Sep 96 20:09 EDT Received: by relay.hq.tis.com; id UAA21972; Thu, 19 Sep 1996 20:13:12 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021967; Thu, 19 Sep 96 20:12:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19608; Thu, 19 Sep 96 20:11:54 EDT Received: by relay.hq.tis.com; id UAA21963; Thu, 19 Sep 1996 20:12:41 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma021961; Thu, 19 Sep 96 20:12:27 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA153248489; Thu, 19 Sep 1996 17:14:50 -0700 Message-Id: <199609200014.AA153248489@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA186618489; Thu, 19 Sep 1996 20:14:49 -0400 To: John Gilmore Cc: ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: gnu's message of Thu, 19 Sep 1996 17:00:04 -0700. <199609200000.RAA28145@toad.com> Date: Thu, 19 Sep 1996 20:14:48 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk Also, your goal assumes a non-interactive attack, that is, that the attacker cannot see any of the outgoing traffic in response to the attack. This is deliberate, though I'm beginning to wonder if it might be a case of "fighting the last war" ... It's a much harder problem if the attacker is positioned on the network so that they can snatch some of the cookies off the ether, and send them back as part of the attack. True. I was attempting to propose an engineering problem, not a PhD dissertation topic.. I think the meta-goal is to require that a swamping attack actually use up enough bandwidth that tracking the flow(s) back to its originator(s) is easy. and also receives ICMP messages resulting from bouncing response packets consuming incoming bandwidth IZ. Assume that the attacker is unable to read any of the response packets. Hmm. I'd rephrase this as "Error packets generated in reply to responses to forged packets should also be considered part of the incoming flooding attack". since different key mgt protocols may well use different ways to return error messages. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa14859; 19 Sep 96 21:01 EDT Received: by relay.hq.tis.com; id VAA22558; Thu, 19 Sep 1996 21:04:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022554; Thu, 19 Sep 96 21:04:13 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20599; Thu, 19 Sep 96 21:03:24 EDT Received: by relay.hq.tis.com; id VAA22549; Thu, 19 Sep 1996 21:04:11 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma022545; Thu, 19 Sep 96 21:04:06 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id SAA23513; Thu, 19 Sep 1996 18:06:27 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA01035; Thu, 19 Sep 1996 17:30:42 -0700 Message-Id: <9609200030.AA01035@maildig1.us.oracle.com> Date: 19 Sep 96 17:29:28 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: IPsec Minutes from Montreal X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 16-Sep-96 16:47 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_26025530_0_11919609191831400" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_26025530_0_11919609191831400 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Ashar: On your complaints: >Paul, if you recall I also complained about the minutes you published >or the Dec '95, San Jose meeting, where you said that "SKIP was >designed to solve a specific multicast problem". That was how you >characterized my presentation, and I thought it a somewhat slanted >view of my presentation and protocol. I complained privately to >you then. That was over a year and a half ago, and I never saw >revised minutes. If it was San Jose then it must have been the Dec. 1994 meeting. : >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.'' This was the first introduction of SKIP to the working group and I am sure that I did not characterize it adequately in the short review in the minutes. Please remember that this meeting had presentations on seven different key management protocols! I do not remember your private complaint, but if you had submitted written comments we might have modified the minutes in 1994. Please, if you have complaints about the minutes call or send me e-mail directly. It also helps to not wait two years to point out changes. > >First, the SKIP PFS exchange requires 2 messages, not 4-6. If we can not count the same it may illustrate why we have difficulty reaching consensous. Please submit more suitable text. If you have additional changes to the version2 of the July 96 minutes please send them to me as direct text replacements and they will be incorporated. If you wish to help further, volunteer to take the notes that we use as the basis for the minutes. Contribute rather than complain. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_26025530_0_11919609191831400 Content-Type:message/rfc822 Date: 16 Sep 96 16:47:47 From:"Ashar Aziz " To:ipsec@tis.com Subject:Re: IPsec Minutes from Montreal X-Mailer:ELM [version 2.4 PL24 PGP5] Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" > and an updated set of minutes reflecting your clarifications have been > prepared (last week actually). No doubt. Paul, if you recall I also complained about the minutes you published for the Dec '95, San Jose meeting, where you said that "SKIP was designed to solve a specific multicast problem". That was how you characterized my presentation, and I thought it a somewhat slanted view of my presentation and protocol. I complained privately to you then. That was over a year and a half ago, and I never saw revised minutes. Now, it is entirely possible that this time revised minutes were going to be published, but you didn't acknowledge receipt of my message, and it's a coincidence that they came out just after I made my comments public. > >First, the SKIP PFS exchange requires 2 messages, not 4-6. > >This is what I presented at the talk, and is present in > >the SKIP PFS I-D. > > It is true that your presentation claimed that SKIP PFS exchange takes 2 > messages. It is also true that other members of the working group claim that > SKIP PFS takes 4 to 6 messages. So depending on who you ask the answer is 2 > to 6 messages. The meeting minutes should reflect what transpired at the meeting. They should not be a place where differences of opinion on the protocols are somehow reconciled. > I am sure that this confusion will be resolved by the working > group, but it is difficult to document in the minutes this type of difference > in opinion. If the difference of opinion is voiced at the meeting, it is fair to mention it. It is unfair to take someone else's views on my protocol, and publish it as "minutes" of my presentation when they don't correspond to my presentation or to what happened at the meeting. Ashar. --=_ORCL_26025530_0_11919609191831400-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa15307; 19 Sep 96 21:45 EDT Received: by relay.hq.tis.com; id VAA22981; Thu, 19 Sep 1996 21:48:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022974; Thu, 19 Sep 96 21:48:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21369; Thu, 19 Sep 96 21:47:25 EDT Received: by relay.hq.tis.com; id VAA22967; Thu, 19 Sep 1996 21:48:12 -0400 Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1.1) id xma022961; Thu, 19 Sep 96 21:47:56 -0400 Received: from picu.morningstar.com by volitans.MorningStar.Com (8.7.1/95070701) id BAA27654; Fri, 20 Sep 1996 01:50:18 GMT Received: by picu.morningstar.com (8.7.5/95031605) id BAA18018; Fri, 20 Sep 1996 01:50:35 GMT Date: Fri, 20 Sep 1996 01:50:35 GMT Message-Id: <199609200150.BAA18018@picu.morningstar.com> From: "Kim L. Toms" To: ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: <199609200014.AA153248489@relay.hp.com> References: <199609200000.RAA28145@toad.com> <199609200014.AA153248489@relay.hp.com> Reply-To: Kim Toms Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm no expert in cryptography, but it seems to me that what is needed is a function which is expensive for the originator of a packet to calculate, but cheap for the receiver to verify. This will make sure that the source of a swamping attack must have a much larger CPU than the receiver. I don't know if there are any such functions, but perhaps the cryptographically sophisticated among us could enlighten? Received: from relay.hq.tis.com by neptune.TIS.COM id aa15801; 19 Sep 96 22:29 EDT Received: by relay.hq.tis.com; id WAA23428; Thu, 19 Sep 1996 22:32:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023425; Thu, 19 Sep 96 22:32:17 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22177; Thu, 19 Sep 96 22:31:24 EDT Received: by relay.hq.tis.com; id WAA23418; Thu, 19 Sep 1996 22:32:11 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma023414; Thu, 19 Sep 96 22:31:49 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id TAA19709; Thu, 19 Sep 1996 19:34:10 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id TAA25805; Thu, 19 Sep 1996 19:38:20 -0700 Message-Id: <199609200238.TAA25805@mailsun2.us.oracle.com> Date: 19 Sep 96 19:33:43 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM, gnu@toad.com Subject: Re: IPSEC WG chairs unresponsive, disruptive, and biased Cc: iesg@ietf.org X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 18-Sep-96 17:01 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_7738095_0_11919609192039210" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_7738095_0_11919609192039210 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" John, >From: John Gilmore >I too submitted revisions to the draft Montreal minutes, .... >... >None of these revisions were reflected in the minutes posted this week >by the co-chairs. After the posting of the last IPsec minutes you posted some "additions": >Date: Mon, 05 Aug 1996 23:55:26 -0700 >From: John Gilmore > >Some minutes additions from my own notes: You never asked that the minutes be modified. It is a pain in the @#$% to get the minutes out. If you have specific contributions please be clear. If you think that the minutes are in error, give specific suggestions for text replacement. The minutes were already in the IETF archive and your "additions" were interpreted by me to be mail list comments and not a specific request to change the already submitted documentation. There is a fairly tight deadline to get the minutes into the IETF. In the future we will post the minutes in draft form to the list for review and approval. >I have heard complaints from a wide variety of people about the >conduct of the IP Security working group co-chairs. So have I, please calm down and address your own concerns rather then spread third party complaints. These other "complaints" were pushed very hard in July and August. Ashar had attempted to remove my co-chair (Ran) for bias through complaints to the IAB. The accusation stated that there must be an unfair bias since his employer had announced a implementation that was not based on SKIP (please excuse my terse summary). This issue was addressed by the IAB and no grounds or evidence for "bias" were found. Speaking as the other co-chair, I can honestly claim to have no bias for any of the proposals in the key management debate. My company currently has no investment in any of the technologies. If I were forced to implement an IPsec key management system today I would select SKIP. As a co-chair I have been careful not to bias the group or push my opinion on the specific proposals being offered. I have also seen no specific bias by my co-chair against the SKIP technology. We both have a responsibility to moderate this groups discussions which does force us to comment on the nature and timing of posting that are inappropriate. We are also in the difficult position of determining consensus. The working group is split in it's views. No bias has created this situation. The frustration with this deadlock obvious. The deadlock is being resolved. Many vendors on this list have invested in key management technologies (SKIP, ISAKMP, Photuris, YAKMP, MKMP, KMP, SAMP, and others). This makes the upcoming decision on direction very sensitive. We need to put aside the posturing and move forward. >But I continue to see >examples of how the co-chairs act to disrupt and skew, rather than to >foster, the process of reaching rough consensus. I will refrain from >speculation on whether this is intentional on their part, or whether >they are merely not suited to the task of managing a complex and >contentious working group. Please John, such general accusations are very unfair. I do admit pounding my "virtual gavel" once in the last month on a posting by Rich Skrenta. If you have specific problems with the working group process or minutes first e-mail or call me (preferred) to work them out. We need to reduce the noise on the mailing list. The issues are better worked out directly then by e-mail broadcast. As for opportunities to "skew" the process, there is very little that I can do to push opinions one way or the other. If there was a way to push the group, we would have consensus now and not be split into factions. This is why we will soon have a decision mandated. >IESG readers may not have seen Ashar Asiz's recent messages regarding >how the coverage of his SKIP proposal in the minutes has been highly >biased for the last two working group meetings. No, his comments were on the last minutes and the December 1994 minutes (nearly two years ago). "Highly biased" is subjective ... the minutes will be edited until all parties interested agree that they are not incorrect (note - I don't want to starting adding significant text). Please consider that good will would be generated in the working group as a whole (perhaps even consensus) by editorial suggestions (minutes or the specifications) that are submitted as constructive and clearly defined changes rather than combative complaints. >In my particular case, the minutes report that Jeff's straw polls >"showed significant differences of opinion between Oakley/ISAKMP and >SKIP", when in fact, as Jeff had told me in advance, he had >deliberately structured his questions to avoid doing straw-polls on >particular algorithms. Please send direct text replacement for minute changes. I plan to avoid recording any of the straw poll numbers since the IETF does not vote and because there seems to be several versions of these numbers. The basic conclusion was that there was not consensus. A decision will be mandated by the Security Directorate. Please try to facilitate this decision. Once again, we need to move forward based on this decision. Regards, Paul PS - unresponsive...? >Subject: IPSEC WG chairs unresponsive, disruptive, and biased While I feel obligated to directly answer complaints about the co-chairs to the mailing list, I do have a real job that can create a several day response lag to e-mail. If you are referring to the minutes... we will do what it takes to correct the existing minutes (not Dec 94). Responding to combative complaints is not constructive and I hope that we find a better way for us all to contribute. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_7738095_0_11919609192039210 Content-Type:message/rfc822 Date: 18 Sep 96 17:01:10 From:"John Gilmore " To:PALAMBER.US.ORACLE.COM,,ipsec@tis.com Subject:IPSEC WG chairs unresponsive, disruptive, and biased To:jis@mit.edu, gnu@toad.com To:iesg@ietf.org In-Reply-To:<199609162035.NAA06638@mailsun2.us.oracle.com> Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" I too submitted revisions to the draft Montreal minutes, to provide a web pointer for my "rapid IPSEC deployment" proposal, and to record what specific questions were asked by Jeff Schiller at the end of the "key managment" meeting, and what the rough votes in response were. None of these revisions were reflected in the minutes posted this week by the co-chairs. I have heard complaints from a wide variety of people about the conduct of the IP Security working group co-chairs. A certain amount of it I could attribute to general grousing. But I continue to see examples of how the co-chairs act to disrupt and skew, rather than to foster, the process of reaching rough consensus. I will refrain from speculation on whether this is intentional on their part, or whether they are merely not suited to the task of managing a complex and contentious working group. I would welcome input from the Working Group and from IESG members on how to handle this situation. I think it has been swept under the rug for far too long. IESG readers may not have seen Ashar Asiz's recent messages regarding how the coverage of his SKIP proposal in the minutes has been highly biased for the last two working group meetings. I'll be glad to forward them to interested parties, or they can be found in this week's ipsec@tis.com mailing list archives. Here is an excerpt: > Also, when there are competing proposals, I believe some > consideration should be given to fairness in the way the various > proposals are described. I refer specifically to the use of > adjectives such as "significant overhead", "hard to implement > and scale" and "claimed" support of multicast when describing > SKIP. By contrast, adjectives used for ISAKMP/Oakley are > "very general", "very flexible", etc. In my particular case, the minutes report that Jeff's straw polls "showed significant differences of opinion between Oakley/ISAKMP and SKIP", when in fact, as Jeff had told me in advance, he had deliberately structured his questions to avoid doing straw-polls on particular algorithms. Here's the minutes coverage, followed by my unaccepted revisions to the minutes. Jeff should have notes that confirm which description is more complete and more accurate. > Closing discussions were process oriented, i.e., how will the WG decide > what will become the default key management standard for IPSEC ? Jeff > Schiller conducted straw polls which showed significant differences of > opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick > resolution to the issue! Jeff suggests having a special committee come back > with a justifiable resolution. Message-Id: <199608060655.XAA10933@toad.com> To: "PALAMBER.US.ORACLE.COM" cc: ipsec@TIS.COM, gnu Subject: Re: IPsec Minutes from Montreal In-reply-to: <199608052345.QAA16081@mailsun2.us.oracle.com> Date: Mon, 05 Aug 1996 23:55:26 -0700 From: John Gilmore Some minutes additions from my own notes: Details on my presentation on rapid deployment of IPSEC in the first meeting are available at http://www.cygnus.com/~gnu/swan.html. Jeff Schiller's closing discussions in the second meeting included these "straw poll" questions, with my rough estimations of the audience reaction. He said he deliberately structured the questions to avoid a straw-poll on particular algorithms, but instead focused on our goals or process. Should we let the marketplace decide on a key managment standard, or should we pick one and move forward? Marketplace - 2/5 Pick one - 3/5 Should we favor generality, or simplicity? Generality - 2/5 Simplicity - 3/5 Do we have to have a plan by the next IETF? On this we have consensus -- YES. Should Jeff grab a few of the WG people who are known not to be committed to any proposal, and together decide? Strong consensus that this was not the way to go. This was when he suggested convening a small group, largely composed of the authors/proponents of existing proposals, to try to hammer out a compromise proposal. He also said that if this group didn't come up with anything by September, Jeff would personally choose one as the standard, though he did not want to be forced to do that. John --=_ORCL_7738095_0_11919609192039210-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa16070; 19 Sep 96 22:47 EDT Received: by relay.hq.tis.com; id WAA23575; Thu, 19 Sep 1996 22:50:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023572; Thu, 19 Sep 96 22:50:13 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22470; Thu, 19 Sep 96 22:49:24 EDT Received: by relay.hq.tis.com; id WAA23567; Thu, 19 Sep 1996 22:50:11 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma023562; Thu, 19 Sep 96 22:49:59 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 19 Sep 1996 22:52:18 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id WAA00258; Thu, 19 Sep 1996 22:52:16 -0400 Message-Id: <199609200252.WAA00258@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Kim Toms Cc: ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: kim's message of Fri, 20 Sep 1996 01:50:35 +0000. <199609200150.BAA18018@picu.morningstar.com> Date: Thu, 19 Sep 1996 22:52:10 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I'm no expert in cryptography, but it seems to me that what is needed is > a function which is expensive for the originator of a packet to > calculate, but cheap for the receiver to verify. This will make sure > that the source of a swamping attack must have a much larger CPU than > the receiver. I don't know if there are any such functions, but perhaps > the cryptographically sophisticated among us could enlighten? A simple imbalance in "expense" isn't enough -- what if the attacker does a lot of precomputation before launching the attack? - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa16220; 19 Sep 96 22:54 EDT Received: by relay.hq.tis.com; id WAA23666; Thu, 19 Sep 1996 22:58:12 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma023660; Thu, 19 Sep 96 22:57:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22594; Thu, 19 Sep 96 22:56:55 EDT Received: by relay.hq.tis.com; id WAA23652; Thu, 19 Sep 1996 22:57:42 -0400 Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (V3.1.1) id xma023646; Thu, 19 Sep 96 22:57:24 -0400 Received: by big-screw id AA03126; Thu, 19 Sep 96 22:59:18 -0400 Message-Id: <32420858.505B@mit.edu> Date: Thu, 19 Sep 1996 22:58:32 -0400 From: "Jeffrey I. Schiller" Reply-To: jis@mit.edu Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 3.0 (Macintosh; U; 68K) Mime-Version: 1.0 To: ipsec@TIS.COM, ietf@ietf.org Subject: Security AD Statement on IPSEC Key Management Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Introduction Standardized security technology is urgently needed on the Internet today. The IPSEC Working Group has been working to provide solutions applicable to the IP Layer of the protocol stack. Over a year ago, consensus was reached on the packet formats necessary to provide data authentication, integrity and confidentiality. However the mechanism to exchange required cryptographic material was not yet ready for standardization. Since then the IPSEC Working Group has been struggling with several competing key management proposals. To have competing proposals within an IETF working group is neither new nor novel. However the time comes when either the proponents of the various proposals come to consensus (along with the rest of the working group) or a decision among them has to be made. That time is now. In Montreal (at the June IETF meeting) I saw several factions at work in the IPSEC working group. There were people supporting each of the proposed key management solutions and a larger number of people who were looking for a single solution to emerge, but who themselves were not in a position to have a technical opinion one way or the other. But one thing was clear, they wanted a solution and they wanted it then. Shortly after the meeting I was approached by several people offering to have a "design team" meeting with the principals behind the various proposals. The goal of the team was to come up with a compromise that all could live with. I considered this very good news, but I was also cautious. The last thing I wanted was to have a working group meeting at the December 1996 IETF and still be where we were in Montreal, namely without a solution! To this end I established a time limit. The charge to the design team was to come up with a compromise solution (or enough progress on a compromise) by September 1. After September 1, if the working group could not decide upon a course of action, then I would step in as Security Area Director and propose one myself. As those of you on the IPSEC list already know, the design team failed in their effort to come up with a compromise. I am both saddened and disappointed by this outcome. The purpose of this document is to end the controversy and establish a productive direction for future work. History To understand the situation requires a bit of history and explanation. Although most Internet problems can be solved by a single protocol, this doesn't always have to be the case. For example, we have TCP and UDP which both provide a transport service, but with very different characteristics to address different problem domains. Similarly we have both the RIP and OSPF routing protocols. Each protocol has features different from the other, and each has its appropriate domain of applicability. Why is IPSEC different? To understand this we have to go back to the original decision reached by the IETF in the IPv6 selection process. Specifically the IETF decided that security, namely IPSEC, was a mandatory requirement for a compliant implementation of IPv6. This was decided upon because the community felt that without such a mandatory feature, security would not be implemented in a lot of products, even though there is a pressing need for security on the Internet. The reasons for this belief are many and varied and beyond the scope of this document. Suffice it to say that IPSEC technology is mandatory in IPv6. The mandatory nature of IPSEC means that for its various protocols, several variants may exist, but one of each class of protocol will need to be designated as mandatory to provide guidance to vendors wishing to build IPv6 compliant versions of products. The mandatory to implement protocols may not necessarily be the ideal solution for any particular problem. Instead they are selected to provide two basic requirements: o Strong Security o Interoperability The goal is for two compliant implementations of IPSEC to be able to communicate securely because they, at a minimum, have the mandatory to implement protocols common between them. They may have other protocols, such as other Authentication Header (AH) and Encapsulated Security Protocol (ESP) transforms, in common which they may negotiate the use of instead of the mandatory protocols. The mandatory transforms may not always be the ideal approach for a particular network application. For example, the mandatory ESP transform involves the use of the U.S. Data Encryption Standard (DES). This encryption algorithm is widely regarded as being secure enough for most applications. It is also commonly recognized that DES is a slow algorithm and applications requiring high speed data transfer (in the absence of high speed DES hardware) may elect to use a faster cipher such as the International Data Encryption Algorithm (IDEA) or RSA Data Security's RC2 or RC4 ciphers. Analysis Keeping in mind that the primary goal of the mandatory protocols is to provide strong security and interoperability, I have read and evaluated the approaches in the two main contenders for the IPSEC key management mandatory standard, SKIP and ISAKMP/Oakley. ISAKMP/Oakley ISAKMP defines a Security Association management protocol for establishing security contexts and keys between a pair of hosts on the Internet. By itself it does not define a key management function. Oakley provides a key management function which can operate within the ISAKMP protocol. The combination provides for complete security association and cryptographic key material management. Oakley itself provides several protocol variations which trade-off between protocol overhead (the number of messages sent between communicating hosts) and services provided (such as identity confidentiality). ISAKMP/Oakley imposes a cost of several packet exchanges between host pairs before secure communication can take place. There is no per-packet overhead to use ISAKMP/Oakley (other then the AH and ESP header overhead itself) once associations are in place. For a set of hosts which communicate with each other on a frequent basis, it is expected that associations will remain in place and the overhead of setting new ones up will not be a significant factor. The primary disadvantage of the ISAKMP/Oakley approach is that it imposes significant overhead in the case where hosts communicate infrequently as it is likely that associations will not exist when needed and will have to be setup. If either party to a security association looses or changes state, so that existing associations are no longer operative, then a new set of security associations can be established. Messages, protected by the new associations, can communicate the demise of the failed associations. SKIP The SKIP proposal is based on in-line keying. Each packet is encrypted in a key which is provided in the packet itself, encrypted in a key that is setup between the communicating host pair. SKIP's advantage is that the protocol for setting up inter-host keys is fairly lightweight. If both hosts already have the other hosts public key certificate, no packet exchanges are required as the arriving data packet will contain sufficient information for the receiving host to compute the shared key and respond accordingly. Computing the shared key requires significant computation (exponentiation). However a communicating host pair can choose to cache their shared keys to avoid this computational overhead. There is a trade-off between computation of shared keys and secure storage to hold already computed keys. In SKIP if a received packet cannot be decrypted, there is little fallback available as SKIP does not naturally support multiple security associations. Put another way, the lightweight key management does not have a heavyweight fallback in the event that key management fails for any reason. The result is that messages must be sent without security enhancements to indicate the failure. However such messages will be indistinguishable from forged messages originated by an attacker for the purpose of disrupting communication. The implication of the lightweight approach of SKIP is that no significant negotiation of algorithms, certificates and other options are possible. The assumption is that certain parameters, such as the Diffie Hellman prime and generator will be constant among members of a community of hosts using SKIP. Among a small community of hosts, e.g., within an autonomous system (AS), such parameters need not be negotiated in real-time, but rather can be configured in advance in the hosts. If at some future point they need to be changed, the amount of management overhead necessary is bounded by the size of the AS. SKIP will also likely be faster at recovery from normal system failure (reboot) when a host communicates with a significant number of peers. In this situation the lightweight approach provides for faster re-establishment of secure communication. Note: Some features of SKIP, including Certificate Discovery and Algorithm Discovery improve its ability to cope with some classes of failures. However this additional mechanism comes at the cost of additional packet exchanges and protocol complexity. It is my opinion that SKIP could be further modified to deal with these issues as well as ISAKMP/Oakley does. However I believe such a modified protocol will be as complicated if not more so then the ISAKMP/Oakley protocol combination. Conclusion I had hoped that the design team would have recognized that each of the two proposals above have domains where they are particularly well suited. It is conceivable to this author that a merged mechanism could exist that provides the benefits of SKIP within an AS (or similar community) and ISAKMP/Oakley when more protocol negotiation is required. A simple (from my point of view) solution would be to require both SKIP and ISAKMP/Oakley be implemented in a compliant IPv6 protocol stack. However it is clear to me that there is significant overlap of functionality between these two protocols and without a compromise (presumably a compromise protocol would result in a lot of shared mechanism and code in implementations) implementors would have to write a lot of excess code. Therefore we have to pick one approach as the mandatory solution. This does not mean that the other approach cannot become an ELECTIVE Internet Standard. Going back to my original view of the goal behind the "mandatory" approach leads me to conclude that if we must pick between ISAKMP/Oakley and SKIP, then ISAKMP/Oakley should be the mandatory standard. My rationale is simple. It is my belief that given an arbitrarily chosen pair of hosts, it is likelier that an ISAKMP/Oakley approach will result in a working security association than SKIP. Furthermore going back to the original working group charter, the ISAKMP/Oakley approach more closely follows the goals established in the charter to the IKMP portion of the IPSEC work. I would like to see the IPSEC working group create three sets of RFCs. o A Set of RFCs which fully define the ISAKMP/Oakley approach. These RFCs will follow the normal IETF standards track ultimately resulting in a protocol that is ELECTIVE for IPv4 and is MANDATORY for IPv6. o A Set of RFCs which fully define the SKIP approach. These RFCs will follow the normal IETF standards tack ultimately resulting in a protocol that is ELECTIVE for IPv4 and is ELECTIVE for IPv6. o One or more RFCs that describe the application domain for ISAKMP/Oakley and SKIP. Although I believe that ISAKMP/Oakley should become the IPv6 Mandatory protocol, I also believe that there exist significant domains of application where the SKIP approach makes more sense. I would like the working group to address this. Recommendation I formally recommend, as Security Area Director, that the charter for the IPSEC working group be amended to charge the working group with the tasks above. The arguments between the ISAKMP/Oakley and SKIP factions should no longer be considered appropriate discussion for the working group, either at its in person meetings or on the working group mailing list. If some people would like to continue that line of discussion they are welcome to form a separate mailing list, not part of the IETF. Proposed New Charter (with change bars) IP Security Protocol (ipsec) Charter Chair(s) * Ran Atkinson * Paul Lambert Security Area Director(s): * Jeffrey Schiller Mailing List Information * General Discussion:ipsec@tis.com * To Subscribe: ipsec-request@tis.com * Archive: ftp://ftp.tis.com/pub/lists/ipsec Description of Working Group Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the | lower layer security protocol. The protocol will be based on the | ISAKMP/Oakley work begun in: | | , | and | . | | A follow on work item may incorporate mechanisms based on SKIP as | defined in: | | | | and related documents. Flexibility in the protocol will allow | eventual support of Key Distribution Centers (KDC), such as are used | by Kerberos. Goals and Milestones Done Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. Done Post as an Internet-Draft the IP Security Protocol. Done Post as an Internet-Draft the specification for Internet key management. Done Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH). | Done Submit revised Internet-Drafts for ESP, AH, and IP Security Architecture. | Dec 96 Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards. | Jan 97 | Submit Internet-Draft of the Internet Key Management Protocol (IKMP). | based on ISAKMP/Oakley to the IESG for consideration as a Proposed | Standard. | Jul 97 | Submit IKMP to IESG for consideration as a Draft Standard. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkHj78UtR20Nv5BtAQEiAgP/XTqrl8Wn4jFpOgtukCbIgDUrsqzKiMDy HCl6pX4BbXGpdiHlayCdhS1g5zbdwRa4J4TQg8sESbDkD49Zcs4a9bIDjY31gIB4 HnP7twW1/sEls5Rp/j9vBHTDHQIMJFVWluuJOrQQfPxcLAEFjH+3enfFRAJXQVmo SOwHCHPmW7I= =mr47 -----END PGP SIGNATURE----- Subject: Re: The WG's inability to choose is good in this case. To: ipsec@TIS.COM Date: Thu, 19 Sep 1996 15:04:33 -0700 (PDT) In-Reply-To: <199609191532.LAA567568@mailhub1.watson.ibm.com> from "HUGO@watson.ibm.com" at Sep 19, 96 10:29:34 am X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: ipsec-approval@neptune.tis.com Message-ID: <9609200726.aa21498@neptune.TIS.COM> > One personal clarification regarding (2): in my opinion, there is a > strong technical basis to require key exchange/refreshment via authenticated > handshakes as supported by Oakley (even if in-line keying is also supported > by the protocol). Doesn't IBM have a patent on this? --tom Subject: Re: IPsec Minutes from Montreal To: ipsec@TIS.COM Date: Thu, 19 Sep 1996 14:59:46 -0700 (PDT) In-Reply-To: <9609191751.AA18970@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Sep 19, 96 01:51:59 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk From: ipsec-approval@neptune.tis.com Message-ID: <9609200726.aa21481@neptune.TIS.COM> > Well, the problem is that any time the minutes say anything good or bad > about either protocol, people are going to claim that the minutes aren't > "fair". The problem is that the minutes don't describe what happened at the meeting, which is what they're supposed to do. We're more than happy to debate the merits of our protocol, but minutes should accurately and fairly records what happens at the meetings -- not provide the chair's opinions. The minutes are not a forum where differences of opinion are somehow resolved. They're supposed to be an accurate record of what took place at the meeting. > According to the ISAKMP camp, saying that SKIP "only" takes 2 > messages is a skewed, slanted view. If someone had presented that at the meeting, yes, that should be in the minutes. Date: Thu, 19 Sep 1996 17:24:26 -0400 To: Bill Sommerfeld , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: resistance to swamping attacks. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609200725.aa21463@neptune.TIS.COM> At 12:30 PM 9/19/96 -0400, Bill Sommerfeld wrote: > >There have been a number of press reports about swamping attacks on >TCP using forged source addresses. Some of these press reports have >suggested that IPv6 will solve all this by requiring authentication. > This is from the End-to-End list: Date: Wed, 18 Sep 1996 14:32:14 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) To: end2end-interest@ISI.EDU Subject: SYN bombing defense Sender: owner-end2end-interest@ISI.EDU As reported here, in article in comp.protocols.tcp-ip, Robert Morris wrote: >Perhaps TCP's listen queue should use random early drop (RED), a >technique used by routers to prevent any one source from monopolizing >a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or >rfc1254. > ... I've just hacked IRIX 6.3 to do random-drop when sonewconn() in tcp_input.c fails. It works great! An IP22 receiving 1200 bogus SYN's per second directed to port 23 continues to answer requests for new telnet as if nothing is happening. I don't think that random <> drop is necessary or desirable. It is not as if we're trying to drop packets early to trigger slow start in the sources. As I figure it, as long as the length of the queue is longer than RTT of the real telnet client times the rate of bogus SYNs, the real clients have an excellent probability of getting through on their first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 telnet listen queue of 383, there should be no trouble with peers with RTT up to about 300 milliseconds. I've tested with a telnet client 250 milliseconds away while simultaneously bombing the machine from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. Vernon Schryver, vjs@sgi.com Robert Moskowitz Chrysler Corporation (810) 758-8212 To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Request For Prior Art For U.S. Patent Number 5,548,646 In-Reply-To: <199609190047.RAA10525@iplaw.Corp.Sun.COM> Date: Thu, 19 Sep 1996 16:31:54 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609200727.aa21519@neptune.TIS.COM> I have updated the "Network Encryption - history and patents" web page with Sun's request for prior art, a copy of the DEC patent they mention, and Greg Ahronian's message about the dangers of letting companies review prior art claims in private with the Patent Office. See http://www.cygnus.com/~gnu/netcrypt.html. John To: Bill Sommerfeld Cc: ipsec@TIS.COM, gnu@toad.com Subject: Re: resistance to swamping attacks. In-Reply-To: <199609191630.MAA00380@thunk.orchard.medford.ma.us> Date: Thu, 19 Sep 1996 17:00:04 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609200728.aa21538@neptune.TIS.COM> Bill Sommerfeld wrote: > If a system has a normal communications bandwidth of X, and recieves > an incoming storm from forged source addresses with a bandwidth of Y > (less than X), it should be able to continue to use at least half of > the remaining bandwith (X-Y) constructively to communicate with > arbitrary legitimate peers, including peers which had never before > communicated with it. It's great to see protocol goals structured this way. Can we do all of them like this? Let's see if we can refine this one a bit to something we believe we can implement! Systems have inbound bandwidth and outbound bandwidth, and we will have to distinguish among them, because an incoming storm will only directly affect the incoming bandwidth. Also, your goal assumes a non-interactive attack, that is, that the attacker cannot see any of the outgoing traffic in response to the attack. It's a much harder problem if the attacker is positioned on the network so that they can snatch some of the cookies off the ether, and send them back as part of the attack. So, my attempt: Resistance to non-interactive flood attacks: Assume a system has a normal incoming communications bandwidth of IX, a normal outgoing communications bandwidth of OX, and the ability to set up N new connections to peers per second. Assume the system is attacked by a flood of incoming packets consuming bandwidth IY, responds to the flood with response packets consuming bandwidth OY, and also receives ICMP messages resulting from bouncing response packets consuming incoming bandwidth IZ. Assume that the attacker is unable to read any of the response packets. Then: The system MUST be able to constructively use IX-IY-IZ of the incoming bandwidth, and The system MUST be able to constructively use OX-OY of the outgoing bandwidth, and The system MUST be able to set up at least N/2 new connections per second. "Constructively use" means that the bandwidth is available for communication with arbitrary legitimate peers, including peers which had never before communicated with the system. John Received: from relay.hq.tis.com by neptune.TIS.COM id aa23670; 20 Sep 96 9:31 EDT Received: by relay.hq.tis.com; id JAA02595; Fri, 20 Sep 1996 09:34:36 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma002586; Fri, 20 Sep 96 09:34:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06515; Fri, 20 Sep 96 09:33:18 EDT Received: by relay.hq.tis.com; id JAA02583; Fri, 20 Sep 1996 09:34:05 -0400 Received: from dns2.noc.best.net(206.86.0.21) by relay.tis.com via smap (V3.1.1) id xma002578; Fri, 20 Sep 96 09:33:45 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id GAA27005; Fri, 20 Sep 1996 06:35:56 -0700 Received: from info-10.noc.interop.net (VPNET-1.us.interop.net [45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id GAA11523; Fri, 20 Sep 1996 06:35:42 -0700 Message-Id: <2.2.32.19960920163401.00698e88@best.com> X-Sender: jlawler@best.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Sep 1996 09:34:01 -0700 To: ipsec@TIS.COM From: John Lawler Subject: Re: Concerns Cc: tytso@mit.edu, karl@ascend.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>>Well, at the IPSEC wg, what I saw was a small group of people... >> That is not the case. I estimated the attendance for the votes at about... >This is not what I saw. I saw only a handful voting for SKIP, a few... Has anyone ever seen "Rashamon"? :-) -John Received: from relay.hq.tis.com by neptune.TIS.COM id aa25653; 20 Sep 96 11:47 EDT Received: by relay.hq.tis.com; id LAA08570; Fri, 20 Sep 1996 11:50:46 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008557; Fri, 20 Sep 96 11:50:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16144; Fri, 20 Sep 96 11:49:30 EDT Received: by relay.hq.tis.com; id LAA08543; Fri, 20 Sep 1996 11:50:12 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma008517; Fri, 20 Sep 96 11:50:07 -0400 Received: from munin.fnal.gov ("port 4815"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I9P6JS626U0022VO@FNAL.FNAL.GOV> for ipsec@tis.com; Fri, 20 Sep 1996 10:52:06 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id KAA26580; Fri, 20 Sep 1996 10:49:59 -0500 (CDT) Date: Fri, 20 Sep 1996 10:49:53 -0500 From: Matt Crawford Subject: Re: resistance to swamping attacks. In-Reply-To: "19 Sep 1996 17:00:04 PDT." <"9609200728.aa21538"@neptune.TIS.COM> To: ipsec@TIS.COM Message-Id: <199609201549.KAA26580@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ says: > So, my attempt: > Assume a system has a normal incoming communications bandwidth of > IX, a normal outgoing communications bandwidth of OX, ... Then: > The system MUST be able to constructively use ... I think your conditions are automatically satisfied for any protocol, if you assume sufficient processing speed in the host. If you don't make that assumtion, that you have to specify the assumed processing speed in some way, in order to get a bound on the computation you will allow a candidate protocol to require. And we all know what happens to assumptions about processing power. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A From: narayanasamy senthil vadivu To: ipsec@ans.net Subject: Requirement for IPSEC SMIB Content-Type: text/plain Message-Id: <96Sep20.053114pdt.1461331(3)@constitution.hotmail.com> Date: Fri, 20 Sep 1996 05:31:14 -0700 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Dear Mr Steve Kent, with reference to ur list of security attributes in the draft : draft-ietf-ipsec-isakmp-05.txt regarding ISAKMP can u kindly give more inputs on these each of these security attributes .U can mail back to kaushikb@future.futsoft.com thanks/regards, kaushik --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa26677; 20 Sep 96 13:22 EDT Received: by relay.hq.tis.com; id NAA12915; Fri, 20 Sep 1996 13:26:24 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma012898; Fri, 20 Sep 96 13:25:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21121; Fri, 20 Sep 96 13:25:05 EDT Received: by relay.hq.tis.com; id NAA12891; Fri, 20 Sep 1996 13:25:53 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma012882; Fri, 20 Sep 96 13:25:49 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Sep 1996 10:28:12 -0700 Date: Fri, 20 Sep 1996 10:27:56 -0700 Posted-Date: Fri, 20 Sep 1996 10:27:56 -0700 Message-Id: <199609201727.AA02219@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Sep 1996 10:27:56 -0700 To: kim@morningstar.com, sommerfeld@apollo.hp.com Subject: Re: resistance to swamping attacks. Cc: ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > I'm no expert in cryptography, but it seems to me that what is needed is > > a function which is expensive for the originator of a packet to > > calculate, but cheap for the receiver to verify. This will make sure > > that the source of a swamping attack must have a much larger CPU than > > the receiver. I don't know if there are any such functions, but perhaps > > the cryptographically sophisticated among us could enlighten? > > A simple imbalance in "expense" isn't enough -- what if the attacker > does a lot of precomputation before launching the attack? Aren't authentication functions symmetric, almost by definition? Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa26775; 20 Sep 96 13:26 EDT Received: by relay.hq.tis.com; id NAA13069; Fri, 20 Sep 1996 13:30:26 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma013053; Fri, 20 Sep 96 13:29:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21448; Fri, 20 Sep 96 13:29:06 EDT Received: by relay.hq.tis.com; id NAA13045; Fri, 20 Sep 1996 13:29:54 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma013037; Fri, 20 Sep 96 13:29:40 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA22386 for ; Fri, 20 Sep 1996 13:32:32 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id NAA539864 for ; Fri, 20 Sep 1996 13:18:14 -0400 Message-Id: <199609201718.NAA539864@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8528; Fri, 20 Sep 96 13:18:11 EDT Date: Fri, 20 Sep 96 11:57:34 EDT To: ipsec@TIS.COM Subject: The WG's inability to choose is good in this case. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Thu, 19 Sep 1996 15:04:33 -0700 (PDT) (attached) > > > One personal clarification regarding (2): in my opinion, there is a > > strong technical basis to require key exchange/refreshment via authenticated > > handshakes as supported by Oakley (even if in-line keying is also supported > > by the protocol). > > Doesn't IBM have a patent on this? > > --tom > IBM has a patent that cover some techniques for key refreshment (more precisley for two-party authentication protocols). IBM has granted a free license for use of this patent (US Patent 5,148,479) in connection to IKMP. For the exact "grant of rights" text see RFC1822. Therefore, there is no reason to avoid these techniques; in particular, Oakley incorporates them already. BTW, this patent (files 3/91 issued 9/92) pre-dates any work in the IPSEC WG. None of the new work that we did in relation to this WG activity (e.g., MKMP, SKEME, HMAC) and which is now incorporated into current WG drafts (Oakley, AH, etc) has been patented by us. Hugo > Received: from relay.hq.tis.com by neptune.TIS.COM id aa27079; 20 Sep 96 13:44 EDT Received: by relay.hq.tis.com; id NAA13716; Fri, 20 Sep 1996 13:47:24 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma013714; Fri, 20 Sep 96 13:46:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22508; Fri, 20 Sep 96 13:46:06 EDT Received: by relay.hq.tis.com; id NAA13708; Fri, 20 Sep 1996 13:46:54 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma013703; Fri, 20 Sep 96 13:46:38 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id KAA00257; Fri, 20 Sep 1996 10:47:02 -0700 Received: from miraj.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id KAA18918; Fri, 20 Sep 1996 10:49:21 -0700 Received: by miraj.incog.com (SMI-8.6/SMI-SVR4) id KAA28752; Fri, 20 Sep 1996 10:47:46 -0700 From: Ashar Aziz Message-Id: <199609201747.KAA28752@miraj.incog.com> Subject: Re: IPSEC WG chairs unresponsive, disruptive, and biased To: ipsec@TIS.COM Date: Fri, 20 Sep 1996 10:47:46 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Ashar had attempted to remove my co-chair (Ran) for bias through > complaints to the IAB. The accusation stated that there must be an unfair > bias since his employer had announced a implementation that was not based > on SKIP (please excuse my terse summary). Paul, I am disappointed that you have chosen to bring this issue on to the list. However, now that you have done so, I feel it is only appropriate to set the record straight. After Cisco became the corporate sponsor of ISAKMP/Oakley in March, I sent mail to Ran personally, asking him to resign because of the potential conflict-of-interest. I asked that someone who had no interest in either protocol replace Ran as co-chair. I Cc'd you and Jeff Schiller on this request. Ran never responded. Jeff Schiller said that he did not believe that a conflict of interest existed. Several months went by, and the situation did not improve. It only got worse, as evidenced by the included (public) posting by Ran below. Since my appeals to the Area Director failed, and the sort of behaviour documented below continued, I then sent a detailed history of my participation in this process, and its lack of openness and fairness (from my perspective) to another IESG member. Your terse summary does injustice to this sequence of events. > I have also seen no specific bias by my co-chair against the SKIP > technology. We posted an announcement of our SKIP Developer's Workshop to comp.security.misc. This is a response which Ran posted: | From: rja@cisco.com (Ran Atkinson) | Newsgroups: comp.security.misc | Subject: Re: SKIP Developers Workshop | Date: 18 May 1996 20:00:24 GMT | Organization: cisco Systems, Incorporated | Lines: 19 | Distribution: world | Message-ID: <4nla8o$j6t@cronkite.cisco.com> | References: <4ng44c$9sv@news.incog.com> | NNTP-Posting-Host: puli.cisco.com | | Note that no _current_ implementation of SKIP _fully_ conforms with the IETF | specifications of IP Security. It would be nice if they did, but they don't | (e.g. they only support SPI==1 which is contrary to the requirements in | RFC-1825). | | Folks who are interested in standards-conforming and freely distributable IP | Security software should consider grabbing the NRL IPsec software for 4.4-Lite | BSD (which supports IPsec with both IPv4 and IPv6), which is available from | several places including: | ftp://ftp.ripe.net/ipv6/nrl/ | | If you need dynamic key management for IPsec, then a technically superior | alternative to SKIP is ISAKMP with Oakley extensions. A freely distributable | implementation of ISAKMP+Oakley that will drop on top of the NRL software is | available by telneting to port 7600 on ftp-eng.cisco.com and following the | instructions there. | | Ran | rja@cisco.com I will be away from my e-mail for the next 3-4 days, so I will be unable to respond for this period of time. Regards, Ashar. Received: from relay.hq.tis.com by neptune.TIS.COM id aa27948; 20 Sep 96 14:51 EDT Received: by relay.hq.tis.com; id OAA16333; Fri, 20 Sep 1996 14:55:26 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma016304; Fri, 20 Sep 96 14:54:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26843; Fri, 20 Sep 96 14:54:06 EDT Received: by relay.hq.tis.com; id OAA16298; Fri, 20 Sep 1996 14:54:54 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma016294; Fri, 20 Sep 96 14:54:50 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 20 Sep 1996 14:57:07 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id OAA00486; Fri, 20 Sep 1996 14:57:06 -0400 Message-Id: <199609201857.OAA00486@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: touch@isi.edu Cc: kim@morningstar.com, ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: touch's message of Fri, 20 Sep 1996 10:27:56 -0700. <199609201727.AA02219@ash.isi.edu> Date: Fri, 20 Sep 1996 14:57:02 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Aren't authentication functions symmetric, almost by definition? > > Joe well, RSA signatures aren't (expense depends on the length of the exponent and the public exponent is usually made short so signature verification is fast at the expense of making signing expensive) but those are clearly too expensive to use in per-packet transforms. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa28081; 20 Sep 96 15:00 EDT Received: by relay.hq.tis.com; id PAA16697; Fri, 20 Sep 1996 15:03:54 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma016691; Fri, 20 Sep 96 15:03:29 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27568; Fri, 20 Sep 96 15:02:38 EDT Received: by relay.hq.tis.com; id PAA16688; Fri, 20 Sep 1996 15:03:24 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma016684; Fri, 20 Sep 96 15:03:05 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 20 Sep 1996 15:05:25 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA00495; Fri, 20 Sep 1996 15:05:23 -0400 Message-Id: <199609201905.PAA00495@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Matt Crawford Cc: ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: crawdad's message of Fri, 20 Sep 1996 10:49:53 -0500. <199609201549.KAA26580@munin.fnal.gov> Date: Fri, 20 Sep 1996 15:05:22 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I think your conditions are automatically satisfied for any protocol, > if you assume sufficient processing speed in the host. John (and I) said "system", not "protocol". > If you don't make that assumtion, that you have to specify the > assumed processing speed in some way, in order to get a bound on the > computation you will allow a candidate protocol to require. And we > all know what happens to assumptions about processing power. Right, but as compute power on the system under attack goes up, it becomes *easier*, not harder, to keep doing productive work in the face of a swamping attack. If we can solve the problem for currently available commodity systems, we're probably on the right track. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa28218; 20 Sep 96 15:07 EDT Received: by relay.hq.tis.com; id PAA17145; Fri, 20 Sep 1996 15:10:54 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017138; Fri, 20 Sep 96 15:10:26 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28121; Fri, 20 Sep 96 15:09:36 EDT Received: by relay.hq.tis.com; id PAA17132; Fri, 20 Sep 1996 15:10:25 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma017127; Fri, 20 Sep 96 15:10:08 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Sep 1996 12:12:31 -0700 Date: Fri, 20 Sep 1996 12:12:15 -0700 Posted-Date: Fri, 20 Sep 1996 12:12:15 -0700 Message-Id: <199609201912.AA02342@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Sep 1996 12:12:15 -0700 To: touch@isi.edu, sommerfeld@apollo.hp.com Subject: Re: resistance to swamping attacks. Cc: kim@morningstar.com, ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From sommerfeld@apollo.hp.com Fri Sep 20 11:57:22 1996 > X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs > To: touch@isi.edu > Cc: kim@morningstar.com, ipsec@tis.com > Subject: Re: resistance to swamping attacks. > Date: Fri, 20 Sep 1996 14:57:02 -0400 > From: Bill Sommerfeld > > > Aren't authentication functions symmetric, almost by definition? > > > > Joe > > well, RSA signatures aren't (expense depends on the length of the > exponent and the public exponent is usually made short so signature > verification is fast at the expense of making signing expensive) but > those are clearly too expensive to use in per-packet transforms. > But then you're authenicating the signature, but not the packet itself, no? In that case, I can replay a signed connection-establishment request with random source addrs. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa28389; 20 Sep 96 15:13 EDT Received: by relay.hq.tis.com; id PAA17583; Fri, 20 Sep 1996 15:17:25 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017540; Fri, 20 Sep 96 15:16:57 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28556; Fri, 20 Sep 96 15:16:07 EDT Received: by relay.hq.tis.com; id PAA17528; Fri, 20 Sep 1996 15:16:55 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma017516; Fri, 20 Sep 96 15:16:41 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 20 Sep 1996 15:19:02 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA00538; Fri, 20 Sep 1996 15:19:00 -0400 Message-Id: <199609201919.PAA00538@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: touch@isi.edu Cc: kim@morningstar.com, ipsec@TIS.COM Subject: Re: resistance to swamping attacks. In-Reply-To: touch's message of Fri, 20 Sep 1996 12:12:15 -0700. <199609201912.AA02342@ash.isi.edu> Date: Fri, 20 Sep 1996 15:18:59 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > But then you're authenicating the signature, but not the packet > itself, no? Huh? Are we using the same definition of "authentication"? - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa28626; 20 Sep 96 15:28 EDT Received: by relay.hq.tis.com; id PAA18520; Fri, 20 Sep 1996 15:31:25 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xmaa18506; Fri, 20 Sep 96 15:30:57 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29597; Fri, 20 Sep 96 15:30:07 EDT Received: by relay.hq.tis.com; id PAA18496; Fri, 20 Sep 1996 15:30:55 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma018477; Fri, 20 Sep 96 15:30:25 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Sep 1996 12:32:48 -0700 Date: Fri, 20 Sep 1996 12:32:33 -0700 Posted-Date: Fri, 20 Sep 1996 12:32:33 -0700 Message-Id: <199609201932.AA02376@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Sep 1996 12:32:33 -0700 To: touch@isi.edu, kim@morningstar.com Subject: swamping security Cc: ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk So, it might be the case that, in order to avoid swamping attacks, we need two kinds of authentication: - whole packet (to keep converstations secure) - header only (for fast processing to check for swamping) If so, do we need another kind of header? (IP-AH specs only the first) Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa29474; 20 Sep 96 16:18 EDT Received: by relay.hq.tis.com; id QAA20210; Fri, 20 Sep 1996 16:21:55 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020208; Fri, 20 Sep 96 16:21:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02852; Fri, 20 Sep 96 16:20:37 EDT Received: by relay.hq.tis.com; id QAA20203; Fri, 20 Sep 1996 16:21:25 -0400 Received: from unknown(192.43.161.5) by relay.tis.com via smap (V3.1.1) id xma020190; Fri, 20 Sep 96 16:21:01 -0400 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v4Buh-0007DEC; Fri, 20 Sep 96 13:11 PDT Received: from kennedy ([205.226.80.185]) by cylink (4.1/SMI-4.1) id AA13303; Fri, 20 Sep 96 13:19:10 PDT Date: Fri, 20 Sep 96 13:19:10 PDT Message-Id: <9609202019.AA13303@cylink> From: John Kennedy To: ipsec@TIS.COM, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch Subject: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: johnmarc@cylink.com X-Mailer: Pronto E-Mail [version 2.01] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk I received the following message from the Internet-Drafts Administrator about a month ago regarding the deletion of the I-D John Marchioni and I co-authored on a "DSS Profile for X.509 Certificates". This draft was submitted only as an interim solution since the PKIX was just coming up to speed and had not yet included this material in the PKIX draft. I do not know exactly what the status of the X.509 DSS profile is in the PKIX document so I am sharing this current status information with you now. As far as I know DSS Certificates are being used in both the SKIP and ISAKMP/Oakley reference implementations and the aforementioned draft is cited in the applicable I-D's for these key management protocols. I have a number of choices: a) Do nothing and let the draft gracefully expire. b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt. c) Pester the PKIX editors to make sure this material gets absorbed into their next draft if it is not already there. (hint, hint...:) ) My preference and intention is to do (a) and (c) and at most submit a revised draft that simply points to PKIX. It is not clear that a revised draft is even necessary if current IPSEC and other working group drafts which point to draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3. So, if anybody thinks I need to do (b) let me know. Otherwise, please reset your DSS / X.509 certificate pointers, questions, and comments to their proper home in PKIX. Thanks, -John Kennedy ----------------BEGIN INCLUDED MESSAGE---------------------------- Date: Fri, 23 Aug 1996 14:35:52 -0400 From: Internet-Drafts Administrator Subject: to be deleted. To: John Kennedy Cc: IESG Secretary The Internet-Draft: Title : DSS Profile for X.509 Certificates Author(s) : John Kennedy, John Marchioni Filename : Last Updated: 02/24/1996 Pages : 3 will be deleted from the internet-drafts directories in the next few weeks as it has exceeded its maximum time allocated as an Internet-Draft. If a updated version of the draft is available please submit it the next few days. Received: from relay.hq.tis.com by neptune.TIS.COM id aa29896; 20 Sep 96 16:47 EDT Received: by relay.hq.tis.com; id QAA20877; Fri, 20 Sep 1996 16:50:55 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020875; Fri, 20 Sep 96 16:50:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04265; Fri, 20 Sep 96 16:49:37 EDT Received: by relay.hq.tis.com; id QAA20868; Fri, 20 Sep 1996 16:50:25 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma020862; Fri, 20 Sep 96 16:50:10 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Sep 1996 13:52:32 -0700 Date: Fri, 20 Sep 1996 13:52:17 -0700 Posted-Date: Fri, 20 Sep 1996 13:52:17 -0700 Message-Id: <199609202052.AA02432@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Sep 1996 13:52:17 -0700 To: touch@isi.edu, smb@research.att.com Subject: Re: resistance to swamping attacks. Cc: sommerfeld@apollo.hp.com, kim@morningstar.com, ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Steven Bellovin > > > From touch@isi.edu > > But then you're authenicating the signature, but not the packet > itself, no? > > In that case, I can replay a signed connection-establishment request > with random source addrs. > > Depends on what you sign. In my note, I said ``in principle''.... > From touch@ISI.EDU Fri Sep 20 12:32:53 1996 > From: touch@ISI.EDU > > So, it might be the case that, in order to avoid swamping attacks, > we need two kinds of authentication: > > - whole packet (to keep converstations secure) > > - header only (for fast processing to check for > swamping) > > If so, do we need another kind of header? > (IP-AH specs only the first) Except that, as a colleague here pointed out, checking authentication of SYNs costs much more than keeping the half-open connection block. That's the argument for *not* needing a header-only authenticator. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa00222; 20 Sep 96 16:56 EDT Received: by relay.hq.tis.com; id QAA21205; Fri, 20 Sep 1996 16:59:55 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021194; Fri, 20 Sep 96 16:59:30 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04553; Fri, 20 Sep 96 16:58:39 EDT Received: by relay.hq.tis.com; id QAA21179; Fri, 20 Sep 1996 16:59:27 -0400 Received: from mailhost.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1.1) id xma021169; Fri, 20 Sep 96 16:59:09 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id OAA21719; Fri, 20 Sep 1996 14:01:20 -0700 Message-Id: <199609202101.OAA21719@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: touch@isi.edu Cc: kim@morningstar.com, ipsec@TIS.COM Subject: Re: swamping security In-Reply-To: Your message of "Fri, 20 Sep 1996 12:32:33 PDT." <199609201932.AA02376@ash.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Sep 1996 14:01:19 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk Joe, et al, > So, it might be the case that, in order to avoid swamping attacks, > we need two kinds of authentication: > > - whole packet (to keep converstations secure) > > - header only (for fast processing to check for > swamping) I actually think the "end system" answer to swamping attacks is to keep minimal state at SYNRCVD time until you get a "correct" ACK from your SYNACK. (This is TCP-speak for saying that you send a verifier [ISS --- sequence number] to the proposed correspondent and see if that verifier comes back [as an ACK number, in this case].) Greg From: Ron Rivest Date: Fri, 20 Sep 96 17:14:38 EDT Message-Id: <199609202114.AA17657@swan.lcs.mit.edu> To: ipsec@TIS.COM Subject: Using cookies to defeat syn-flooding Sender: ipsec-approval@neptune.tis.com Precedence: bulk Here is a thought on a scheme for defeating swamping (syn-flooding) attacks, together with an improvement suggested by Butler Lampson. Since I'm not an expert on network protocols, it needs review by those who are... Flooding attack (paragraph to define problem and establish terminology): Assume that the scenario is that machine A receives a SYN packet allegedly from machine B. Currently A returns its own SYN packet, after logging the connection request in a queue. If the original SYN packet was bogus, and had a spoofied source ip address, then A is left waiting for B to complete the handshake until timeout, tying up A's resources. With many bogus SYN packets received, A is clogged up and A's legitimate users are denied service. Analysis: The problem is that A is allocating resources (i.e. making queue entries) with every SYN packet received. The idea: Defer A's allocation of resources until A has some confirmation that B is "real". (I.e. until the third message of the three-message protocol is received from B). How: When A receives the first SYN packet, it does NOT generate a queue entry. Rather, it sends B, as part of its return SYN packet, a "cookie" that contains the information that the queue entry would have: -- source id of the SYN packet received -- when to time the connection request out -- port number -- other stuff (?) The cookie would contain this material in the clear, together with a cryptographic checksum (MAC) on this data, computing from the data of the cookie and a secret key known only to machine A. When B replies, he returns the cookie, which A checks. A cookie with an invalid MAC is discarded. A cookie with a good MAC that has not timed out and which has not already been honored will generate a new connection. (Note that to prevent replays A must keep track of which connections have been opened within the last cookie-time-out period, but A does not need to keep track of cookies that have never been returned.) In this way, syn-flooding is defeated. Improvement: Butler Lampson suggested that the cookie might actually be squeezed into the current protocol. I don't know enough of the details to tell. He thought that A's return SYN includes a 32-bit number which is returned (slightly modified) in B's final ACK. This might be used to store just the MAC for the cookie, if the rest of the cookie could be reconstructed from the material already in the second message. More likely, the 32-bit quantity would have to code both the time-out and the MAC. (Allocate say 12 bits for time out to the minute mark and 20 bits for checksum; change to a new crypto key whenever every 2^{12} minutes.) It would be neat if this improvement could fit within the current implementation of IPv4. Perhaps something like this would be valuable for IPv6 in any case... Comments appreciated ... Ron Rivest From: Ron Rivest Date: Fri, 20 Sep 96 17:39:12 EDT Message-Id: <199609202139.AA17662@swan.lcs.mit.edu> To: ipsec@TIS.COM Subject: Resistance to swamping attacks via Kim Tom's idea Sender: ipsec-approval@neptune.tis.com Precedence: bulk Kim Toms (below) suggested a cryptographic function that is easier to verify than to compute. The sender of a packet P would have to compute a quantity f(P), such that the receiver would be able (VERY EASILY) check that this computation was proper. Here is a simple idea: Let k be a small integer (e.g. k=10) Let P be the packet data The sender of a packet must also send along a tag T such that: the low-order k bits of MD5(P || T) are all zero (Here || denotes concatenation.) MD5 acts like a "random" function, and the sender would have to check approximately 2^k values of T before finding one that works. The receiver has only one MD5 computation to perform, and so he is able to check packets 2^k times more efficiently than an attacker can generate them. The expected length of T is k bits, and the chance that T will be longer than c*k bits is approximately exp{-k*(c-1)}, so allocating space in the packet for T can probably afford 2k bits easily. (E.g. for k=10, the chance that the length of T is greater than 20 is about 10^-434). I'm not terribly excited about the proposal overall, but just wanted to point out that the cryptography is available to make it doable, as desired. Cheers, Ron Rivest ============================================================================== Date: Fri, 20 Sep 1996 01:50:35 GMT From: "Kim L. Toms" Subject: Re: resistance to swamping attacks. Reply-To: Kim Toms I'm no expert in cryptography, but it seems to me that what is needed is a function which is expensive for the originator of a packet to calculate, but cheap for the receiver to verify. This will make sure that the source of a swamping attack must have a much larger CPU than the receiver. I don't know if there are any such functions, but perhaps the cryptographically sophisticated among us could enlighten? To: touch@isi.edu Cc: sommerfeld@apollo.hp.com, kim@morningstar.com, ipsec@TIS.COM Subject: Re: resistance to swamping attacks. Date: Fri, 20 Sep 1996 16:45:38 -0400 From: Steven Bellovin MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609230725.aa26132@neptune.TIS.COM> > From sommerfeld@apollo.hp.com Fri Sep 20 11:57:22 1996 > X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld ow ned process doing -bs > To: touch@isi.edu > Cc: kim@morningstar.com, ipsec@tis.com > Subject: Re: resistance to swamping attacks. > Date: Fri, 20 Sep 1996 14:57:02 -0400 > From: Bill Sommerfeld > > > Aren't authentication functions symmetric, almost by definition? > > > > Joe > > well, RSA signatures aren't (expense depends on the length of the > exponent and the public exponent is usually made short so signature > verification is fast at the expense of making signing expensive) but > those are clearly too expensive to use in per-packet transforms. > But then you're authenicating the signature, but not the packet itself, no? In that case, I can replay a signed connection-establishment request with random source addrs. Depends on what you sign. In my note, I said ``in principle''.... Date: 23 Sep 96 11:26:00 GMT From: "SPARKS::WEAVER" Subject: ISAKMP Exchanges To: ipsec Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609230746.aa26548@neptune.TIS.COM> I would like to get a feel for the demand, if any, for a simple EXCHANGE for ISAKMP: Comments or even a suggestion ? Elfed weaver@dra.hmg.gb Date: 23 Sep 96 11:20:00 GMT From: "SPARKS::WEAVER" Subject: ISAKMP implementations To: rja Cc: ipsec Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609230745.aa26527@neptune.TIS.COM> rja wrote :- > There are non-US implementations of ISAKMP already. For example, >DRA/Malvern (UK) has an implementation of ISAKMP for UNIX. Dan Harkins >of cisco has done some interoperability testing with DRA/Malvern already, >more interoperability testing is planned. Yes, DRA - Malvern (UK) does have a prototype implementation of ISAKMP version 4. This prototype has been used, successfully !, to interoperate with Dan Arkins/cisco ISAKMP version 4 implementation. Currently, (well, when time permits !) we are upgrading the protoype to the ISAKMP version 5 specification. We would like to have a protoype that supports the ISAKMP/Oakley exchange ready for interoperability testing by the December IETF - We shall see ;-) > If vendors implement the "PF_KEY Key Management API version 2" (I-D should >be coming out soon), then anyone can build any key management daemon they want >and drop it on top of that API without needing kernel sources. We are currently looking at modifying a publicly (European) available version of IPsec with which to use our ISAKMP implementation and intend to implement "PF_KEY Key Management API version 2". Two questions I expect many will want answered: 1. Will the code be publicly available - Personally, I dont believe there will be a problem with this. 2. When will it be available - When it supports, the mandatory exchanges and the PF_KEY API. Elfed weaver@dra.hmg.gb From: Germano Caronni Message-Id: <199609231120.NAA01210@kom30.ethz.ch> Subject: The skip-info mailing list To: skip-info@skip.org, Project SKIP , Bernhard Plattner , ipsec@TIS.COM Date: Mon, 23 Sep 1996 13:20:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk The SKIP internal mailing list 'skip-info@tik.ee.ethz.ch' has moved. It is now located at skip-info@skip.org. If you are already a subscriber, your subscription will hopefully have been moved to the new list. Otherwise, to subscribe, send email to majordomo@skip.org, with the folowing text in the body (not subject) of your message: subscribe skip-info Friendly greetings, Germano Caronni From: narayanasamy senthil vadivu To: ipsec@ans.net Cc: senthilvn@future.futsoft.com Subject: Reg. security attributes mentioned in ISAKMP draft Content-Type: text/plain Message-Id: <96Sep21.063857pdt.1463609(4)@constitution.hotmail.com> Date: Sat, 21 Sep 1996 06:38:57 -0700 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi Steve Kent, As there is reference in the ISAKMP draft, june 13, 1996 to this email address for quering more on the security attributes mentioned for security association (SA), I am sending this mail. Please do send description of these attributes and as well as information on what other drafts can be referred for SA. Thanks senthil vadivu. --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- From: narayanasamy senthil vadivu To: ipsec@ans.net Cc: Subject: Regarding Security Association Attributes Content-Type: text/plain Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 23 Sep 96 10:17:17 EDT Message-ID: <9609231017.aa28736@neptune.TIS.COM> Hi, Please let us know as what are the web sites that can give more information on the security attributes of security association (SA). Also, please provide the information that you have. Thanks senthil --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29226; 23 Sep 96 10:52 EDT Received: by relay.hq.tis.com; id KAA17372; Mon, 23 Sep 1996 10:56:31 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017344; Mon, 23 Sep 96 10:56:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26091; Mon, 23 Sep 96 10:55:10 EDT Received: by relay.hq.tis.com; id KAA17335; Mon, 23 Sep 1996 10:56:00 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma017329; Mon, 23 Sep 96 10:55:52 -0400 Received: from munin.fnal.gov ("port 1589"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I9TBIYZ72W002C9W@FNAL.FNAL.GOV>; Mon, 23 Sep 1996 09:58:10 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA04050; Mon, 23 Sep 1996 09:56:02 -0500 (CDT) Date: Mon, 23 Sep 1996 09:55:55 -0500 From: Matt Crawford Subject: Re: Using cookies to defeat syn-flooding In-Reply-To: "20 Sep 1996 17:14:38 EDT." <"199609202114.AA17657"@swan.lcs.mit.edu> To: Ron Rivest Cc: ipsec@TIS.COM Message-Id: <199609231456.JAA04050@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ When A receives the first SYN packet, [...], it sends B, as part of > its return SYN packet, a "cookie" that contains the information that > the queue entry would have: > -- source id of the SYN packet received [...] > Comments appreciated ... Such a cookie can only be computed after receipt of the SYN, making this a time-space tradeoff. The CPU power of A must be compared to the bandwidth of its connection to the internet to determine whether more queue space and random drop of half-open connections is better than spending cycles on verification of the correpsondent's source address. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Received: from relay.hq.tis.com by neptune.TIS.COM id aa29284; 23 Sep 96 10:57 EDT Received: by relay.hq.tis.com; id LAA17518; Mon, 23 Sep 1996 11:01:31 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017509; Mon, 23 Sep 96 11:01:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26365; Mon, 23 Sep 96 11:00:16 EDT Received: by relay.hq.tis.com; id LAA17495; Mon, 23 Sep 1996 11:01:05 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma017489; Mon, 23 Sep 96 11:00:44 -0400 Received: from munin.fnal.gov ("port 1595"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I9TBP1DKTE002C9W@FNAL.FNAL.GOV>; Mon, 23 Sep 1996 10:03:04 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id KAA04086; Mon, 23 Sep 1996 10:00:55 -0500 (CDT) Date: Mon, 23 Sep 1996 10:00:55 -0500 From: Matt Crawford Subject: Re: Resistance to swamping attacks via Kim Tom's idea In-Reply-To: "20 Sep 1996 17:39:12 EDT." <"199609202139.AA17662"@swan.lcs.mit.edu> To: Ron Rivest Cc: ipsec@TIS.COM Message-Id: <199609231500.KAA04086@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ The receiver has only one MD5 computation to perform, and so he is able > to check packets 2^k times more efficiently than an attacker can generate > them. The attacker can pre-compute a million valid packets and send them cyclically. To avoid verifying them all, the victim would have to allot O(million) space. Or even simpler: the attacker does zero MD5 computations and sends packets which always (or usually) fail the test. Now who is spending more cycles? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Received: from relay.hq.tis.com by neptune.TIS.COM id aa00664; 23 Sep 96 12:26 EDT Received: by relay.hq.tis.com; id MAA20123; Mon, 23 Sep 1996 12:30:28 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020106; Mon, 23 Sep 96 12:29:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00652; Mon, 23 Sep 96 12:29:03 EDT Received: by relay.hq.tis.com; id MAA20100; Mon, 23 Sep 1996 12:29:54 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma020085; Mon, 23 Sep 96 12:29:26 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 23 Sep 1996 09:31:45 -0700 Date: Mon, 23 Sep 1996 09:31:27 -0700 Posted-Date: Mon, 23 Sep 1996 09:31:27 -0700 Message-Id: <199609231631.AA05685@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Mon, 23 Sep 1996 09:31:27 -0700 To: ipsec@TIS.COM, rivest@theory.lcs.mit.edu Subject: Re: Resistance to swamping attacks via Kim Tom's idea X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.hq.tis.com Mon Sep 23 05:57:48 1996 > From: Ron Rivest > Date: Fri, 20 Sep 96 17:39:12 EDT > To: ipsec@tis.com > Subject: Resistance to swamping attacks via Kim Tom's idea > > > Kim Toms (below) suggested a cryptographic function that is easier to > verify than to compute. The sender of a packet P would have to compute > a quantity f(P), such that the receiver would be able (VERY EASILY) check > that this computation was proper. Here is a simple idea: > > Let k be a small integer (e.g. k=10) > Let P be the packet data > The sender of a packet must also send along a tag T such that: > the low-order k bits of MD5(P || T) are all zero > (Here || denotes concatenation.) > > MD5 acts like a "random" function, and the sender would have to check > approximately 2^k values of T before finding one that works. > > The receiver has only one MD5 computation to perform, and so he is able > to check packets 2^k times more efficiently than an attacker can generate > them. ...than the attacker can generate *valid* packets. The attacker can easily generate invalid packets, and the cost is the same for the receiver. In fact, a good spoof would be to send packets with arbitrary values for the MD5 checksum. The cost to the sender is small and fixed, and the cost to the receiver is a full check of the data of each packet. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa00797; 23 Sep 96 12:32 EDT Received: by relay.hq.tis.com; id MAA20317; Mon, 23 Sep 1996 12:35:53 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020310; Mon, 23 Sep 96 12:35:30 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00865; Mon, 23 Sep 96 12:34:37 EDT Received: by relay.hq.tis.com; id MAA20304; Mon, 23 Sep 1996 12:35:27 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma020288; Mon, 23 Sep 96 12:35:08 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 23 Sep 1996 09:37:28 -0700 Date: Mon, 23 Sep 1996 09:37:10 -0700 Posted-Date: Mon, 23 Sep 1996 09:37:10 -0700 Message-Id: <199609231637.AA05690@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Mon, 23 Sep 1996 09:37:10 -0700 To: ipsec@TIS.COM, rivest@theory.lcs.mit.edu Subject: Re: Using cookies to defeat syn-flooding X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.hq.tis.com Mon Sep 23 05:51:48 1996 > From: Ron Rivest > Date: Fri, 20 Sep 96 17:14:38 EDT > To: ipsec@tis.com > Subject: Using cookies to defeat syn-flooding > > > Here is a thought on a scheme for defeating swamping (syn-flooding) > attacks, together with an improvement suggested by Butler Lampson. > Since I'm not an expert on network protocols, it needs review by those > who are... > > Flooding attack (paragraph to define problem and establish terminology): > ... > The idea: > > Defer A's allocation of resources until A has some confirmation that > B is "real". (I.e. until the third message of the three-message protocol > is received from B). This is the key issue - deferring resources. As others have pointed out, this includes CPU time. > How: > > When A receives the first SYN packet, it does NOT generate a queue > entry. Rather, it sends B, as part of its return SYN packet, > a "cookie" that contains the information that the queue entry would have: > -- source id of the SYN packet received > -- when to time the connection request out > -- port number > -- other stuff (?) > The cookie would contain this material in the clear, together with > a cryptographic checksum (MAC) on this data, computing from the data > of the cookie and a secret key known only to machine A. > When B replies, he returns the cookie, which A checks. A cookie with > an invalid MAC is discarded. A cookie with a good MAC that has not > timed out and which has not already been honored will generate a new The time-out, together with the resources to store the cookie and associated info, is the resource that needs to be deferred. So this has the same problem. Rather than tying up a TCP control block, this will tie-up your "cookie" table. The presumption here must be that, by sending a cookie, the receiver can time-out quicker. This can't occur, since a gap in the cookie-exchange has no effect on the timeout of the TCP connection establishment. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From: "carlisle (c.m.) adams" Message-Id: <"1680 Mon Sep 23 10:32:20 1996"@bnr.ca> To: jkennedy@cylink.com Cc: johnmarc@cylink.com, ipsec@TIS.COM, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch Subject: re:NOTICE: DSS Profile for X.509 Certificates to be deleted. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 23 Sep 96 12:39:20 EDT In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.", jkennedy@cylink.com writes: > >I received the following message from the Internet-Drafts Administrator about >a month ago regarding the deletion of the I-D John Marchioni and I co-authored >on a "DSS Profile for X.509 Certificates". This draft was submitted only as >an interim solution since the PKIX was just coming up to speed and had not yet >included this material in the PKIX draft. I do not know exactly what the >status of the X.509 DSS profile is in the PKIX document so I am sharing this >current status information with you now. As far as I know DSS Certificates >are being used in both the SKIP and ISAKMP/Oakley reference implementations >and the aforementioned draft is cited in the applicable I-D's for these key >management protocols. > >I have a number of choices: > >a) Do nothing and let the draft gracefully expire. >b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt. >c) Pester the PKIX editors to make sure this material gets absorbed into their >next draft if it is not already there. (hint, hint...:) ) > >My preference and intention is to do (a) and (c) and at most submit a revised >draft that simply points to PKIX. It is not clear that a revised draft is >even necessary if current IPSEC and other working group drafts which point to >draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3. Do you really mean "pkix-3" here, or do you mean "pkix-1". Part three is the certificate management protocols -- it's not clear to me that a DSS profile for X.509 certificates belongs there. Or am I missing something? Carlisle. From: Ran Atkinson Reply-To: rja1@home.net Organization: The Internet Guild X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: senvad@hotmail.com Cc: ipsec@TIS.COM Subject: IPsec Security Association attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 23 Sep 96 13:18:23 EDT Message-ID: <9609231318.aa01788@neptune.TIS.COM> Hi, Please go read RFC-1825, available online from ftp://ds.internic.net/rfc/rfc1825.txt, where the attributes of an IPsec Security Association are defined. If you're looking for reference code, I usually recommend examining the NRL IPsec source code for 4.4 BSD available from http://web.mit.edu/network/isakmp/ OR ftp://ftp.ripe.net/ipv6/nrl/ Thanks, Ran rja@inet.org Received: from relay.hq.tis.com by neptune.TIS.COM id aa01969; 23 Sep 96 13:27 EDT Received: by relay.hq.tis.com; id NAA22743; Mon, 23 Sep 1996 13:31:20 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022728; Mon, 23 Sep 96 13:30:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04344; Mon, 23 Sep 96 13:29:59 EDT Received: by relay.hq.tis.com; id NAA22722; Mon, 23 Sep 1996 13:30:50 -0400 Received: from mailhost.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1.1) id xma022718; Mon, 23 Sep 96 13:30:41 -0400 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id KAA09412; Mon, 23 Sep 1996 10:31:56 -0700 Message-Id: <199609231731.KAA09412@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Ron Rivest Cc: ipsec@TIS.COM Subject: Re: Using cookies to defeat syn-flooding In-Reply-To: Your message of "Fri, 20 Sep 1996 17:14:38 EDT." <199609202114.AA17657@swan.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Sep 1996 10:31:52 -0700 From: Greg Minshall Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ron, Actually, this is approximately what i was trying to say in email last week. Here is how the exchange happens: B chooses an initial sequence number (ISS-B) and sends a packet to A with the synchronize bit turned on, the acknowledgement bit turned off, and the sequence number set to ISS-A (this is the "SYN" packet). A chooses an initial sequence number (ISS-A) and sends a packet to B with the synchronize bit turned on, the acknoweldgement bit turned on, the sequence number set to ISS-A, and the acknowledgement number set to ISS-B+1 (this is the "SYNACK" packet). B then sends a packet to A with the synchronize bit turned off (it stays off for the rest of the conversation), the acknowledgement bit turned on (it stays on for the rest of the conversation), the sequence number set to ISS-B, and the acknowledgement number set to ISS-A+1 (this is the first "ACK" packet). The point is that if ISS-A is "not guessable", and if A refrains from allocating "much" state until B has replied to A's SYNACK packet, then when A sees an ACK from B acknowledging ISS-A, then A knows that B has seen A's SYNACK. Thus, A knows it can send packets "to" (possibly "past") the system purporting to be B. Good old "weak security". But, it has the advantage that from looking at the forwarding tables starting at A one can (more or less) generate a finite list of places where the system purporting to be B could be located. This would be a "good thing". Currently, we have no idea where the sources of the packets might be. Greg Minshall Received: from relay.hq.tis.com by neptune.TIS.COM id aa02092; 23 Sep 96 13:34 EDT Received: by relay.hq.tis.com; id NAA22942; Mon, 23 Sep 1996 13:37:50 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022931; Mon, 23 Sep 96 13:37:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04693; Mon, 23 Sep 96 13:36:31 EDT Received: by relay.hq.tis.com; id NAA22914; Mon, 23 Sep 1996 13:37:21 -0400 Received: from europe.std.com(199.172.62.20) by relay.tis.com via smap (V3.1.1) id xma022899; Mon, 23 Sep 96 13:37:08 -0400 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id NAA20789; Mon, 23 Sep 1996 13:39:27 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA04210; Mon, 23 Sep 1996 13:39:26 -0400 Message-Id: <199609231739.AA04210@world.std.com> To: ipsec@TIS.COM Subject: Re: Using cookies/computational effort to defeat syn-flooding In-Reply-To: Your message of "Fri, 20 Sep 1996 17:14:38 EDT." <199609202114.AA17657@swan.lcs.mit.edu> Date: Mon, 23 Sep 1996 13:39:26 -0400 From: "Donald E. Eastlake 3rd" Sender: ipsec-approval@neptune.tis.com Precedence: bulk There are two facets to this problem, as I see it. One is spam packets of any type that have forged sources, can't be easily traced due to ISPs not being prepared to do this, etc. The second is fragile mechanisms that are easily toppled even without any forgery. While we need to fix the second where we can, there will always be packets that can cause trouble and evem just a string of nonsense packets firehosed at a host can degrade/deny service to others due to bandwidth considerations. ((Actually I wonder what the chance is that mostly random packets would crash the IP stack in an average host... Seems like the kind of test everyone would know you should do on your software but who knows...)) I think we need to always worry about the first with some sort of IP level mechanism that is very much cheaper than any of the current IPSECs and which also provides some assistance in tracing back the physical origin of packets. The Internet is increasingly under attack and we need continuing effort at making it more robust at all levels. Donald From: Germano Caronni Message-Id: <199609231120.NAA01210@kom30.ethz.ch> Subject: The skip-info mailing list To: skip-info@skip.org, Project SKIP , Bernhard Plattner , ipsec@TIS.COM Date: Mon, 23 Sep 1996 13:20:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk The SKIP internal mailing list 'skip-info@tik.ee.ethz.ch' has moved. It is now located at skip-info@skip.org. If you are already a subscriber, your subscription will hopefully have been moved to the new list. Otherwise, to subscribe, send email to majordomo@skip.org, with the folowing text in the body (not subject) of your message: subscribe skip-info Friendly greetings, Germano Caronni Received: from relay.hq.tis.com by neptune.TIS.COM id aa05483; 23 Sep 96 17:50 EDT Received: by relay.hq.tis.com; id RAA01684; Mon, 23 Sep 1996 17:53:54 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma001681; Mon, 23 Sep 96 17:53:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19026; Mon, 23 Sep 96 17:52:36 EDT Received: by relay.hq.tis.com; id RAA01678; Mon, 23 Sep 1996 17:53:25 -0400 Received: from unknown(192.43.161.5) by relay.tis.com via smap (V3.1.1) id xma001615; Mon, 23 Sep 96 17:52:57 -0400 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v5Igu-0007CmC; Mon, 23 Sep 96 14:37 PDT Received: from kennedy ([205.226.80.185]) by cylink (4.1/SMI-4.1) id AA11834; Mon, 23 Sep 96 14:44:38 PDT Date: Mon, 23 Sep 96 14:44:38 PDT Message-Id: <9609232144.AA11834@cylink> From: John Kennedy To: wford@mail.intranet.ca, johnmarc@cylink.com, cadams@nortel.ca Subject: Re: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: ipsec@TIS.COM, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch X-Mailer: Pronto E-Mail [version 2.01] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > At 10:40 AM 9/23/96 -0700, John Marchioni wrote: {Recommendation from John Marchioni deleted} > > For the benefit of everyone, I have attached below a copy of the referenced > e-mail from me. I won't include the uuencoded Word attachment on such a > wide distribution as this message, but will send it to anyone requesting > it. > > >The Diffie-Hellman cert profile should be added next when it is agreed > that > the D-H cert section of ANSI >X9.42 is stable. I recommend that the IETF > and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with > D-H > keys and certificates, if this ARC is registered and valid. > > The X9.57 arc is certainly registered (under ANSI as an ANSI standard) > and > valid, and we have used it for X9.57 and X9.55. I would not object to > using > it also for X9.42 Warwick, I have just received a newly assigned ARC for ANSI X9.42 (Diffie-Hellman). I suspect the parameter syntax and encoding section for X9.42 to undergo some revision after the ANSI X9.F1 next week after I get some feedback. (BTW, you should have received hardcopy of this document a few weeks ago. Please let me know if you haven't. (That goes for anyone else that needs a copy, too)). I have assumed that X9.57 and X9.55 would be integrating details on constructing and encoding Diffie-Hellman certificates. I.e., I deliberately ommitted a D-H certificate section since I considered out of scope. As such, I only specified public number and system parameter syntax and encoding in X9.42. Basically, I agree that the X9.57 ARC should be used for certificates but I disagree regarding the use of the X9.57 ARC for the public numbers and system parameters. Why not stick with the X.42 ARC for those? Regards, -John Kennedy p.s. For follow-ups, I suggest we prune down the distribution to only Cc: ietf-pkix@tandem.com and ipsec@tis.com From: John Marchioni To: "jkennedy@cylink.com" , "'carlisle (c.m.) adams'" Cc: "johnmarc@cylink.com" , "ipsec@tis.com" , "ietf-pkix@tandem.com" , "isakmp-oakley@cisco.com" , "skip-info@tik.ee.ethz.ch" Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Date: Mon, 23 Sep 1996 10:40:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609240717.aa12310@neptune.TIS.COM> That's correct, it should have been "section 7" of "pkix-1" which is = essentially correct but we don't like the current OID value for DSA with = SHA1, looks like the leftover from the NIST OIW/OSE. =20 Warwick just distributed a softcopy of a paper from his work with the = NIST PKI TWG which seems to be comprehensive in filling in the holes for = DSA certs. If Warwick folds this into "section 7" then I think the DSA = cert profile work for IETF is complete for now. =20 The Diffie-Hellman cert profile should be added next when it is agreed = that the D-H cert section of ANSI X9.42 is stable. I recommend that the = IETF and ANSI X9.42 use the same ARC for OIDs as in X9.57 when dealing = with D-H keys and certificates, if this ARC is registered and valid. - John ---------- From: carlisle (c.m.) adams Sent: Monday, September 23, 1996 7:23 AM To: jkennedy@cylink.com Cc: johnmarc@cylink.com; ipsec@tis.com; ietf-pkix@tandem.com; = isakmp-oakley@cisco.com; skip-info@tik.ee.ethz.ch Subject: re:NOTICE: DSS Profile for X.509 Certificates to be deleted.=20 In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.",=20 jkennedy@cylink.com writes: > >I received the following message from the Internet-Drafts Administrator = about=20 >a month ago regarding the deletion of the I-D John Marchioni and I = co-authored=20 >on a "DSS Profile for X.509 Certificates". This draft was submitted = only as=20 >an interim solution since the PKIX was just coming up to speed and had = not yet=20 >included this material in the PKIX draft. I do not know exactly what = the=20 >status of the X.509 DSS profile is in the PKIX document so I am sharing = this=20 >current status information with you now. As far as I know DSS = Certificates=20 >are being used in both the SKIP and ISAKMP/Oakley reference = implementations=20 >and the aforementioned draft is cited in the applicable I-D's for these = key=20 >management protocols. > >I have a number of choices: > >a) Do nothing and let the draft gracefully expire. >b) Update and submit a revised draft of = To: ipsec@TIS.COM, gnu@toad.com Subject: Readable specs? Date: Mon, 23 Sep 1996 17:47:10 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609240718.aa12349@neptune.TIS.COM> Now that we've "decided" what the key management protocol will be called, does anyone plan to write a readable spec for it? Or are we doomed to produce the first IETF standard as incomprehensible as an OSI or ANSI standard? John Date: Mon, 23 Sep 1996 17:08:00 -0400 To: John Marchioni , "jkennedy@cylink.com" , "'carlisle (c.m.) adams'" From: Warwick Ford Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: "ipsec@tis.com" , "ietf-pkix@tandem.com" , "isakmp-oakley@cisco.com" , "skip-info@tik.ee.ethz.ch" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609240718.aa12331@neptune.TIS.COM> At 10:40 AM 9/23/96 -0700, John Marchioni wrote: >That's correct, it should have been "section 7" of "pkix-1" which is essentially correct but we don't like the current OID value for DSA with SHA1, looks like the leftover from the NIST OIW/OSE. > >Warwick just distributed a softcopy of a paper from his work with the NIST PKI TWG which seems to be >comprehensive in filling in the holes for DSA certs. If Warwick folds this into "section 7" then I think >the DSA cert profile work for IETF is complete for now. For the benefit of everyone, I have attached below a copy of the referenced e-mail from me. I won't include the uuencoded Word attachment on such a wide distribution as this message, but will send it to anyone requesting it. >The Diffie-Hellman cert profile should be added next when it is agreed that the D-H cert section of ANSI >X9.42 is stable. I recommend that the IETF and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with D-H keys and certificates, if this ARC is registered and valid. The X9.57 arc is certainly registered (under ANSI as an ANSI standard) and valid, and we have used it for X9.57 and X9.55. I would not object to using it also for X9.42 Warwick ---------------------------------- >Date: Mon, 23 Sep 1996 10:39:36 -0400 >To: pki-twg@csmes.ncsl.nist.gov,housley@spyrus.com >From: Warwick Ford >Subject: DSA Algorithm Definitions >X-Attachments: C:\Business\ANSIX9\Algids.doc; > >Attached are the latest algorithm definitions from ANSI X9.57. When Russ, Rich Ankney, and I devised this set, we hoped we had developed one answer that would satisfy everyone (ANSI, PKIX, and the FPKI). > >There are 3 algorithmIds: >- dsa - has p, q, and g parameters - for use in subjectPublicKeyInfo >- dsa-with-sha-1 - no parameters - for use in the signature fields >- dsa-match - has key length as parameter - for use in those situations where you want to determine the capabilities of a remote system, e.g., in supportedAlgorithms attribute > >Warwick > ------------------------------------------------------------------- Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 ------------------------------------------------------------------- Date: Tue, 24 Sep 96 09:35:55 EDT From: "W. Douglas Maughan" Message-Id: <9609241335.AA04357@dolphin.ncsc.mil> To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Readable specs? Sender: ipsec-approval@neptune.tis.com Precedence: bulk John, > Now that we've "decided" what the key management protocol will be > called, does anyone plan to write a readable spec for it? Or are we > doomed to produce the first IETF standard as incomprehensible as an > OSI or ANSI standard? We are in the process of editing and improving the existing ISAKMP Internet-Draft. As it was explained to me by the IPSEC co-chairs, we have the following timeline: 4 November I-D available for Working Group Late Nov. WG chairs will issue Last Call (NOTE: Last Call will include the Dec. IETF) Late Dec. Last Call will be completed (RAN/PAUL: Please correct me if I'm wrong) This will meet the schedule proposed by Jeff Schiller in his Security AD Statement (i.e. Jan 97 - Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard). We welcome all comments, corrections, etc. pertaining to the existing ISAKMP I-D (draft-ietf-ipsec-isakmp-05). If you have specific text you would like to propose for version 6 of the draft that would be great. Regards, Doug Maughan Date: Tue, 24 Sep 1996 10:45:13 -0400 To: Germano Caronni , skip-info@skip.org, Project SKIP , Bernhard Plattner , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: The skip-info mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609241057.aa15315@neptune.TIS.COM> At 01:20 PM 9/23/96 +0200, Germano Caronni wrote: >The SKIP internal mailing list 'skip-info@tik.ee.ethz.ch' has moved. It is >now located at skip-info@skip.org. > OMG, what they let into .ORG these days ;) Is there really a registered (someplace on this planet) SKIP organization? Facinating. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa18961; 24 Sep 96 16:02 EDT Received: by relay.hq.tis.com; id QAA26177; Tue, 24 Sep 1996 16:05:40 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026166; Tue, 24 Sep 96 16:05:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07311; Tue, 24 Sep 96 16:04:20 EDT Received: by relay.hq.tis.com; id QAA26156; Tue, 24 Sep 1996 16:05:11 -0400 Received: from netcom14.netcom.com(192.100.81.126) by relay.tis.com via smap (V3.1.1) id xma026152; Tue, 24 Sep 96 16:05:09 -0400 Received: (from andrade@localhost) by netcom14.netcom.com (8.6.13/Netcom) id NAA16332; Tue, 24 Sep 1996 13:07:17 -0700 From: Andrade Software Andrade Networking Message-Id: <199609242007.NAA16332@netcom14.netcom.com> Subject: Re: "user" and "network layer" security. To: karn@qualcomm.com Date: Tue, 24 Sep 1996 13:07:16 -0700 (PDT) Cc: netsec@panix.com, ipsec@TIS.COM In-Reply-To: <9608260715.aa04497@neptune.TIS.COM> from "Phil Karn" at Aug 26, 96 07:15:18 am Sender: ipsec-approval@neptune.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2459 Mitch Nelson: > >"User" based security and "network layer" security can each be designed > >and implemented in ways that are consistent with the established network > >architecture. With some pro-forma cross consultation, one should expect > >to arrive at reasonable results that provide good security without > >conflict and without unduly compromising present network functionality. > >The alternative does not offer as much grounds for optimism. Therefore it > >seems that all lanquage related to "user" should be expunged from IPSEC > >and instead treated in a seperate discussion group. Phil Karn: > If the IPSEC group's work is to ever have any relevance, it must > return to the original, bare-bones goal of building protected > "tunnels" at the host-to-host or subnet-to-subnet level of > granularity. There's still plenty of need for this function, but > trying to do more than this is likely to continue to get us nowhere. > Mitch and Phil are right. Security at the IP layer should concentrate only on providing authentication of packets between IP addresses, integrity of the IP packets and their data payloads, and encryption of the data payloads. I believe that the critical problems that need to be solved are: 1. Ensuring that two network level entities are allowed to exchange IP packets. The best solution that I've seen requires a trusted central server to issue permits to the two communicating entities. This centralizes access control and auditing. 2. Enrollment of network entities. This is a key step that establishes entity trust that must be done correctly or all security in the system will be worthless. 3. Raw encryption (and authentication) performance can't keep up with the network speeds required by routers and protocol stacks. Right now DES and other bulk ciphers are too slow without a hardware boost. RSA and Diffie-Hellman are so slow that it is impossible to seriously contemplate them. Especially once you realize that they don't confer a significant advantage in establishing trust between entities (see #2 about enrollment above). Hashes such as the MD5 HMAC are a step forward, but they still cost hundreds of CPU cycles per byte. - Alex -- Alexander I. Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 426-1528 Voice (510) 417-0159 FaxVoice Message-Id: <01BBAA1D.AC418850@lobster> From: John Marchioni To: wford@mail.intranet.ca, johnmarc@cylink.com, cadams@nortel.ca Cc: ipsec@TIS.COM, ietf-pkix@tandem.com, isakmp-oakley@cisco.com Subject: RE: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Date: Tue, 24 Sep 1996 13:38:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk { JK's comments } Basically, I agree that the X9.57 ARC should be used for certificates = but I=20 disagree regarding the use of the X9.57 ARC for the public numbers and = system parameters. Why not stick with the X.42 ARC for those? Regards, -John Kennedy p.s. For follow-ups, I suggest we prune down the distribution to only = Cc:=20 ietf-pkix@tandem.com and ipsec@tis.com OK by me, I thought X9.42 was still lacking a registered ARC, that's the = only reason I suggested using X9.57's ARC. It would be nice, if X9.57 = does include the Diffie-Hellman certificate profile, to have all related = OIDs for Diffie-Hellman (the X9.42 OID values) also included in X9.57, = just a suggestion. - John Marchioni Received: from relay.hq.tis.com by neptune.TIS.COM id aa28714; 25 Sep 96 13:34 EDT Received: by relay.hq.tis.com; id NAA00745; Wed, 25 Sep 1996 13:37:55 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000614; Wed, 25 Sep 96 13:36:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15868; Wed, 25 Sep 96 13:34:47 EDT Received: by relay.hq.tis.com; id NAA00206; Wed, 25 Sep 1996 13:35:20 -0400 Received: from chirality.rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma018188; Wed, 25 Sep 96 13:24:19 -0400 Received: from snail.rsa.com by RSA.COM with SMTP id AA15804; Wed, 25 Sep 96 09:45:20 PDT Received: from cc:Mail by snail.rsa.com id AA843671581; Wed, 25 Sep 96 09:50:40 PST Date: Wed, 25 Sep 96 09:50:40 PST From: tim Message-Id: <9608258436.AA843671581@snail.rsa.com> To: ipsec@TIS.COM Subject: Interop Testing Sender: ipsec-approval@neptune.tis.com Precedence: bulk All, The S/WAN Initiative is sponsoring another round of IPSec interoperability testing, starting in the beginning of October. Three groups of testers are planned, according to their key management preference: ISAKMP/Oakley, Manual, or SKIP. This is an open test, designed to further interoperability and gain experience from implementation. Anyone interested can contact me directly and I will give you more details. Results of past tests can be found at http://www.rsa.com/rsa/SWAN. Regards, Tim Received: from relay.hq.tis.com by neptune.TIS.COM id aa02977; 25 Sep 96 20:42 EDT Received: by relay.hq.tis.com; id UAA14253; Wed, 25 Sep 1996 20:46:10 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014248; Wed, 25 Sep 96 20:45:43 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06791; Wed, 25 Sep 96 20:44:49 EDT Received: by relay.hq.tis.com; id UAA14240; Wed, 25 Sep 1996 20:45:41 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xmaa14218; Wed, 25 Sep 96 20:45:12 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id RAA19935; Wed, 25 Sep 1996 17:47:33 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id RAA23126; Wed, 25 Sep 1996 17:51:47 -0700 Message-Id: <199609260051.RAA23126@mailsun2.us.oracle.com> Date: 25 Sep 96 16:23:15 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: IPsec at Thirty-Seventh IETF Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: ipsec-approval@neptune.tis.com Precedence: bulk The IPsec working group will meet during the Thirty-Seventh IETF (December 9-13, 1996) in San Jose. Presentations on topics appropriate to the working group charter are solicited for this meeting. Note that priority will be given to presentations that are accompanied by internet drafts. Please send your requests for agenda slots to the co-chairs (rja@cisco.com, palamber@us.oracle.com). Paul Received: from relay.hq.tis.com by neptune.TIS.COM id aa07920; 26 Sep 96 8:45 EDT Received: by relay.hq.tis.com; id GAA19447; Thu, 26 Sep 1996 06:53:53 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma019445; Thu, 26 Sep 96 06:53:40 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16619; Thu, 26 Sep 96 06:52:34 EDT Received: by relay.hq.tis.com; id GAA19442; Thu, 26 Sep 1996 06:53:23 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma019440; Thu, 26 Sep 96 06:53:05 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id MAA26971; Thu, 26 Sep 1996 12:53:30 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id MAA15079; Thu, 26 Sep 1996 12:53:27 +0200 (MET DST) Message-Id: <199609261053.MAA15079@kom30.ethz.ch> Subject: Re: resistance to swamping attacks. To: Bill Sommerfeld Date: Thu, 26 Sep 1996 12:53:26 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <199609191630.MAA00380@thunk.orchard.medford.ma.us> from "Bill Sommerfeld" at Sep 19, 96 12:30:27 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bill Sommerfeld wrote: > Here's a more specific goal: > If a system has a normal communications bandwidth of X, and recieves > an incoming storm from forged source addresses with a bandwidth of Y > (less than X), it should be able to continue to use at least half of > the remaining bandwith (X-Y) constructively to communicate with > arbitrary legitimate peers, including peers which had never before > communicated with it. One issue here is probably that if a real packet storm occurs, the links to the attacked host become saturated, and no communication whatsoever can occur. Or at least: The bandwith for legitimate users sinks drastically towards 0. No protocol can fix this, if the routers do not help you. Assuming that only the end system is saturated, and the link would be able to carry more data, then perhaps two goals should be formulated: a) An endsystem which is flooded by a storm of connection establishment requests should try to distinguish 'real' connection requests (well, you could build a list of 'preferred hosts', e.g. hosts you had an conenction (or SA) lately, and handle these with a preferred ratio. If this is not possible or practial, at least all requests should have the same chance to succeed. And no, this would not be a very nice persepctive. (X-Y)/2 would not work here, as you do not a priori know who is legitimate, and who not. b) Existing connections (or SAs) should be given priority of use for CPU power and available bandwith. They should not suffer at all from somebody trying to establish (or forge the establishment) of a new connection. [Is this wise?] Another problem with the (X-Y)/2 approach might be that you do not *know* if any link upstream is not fully saturated by the attacker, denying you all your bandwith. Focussing on available end-system bandwith (CPU power, memory consumption) might be a good thing here. Comments anyone? Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa10198; 26 Sep 96 13:52 EDT Received: by relay.hq.tis.com; id NAA03229; Thu, 26 Sep 1996 13:56:29 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003220; Thu, 26 Sep 96 13:56:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14015; Thu, 26 Sep 96 13:55:13 EDT Received: by relay.hq.tis.com; id NAA03210; Thu, 26 Sep 1996 13:55:59 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma003203; Thu, 26 Sep 96 13:55:45 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 26 Sep 1996 10:58:09 -0700 Date: Thu, 26 Sep 1996 10:58:03 -0700 Posted-Date: Thu, 26 Sep 1996 10:58:03 -0700 Message-Id: <199609261758.AA25657@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Thu, 26 Sep 1996 10:58:03 -0700 To: sommerfeld@apollo.hp.com, caronni@tik.ee.ethz.ch Subject: Re: resistance to swamping attacks. Cc: ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Bill Sommerfeld wrote: > > Here's a more specific goal: > > If a system has a normal communications bandwidth of X, and recieves > > an incoming storm from forged source addresses with a bandwidth of Y > > (less than X), it should be able to continue to use at least half of > > the remaining bandwith (X-Y) constructively to communicate with > > arbitrary legitimate peers, including peers which had never before > > communicated with it. > > One issue here is probably that if a real packet storm occurs, the links to > the attacked host become saturated, and no communication whatsoever can > occur. Or at least: The bandwith for legitimate users sinks drastically > towards 0. No protocol can fix this, if the routers do not help you. > > Assuming that only the end system is saturated, and the link would be able > to carry more data, then perhaps two goals should be formulated: > > a) An endsystem which is flooded by a storm of connection establishment > requests should try to distinguish 'real' connection requests (well, you > could build a list of 'preferred hosts', e.g. hosts you had an conenction > (or SA) lately, and handle these with a preferred ratio. If this is not > possible or practial, at least all requests should have the same chance > to succeed. And no, this would not be a very nice persepctive. (X-Y)/2 > would not work here, as you do not a priori know who is legitimate, and > who not. > b) Existing connections (or SAs) should be given priority of use for CPU > power and available bandwith. They should not suffer at all from somebody > trying to establish (or forge the establishment) of a new connection. [Is > this wise?] These are what we came up with here. A more concise description we came up with is: a) All resources are FIRST allocated to existing connections. b) Remaining resources are allocated 'fairly' on a per-connection-attempt basis. c) Connections not fully established have a finite resource limit, BOTH individually and as an aggregate class. I think these are necessary and sufficient. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa11872; 26 Sep 96 17:40 EDT Received: by relay.hq.tis.com; id RAA10327; Thu, 26 Sep 1996 17:44:08 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010311; Thu, 26 Sep 96 17:43:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26097; Thu, 26 Sep 96 17:45:52 EDT Received: by relay.hq.tis.com; id RAA10308; Thu, 26 Sep 1996 17:43:38 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma010306; Thu, 26 Sep 96 17:43:28 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Thu, 26 Sep 1996 14:45:25 PDT Date: Thu, 26 Sep 1996 14:44:01 From: Rob Adams Message-Id: <19960926144401adams@161.44.128.127> To: ipsec@TIS.COM Subject: Comments on ESP and AH IPSEC drafts. X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk After implementing the IPSEC AH and ESP transforms, I have a few comments I'd like to make on the drafts. Most of the comments I have concern the performance of the transforms. Although I've achieved performance numbers which are better than my expectations, there is always room for improvement. Also, the more closely the transforms perform to clear packets, the faster people will adopt IPSEC in general, obviously. ESP Draft (draft-ipsec-esp-des-md5-03.txt Sept 96): Section 2.2: Initialization Vector. I think including an IV in the packet should constitute a separate transform with a unique IANA designation. Optional fields slow performance and in this case, the keying material and caching information are different even though most of the actual operation is substantially the same. A separate transform designation would allow implementations treat the packets differently, to store cached information differently and process packets uniformly without in-line testing. Implementations could achieve the same effect by sub-categorizing transform designations on their own, however a separate designation would allow the transforms to diverge in order to support hardware assist (original intention) and to simplify SA negotiation for transforms without the IV. Section 2.3: Replay Prevention. I don't see the purpose of negotiated window sizes unless there is some vulnerability in accepting out of order packets. I don't know of any such vulnerabilities but if there are, it would be nice if they were called out in the draft. If there are no such vulnerabilities, then why would I ever want to NOT support receiving packets out of order if my implementation supports a sliding window? If I'm communicating with a host that does not have a window, I'll be re-transmitting a lot of packets but there is no reason for me not to accept packets out of order. This seems like an implementation detail not to be negotiated. Section 2.5: Padding. I would like to suggest placing the Payload Type, Pad Length and padding fields before the payload data. Stop laughing. After having implemented this, I can say that it would be a heck of a lot more efficient and therefore, perform better, if I didn't have to walk an MBUF chain twice to remove padding. You have to do this twice because you have to go to the end first to get the length of the padding. Since the padding could be spread out of a variable number of buffers behind you, you have to start at the head again and walk down until you find the buffer containing packet[length-pad], and free from there. Chopping the data off the head of the buffer chain would save this walk and some hairy math to crop the right size of data off the end. The HMAC data at the end isn't as much of a problem because you can find it on the first pass. Placing it at the head however would remove the buffer chain walk completely. I don't know if this is enough of a win to change its location, considering the buffer would have to zero'd as is the case with AH. AH Draft (draft-ietf-ipsec-ah-hmac-md5-02.txt Aug 96) Section 2.1: Replay Prevention. The replay field, as described, is NOT similar to the replay field described in the document ESP-DES-MD5 document. ESP-DES-MD5 contains only a 32 bit field while this document calls for a 64 bit field. Also, the paragraph concerning the key lifetime not exceeding the period to transmit 2^64 packets contradicts other statement made in document. The section on keys states, "Thus implementations should, and as frequently as possible, change the AH key." It seems a 32 bit replay field would be more in line with key refresh needs. If we agree to a 64 bit field for easier support on 64 bit architectures, it may be wise to support using only 32 bits for key refresh purposes anyway. Also, for performance sake, could we make the field non-optional? If the key negotiation determines the parties not do replay detection, the field should still exist, left untested. This would fix the overhead of the header and reduce testing and gyrations around optional fields in the middle of the header. If it is truly to be optional, lets move it to after the authentication data. As an overall comment, the AH document does not include varied keys for initiator and responder as the ESP document does. Shouldn't we vary the keys in the same manner? Comments anyone? ------------------------------------------------ Rob Adams adams@cisco.com Cisco Systems 408 457 5200 101 Cooper St. Santa Cruz, CA 95060 Received: from relay.hq.tis.com by neptune.TIS.COM id aa15901; 27 Sep 96 5:09 EDT Received: by relay.hq.tis.com; id FAA16608; Fri, 27 Sep 1996 05:12:13 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma016606; Fri, 27 Sep 96 05:12:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11568; Fri, 27 Sep 96 05:13:56 EDT Received: by relay.hq.tis.com; id FAA16603; Fri, 27 Sep 1996 05:11:43 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma016601; Fri, 27 Sep 96 05:11:34 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id LAA08636; Fri, 27 Sep 1996 11:13:54 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id LAA16128; Fri, 27 Sep 1996 11:13:49 +0200 (MET DST) Message-Id: <199609270913.LAA16128@kom30.ethz.ch> Subject: Re: resistance to swamping attacks. To: touch@isi.edu Date: Fri, 27 Sep 1996 11:13:48 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <199609261758.AA25657@ash.isi.edu> from "touch@ISI.EDU" at Sep 26, 96 10:58:03 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk touch@ISI.EDU wrote: > a) All resources are FIRST allocated to existing > connections. > > b) Remaining resources are allocated 'fairly' on > a per-connection-attempt basis. > > c) Connections not fully established have a finite > resource limit, BOTH individually and as an > aggregate class. > > I think these are necessary and sufficient. Right. I fully agree. Now it would be interesting, how you can modfiy the protocol used for connection attempts to make life for swamping attacks *much* harder. The cookie approach certainly does this. The idea [expense for the sender, cheap verification for the receiver] is interesting, but fails if precomputing can happen on the sending side. Others? Germano Received: from relay.hq.tis.com by neptune.TIS.COM id aa18547; 27 Sep 96 9:53 EDT Received: by relay.hq.tis.com; id JAA21959; Fri, 27 Sep 1996 09:56:40 -0400 From: HUGO@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021939; Fri, 27 Sep 96 09:56:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21091; Fri, 27 Sep 96 09:58:20 EDT Received: by relay.hq.tis.com; id JAA21936; Fri, 27 Sep 1996 09:56:06 -0400 Received: from unknown(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma021928; Fri, 27 Sep 96 09:55:43 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id JAA04970; Fri, 27 Sep 1996 09:55:10 -0400 Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id JAA739976; Fri, 27 Sep 1996 09:55:09 -0400 Message-Id: <199609271355.JAA739976@mailhub1.watson.ibm.com> Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0177; Fri, 27 Sep 96 09:55:06 EDT Date: Fri, 27 Sep 96 09:47:02 EDT To: caronni@tik.ee.ethz.ch, touch@isi.edu Cc: ipsec@TIS.COM Subject: resistance to swamping attacks. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ref: Your note of Fri, 27 Sep 1996 11:13:48 +0200 (MET DST) (attached) > The cookie approach certainly does this. The idea [expense > for the sender, cheap verification for the receiver] is interesting, but > fails if precomputing can happen on the sending side. Others? > > Germano To avoid the benefits of pre-computing you need to have some kind of "fresh challenge" sent from receiver to sender. This requires an additional round-trip (like Karn's cookies do). If one does not add the round trip, one can still make the life of the sender somewhat harder by mixing into the "hard" problem to be solved (by the sender) both the receiver's IP address and the time of the connection. Precomputation is then possible but the product of that computation must be used with a particular host and withing a time limit. Hugo Received: from relay.hq.tis.com by neptune.TIS.COM id aa18989; 27 Sep 96 10:26 EDT Received: by relay.hq.tis.com; id KAA22826; Fri, 27 Sep 1996 10:30:11 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022822; Fri, 27 Sep 96 10:30:04 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23325; Fri, 27 Sep 96 10:31:58 EDT Received: by relay.hq.tis.com; id KAA22813; Fri, 27 Sep 1996 10:29:41 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma022808; Fri, 27 Sep 96 10:29:33 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id QAA13976; Fri, 27 Sep 1996 16:31:47 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id QAA16593; Fri, 27 Sep 1996 16:31:42 +0200 (MET DST) Message-Id: <199609271431.QAA16593@kom30.ethz.ch> Subject: Re: resistance to swamping attacks. To: HUGO@watson.ibm.com Date: Fri, 27 Sep 1996 16:31:40 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <199609271355.JAA739976@mailhub1.watson.ibm.com> from "HUGO@watson.ibm.com" at Sep 27, 96 09:47:02 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk HUGO@watson.ibm.com wrote: > If one does not add the round trip, one can still make the life of the > sender somewhat harder by mixing into the "hard" problem to be solved (by > the sender) both the receiver's IP address and the time of the connection. > Precomputation is then possible but the product of that computation must > be used with a particular host and withing a time limit. Time does pose a problem here. As I was educated on the list ;-) we can not assume even loosely synchronized systems, thus if A wants to connect to B, B has to tell a its internal time (or sequence number, or whatever) first, resulting in the round trip... Germano To: Rob Adams Cc: ipsec@TIS.COM Subject: Re: Comments on ESP and AH IPSEC drafts. In-Reply-To: Your message of "Thu, 26 Sep 1996 14:44:01." <19960926144401adams@161.44.128.127> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 27 Sep 1996 10:04:59 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609271227.aa20204@neptune.TIS.COM> Rob Adams writes: > I think including an IV in the packet should constitute a separate > transform with a unique IANA designation. Optional fields slow > performance and in this case, the keying material and caching information > are different even though most of the actual operation is substantially > the same. Without an IV, what you are running is the ECB mode of these algorithms which is highly insecure. I do not think that should be encouraged. > I don't see the purpose of negotiated window sizes unless there is some > vulnerability in accepting out of order packets. Serious denial of service attacks result if you are forced to keep an infinite window. Perry Message-Id: <199609271558.LAA10511@devildog.cis.upenn.edu> To: rgm3@chrysler.com Cc: Germano Caronni , skip-info@skip.org, Project SKIP , Bernhard Plattner , ipsec@TIS.COM Subject: Re: The skip-info mailing list In-Reply-To: Your message of "Tue, 24 Sep 1996 10:45:13 EDT." <3.0b19.32.19960924103441.00aa8900@pop3hub.is.chrysler.com> Date: Fri, 27 Sep 1996 11:58:23 EDT From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <3.0b19.32.19960924103441.00aa8900@pop3hub.is.chrysler.com>, Robert Moskowitz writes: >OMG, what they let into .ORG these days ;) > >Is there really a registered (someplace on this planet) SKIP organization? >Facinating. > FYI, there's a detergent brand named SKIP in Greece. I'm unaware of any relation between them and Sun Microsystems. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMkv5mL0pBjh2h1kFAQHdhgP/emuNfrCRC7NmN62Cw9DSKD6E+yzyJTv1 +xTOOnJjfhA3eIsf0sNzWAj5S/3gIXZ0oD68zrI6op/6T7zxYGZh7bs3kHYH5M7P qfGSCnedo4EZ1R/oyHsYG0e14GtxDQZS+2A8y/lIgohY0OPdb/zIMbi4uRyKvhVr 4WMRMjd/o4c= =WsGN -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa21132; 27 Sep 96 13:18 EDT Received: by relay.hq.tis.com; id NAA28284; Fri, 27 Sep 1996 13:21:59 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma028261; Fri, 27 Sep 96 13:21:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02216; Fri, 27 Sep 96 13:23:54 EDT Received: by relay.hq.tis.com; id NAA28216; Fri, 27 Sep 1996 13:21:31 -0400 Received: from border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma028159; Fri, 27 Sep 96 13:20:58 -0400 Received: by janus.border.com id <18476-2>; Fri, 27 Sep 1996 13:21:28 -0400 Message-Id: <96Sep27.132128edt.18476-2@janus.border.com> To: Rob Adams Cc: ipsec@TIS.COM Subject: Re: Comments on ESP and AH IPSEC drafts. References: <19960926144401adams@161.44.128.127> In-Reply-To: Your message of "Thu, 26 Sep 1996 10:44:01 -0400". <19960926144401adams@161.44.128.127> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 27 Sep 1996 13:23:05 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <19960926144401adams@161.44.128.127>, Rob Adams writes: > I would like to suggest placing the Payload Type, Pad Length and padding > fields before the payload data. Stop laughing. After having implemented > this, I can say that it would be a heck of a lot more efficient and > therefore, perform better, if I didn't have to walk an MBUF chain twice to > remove padding. Ah, there's the problem; you're using MBUFs. :-) IME, when using MBUFs there are much worse performance problems than 'walking the chain twice' to remove the padding. Get yourself an MBUF-less kernel... > Since the padding could be > spread out of a variable number of buffers behind you, you have to start at > the head again and walk down until you find the buffer containing > packet[length-pad], and free from there. If your network device drivers are at all sensible, you'll be receiving (almost) all packets in single MBUFs. optimize for that case, and special-case the process for badly formed packets; you'll get all the performance you need without changing the transforms. Padding at the end greatly assists hardware implementations on the transmitting side. Since data buffers are usually front-aligned by the networking code, you can simply pad/type, and then pass the entire (aligned) buffer to the hardware. -- C. Harald Koch | Senior System Developer, BorderWare Firewall Server chk@border.com | Secure Computing Canada Ltd. +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.hq.tis.com by neptune.TIS.COM id aa21582; 27 Sep 96 13:51 EDT Received: by relay.hq.tis.com; id NAA29813; Fri, 27 Sep 1996 13:55:22 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma029806; Fri, 27 Sep 96 13:55:11 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03938; Fri, 27 Sep 96 13:57:17 EDT Received: by relay.hq.tis.com; id NAA29797; Fri, 27 Sep 1996 13:54:52 -0400 Received: from border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma029791; Fri, 27 Sep 96 13:54:48 -0400 Received: by janus.border.com id <18435-1>; Fri, 27 Sep 1996 13:55:28 -0400 Date: Fri, 27 Sep 1996 13:57:01 -0400 From: Norman Shulman To: ipsec@TIS.COM Cc: Rob Adams Subject: Re: Comments on ESP and AH IPSEC drafts. In-Reply-To: <19960926144401adams@161.44.128.127> Message-Id: <96Sep27.135528edt.18435-1@janus.border.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Thu, 26 Sep 1996, Rob Adams wrote: > ESP Draft (draft-ipsec-esp-des-md5-03.txt Sept 96): > > Section 2.5: Padding. > > I would like to suggest placing the Payload Type, Pad Length and padding > fields before the payload data. Stop laughing. After having implemented > this, I can say that it would be a heck of a lot more efficient and > therefore, perform better, if I didn't have to walk an MBUF chain twice to > remove padding. You have to do this twice because you have to go to the > end first to get the length of the padding. Since the padding could be > spread out of a variable number of buffers behind you, you have to start at > the head again and walk down until you find the buffer containing > packet[length-pad], and free from there. Chopping the data off the head of > the buffer chain would save this walk and some hairy math to crop the right > size of data off the end. In Net/3 code, the padding can span at most 2 mbufs, so you only need to keep track of the current and previous mbufs. Norm Norman Shulman Border Network Technologies Inc. Software Engineer Tel 1 416 368 7157 ext 304 norm@border.com Fax 1 416 368 7178 Received: from relay.hq.tis.com by neptune.TIS.COM id aa23845; 27 Sep 96 16:33 EDT Received: by relay.hq.tis.com; id QAA06036; Fri, 27 Sep 1996 16:37:15 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma006030; Fri, 27 Sep 96 16:36:46 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13631; Fri, 27 Sep 96 16:38:57 EDT Received: by relay.hq.tis.com; id QAA06024; Fri, 27 Sep 1996 16:36:45 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma006018; Fri, 27 Sep 96 16:36:15 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 27 Sep 1996 13:38:38 -0700 Date: Fri, 27 Sep 1996 13:38:37 -0700 Posted-Date: Fri, 27 Sep 1996 13:38:37 -0700 Message-Id: <199609272038.AA06712@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Fri, 27 Sep 1996 13:38:37 -0700 To: touch@isi.edu, caronni@tik.ee.ethz.ch Subject: Re: resistance to swamping attacks. Cc: ipsec@TIS.COM X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > touch@ISI.EDU wrote: > > a) All resources are FIRST allocated to existing > > connections. > > > > b) Remaining resources are allocated 'fairly' on > > a per-connection-attempt basis. > > > > c) Connections not fully established have a finite > > resource limit, BOTH individually and as an > > aggregate class. > > > > I think these are necessary and sufficient. > > Right. I fully agree. Now it would be interesting, how you can modfiy the > protocol used for connection attempts to make life for swamping attacks > *much* harder. The cookie approach certainly does this. The idea [expense > for the sender, cheap verification for the receiver] is interesting, but > fails if precomputing can happen on the sending side. Others? > > Germano I disagree. There is a certain processing and storage cost (and duration) to maintaining half-open connections. Adding cookies to the connection attempt does not substantially reduce the storage cost (still have to store the incoming packet, cookie, and state vs. a TCP connection control block). It does increase the processing cost (checking the validity of the exchange). It does not decrease the time the state needs to be kept. As a result, limiting the processing of ALL connection attempts is the only viable solution. Security exchanges, in this case, would be better left to validating the connection after the first packet exchange. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa23689; 30 Sep 96 16:55 EDT Received: by relay.hq.tis.com; id QAA15509; Mon, 30 Sep 1996 16:59:31 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015493; Mon, 30 Sep 96 16:59:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19389; Mon, 30 Sep 96 17:01:11 EDT Received: by relay.hq.tis.com; id QAA15484; Mon, 30 Sep 1996 16:59:01 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma015445; Mon, 30 Sep 96 16:58:34 -0400 Received: from 161.44.128.127 ([161.44.128.127]) by HQ.CISCO.COM via INTERNET ; Mon, 30 Sep 1996 13:59:42 PDT Date: Mon, 30 Sep 1996 13:57:52 From: Rob Adams Message-Id: <19960930135752adams@161.44.128.127> To: gnu@toad.com Subject: Re: Comments on ESP and AH IPSEC drafts. Cc: ipsec@TIS.COM X-Mailer: Pronto Mail [tgv Ver 2.03] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Isn't it true that the most common (as opposed to most general) case >is that these fields can be removed from the mbuf chain by simply >decreasing the byte count in the last mbuf? Like Van Jacobson's >fast-path TCP code, you look for the common case first and do it >quickly. Then, 95% of the time, you don't have to search the chain >twice, or release any trailing whole mbuf's. > Finding the payload type and padding length is very simple and I wouldn't mind leaving them at the end. It has been rare, in my experience, that the payload type and padding length have been split between MBUFs. The problem is the padding itself. It could be spread out over up to three MBUFs if your driver fills out MBUFs completely, which drivers don't. You won't know this until you're at the end of the chain. The best case is when the padding is small and the chain is filled out such that the padding is included with the signature and trailing data in the last MBUF along with 1 or more bytes of the payload. In reality, this happens very infrequently. In any other case you must manipulate MBUFs that are before you in the chain. Someone else mentioned that if you're driver gives you the packet in a cluster, you're all set. This is true in most cases where MTU is smaller than your cluster size, but if your clusters are less than 1/2 your MTU, you'll have the same problem. For instance, an MTU size of 4352 for FDDI and an implemenation with clusters of 2048 bytes. >By the way, intuitively it seems that this kind of bookkeeping >overhead contributes insignificantly to poor performance; True, that these gyrations add little compared to the encryption itself. But every little bit helps and the bookkeeping and operations aren't necessary if the padding is up front. As far as the IV being optional and the Replay field being optional in AH is that we have a variable option in the middle of a fixed header. If we are going to allow for IV's optionally in the header, then I think this should be in a fixed header for another transform. As far as AH goes, if we are going to keep an optional replay field, we should move the replay field to the end of the AH header, after the signature. Why is the AH replay field 64 bits anyway? -Rob