From owner-ipsec Thu Jan 2 11:16:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15043 for ipsec-outgoing; Thu, 2 Jan 1997 11:07:12 -0500 (EST) Message-Id: <199701021610.LAA00681@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: dennis.glatting@plaintalk.bellevue.wa.us Cc: phan@itd.nrl.navy.mil, cmetz@inner.net, danmcd@eng.sun.com, ipsec@tis.com Subject: Re: Comment regarding draft-mcdonald-pf-key-v2-00.txt In-Reply-To: dennis.glatting's message of Tue, 31 Dec 1996 17:47:17 -0800. <199701010147.RAA02144@imo.plaintalk.bellevue.wa.us> Date: Thu, 02 Jan 1997 11:10:03 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Assuming the kernel is supposed to generate the IV, why not > allow the PF_KEY interface transfer an IV? It seems to me, if an > external hardware were available, random data would be best > obtained by a user level application rather than the kernel. I don't agree. 1) Assuming we're talking about UNIX-like systems (monolithic large kernel), I'm not sure this statement is really true.. especially given the work by Don Davis and others sampling randomness from disk drives and Ted Ts'o's /dev/random driver for linux (which also exports a kernel-internal API for kernel code which needs strong randomness). 2) even if it were true, I don't think PF_KEY is the right place to put a "deliver random bitstream to kernel" interface. For any number of reasons, you really want a "pipe" of randomness, not a request-response protocol. - Bill From owner-ipsec Thu Jan 2 12:40:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15775 for ipsec-outgoing; Thu, 2 Jan 1997 12:39:05 -0500 (EST) Message-Id: <199701021742.JAA00730@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 2 Jan 97 09:41:59 -0800 To: Bill Sommerfeld Subject: Re: Comment regarding draft-mcdonald-pf-key-v2-00.txt cc: dennis.glatting@plaintalk.bellevue.wa.us, phan@itd.nrl.navy.mil, cmetz@inner.net, danmcd@eng.sun.com, ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701021610.LAA00681@thunk.orchard.medford.ma.us> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Assuming the kernel is supposed to generate the IV, why not > > allow the PF_KEY interface transfer an IV? It seems to me, if an > > external hardware were available, random data would be best > > obtained by a user level application rather than the kernel. > > I don't agree. > > 1) Assuming we're talking about UNIX-like systems > (monolithic large kernel), I'm not sure this statement is > really true.. especially given the work by Don Davis and others > sampling randomness from disk drives and Ted Ts'o's > /dev/random driver for linux (which also exports a > kernel-internal API for kernel code which needs strong > randomness). > Yes, a UNIX like system: Mach. > 2) even if it were true, I don't think PF_KEY is the right place to > put a "deliver random bitstream to kernel" interface. For any > number of reasons, you really want a "pipe" of randomness, not a > request-response protocol. > The reasons I think query/response is a reasonable alternative are: * I do not have source for my kernel (and not likely to ever get it) thus probing interfaces and buffers is somewhat problematic. Not having kernel source requires the operating system vendor to implement a PF_KEY domain. I think this is a little too ambitious and less likely to happen for legacy systems. Not having source forces me to diverge from the spec. Perhaps a reasonable alternative to creating a socket in the PF_KEY domain is to open a device? * One of my random data sources is an open mic indirectly accessible via /dev. To use that device I have to implement some mechanism to tell the kernel it (or another) may be available as a random data source. Also, its interface is through a given API not usable within the kernel. -dpg From owner-ipsec Fri Jan 3 09:14:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22005 for ipsec-outgoing; Fri, 3 Jan 1997 09:09:16 -0500 (EST) Date: Fri, 3 Jan 1997 00:22:52 -0500 From: Ran Canetti Message-Id: <9701030522.AA17553@ornavella.watson.ibm.com> To: hughes@nsco.network.com, narten@raleigh.ibm.com Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard Cc: ipsec@tis.com Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk >From: "James Hughes" >Message-Id: > >>> > 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. > ... > >Since the count is encrypted (and assuming the attacker does not have the >DES key and therefore can not create known non-duplicate counts), detecting >someone trying to clog can be performed by decrypting the first block and >seeing -if- the decrypted count is reasonably valid (since the attacker can >not control what the data looks like after the decryption step). > -This may not always hold: Note that in DES-CBC the first block of the ciphertext is computed as C = DES(M + IV) where + denotes XOR and M is the first block of the message. (Here M includes the replay prevention counter.) Therefore, when the IV is specified in the header it is easy to "spoof" the quick-check that decrypts only the first block and verifies that the replay counter value is "reasonable": In order to generate a packet that looks like it has a counter value close to the current one, keep the ciphertext the same, but slightly modify the appropriate bits of the IV. (Ofcourse, when the entire packet is derypted and the HMAC is verified the spoofing will be revealed...) Ran Canetti BTW, if the replay counter were always in the second (or subsequent) 64-bit block then the above attack would be impossible. From owner-ipsec Fri Jan 3 09:59:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22358 for ipsec-outgoing; Fri, 3 Jan 1997 09:58:00 -0500 (EST) Message-Id: <3.0.16.19970103095702.364738dc@pop3.pn.com> X-PGP-Key: http://www.shore.net/~sable/info/rltkey.htm X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 03 Jan 1997 09:58:50 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: pf_key comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I am looking into implementing PF_KEY and I have some comments on this too: 1. I like the idea of sending the IV down from an application. I think that an application is a reasonable place to do the random number generation because - -- I too don't have all my kernel sources - -- I don't think the kernel IPSEC component should be using other parts of the kernel in weird ways as randomization sources 2. I wish there was some a notification mechanism for events. As per 2026 we have agreed it's germaine and legitimate to think about network management when developing Internet components. I have a requirement to generate events under certain conditions like perhaps when there is an encryption failure. Therefore I suggest there be two new messages, SADB_REGISTER_EVENT and SADB_MANAGEMENT_EVENT. SADB_REGISTER_EVENT works like SADB_REGISTER. SADB_MANAGEMENT_EVENT returns a base message followed by a proper SNMPv2 style trap message (this is chosen to be 2026 compliant!) I think it's appropriate to put this here because there isn't any other place to get these events, and the existing messages don't do this, and I believe we need network management. 3. I suggest we *not* claim SADB_DUMP be removed in the future. It's very useful for network managment. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMs0eLcKmlvJNktGxAQGzggQAmLaNHP9bJDtKI74UxbAMWZahuKjmIo+Y vjVEFqQ7J8hd4nlE0XNmCkyF1JdY/z9SQQ4eD0cfIxkdhvc9TVhfwgHpsRl8HA0M VeQu9SRZfLpOID0h0Om15kbf1kELhIl/iz31pHJY4sEKLq+lUT+nF6dbjwH4xu+5 E4Vhzg/S0vM= =wDB/ -----END PGP SIGNATURE----- Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Fri Jan 3 12:05:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23230 for ipsec-outgoing; Fri, 3 Jan 1997 12:01:08 -0500 (EST) Message-Id: <199701031703.MAA10942@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Rodney Thayer cc: ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 09:58:50 EST." <3.0.16.19970103095702.364738dc@pop3.pn.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 12:03:53 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > I am looking into implementing PF_KEY and I have some comments on this too: > > 1. I like the idea of sending the IV down from an application. I think > that an application is a reasonable place to do the random number > generation because Its completely unreasonable to send the IV from the application. Since IVs have to be sent on every packet, that would mean you would need to do a PF_KEY operation on every packet. This is not going to be feasable. Perry From owner-ipsec Fri Jan 3 12:29:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23355 for ipsec-outgoing; Fri, 3 Jan 1997 12:29:37 -0500 (EST) Message-Id: <3.0.16.19970103122103.2907efd0@pop3.pn.com> X-PGP-Key: http://www.shore.net/~sable/info/rltkey.htm X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 03 Jan 1997 12:30:22 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: pf_key comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I thought people were generating the IV once at the initialization of the S-A but I realize that could be wrong. The scheme still applies for generating the random seed for an IV, though, doesn't it? At 12:03 PM 1/3/97 -0500, you wrote: > >Rodney Thayer writes: >> I am looking into implementing PF_KEY and I have some comments on this too: >> >> 1. I like the idea of sending the IV down from an application. I think >> that an application is a reasonable place to do the random number >> generation because > >Its completely unreasonable to send the IV from the application. Since >IVs have to be sent on every packet, that would mean you would need to >do a PF_KEY operation on every packet. This is not going to be >feasable. > >Perry > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Fri Jan 3 13:18:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23662 for ipsec-outgoing; Fri, 3 Jan 1997 13:17:16 -0500 (EST) Message-Id: <2.2.32.19970103182640.00ba6404@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: Fri, 03 Jan 1997 13:26:40 -0500 To: perry@piermont.com From: Naganand Doraswamy Subject: Re: pf_key comments Cc: Rodney Thayer , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, >Its completely unreasonable to send the IV from the application. Since >IVs have to be sent on every packet, that would mean you would need to >do a PF_KEY operation on every packet. This is not going to be >feasable. > IV is optional field. This is used in cases where we use a constant IV. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Jan 3 13:23:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23740 for ipsec-outgoing; Fri, 3 Jan 1997 13:23:37 -0500 (EST) Message-Id: <199701031826.KAA01494@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Fri, 3 Jan 97 10:26:20 -0800 To: perry@piermont.com Subject: Re: pf_key comments cc: Rodney Thayer , ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701031703.MAA10942@jekyll.piermont.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I am looking into implementing PF_KEY and I have some comments on this too: > > > > 1. I like the idea of sending the IV down from an application. I think > > that an application is a reasonable place to do the random number > > generation because > > Its completely unreasonable to send the IV from the > application. Since IVs have to be sent on every packet, that > would mean you would need to do a PF_KEY operation on every > packet. This is not going to be feasable. > There is no need to do an operation for every packet. The kernel could ask for a block of random data and use it as it wishes. -dpg From owner-ipsec Fri Jan 3 14:42:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24348 for ipsec-outgoing; Fri, 3 Jan 1997 14:41:38 -0500 (EST) Message-Id: <199701031944.LAA01547@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Fri, 3 Jan 97 11:44:18 -0800 To: dennis.glatting@plaintalk.bellevue.wa.us Subject: Re: pf_key comments cc: perry@piermont.com, Rodney Thayer , ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701031703.MAA10942@jekyll.piermont.com> <199701031826.KAA01494@imo.plaintalk.bellevue.wa.us> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > I am looking into implementing PF_KEY and I have some comments on this too: > > > > > > 1. I like the idea of sending the IV down from an application. I think > > > that an application is a reasonable place to do the random number > > > generation because > > > > Its completely unreasonable to send the IV from the > > application. Since IVs have to be sent on every packet, that > > would mean you would need to do a PF_KEY operation on every > > packet. This is not going to be feasible. > > > > There is no need to do an operation for every packet. The kernel > could ask for a block of random data and use it as it wishes. > However, if we assume a 100mbs ethernet link ~85% efficient and 1024 byte packets (and enough CPU juice to handle that data :), that's ~10k packets per second. Using 8 bytes of random IV for each packet the kernel will require ~80k of random IV per second. It seems unreasonable for the kernel to acquire that amount of data from a user level process each second; however, I wonder whether pseudo random data generators can produce that amount of data at that rate too. If not, then pseudo random IV is useful for slow packet rates in which case it may be reasonable for the kernel to request random data from a user level process. -dpg From owner-ipsec Fri Jan 3 14:54:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24461 for ipsec-outgoing; Fri, 3 Jan 1997 14:54:08 -0500 (EST) Message-Id: <199701031956.OAA01250@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: pf_key comments In-Reply-To: rodney's message of Fri, 03 Jan 1997 12:30:22 -0500. <3.0.16.19970103122103.2907efd0@pop3.pn.com> Date: Fri, 03 Jan 1997 14:56:38 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I thought people were generating the IV once at the initialization of the > S-A but I realize that could be wrong. my understanding is that, for best security, the IV should be different for each packet. - Bill From owner-ipsec Fri Jan 3 15:05:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24548 for ipsec-outgoing; Fri, 3 Jan 1997 15:05:10 -0500 (EST) Message-Id: <199701032008.PAA11490@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dennis.glatting@plaintalk.bellevue.wa.us cc: ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 11:44:18 PST." <199701031944.LAA01547@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 15:08:12 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > However, if we assume a 100mbs ethernet link ~85% efficient and > 1024 byte packets (and enough CPU juice to handle that data :), > that's ~10k packets per second. Using 8 bytes of random IV for > each packet the kernel will require ~80k of random IV per > second. > > It seems unreasonable for the kernel to acquire that amount of > data from a user level process each second; however, I wonder > whether pseudo random data generators can produce that amount > of data at that rate too. If you can't crank a block cipher fast enough to generate a random sequence good enough for IVs, then you can't crank it fast enough to encrypt the plaintext, either. > If not, then pseudo random IV is useful > for slow packet rates in which case it may be reasonable for the > kernel to request random data from a user level process. I don't understand. If the kernel can't crank a cipher at a given rate, why would userland? Perry From owner-ipsec Fri Jan 3 16:29:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24993 for ipsec-outgoing; Fri, 3 Jan 1997 16:24:04 -0500 (EST) Message-Id: <97Jan3.162331est.30785-2@janus.border.com> To: Bill Sommerfeld cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments References: <199701031956.OAA01250@thunk.orchard.medford.ma.us> In-reply-to: sommerfeld's message of "Fri, 03 Jan 1997 14:56:38 -0500". <199701031956.OAA01250@thunk.orchard.medford.ma.us> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 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, 3 Jan 1997 16:22:06 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199701031956.OAA01250@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > > my understanding is that, for best security, the IV should be > different for each packet. Question: Does the IV have to be *unpredictably* different, or just different? (The NRL code, for example, simply increments the IV after each packet). -- C. Harald Koch chk@border.com From owner-ipsec Fri Jan 3 17:17:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25260 for ipsec-outgoing; Fri, 3 Jan 1997 17:17:15 -0500 (EST) Message-Id: <199701032220.RAA01331@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "C. Harald Koch" Cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments In-Reply-To: chk's message of Fri, 03 Jan 1997 16:22:06 -0500. <97Jan3.163527est.30870-1@janus.border.com> Date: Fri, 03 Jan 1997 17:20:09 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Does the IV have to be *unpredictably* different, or just different? The part of me which is a Paranoid Cryptographic Protocol Engineer would generate it with a CPRNG. The IV is sent in the clear. I don't think it makes a difference how different it is, but I'm not a Real Cryptographer(tm). - Bill From owner-ipsec Fri Jan 3 17:17:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25254 for ipsec-outgoing; Fri, 3 Jan 1997 17:16:25 -0500 (EST) Message-Id: <199701032217.RAA11629@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Bill Sommerfeld cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 14:56:38 EST." <199701031956.OAA01250@thunk.orchard.medford.ma.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 17:17:50 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > I thought people were generating the IV once at the initialization of the > > S-A but I realize that could be wrong. > > my understanding is that, for best security, the IV should be > different for each packet. Absolutely. The whole point of an IV is to assure that identical data doesn't encrypt identically. If you use the same IV each time, you've already lost. Perry From owner-ipsec Fri Jan 3 18:36:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25564 for ipsec-outgoing; Fri, 3 Jan 1997 18:35:15 -0500 (EST) From: hoodr@livingston.com Message-Id: <199701032338.PAA27813@server.livingston.com> Date: Fri, 3 Jan 1997 15:37:23 -0800 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Bill Sommerfeld , "C. Harald Koch" Subject: Re: pf_key comments Cc: Rodney Thayer , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Does the IV have to be *unpredictably* different, or just different? > >The part of me which is a Paranoid Cryptographic Protocol Engineer >would generate it with a CPRNG. > >The IV is sent in the clear. I don't think it makes a difference how >different it is, but I'm not a Real Cryptographer(tm). My understanding of CBC, was that the IV for each block was the output of the last CBC block (except of course for the very first block). I've just been carrying the last block over from the previous packet, and making that the next IV for the new packet. Since this is exactly whats happening within each packet, I figured (read guessed) that it was just as secure to extend it to the next packet. Obviously, I'm not a Real Cryptographer(tm) either :) From owner-ipsec Sun Jan 5 04:37:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA03376 for ipsec-outgoing; Sun, 5 Jan 1997 04:30:20 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701050933.BAA00135@netcom17.netcom.com> Subject: Re: IPsec and TCP To: ipsec@tis.com Date: Sun, 5 Jan 1997 01:33:17 -0800 (PST) Cc: naganand@ftp.com, ho@earth.hpc.org In-Reply-To: <199612202305.SAA10850@earth.hpc.org> from "Hilarie Orman" at Dec 20, 96 06:05:21 pm Sender: owner-ipsec@ex.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: 634 This is interesting. I knew that TCP/IP will be miserably slow when you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I forgot about the impact of key exchange performance. You'd be lucky to see 5 keys exchanged a second with Diffie-Hellman. Has anyone measured (or at least estimated) the performance metrics for IPsec routers (and hosts) to exchange/update keys? And on total IPsec routing performance, say with a mixture of clear and encrypted links, using various key update intervals. - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sun Jan 5 14:44:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05821 for ipsec-outgoing; Sun, 5 Jan 1997 14:42:58 -0500 (EST) Date: Sun, 5 Jan 1997 14:44:53 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199701051944.OAA10022@earth.hpc.org> To: andrade@netcom.com Cc: ipsec@tis.com, naganand@ftp.com In-reply-to: Yourmessage <199701050933.BAA00135@netcom17.netcom.com> Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie From owner-ipsec Sun Jan 5 16:24:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06166 for ipsec-outgoing; Sun, 5 Jan 1997 16:23:29 -0500 (EST) Date: Sun, 5 Jan 97 21:16:21 GMT Standard Time From: Ran Atkinson Subject: Re: IPsec and TCP To: Andrade Software Andrade Networking Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199701050933.BAA00135@netcom17.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Between a pair of 586/90 boxes running BSDI, NRL IPsec, and cisco's ikmpd(8), there is not a huge performance problem due to key management with the kinds of things I normally do (telnet, ftp, rlogin). In any event, a clever key mgmt implementation would acquire more than one IPsec SA at a time and cache the extra SAs in the key engine for future use. In such a case, there would generally be zero startup latency when locality holds (note that when locality does not hold, any inline key management scheme would also have a startup delay due to initial exchange of master keys (KEK) and algorithm information). Since the source to cisco's daemon is available (modulo export controls), anyone could add that feature to the daemon if they wished to do so. Since cisco's competitors are building products around the freely distributable cisco daemon, it would be unwise for cisco to spend lots of time optimising performance of its UNIX key management daemon. However, I speculate that if someone else did such performance optimisations, cisco might well be willing to incorporate context diffs. One would need to ask the maintainer of cisco's daemon to ascertain their policy on contributions of course. A couple of router vendors have implemented dynamic key management schemes based on D-H in their products. In both of the cases that I'm aware of, the D-H overhead is not a significant performance issue (probably in part due to thoughtful implementations). Ran rja@inet.org From owner-ipsec Sun Jan 5 16:47:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06293 for ipsec-outgoing; Sun, 5 Jan 1997 16:46:28 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sun, 05 Jan 1997 14:49:30 -0700 From: John Kennedy To: ho@earth.hpc.org, andrade@netcom.com Cc: naganand@ftp.com, ipsec@tis.com Subject: Diffie-Hellman Performance Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me add that careful choice of a secret exponent size commensurate with the size of the modulus, any underlying subgroup q, and the target algorithm you are deriving keying material for is also important. Using 160-bit or 256-bit exponents can be quite reasonable in many cases. Especially if the DH exchange at hand is only to provide bits for forward secrecy purposes. Compare this to using, say, a 1024-bit exponent, and things are going to be relatively zippy. For example, what purpose does it serve to use 1024-bit parameters if the algorithm you need keying material for is 40-bit DES? (Hilarie, maybe you could give a pointer to the presentation you gave at the Dallas IETF meeting on this.) For routers, servers, and other high-throughput machines, look for specialized co-processors dedicated to this purpose. Quite a few different companies have these in development for release this year and the economics and market are pulling the market in this direction. Look for 100 connections-per-second or so, including authentication, in the not-to-distant future. Besides, compared with all the other delays in building a connection over the Internet these days, this is a fraction of a second I'm willing to put up with. (Of course, your mileage may vary...) Even without the special silicon DH-based key agreement can be implemented quite efficiently. Using assembly-language optimized libraries and keeping your key and group parameter sizes realistic is the way to go. Using 2048-bit parameters when 512 bits is more appropirate is an easy mistake to make in any public-key application if you don't take the time to understand the attacks on the mechanisms you are using and the real security requirements and risks for your system. -John Kennedy jkennedy@novell.com >>> Hilarie Orman 01/05/97 12:44pm >>> > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie Received: from portal.ex.tis.com by prv1-mx.provo.novell.com ; 5 JAN 97 13:39:15 MDT Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05821 for ipsec-outgoing; Sun, 5 Jan 1997 14:42:58 -0500 (EST) Message-ID: <199701051944.OAA10022@earth.hpc.org> In-reply-to: Yourmessage <199701050933.BAA00135@netcom17.netcom.com> Content-Length: 989 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Sun, 05 Jan 1997 12:44:53 -0700 From: Hilarie Orman To: andrade@netcom.com Cc: naganand@ftp.com, ipsec@tis.com Subject: Re: IPsec and TCP > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie From owner-ipsec Mon Jan 6 14:02:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01208 for ipsec-outgoing; Mon, 6 Jan 1997 13:46:22 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: "Waterhouse, Richard" To: "'IPSEC Working Group'" Subject: Multi-DOI Messages Date: Mon, 6 Jan 1997 13:50:13 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipsec@ex.tis.com Precedence: bulk General question. I see nothing in the ISAKMP Draft that precludes including Payloads in the same message which apply to SAs negotiated under different DOIs. For example, if I have two SAs to which different DOIs apply I can have two Delete Payloads, one for each SA, included in the same Message. Is this a correct reading of the ISAKMP Standard. begin 600 WINMAIL.DAT M>)\^(A 2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0``# $IV_```#``80#"8)B0,` M!Q ;`0``'@`($ $```!E````1T5.15)!3%%515-424].25-%14Y/5$A)3D=) M3E1(14E304M-4$1204945$A!5%!214-,541%4TE.0TQ51$E.1U!!64Q/0413 M24Y42$5304U%34534T%'15=(24-(05!03%E43P`````#`! 0``````,`$1 ! M`````@$)$ $```")`0``A0$``&$"``!,6D9UUTR)F/\`"@$/`A4"I /D!>L" M@P!0$P-4`@!C: K FAE; ,@1&SZ9P* M?0J ",\)V0* "H&##;$+8&YG,3 S%"#G"PH2\@'0($<)\ 20!T!$('$*4'-T M:0(@+A,*A0J%22 1\&4@;DAO=&@+@&<@"X @`QPP&_!)4T%+35"O%3 :``& M'+%A!4!P%G!^8PI #; $( N 'E(<4E!D87D6`&%D'J( ( >!(&!G M&_!WHQQ $; @87 +4'D,05 %G ?L!Q2]F\F(!S)4P&0(R +$1K-!161 M`#,``````P#Q/PD$```#`"8```````,`-@```````@%'``$````L````8SU5 M4SMA/2 [<#U'5$4[;#U.1$A-,#8M.3`/@_`0```!0` M``!7871E From: Brett Howard To: "'C. Harald Koch'" Cc: "'ipsec@tis.com'" Subject: RE: pf_key comments Date: Mon, 6 Jan 1997 13:02:43 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald Koch writes: > Does the IV have to be *unpredictably* different, or just different? > > (The NRL code, for example, simply increments the IV after each packet). Just different. If you look at the nature of the feedback in CBC for any chained blocks, the IV is simply the last data-cipher block, which is "public" information. The only danger I've ever heard of incrementing an IV from one chain to the next is that the IV bits are almost identical at the start of each chain; but to my knowledge, this has never been exploited. Brett TimeStep Corporation From owner-ipsec Mon Jan 6 14:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01358 for ipsec-outgoing; Mon, 6 Jan 1997 14:12:19 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: "Waterhouse, Richard" To: "'IPSEC Working Group'" Subject: DOI in the Header Date: Mon, 6 Jan 1997 14:16:38 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipsec@ex.tis.com Precedence: bulk Back on Dec 18 Elfed T. Weaver proposed moving DOI up to the Header. I've just become convinced that this must be done. Protocol-ID can only be interpreted in the context of a DOI. (Section A.2.2) SPI can only be interpreted in the context of a Protocol-ID. In a Delete Payload all you have is Protocol-ID and SPI. But by the above this can only be interpreted in the context of a DOI. And the DOI doesn't appear in the Delete Payload or its Header. begin 600 WINMAIL.DAT M>)\^(BD3`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0`' ``0```!(```!$3TD@:6X@=&AE($AE861E<@````(! M<0`!````%@````&[_ :!''[WD$-GMA'0MMX``, 2G;\```,`!A#Q")'.`P`' M$&$!```>``@0`0```&4```!"04-+3TY$14,Q.$5,1D5$5%=%059%4E!23U!/ M4T5$34]624Y'1$])55!43U1(14A%041%4DE614I54U1"14-/345#3TY624Y# M14142$%45$A)4TU54U1"141/3D504D]43T-/``````,`$! ``````P`1$ $` M```"`0D0`0```+P!``"X`0``^0(``$Q:1G6GH))>_P`*`0\"%0*D`^0%ZP*# M`% 3`U0"`&-H"L!S973N,@8`!L,"@S(#Q@<3`H,2,Q,/9C0/>FAE;-$#($1L M9P* ?0J ",\?"=D"@ J!#;$+8&YG,3PP,Q0@"PH2\@'0($(Y`-!K( (@%F % MD" Q'C@*X0MD%"(:P45L9@$)@"!4+B!796&2=@20(' #8'!O$? K'1 $8'8+ M@&<68$])P"!U<"!T;Q\P%B"<($@=< 2!'4!))QV0T"!J=7,%0&(%D0> :B % MH&X>@6,=`1]P89\%0!]P! `>4""4(&0"(.QE+@J%"H50`V ?0!<1."U)1"$P M`Y$"(&QY^R+""X!T!) =T!(`'0$+@!1%C L,20@87FO M%S ?T"> %D%Y"& @$<#_(%$B420Z`' =$"K!'4 :X/YU(+$KTB,`B0>0;B<%0&%P4OO06Q:70$(!^U M"R-<%L$`/( #`/$_"00```,`)@```````P`V```````"`4<``0```"P```!C M/553.V$](#MP/4=413ML/4Y$2$TP-BTY-S Q,#8Q.3$V,SA:+3$R,S(X``(! M^3\!````1P````````#`#T``0````$`````````"P`I``$````+ M`",```````(!?P`!````10```#QC/553)6$]7R5P/4=4125L/4Y$2$TP-BTY M-S Q,#8Q.3$V,SA:+3$R,S(X0&YD:&TP-BYN9&AM+F=T96=S8RYC;VT^```` #`( To: bhoward@TimeStep.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199701061923.MAA24523@baskerville.CS.Arizona.EDU> Subject: RE: pf_key comments Sender: owner-ipsec@ex.tis.com Precedence: bulk > Harald Koch writes: > > Does the IV have to be *unpredictably* different, or just > different? > > > > (The NRL code, for example, simply increments the IV after each > packet). > Just different. If you look at the nature of the feedback in CBC for > any chained blocks, the IV is simply the last data-cipher block, which > is "public" information. The only danger I've ever heard of > incrementing an IV from one chain to the next is that the IV bits are > almost identical at the start of each chain; but to my knowledge, this > has never been exploited. Phil Rogaway has pointed out that if the IV and the first data block are both changing so as to cause their xor to be constant, the purpose of the IV is defeated. I don't know if this has ever been observed in practice, but it is something to keep in mind (I suppose someone now will try to design this into a protocol as some kind of optimization!). Hilarie From owner-ipsec Mon Jan 6 15:25:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01739 for ipsec-outgoing; Mon, 6 Jan 1997 15:25:19 -0500 (EST) Date: Mon, 6 Jan 1997 15:25:54 -0500 (EST) Message-Id: <199701062025.PAA01101@gabber.multinet.net> From: graydon hoare To: ipsec@tis.com Subject: Thinkin' about identifiers... Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been looking over the material on security topics currently available, and have become a little concerned. While it's true that identification and authentication systems are slowly stabilizing through the analysis of the members of the IETF and security-related companies, one issue which remains to be dealt with properly (from my perspective) is that of the naming system. It does not seem effective to rely on the DNSSEC (basically email) or X.500/LDAP architectures, because under these systems an identifier is logically connected to an authority for other, non authentication-related information This looks like a small problem, but as time goes on it blossoms into a whole bunch of problems. The key concern is that your name tells other principals a lot about you as a principal (not just humans -- organizations and software agents too) If a principal has information about your name, it partially or fully denies you the option of acting anonymously. In DNS or X.500, having an obscure or hard-to-remember identifier invalidates the point of the databases. But making names easy to remember means associating them with real-world things, such as the place you work, the place you get your email, the country you live in etc. Furthermore since DNS and X.500 are both used to store other identifying information, having multiple DNS or X.500 names does not preclude the possibility of someone matching them up (for instance, by given name). While this may not annoy you much when it comes to junk email or the like, having control over joinable database keys will make your life a lot more pleasant as interoperability increases. And even if you have complete trust in the harmlessness of data collecting and indexing based on things you don't want to change (your name) or can't realistically deny (that you got your name in a certain country), there is this horrible problem of a hierarchical name space being tied to real world organizational hierarchies. If everyone who works for the military gets their keys stashed under the mil hierarchy, guess which machine an attacker is going to try to compromise? SOA (or "keyserver") for mil. Although you need a hierarchical name space for a good distributed system, you don't need to be spelling out what is represented in each branch of the hierarchy. Finally, as you may be aware, the dynamic creation and assignment of DNS names is being intentionally slowed (60 days is a suggested wait time) in order to make trademark conflicts less troublesome. It is an admirable effort, but I would prefer for a system responsible for network-wide authentication to be extremely robust and therefore make use of any host with any spare CPU cycles for replication and distribution. I am considering implementing a portable, low-overhead identification and certificate server. It will be similar to OSPF/gated or named, but will not couple with internet names or addresses internally -- I'm assuming that many things in the world will be able to store identifiers without necessarily being "on the net" all the time. The design is very clear and modular and has strong controls for cache consistency and replication. Its records are mobile and reasonably hard to track, and there is maximum effort put into keeping the identifiers anonymous. The communication protocol is based on certificate-exchange protocols previously defined by IETF, and should work with various authentication systems already in place. The goal of this implementation is to create a framework in which strong cryptosystems and authorization schemes can flourish. I am not smart enough to invent any such schemes myself, but I do see that the name system, in order to be useful, should be lowest-common-denominator equipment. If they are kept at the level they are being proposed at today, the options for speed, efficiency, and anonymity are severely hampered. I will make available an RFC as soon as I put one together. It's pretty straightforward. I am interested in keeping identifiers as "out of the way" as possible across the entire network. I work for an ISP, and am all too familliar with the accounting and authorization nightmare that inconsistent identities beings up. I am not a C expert, nor a crypto expert, nor a distributed systems expert. Furthermore I am working full-time, so I really only have my evenings free. I would appreciate any assistance from others who are interested in helping. graydon@pobox.com From owner-ipsec Mon Jan 6 16:00:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01922 for ipsec-outgoing; Mon, 6 Jan 1997 15:59:52 -0500 (EST) From: Uri Blumenthal Message-Id: <9701062102.AA194199@hawpub.watson.ibm.com> Subject: Re: pf_key comments To: ho@earth.hpc.org (Hilarie Orman) Date: Mon, 6 Jan 1997 16:02:56 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199701062024.PAA03400@earth.hpc.org> from "Hilarie Orman" at Jan 6, 97 03:24:52 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie Orman says: >>> Does the IV have to be *unpredictably* different, or just different? >> >> Just different. > > Phil Rogaway has pointed out that if the IV and the first data block are > both changing so as to cause their xor to be constant, the purpose of > the IV is defeated. Cute! > I don't know if this has ever been observed in practice, but it > is something to keep in mind (I suppose someone now will try to design > this into a protocol as some kind of optimization!). (:-) Considering that IV has nothing to do with the data block, I'd say the chance to see this in practice is nil. Could anybody comment on this? Was/is there ever a case when IV was somehow data-dependent? Oh, and when you use the last ciphertext from the last message as the IV for the next message, due to ciphertext properties of any semi-decent cipher this should be a no-issue. Correct? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Mon Jan 6 22:20:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03805 for ipsec-outgoing; Mon, 6 Jan 1997 22:18:33 -0500 (EST) Date: Mon, 6 Jan 1997 19:20:50 -0800 (PST) From: Phil Karn Message-Id: <199701070320.TAA03077@servo.qualcomm.com> To: andrade@netcom.com CC: ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org In-reply-to: <199701050933.BAA00135@netcom17.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >This is interesting. I knew that TCP/IP will be miserably slow when >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I I don't know where you get such pessimistic figures. My own DES (in a mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) MHz Pentium, and in triple DES mode gets about 6 megabits as I recall. The source is free by email to anybody who will state that they're a US citizen or permanent resident physically in the US. I routinely encrypt just about all of my remote login/X sessions and file copies with SSH in the 3DES or IDEA mode, and I hardly notice the encryption overhead. Phil From owner-ipsec Tue Jan 7 00:16:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA04442 for ipsec-outgoing; Tue, 7 Jan 1997 00:15:33 -0500 (EST) Message-Id: <199701070516.VAA18319@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Mon, 6 Jan 97 21:16:55 -0800 To: Phil Karn Subject: Re: IPsec and TCP cc: andrade@netcom.com, ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701070320.TAA03077@servo.qualcomm.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > >This is interesting. I knew that TCP/IP will be miserably slow when > >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > > I don't know where you get such pessimistic figures. My own DES > (in a mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 > (not 200) MHz Pentium, and in triple DES mode gets about 6 > megabits as I recall. The source is free by email to anybody who > will state that they're a US citizen or permanent resident > physically in the US. > This is what I get on a 133 under NeXTSTEP 3.3 against libdes-3.23 > > % speed > > Doing set_key for 10 seconds > > 819602 set_key's in 8.77 seconds > > Doing des_ecb_encrypt's for 10 seconds > > 1277920 des_ecb_encrypt's in 8.84 second > > Doing des_cbc_encrypt on 8192 byte blocks for 10 seconds > > 1307 des_cbc_encrypt's of 8192 byte blocks in 9.31 second > > Doing des_ede_cbc_encrypt on 8192 byte blocks for 10 seconds > > 485 des_ede_cbc_encrypt's of 8192 byte blocks in 9.34 second > > Doing crypt for 10 seconds > > 47930 crypts in 9.31 second > > set_key per sec = 93501.83 ( 10.7uS) > > DES ecb bytes per sec = 1155998.30 ( 6.9uS) > > DES cbc bytes per sec = 1149738.95 ( 7.0uS) > > DES ede cbc bytes per sec = 425216.86 ( 18.8uS) > > crypt per sec = 5146.85 (194.3uS) > > > -dpg From owner-ipsec Tue Jan 7 07:59:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06752 for ipsec-outgoing; Tue, 7 Jan 1997 07:55:19 -0500 (EST) Date: Mon, 6 Jan 1997 18:01:12 -0500 (EST) From: graydon hoare To: ipsec@tis.com Subject: RE: Thinkin' about identifiers... In-Reply-To: <01BBFBF3.B6A1C3A0@erussell-2.ftp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 6 Jan 1997, Edward A. Russell wrote: > to services and machines incorporated with a public key infrastructure. > I should be able to walk up to any PC and authenticate myself (via smart > card or secure key/cert package downloaded from my server) and then gain > access to all things I am allowed access to. But fundamental to this is > WHO AM I? What is my name. I agree 100%. The notion of having to carry around multiple IDs is getting stale my the minute. Have you read about IBM's little "personal area networks"? Forget smart cards -- we're talking about smart shoes now ;) > > I would also like to see user-based IPSEC where machines authenticate a > session based on a user certificate, not a DNS machine certificate. > Again, what is the namespace here. > > I disagree with the need for hiding information about where I work or > the country I live in however - that is too paranoid for my own taste - > the concept of "anonymous authentication" makes no sense to me. However Personally, yeah. I don't see knowledge of my identity interfering with me getting my work done on a daily basis... "anonymous authentication" is very normal though, you just need to use non-binding identifiers. You can use the pub-key to "authenticate" that I am who I claim to be. Who do I claim to be? Rudolph the red-nosed raindeer. Who cares? If you trust the person you use to verify the identifier, you don't need to know who the person you talk to is. it would be nice to have the option, keep it available, like say if I use one smartcard to buy illegal merchandise (using the first virtual bank of the underworld ;), I don't want ANY personal data that the first secret service database may also know about me available when the criminal database is eventually compromised. Simpler context: if I want 1 company to know my phone number (cause they provide a useful service through the phone) but I do not want the direct-marketing department of my grocery store to get my phone number cause they'll call me at 2:33am and ask if my lettuce is crispy enough, how do I realistically prevent them from doing a merge on my name once they sell each other their databases? if my name is not bound by reality, I can keep multiple identifiers and they can't be easily connected to one another. I keep one for people I want to have my phone number, and one for people I do not want to have it. ta da. Multiple-identity management should be the responsibility of an individual, not of viacrypt. > > You talk about an implementation, but what are your ideas for a > namespace? Doesn't it have to be hierarchial and to that extent don't > you eventually wind up with X.500 Distinguished names anyway? > I've been thinking about a fixed-length binary string around 18-24 bytes. Maybe so big as 30, cause there's no point having to come up with a whole new distributed naming database for software agents, consumer electronics, and whatnot. Still, playing with a calculator for a minute it's not hard to see that you are fine within 24 bytes. It would definitely have to be hierarchical, but the nice thing is that there need not be any organizational tie to the outside world as far as Authority of Service. Therefore, if you introduce a new server into the system and it advertizes to its nearest peer, it should be reasonable for the peers to begin loading any old data they feel like into the new peer's allocated storage. There are no trademarks to worry about in 24-byte binary jumbles (god I hope there aren't ;) so why should you care whose names you're serving? Part of the intended reliability is the fact that anyone with a reasonably reliable machine can download the software, get some sort of trusted key out of band from another peer, and then add their collective resources to the pool immediately. I sorta prefer the trust-web to the CA model, but probably a healthy mixture of the two will evolve. I don't _dislike_ X.500... I bet it will help me find my friends' email addresses. The problem is that if I write down their DN, and they move, their DN doesn't yield their certificate anymore. If they signed one of my certificates, like in a trust web, then the authority they bestowed on me is broken until I figure out where they moved to. It's an incomplete solution. Particularly if you start dealing with comsumer electronics which need to authenticate. Is the Hitachi X.500 server supposed to handle the load for all of them? What if you compromise that server? Every VCR in the world is under your control .. worse, if you make a business keep track of its own hardware, you only need to do a denial-of-service attack on their key server to shut down all business operations. ugly! I just think the identifier <-> certificate table should be spread far and wide all over the net, and the IDs need to be rock-solid. -graydon From owner-ipsec Tue Jan 7 08:29:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA07242 for ipsec-outgoing; Tue, 7 Jan 1997 08:29:15 -0500 (EST) Message-Id: <199701071332.NAA07888@inner.net> To: Phil Karn cc: ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org Subject: Re: IPsec and TCP In-reply-to: Your message of "Mon, 06 Jan 1997 19:20:50 PST." <199701070320.TAA03077@servo.qualcomm.com> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Tue, 07 Jan 1997 08:32:27 -0500 From: Craig Metz Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199701070320.TAA03077@servo.qualcomm.com>, you write: >>This is interesting. I knew that TCP/IP will be miserably slow when >>you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > >I don't know where you get such pessimistic figures. My own DES (in a >mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) In a *highly* unscientific experiment, I was able to move a 100MB file via FTP (TCP/IPv4) between a P120 and a P90 with both ESP DES-CBC and AH HMAC-SHA on every packet and got an average throughput of about 3.18Mb/s. This is with a software implementation that is unoptimized and has lots of debug code in place. It would not at all surprise me if a well-optimized implementation could at least double that. You want faster? Use hardware assists for the crypto. -Craig From owner-ipsec Tue Jan 7 10:30:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08259 for ipsec-outgoing; Tue, 7 Jan 1997 10:28:50 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199701071531.KAA79270@mailhub1.watson.ibm.com> Date: Tue, 7 Jan 97 10:31:29 EST To: bhoward@TimeStep.com, chk@border.com, URI@watson.ibm.com cc: ipsec@tis.com Subject: pf_key comments (predictable IVs) Sender: owner-ipsec@ex.tis.com Precedence: bulk The traditional motivation for IVs is to cause two encryptions of the same plaintext to result in two different cipheretexts. For such a use just different (even if predicatable) IVs are enough. However, there is more functionality built into IVs. They are intended to randomize plaintext before encryption for a variety of other reasons. Especially, against chosen message attacks. Consider, for example, an attacker that builds a table with encryptions of the all-zero message under the 2^56 DES keys. How does the guy gets an encryption of zero under the victim's key? If the attcker can mount a chosen plaintext attack it could ask for the encryption of the zero message. But if the encryptor chooses an IV before encrypting then the attacker gets DES(K,IV) rather than DES(K,0). On the other hand, if the IV is known to the attacker before hand (e.g., the IV is an incrementing counter or the last block of ciphertext from the *previous* message) then the task for the attacker is easy. He just chooses the message to encrypt to be equal to the next IV. The ciphertext he will see is DES(K, IV XOR IV) = DES(K,0) ! If instead, the IV is chosen *after* the plaintext is fixed (in a way which is unpredictable to the attacker) then the attacker has little to do to get DES(K,0). I hope this helps in clarifying the issue of predictable vs unpredictable IVs. In particular, IVs known *before* choosing/fixing the message to be encrypted or *after*. Another example from Phil Rogaway (draft-rogaway-ipsec-comments-00.txt): "...suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000001 is recognizably distinct from a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000000. Clearly this violates violates the notion of a secure encryption sketched in Section 2." [You can find the full Rogaway's draft in http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html A related one in the same page is: draft-rogaway-cbc-encrypt-00.txt (April 27, 1995)] Hugo From owner-ipsec Tue Jan 7 10:30:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08266 for ipsec-outgoing; Tue, 7 Jan 1997 10:30:20 -0500 (EST) Date: Tue, 7 Jan 1997 10:29:55 -0500 (EST) From: graydon hoare To: Ron Rivest cc: ipsec@tis.com Subject: Re: [graydon@gabber.multinet.net: Thinkin' about identifiers...] In-Reply-To: <199701062134.AA22448@swan.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 6 Jan 1997, Ron Rivest wrote: > > I'd be interested in seeing what you come up with. > > If you haven't seen our paper on SDSI, please take a peek at it > (http://theory.lcs.mit.edu/~rivest, publications); it deals with > similar stuff, a bit differently... > > Cheers, > Ron Rivest I have just read your paper on SDSI; happily it seems we are working on projects which complement each other well. My original intrest in a strong naming scheme grew out of my intrest in publicly implementing stanford's ontology server project, which uses KIF to represent local-name-scope knowledge bases in a (possibly) distributed system. The possibilities for machine-learning and CMC within such a setting are immense and quite inspiring. I thought I'd get to work making a friendly client and possibly porting their server, in order to make the effort to build a good sized KB as public as possible. I totally support the exported-lexical-scope notion for building local bindings. The problem which arose, and which I believe still plagues the name systems you have included thus far in your "well known roots" list, which gets used when exported relationships either do not exist or have failed, is that these global name systems are too heavily influenced by other uses, other application-domains. As a result of being tied to a domain which is unrelated to principal identity, such a global name is not under individual control. Furthermore you're placing the burden of resolving multiple name-types on the clients, which likely already have to deal with multiple hashing algorithms and multiple security paradigms. Also, it becomes tricky to decide where (physically) SDSI auto-cert servers go, when they live in multiple namespaces. What if your X.500 organization borders fon't follow your DNS borders? Where do you put certificates for principals in one office with both email names and X.500 names? How do you co-ordinate the databases? Who is running your server? SDSI seems extremely advanced and flexible, but basically requires a powerful recursive S-expression evaluation engine (like say, libguile) to be embedded in each implementation. While this is a desirable scenario for all software, it's not likely given today's programmers and today's market -- particularly not in consumer electronics or embedded systems. I don't expect all secure devices will have the patience or resources to do a full SDSI implementation. All I'm proposing is an identifier-distribution and association network. The certificate-authentication interface of my implementation will be quite generic, and will likely be amenable to SDSI as well as X.509, PGP, and hopefully some low-overhead schemes which consumer electronics can use to work securely even given limited memory. It is neither my concern nor remotely within my ability to code such security systems. I'm focusing on making an identifier system which is an order of magnitude more reliable and flexible than DNS, which requires virtually no maintenance and which has no identifiable attack points. You should be able to walk up to any system, connected to the internet in even the thinnest possible way, and say "I am bleh-bleh, and I have someone here who says they are blah-blah-blah... give me some credentials so I can prove it". This includes the special case of "I am bleh-bleh, here are some personal credentials, I want access to everything I am authorized to do, from this new location". It's up to them what sorts of extended credentials they use, and it is up to an external module of the server software to decide what sort of inter-peer communication security / update authorization system gets used. My plan is to rip off the structure of IP6 secure-OSPF code for the server-location and database concurrency module, I'll probably just wrap data-conversion code around berkeley DB for the actual records, and then present pluggable generic security and communication layer APIs to handle the outside world. I'm using a very simple protocol.. most of the thinking work gets done by client libraries living above the name service (like SDSI). I definitely like what you've done so far. It's cool. It's essentially the set of security predicates which were missing from early KIF/KQML designs. Hopefully they can be more tightly integrated in the future. You might try re-coding your predicates in KIF, as ARPA likes it so much ;) In the meantime I am going to go ahead with designing my little identfier/credential daemon. I'll publish it widely as soon as I have even a fragment of code that compiles (some of us really suck at anything system-level ;) I'm working on an internet-draft that spells out my motives a little better. I think I have most of the glaring technical details covered. I'll post it when I'm done. Thanks for your response. -graydon From owner-ipsec Tue Jan 7 17:26:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10780 for ipsec-outgoing; Tue, 7 Jan 1997 17:11:38 -0500 (EST) Date: Tue, 7 Jan 97 22:10:03 GMT Standard Time From: Ran Atkinson Subject: [Admin] New Editor for IPsec Base Specs To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm pleased to announce that Steve Kent has agreed to take over editing the IPsec Base Specifications (IP Security Architecture, AH, ESP). Comments on revising those drafts should be sent directly to him or to the IPsec mailing list . Ran rja@inet.org From owner-ipsec Thu Jan 9 07:52:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24023 for ipsec-outgoing; Thu, 9 Jan 1997 07:43:43 -0500 (EST) Message-Id: <199701091243.HAA24023@portal.ex.tis.com> To: ipsec@tis.com Subject: Draft des-md5 v3 Date: Thu, 09 Jan 1997 01:22:46 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- While implementing the DES-MD5 transform as of draft v3, i noticed that the algorithm that checks the replay counter window that's given would not work correctly with the draft's specification; the algorithm assumes that the initial value of the replay counter is 1 (or 0), but the draft has the counter initialized to some arbitrary value (an MD5 result). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMtSOtL0pBjh2h1kFAQEAwAP9FpNuPvjdM9ZT9qgLB2ach8BAW3PLs5M1 hP/gRLm2c7TQgw/pfJ47k9u7WldWpvtmSp59+IcGn9Thgrr0KUYZDn400flKFnGE I4m+jQAK6IhG/2Z1uXLf/qvXsdJzQB5q8tnIAqO4zcJIUSevCLgsI9Jb3XTFG9Ui 1nRxFwf9vj0= =Q6VJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 9 08:47:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA24422 for ipsec-outgoing; Thu, 9 Jan 1997 08:45:14 -0500 (EST) Message-Id: <199701091348.FAA04890@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Rodney Thayer cc: ipsec@tis.com, gnu@toad.com Subject: Re: pf_key comments (random number generation) In-reply-to: <3.0.16.19970103095702.364738dc@pop3.pn.com> Date: Thu, 09 Jan 1997 05:48:34 -0800 From: John Gilmore Sender: owner-ipsec@ex.tis.com Precedence: bulk > 1. I like the idea of sending the IV down from an application. I think > that an application is a reasonable place to do the random number > generation On the PF_KEY question I'm not qualified to answer. But the question reminded me of a randomness issue for overall security that wasn't addressed in RFC 1750. In looking at the harm that can be done to cryptographic protocols by attacking their random numbers, I have some tentative rules of thumb: * Randomness should be mixed in from a variety of sources, at different levels (e.g. application, kernel, hardware). * This mixing must be deterministic or verifiable, so that it can be detected if subverted. For example, if software feeds random values to black box hardware, and the black box hardware then outputs a "mixed" random number, you have no idea if the output was actually chosen to subvert the process, since you couldn't see the hardware's random input to the mixer before you handed it the software input to the mixer. If instead the hardware outputs a random value, then SOFTWARE mixes it with other software-generated values, you can at least examine that mixing software with debuggers, logic analyzers, oscilloscopes and tweezers to see if the mixing has been subverted. * Relying on a hardware black box ALONE to generate your random numbers is foolish. Mixing the output of such a box with your software random numbers probably improves them; even if the box knows your software "random number" algorithm, it probably can't see all the inputs to it, so it probably can't reduce (subtract out) the entropy the software found. Young and Yung did a great paper for Crypto '96 on how to subvert protocols with bad random black-boxes (like how malicious random number hardware could hide your RSA private-key inside your published "random" RSA public-key, in a subliminal channel such that only those who knew a secret could detect it). John From owner-ipsec Thu Jan 9 10:01:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25084 for ipsec-outgoing; Thu, 9 Jan 1997 10:00:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199701091348.FAA04890@toad.com> References: <3.0.16.19970103095702.364738dc@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Jan 1997 10:03:47 -0500 To: John Gilmore From: Stephen Kent Subject: Re: pf_key comments (random number generation) Cc: Rodney Thayer , ipsec@tis.com, gnu@toad.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, If one has a good hardware RNG, nothing you do with the output in software is likely to improve on the output, and many things that you do could degrade the result. I acknowledge that if you lack confidence in the hardware RNG output, then you have a problem, and then it might be appropriate to try to improve on the output with good software (although use of a second hardware RNG would be better). However, we have many more examples of bad software PRNGs than bad hardware RNGs. I also am very skeptical that application-based PRNG sources are an improvement over good, kernel PRNG sources; I suspect the opposite is true in most cases. I'd rather not see an API based on the assumption that the kernel code can't get it right and the application code will do better. Should we ever evolve to more secure OSs, the likelihood is much greater that Trojan Horse software will be able to degrade the application environment PRNG than a kernel-based PRNG. Also, we are ultimately dependent on the security of kernel code anyway, to protect user traffic from disclosure. So, I tend to think that suggestion of making specific API provisions for application-supplied PRNG data is questionable. In a more general vein, while I too do not profess to have examined the pf_key interface in detail, I am puzzled by several of the suggestions I have seen in this thread. - Making a kernel call to get an IV (or a sequence of IVs), which the application would pass back with a packet to be protected, seems very odd to me. IV generation si a side effect of IPSEC (ESP) use, and is dependent on the algorithm and the mode being employed. So, it seems appropriate to let the IPSEC implementation handle the IV generation and use, to hide the details from applications. - The discussions about user vs. kernel performance for the IV generation task also struck me as odd. In general, I don't think we want to make user code knowledgable about the crypto details of IPSEC, so IV management really should be hidden in the IPSEC code, not visible to the caller. - As others have pointed out, after an initial IV has been generated for a CBC session, one can just use the last ciphertext block from packet N as the IV for packet N+1, just as one dies within the context of a single packet. The specs for use of DES in this mode do allow re-use of the first IV for subsequent packets, but that always struck me as a bandwidth-saving measure that was not worth the potential security downside. However, the same spec points to the need to protect the first IV against modification attacks, e.g., by encrypting it using ECB mode, on the assumption that a constant IV is used for every packet. The reasons for this are left as an exercise for the reader, and for explication by the list members who do not shrink from being called cryptographers! Steve From owner-ipsec Thu Jan 9 13:38:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26856 for ipsec-outgoing; Thu, 9 Jan 1997 13:37:38 -0500 (EST) Message-Id: <2.2.16.19970109154134.0cdf27c8@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jan 1997 10:41:34 -0500 To: ipsec@ex.tis.com From: John Burke Subject: Various difficulties in ISAKMP ver-06 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have found a number of points which ISAKMP draft ver-06 still seems to leave up in the air, most of which I would call obstacles to interworking. So here they are: o Initiator should be allowed to send both ID's in all exchanges. The drafts seem to forget the firewall/router case, which is the more general case and so should be the target of the drafts. Note that the original Oakley, and Harkins/Carrell Quick Mode, do have this provision. Of course this makes the ID payload order dependent and the exchange has to say which is which. o It is not clear which payload the SA names as Next Payload: the Proposal or the next load after the proposals and transforms. There are contradictory indications which need to be fixed; I assume option 1 is correct and 2 is a mistake: 1) Description of SA Payload (p. 26) specifies that Next Payload may be zero. This implies that the Next-Payload is the next major payload, after all the proposals and transforms. This would conform with the Payload Size of the SA. 2) The example exchange picture in 4.1.1 (ver-02 p. 42) shows the Next-Payload of the SA contains "Proposal". (Also this picture does not show an actual payload-size value.) o Ambiguity about correct use of Notification: The description of the Notify payload (ver-02 p.37) starts out saying, that a Notification in phase 1 is identified by the cookies in the message header, and a Notification in phase 2 is identified by the cookies and the Message ID. (It also mentions "the SPI associated with the current negotiation"; this phrase has no connection to the rest of the section; if it is meant to convey something particular, it has to be clarified.) But the Notification always contains the SPI field; and there is the provision for the Informational Exchange which permits a fresh Exchange to carry a Notification. This implies that the SPI in the Payload is ALWAYS the defining identifier for the SA being acted upon. Surely it is permitted to send Notification within a message of an exchange in progress, and surely the Notification will contain the SPI which the message applies to? This should be stated. It would seem silly to permit sending the Notify "Connected" in a separate Informational Exchange; it would be unreasonable to require that it MUST be sent in the separate exchange. I recommend it be allowed only on the cookies/ID of the original exchange. Is it forbidden to send Notification for SA B in a message whose cookies/msg ID name SA A, when the Exchange Type is not "Informational"? I would want and expect it to be forbidden, but it doesn't have to be that way; needs to be spelled out. Is it required in any circumstances that a Notify MUST be sent in a new Informational Exchange and not with the cookies/ID and type of the Exchange in progress? If this requirement applies in common cases, it will use up the space of Message ID's twice as fast as otherwise. Is it valid to retain the Message ID of an Informational Exchange and send further Notifications over time for various SA's? In both directions? Is it valid to send a Notification applying to a User SA, when the ISAKMP SA is Up, in a message with: The ISAKMP SA cookies Exchange Type = "Informational" Message ID = zero o Ambiguity in the correct use of Delete The questions above on Notification apply to Delete too. One would think that after a connection completes successfully, the Delete SHOULD be sent in a separate Informational Exchange, but we have to provide for a necessary ambiguity here. Consider: the state of setup is unclear in the partner who has sent the last message of the Exchange until it receives something valid over the SPI; meanwhile this side doesn't know whether the other side has completed. The above implies that a Delete MUST be permitted to arrive in a separate Informational Exchange for an incomplete connection. o Requirements for an adequate cookie should be stated. Karn's cookie is noted as existing but its features are not said to be required. o Ordering of payloads There is no statement on whether payloads within one message must appear in exactly a given order. The diagrams show a specific ordering on the face of it, but this is an inadequate basis for the reader to deduce a requirement, and the very existence of payload types makes it reasonable to allow any order. Precision on this point is especially needed wherever a hash or signature is prescribed to be over all the content of a message. o Notifications sent in the clear: Does the draft want to address whether a Notification should be sent in the clear at all when it says the connection failed, considering this is a vulnerability to attack? o The term "string" is not defined, e.g. for domain names. People can conclude with equal reasonableness, a) that it means with zero terminator, or b) all characters included in the count are significant content. o Alignment o General: It appears clear to me that all payloads in messages may appear unaligned, since some can have a size of odd bytes. The text should state this, since the pictures show several things as being four bytes wide though this is not required by the text. If we do want alignment it has to be stated explictly, and as "aligned at 4-byte multiples" or "2-byte". o TLV Attributes: The discussion of TLV Attribute format specifies "word alignment"; "word" is not a precise term. Two-octet? Four? And the wording of this section does not actually say alignment is required, but it sounds like it wants to. It unequivocally says any padding must be by leading zeroes; this gives no guidance to someone who invents a character attribute. o Lifetime Attributes The use of "Lifetime Type" and "Lifetime Duration" attribute pairs introduces an unnecessary complication and, as it is now, an ambiguity. What is the correct procedure for pairing up the attributes, since the draft does not specify what order they have to be sent in? Is it absolutely required that each "Lifetime Type" appear before its respective "Lifetime Duration"? Also, question: can one supply both a KB life limit and a time life limit? I think the draft should say Yes". I would rather see the simple answer: change to have a separate attribute each for: ESP life in seconds; ESP life in KB, AH life in seconds, AH life in KB, etc. I see no argument against this, and it will save us all a hunk of just plain useless implementation code. From owner-ipsec Thu Jan 9 14:57:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27574 for ipsec-outgoing; Thu, 9 Jan 1997 14:55:27 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701091957.LAA01904@netcom11.netcom.com> Subject: Re: IPsec and TCP To: karn@qualcomm.com (Phil Karn) Date: Thu, 9 Jan 1997 11:57:00 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199701070320.TAA03077@servo.qualcomm.com> from "Phil Karn" at Jan 6, 97 07:20:50 pm Sender: owner-ipsec@ex.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: 855 > >This is interesting. I knew that TCP/IP will be miserably slow when > >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > > I don't know where you get such pessimistic figures. My own DES (in a > mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) > MHz Pentium, and in triple DES mode gets about 6 megabits as I > recall. The source is free by email to anybody who will state that > they're a US citizen or permanent resident physically in the US. > Sorry. I meant about 1 MByte (still slow). Using a pure C implementation by Richard Outbridge (D3DES) I am getting about 0.9 Mbytes on a Pentium Pro 200 Mhz. Your numbers seem to indicate a speedup of 2x is possible (still quite slow). - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu Jan 9 15:07:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27640 for ipsec-outgoing; Thu, 9 Jan 1997 15:07:25 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701092009.MAA02614@netcom11.netcom.com> Subject: Re: IPsec and TCP To: cmetz@inner.net (Craig Metz) Date: Thu, 9 Jan 1997 12:09:02 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199701071332.NAA07888@inner.net> from "Craig Metz" at Jan 7, 97 08:32:27 am Sender: owner-ipsec@ex.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: 818 > > In a *highly* unscientific experiment, I was able to move a 100MB > file via FTP (TCP/IPv4) between a P120 and a P90 with both ESP DES-CBC and AH > HMAC-SHA on every packet and got an average throughput of about 3.18Mb/s. This > is with a software implementation that is unoptimized and has lots of debug > code in place. It would not at all surprise me if a well-optimized > implementation could at least double that. You want faster? Use hardware > assists for the crypto. > Do you mean 3.18 Mbits/s or 3.18 Mbytes/s? Unfortunately hardware assists are not possible for economic or other reasons. In particular if you wish to deliver shrinkwrap software to a Win95/Intel type platform. - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu Jan 9 16:22:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28121 for ipsec-outgoing; Thu, 9 Jan 1997 16:19:56 -0500 (EST) Message-ID: From: "Waterhouse, Richard" To: "'IPSEC WG'" Subject: re: Delete (in John Burke's recent message) Date: Thu, 9 Jan 1997 16:24:47 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk "The above implies that a Delete MUST be permitted to arrive in a separate Informational Exchange for an incomplete connection." > This would imply the rules for the Delete must be different for Phase 1 and Phase 2. "Deletion of a Security Association MUST always be performed under the protection of an ISAKMP SA." (Section 5.13) would prohibit implementation of your suggestion for Phase 1. From owner-ipsec Thu Jan 9 18:58:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28949 for ipsec-outgoing; Thu, 9 Jan 1997 18:57:17 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: IPSEC DOI doc and Identification Payload Date: Thu, 9 Jan 1997 18:54:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry if this has already come up... The Identification Type is specified as 1 octet, yet gives values ranging from 0 to 512. Bye. From owner-ipsec Thu Jan 9 21:28:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA29888 for ipsec-outgoing; Thu, 9 Jan 1997 21:27:35 -0500 (EST) Message-Id: <2.2.16.19970109233152.0f2f046c@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jan 1997 18:31:52 -0500 To: ipsec@ex.tis.com From: John Burke Subject: re: Delete (in John Burke's recent message) Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:24 PM 1/9/97 -0500, "Waterhouse, Richard" wrote: > > "The above implies that a Delete MUST be permitted to arrive in > a separate Informational Exchange for an incomplete connection." > >> This would imply the rules for the Delete must be different for Phase 1 and >Phase 2. > >"Deletion of a Security Association MUST always be performed under the >protection of an ISAKMP SA." (Section 5.13) would prohibit >implementation of your suggestion for Phase 1. Yes, that's right; I was not considering that point. As you say, this is a difference between Phase 1 and Phase 2. I believe it's necessarily so; and in fact it appears to me the same logic applies to any Notify that signals failure. Best regards, John Burke From owner-ipsec Fri Jan 10 17:28:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA06826 for ipsec-outgoing; Fri, 10 Jan 1997 17:15:43 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: Deletes and cookies - problem Date: Fri, 10 Jan 1997 17:12:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Under Section 2.4 Identifying Security Associations "ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs." I take this to mean that the combined cookies identify the SA, there is wording elsewhere in the draft which supports this. Under Section 2.5.3 Anti-Clogging Token (Cookie) Creation of the ISAKMP draft (page 21)it states: "ISAKMP requires that the cookie be unique for each SA establishment, SA Notify, and SA Delete to help prevent replay attacks." Does this imply that the new cookies are for the new ISAKMP SA which must be negotiated in order to delete the old ISAKMP SA or does this mean that for each establishment and informational exchange the cookies must be unique. If it is the former then the statement is redundant and misleading and should only state "ISAKMP requires that the cookie be unique for each ISAKMP SA establishment or SA Notifies sent when SA establishment has failed." If it is the latter (how I interpret it) there are problems. Referring to section 4.8 Informational Exchange (page 51): "Once an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under protection provided by the ISAKMP SA." If a new cookie is generated for the Delete(Informational exchange) how are we supposed to identify what SA (ie the encryption algorithm, key) that is being used to protect the remainder of the packet? It would seem clear that if the combined cookies are to be used to identify ISAKMP SAs, that they cannot change from ISAKMP SA establishment to SA delete (for any protocol). Since a delete will only ever be sent after an SA has been established there is never a case to generate a new cookie when sending deletes. For Notify messages where an ISAKMP phase one negotiation has failed a new cookie should be generated, otherwise the message is sent under protection of the SA and therefore the original cookies are needed to identify the SA used to protect it. If I am missing something let me know. Thanks Bye. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Fri Jan 10 18:52:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07176 for ipsec-outgoing; Fri, 10 Jan 1997 18:43:45 -0500 (EST) Message-Id: Date: Thu, 9 Jan 1997 19:22:12 -0800 (PST) From: Phil Karn To: andrade@netcom.com CC: ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199701091957.LAA01904@netcom11.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk My code is based on Outerbridge's. It's a hand-optimized, manual translation of the core of his code to 386/486/Pentium assembler. Phil From owner-ipsec Fri Jan 10 19:07:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07266 for ipsec-outgoing; Fri, 10 Jan 1997 19:02:44 -0500 (EST) Message-Id: <9701110001.AA23417@sol.hq.tis.com> To: cat-ietf@MIT.EDU, e-payment@bellcore.com, firewalls@greatcircle.com, ids@uow.edu.au, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-tls@w3.org, ietf@cnri.reston.va.us, ipsec@ans.net, pem-dev@tis.com, psrg@isi.edu, sndss-authors@isi.edu, sndss-chairs@tis.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: 2ND ANNOUNCEMENT: ISOC 97 SYMP NETWORK & DISTRIBUTED SYSTEM SECURITY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23400.852940884.1@tis.com> Date: Fri, 10 Jan 1997 19:01:26 -0500 From: "David M. Balenson" Sender: owner-ipsec@ex.tis.com Precedence: bulk PLEASE NOTE THE EARLY REGISTRATION AND HOTEL ROOM AVAILABILITY AND SPECIAL RATES DEADLINES ARE APPROACHING!! RESERVATIONS AT THE PRINCESS RESORT MUST BE MADE NO LATER THAN JAN 13TH FOR THE GOVERNMENT RATE, AND NO LATER THAN JAN 20TH FOR THE REDUCED GROUP RATE. EARLY REGISTRATION FOR THE SYMPOSIUM MUST BE POSTMARKED NO LATER THAN JAN 22ND. --------------------------------------------------------------------------- THE INTERNET SOCIETY 1997 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '97) 10-11 FEBRUARY 1997 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA This fourth annual symposium will bring together researchers, implementors, and users of network and distributed system security technologies to discuss today's important security issues and challenges. It will provide a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. We hope to foster the exchange of technical information and encourage the Internet community to deploy available security technologies and develop new solutions to unsolved problems. WHY YOU SHOULD ATTEND The use of the Internet is rapidly growing and expanding into all aspects of our society. Commercial organizations are coming under increasing pressure to make their services available on-line. This in turn is increasing the need for rapid and widespread deployment of usable and effective network and distributed system security technologies. High visibility attacks on the Internet underscore the vulnerabilities of the Internet and the need to solve its security problems. There is growing concern for securing the network infrastructure itself. Recent trends in software distribution (such as Java and ActiveX technologies) have made certain attacks easier to carry out. Privacy has become an important issue for the Internet. NDSS '97 will bring together researchers, implementors, and users of network and distributed system technologies to discuss today's important security issues and challenges. We have selected the technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. Topics to be addressed include Internet infrastructure and routing security, security for the World Wide Web, Java and ActiveX security, cryptographic protocols, public key management, and protection of privacy. The symposium will have a positive impact on the state of Internet security. You will have the opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues during the panel sessions, and let other participants know of your requirements, observations, and experience in this important area. We hope to encourage the wide-scale deployment of security technologies and to promote new research that can address the currently unmet security needs of the Internet community. CONTENTS Preliminary Program Organizing Committee San Diego Princess Resort Registration Information Registration Form --------------------------------------------------------------------------- P R E L I M I N A R Y P R O G R A M SUNDAY, FEBRUARY 9 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MONDAY, FEBRUARY 10 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: THINGS THAT GO BUMP IN THE NET Chair: Stephen T. Kent (BBN Corporation, USA) Experimental Results of Covert Channel Elimination in One-Way Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard Schroeppel, Sean O'Malley, and Oliver Spatscheck (University of Arizona, USA) Blocking Java Applets at the Firewall, David M. Martin Jr., Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA) Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection & Configuration Analysis, Abdelaziz Mounji and Baudouin Le Charlier (Institut D'Informatique, Namur, BELGIUM) 10:30 A.M. BREAK 11:00 A.M. SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT Chair: Aviel Rubin (AT&T Research Labs, USA) Panelists: Li Gong (JavaSoft, USA), Jim Roskind (Netscape, USA), Edward W. Felten (Princeton University, USA) and Peter G. Neumann (SRI International, USA) 12:30 NOON LUNCH 2:00 P.M. SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS Chair: Christoph Schuba (Purdue University, USA) An Interface Specification Language for Automatically Analyzing Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA) Probable Plaintext Cryptanalysis of the IP Security Protocols, Steven M. Bellovin (AT&T Research, USA) Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford (Purdue University, USA) 3:30 P.M. BREAK 4:00 P.M. SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE Chair: Russ Mundy (Trusted Information Systems, USA) Panelists: Paul Lambert (Oracle, USA), Jeff Schiller (MIT, USA), Olafur Gudmundsson (Trusted Information Systems, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TUESDAY, FEBRUARY 11 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: ROUTING SECURITY Chair: Hilarie Orman (DARPA, USA) Securing the Nimrod Routing Architecture, Karen E. Sirois and Stephen T. Kent (BBN Corporation, USA) Securing Distance-Vector Routing Protocols, Bradley R. Smith, Shree Murthy and J.J. Garcia-Luna-Aceves (University of California Santa Cruz, USA) Reducing the Cost of Security in Link-State Routing, R. Hauser, A. Przygienda and G. Tsudik (IBM and USC/ISI, USA) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) Securing Web Access with DCE, Brian C. Schimpf (Gradient Technologies, USA) PANEL: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) 12:00 A.M. LUNCH 1:30 P.M. SESSION 7: PUBLIC KEY MANAGEMENT Chair: Jonathan Trostle (CyberSafe, USA) Hierarchical Organization of Certification Authorities for Secure Environments, Lourdes Lopez and Justo Carracedo (Universidad Politecnica de Madrid, SPAIN) Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic (Univeristy of Salford, UNITED KINGDOM) Distributed Authentication in Kerberos Using Public Key Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie Mellon University, USA) 3:00 P.M. BREAK 3:30 P.M. SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY Chair: Clifford Neuman (USC Information Sciences Institute, USA) --------------------------------------------------------------------------- O R G A N I Z I N G C O M M I T T E E GENERAL CHAIR David Balenson, Trusted Information Systems PROGRAM CHAIRS Clifford Neuman, USC Information Sciences Institute Matt Bishop, University of California at Davis PROGRAM COMMITTEE Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Verisign Richard Graveman, Bellcore Li Gong, JavaSoft Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Hilarie Orman, DARPA/ITO Michael Roe, University of Cambridge Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research PUBLICATIONS CHAIR Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR Thomas Hutton, San Diego Supercomputer Center REGISTRATIONS CHAIR Torryn Brazell, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group SPONSORED BY THE INTERNET SOCIETY Donald M. Heath, President & CEO Martin Burack, Executive Director --------------------------------------------------------------------------- S A N D I E G O P R I N C E S S R E S O R T LOCATION The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. Plan to visit La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. HOUSING INFORMATION We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio Rooms $ 81* Lanai Garden Rooms $114 * This represents the Government Rate for San Diego. A limited number of rooms are available at this rate. Reservations must be made no later than January 13, 1997. You must present a valid government id upon check-in. Based on room type and space availability, the special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. TO MAKE A RESERVATION Contact the San Diego Princess Resort at +1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1997. To receive the special goverment rate, you must make your reservation by January 13, 1997. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate, although, occasionally it rains. --------------------------------------------------------------------------- R E G I S T R A T I O N I N F O R M A T I O N FEES ISOC Non- Members Member* Early registration (postmarked on/before Jan. 22) $305 $345 Late registration $375 $415 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks * Non-Member fee includes one year Internet Society membership. FOR MORE INFORMATION Contact Carol Gray at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. WEB PAGE Additional information about the symposium and San Diego, plus on-line registration, are available via the Web at: http://www.isoc.org/conferences/ndss97 SPONSORSHIP OPPORTUNITIES AVAILABLE! Contact Torryn Brazell at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. --------------------------------------------------------------------------- R E G I S T R A T I O N F O R M INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887, send it via E-mail to Ndss97reg@isoc.org, or mail it to NDSS97, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA PERSONAL INFORMATION __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: ________________________________ MI: ____________________ Family Name: ___________________________________ __Sr __Jr __II __III Badge Name: __________________________________________________________ Please enter your name as you would like it to appear on your name tag. CONTACT INFORMATION Title: _______________________________________________________________ Organization: ________________________________________________________ Street address: ______________________________________________________ ______________________________________________________________________ City: ________________________________________________________________ State/Province: ___________________________ Postal Code: ____________ Country: _____________________________________________________________ Telephone Number (work): _____________________________________________ Telephone Number (home): _____________________________________________ Fax Number: __________________________________________________________ E-mail address: ______________________________________________________ SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?) ______________________________________________________________________ ______________________________________________________________________ APPEAR ON REGISTRANTS LIST? ___ Please check here if you would NOT like your name included in the list of registrants. PAYMENT INFORMATION All Payments must be in United States Dollars. Conference Fee -------------- If you are an Internet Society member, you are eligible for a reduced conference registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: On/Before After January 22 January 22 ---------- ---------- ___ Internet Society Member Fee US$ 305.00 US$ 375.00 ___ Non-Member Fee US$ 345.00 US$ 415.00 Method of Payment ----------------- Payment must be received on/before February 7, 1997 or we will be unable to pre-register you. 1. ___ Check. Make payable to the Internet Society. 2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard Name on Credit Card: ____________________________________ Credit Card Number: _____________________________________ Expiration Date: ________________________________________ 3. ___ CyberCash. Account Number: _____________________________ 4. ___ First Virtual. Account Number: _________________________ 5. ___ Wire Transfer* Bank ABA Number: 054000030 Account Number: Internet Society 148 387 10 Riggs National Bank of Virginia 950 Herndon Parkway Herndon, VA 20171 USA Wire Transfer Confirmation Number: ______________________ * Please process wire transfer before sending registration form. 6. ___ U.S. Government Purchase Order* P.O. Number: ____________________________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds (less a $25 processing fee) will be issued for cancellations received on/before February 7, 1997. No refunds will be issued after February 7, 1997. ------------------------------------------------------------------------ From owner-ipsec Tue Jan 14 08:08:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03027 for ipsec-outgoing; Tue, 14 Jan 1997 07:56:30 -0500 (EST) Date: Tue, 14 Jan 97 04:15:03 GMT Standard Time From: Ran Atkinson Subject: change of address To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk IPsec folks, My email address has changed to from . Should anyone need to reach me via email, please be sure to use the new address. Thanks very much, Ran rja@inet.org Co-chair, IPsec WG, IETF From owner-ipsec Tue Jan 14 13:49:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05447 for ipsec-outgoing; Tue, 14 Jan 1997 13:43:10 -0500 (EST) Date: 14 Jan 97 13:46:36 -0500 Subject: Re: Draft des-md5 v3 From: "James Hughes" To: ipsec@tis.com, "Angelos D. Keromytis" X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > While implementing the DES-MD5 transform as of draft v3, i noticed > that the algorithm that checks the replay counter window that's given > would not work correctly with the draft's specification; the algorithm > assumes that the initial value of the replay counter is 1 (or 0), but > the draft has the counter initialized to some arbitrary value (an MD5 > result). The counter must be "aliased" to 0 by subtracting the received value from the initial value. Unsigned arithemetic works just fine for this. jim From owner-ipsec Tue Jan 14 20:57:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07725 for ipsec-outgoing; Tue, 14 Jan 1997 20:55:43 -0500 (EST) Hops: 0 Host: clinet.fi. Posted-Date: Wed, 15 Jan 1997 03:57:03 -0200 (GMT) Message-Id: <199701150158.DAA14112@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com Subject: Release 0.4 of my Linux IPSEC code is out. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 03:58:37 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk It should appear in ftp://ftp.funet.fi/pub/unix/security/net/ip/ within a day. The impatient can get it from http://prometheus.hol.gr/~ji/ipsec/. /ji From owner-ipsec Wed Jan 15 15:00:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13716 for ipsec-outgoing; Wed, 15 Jan 1997 14:56:04 -0500 (EST) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" , "'isakmp-oakley'" , "'IETF Security Test mailing list'" Subject: 64-bit replay counters Date: Wed, 15 Jan 1997 14:59:51 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [AH-HMAC-MD5] and [AH-HMAC-SHA1] state that the replay counter is 64 bits, but it points to the [ESP-DES-MD5] draft for an exmple of a 32-bit replay counter source code. Could it provide more information on how to transform that 32-bit code to handle the newer 64-bit counters. -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 15:00:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13692 for ipsec-outgoing; Wed, 15 Jan 1997 14:51:34 -0500 (EST) Message-ID: From: Roy Pereira To: "'Derrell Piper'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: negotiating IVs Date: Wed, 15 Jan 1997 14:56:07 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [IPSEC-DOI] doesn't include a method to negotiate whether or not to use an explicit IV and what size to use. RFC1829 [ESP-DES] and RFC1851 [ESP-DES3] state that the IV is always 64 octets, but the newer ESP transform drafts [draft-ietf-ipsec-esp-des-md5-03.txt] state that the explicit IV is optional and should be negotiated. Should [IPSEC-DOI] be updated ? -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 15:05:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13792 for ipsec-outgoing; Wed, 15 Jan 1997 15:02:34 -0500 (EST) Message-Id: From: Roy Pereira To: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" , "'Daniel Harkins'" Subject: ISAKMP/Oakley algorithms Date: Wed, 15 Jan 1997 15:05:44 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-ietf-ipsec-isakmp-oakley-02.txt it lists encryption and hash algorithms that are not listed with draft-ietf-ipsec-doi-02.txt (IDEA, Blowfish, Tiger). Should we try and keep all protocols the same between both levels or at least try and include the same commone core algorithms. Basically, I'd like to see DES3 added to this list as well a reference that points to these other les common algorithms. -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 16:53:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14540 for ipsec-outgoing; Wed, 15 Jan 1997 16:51:20 -0500 (EST) Date: Wed, 15 Jan 1997 16:53:50 -0500 Message-Id: <9701152153.AA01140@ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: isakmp-oakley@cisco.com, ipsec@tis.com From: Naganand Doraswamy Subject: Key Material Sender: owner-ipsec@ex.tis.com Precedence: bulk When we negotiate Key Material using Oakley QM, we could negotiate for both ESP and AH using two proposals under the same SA payload. The keying material we come up with is the same as they are not in separate SA payload. Once we come with a keying material, we dont say how the proposals will use them for generating keys. Should we be worried about wierd interaction between authentication and encryption algorithms if both end up using the first few bits of the key material. If this is an issue, then we should probably say that for each proposal we will come up with different keying materail as we do in the case of multiple SA's. Comments? Naganand From owner-ipsec Wed Jan 15 18:49:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15080 for ipsec-outgoing; Wed, 15 Jan 1997 18:47:53 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: SA payloads and Next payload Date: Wed, 15 Jan 1997 18:46:22 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello All, Could those in the know please clarify the next payload for SA payloads. In the examples it is always set to PROPOSAL, but from the wording of the ISAKMP doc it suggests otherwise and my opinion is that it should be otherwise, the next NON SA related payload ( ie in aggresive mode it would be KE, NONE for Main Mode). Section 4.1 SA Establishment (Page 41 first paragraph) ..."An SA establishment message consists of a single SA payload followed by AT LEAST one and possible many proposal and transform payloads." so there isn't a need to look to the next payload of the SA header to know that the data in the SA payload is in fact a proposal. Since this is in the ISAKMP doc I would assume that this would have to hold up across any DOI. Section 4.1 SA Establishment (Page 42 first paragraph) ..."Note that the Next Payload field of the proposal payload points to another Proposal (if it exists)." same section last paragraph ..."Note that the Next Payload field of the Transform payload points to another Transform payload or 0." So if we can't get it from the proposal or transform(which I don't think would be a good idea anyways) then we have to get it from the SA header. Thanks. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com From owner-ipsec Wed Jan 15 19:17:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15217 for ipsec-outgoing; Wed, 15 Jan 1997 19:16:54 -0500 (EST) Date: Wed, 15 Jan 1997 19:19:06 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199701160019.TAA02181@earth.hpc.org> To: naganand@ftp.com Cc: ipsec@tis.com, isakmp-oakley@cisco.com In-reply-to: Yourmessage <9701152153.AA01140@ftp.com> Subject: Re: Key Material Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmmm. I suppose you could include the key from the previous proposal as input to the hash for computing the key for the current proposal. Hilarie From owner-ipsec Thu Jan 16 08:22:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA18977 for ipsec-outgoing; Thu, 16 Jan 1997 08:17:58 -0500 (EST) Date: Thu, 16 Jan 97 08:29:52 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9701161329.AA27488@dolphin.ncsc.mil> To: ipsec@tis.com, carterg@entrust.com Subject: Re: SA payloads and Next payload Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, The Last Call for ISAKMP has completed. I am working on making editorial changes based on comments from several people. Here's the latest on your question, so feel free to let me know if you (or anyone) disagrees. > Could those in the know please clarify the next payload for SA > payloads. In the examples it is always set to PROPOSAL, but from the > wording of the ISAKMP doc it suggests otherwise and my opinion is that > it should be otherwise, the next NON SA related payload ( ie in > aggresive mode it would be KE, NONE for Main Mode). The Next Payload field of an SA payload will point to the next payload of the message (if one exists) and not to the Proposal payload as version 6 of the draft specifies. > Section 4.1 SA Establishment (Page 41 first paragraph) > ..."An SA establishment message consists of a single SA payload followed > by AT LEAST one and possible many proposal and transform payloads." > > so there isn't a need to look to the next payload of the SA header to > know that the data in the SA payload is in fact a proposal. Since this > is in the ISAKMP doc I would assume that this would have to hold up > across any DOI. Correct. > Section 4.1 SA Establishment (Page 42 first paragraph) > ..."Note that the Next Payload field of the proposal payload points to > another Proposal (if it exists)." > > same section last paragraph > ..."Note that the Next Payload field of the Transform payload points to > another Transform payload or 0." > > So if we can't get it from the proposal or transform(which I don't think > would be a good idea anyways) then we have to get it from the SA header. Correct. Regards, Doug From owner-ipsec Thu Jan 16 12:30:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20189 for ipsec-outgoing; Thu, 16 Jan 1997 12:20:55 -0500 (EST) Message-Id: <199701161724.JAA00461@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: Re: ISAKMP/Oakley algorithms In-Reply-To: Your message of "Wed, 15 Jan 1997 15:05:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 09:24:14 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In draft-ietf-ipsec-isakmp-oakley-02.txt it lists encryption and hash > algorithms that are not listed with draft-ietf-ipsec-doi-02.txt (IDEA, > Blowfish, Tiger). Should we try and keep all protocols the same between > both levels or at least try and include the same commone core > algorithms. Those algorithms are used to protect ISAKMP-ISAKMP communication and are not bound by the IPsec DOI. Ideally, a draft-ietf-ipsec-isakmp-oakley-02.txt compatible peer can negotiate more than just IPsec. I don't want to remove these algorithms to "keep all protocols the same" but that goal can also be realized by writing an AH-Tiger-HMAC document, and an ESP-IDEA-CBC-REPLAY-et-al document, etc. (insert emoticon here). > Basically, I'd like to see DES3 added to this list as well a reference > that points to these other les common algorithms. Applied Cryptography references IDEA and Blowfish. I can add a reference to Tiger. Dan. ------------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (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 ------------------------------------------------------------------------------- From owner-ipsec Thu Jan 16 12:35:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20256 for ipsec-outgoing; Thu, 16 Jan 1997 12:31:26 -0500 (EST) Message-Id: <2.2.32.19970116173456.00b51d70@mailhost> X-Sender: jtardo@mailhost X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 09:34:56 -0800 To: wdm@epoch.ncsc.mil (W. Douglas Maughan) From: Joe Tardo Subject: Re: SA payloads and Next payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:29 AM 1/16/97 EST, you wrote: >The Last Call for ISAKMP has completed. Doug: When did this happen, and on which mailing list? Thanks, Joe From owner-ipsec Thu Jan 16 14:14:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20956 for ipsec-outgoing; Thu, 16 Jan 1997 14:11:15 -0500 (EST) Date: Thu, 16 Jan 97 19:06:16 GMT Standard Time From: Ran Atkinson Subject: IPsec WG Last Call over To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Just a reminder... The IPsec WG Last Call period for ISAKMP/Oakley ended as scheduled during the first week of January and is now over. There were a number of editorial clarifications requested and the editors are now off making those editorial changes to their drafts. I anticipate that revised drafts will appear online soon. Anyone who has any remaining editorial suggestions should send those directly to the appropriate document editor(s) immediately. As reminder to folks not familiar with IETF procedures, I'll mention that unlike ANSI/IEEE there is no requirement for a formal response to each input sent to the list or to the co-chairs because we aren't tallying votes or voting. Each input is, however, considered. Paul and I are comparing notes in case someone sent mail to one of us but not to the other of us. Result of the Last Call should be out soon to this list. Ran rja@inet.org Co-Chair, IPsec WG From owner-ipsec Thu Jan 16 16:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22087 for ipsec-outgoing; Thu, 16 Jan 1997 16:46:45 -0500 (EST) Message-Id: <199701162150.NAA00798@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Naganand Doraswamy Cc: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Re: Key Material In-Reply-To: Your message of "Wed, 15 Jan 1997 16:53:50 EST." <9701152153.AA01140@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 13:50:07 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > When we negotiate Key Material using Oakley QM, we could negotiate for both > ESP and AH using two proposals under the same SA payload. The keying > material we come up with is the same as they are not in separate SA payload. > Once we come with a keying material, we dont say how the proposals will use > them for generating keys. Good point. The solution to this problem also convieniently solves another problem: how to force the 2 SA's that result from a single SA negotiation (one inbound, one outbound) to have different keys. The solution is to hash the SPI into KEYMAT using the negotiated hash function. This will be noted in the next version of the draft. regards, Dan. From owner-ipsec Fri Jan 17 11:35:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29697 for ipsec-outgoing; Fri, 17 Jan 1997 11:29:06 -0500 (EST) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" Cc: "'piper@tgv.com'" , "'ipsec@tis.com'" Subject: Inconsistencies between values and field size Date: Fri, 17 Jan 1997 11:26:00 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know if has been pointed out yet, please ignore if it has... ISAKMP Draft 6 Proposal Payloads Protocol ID - 1 octet DOI Draft 2 (Dec 9) The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI. ... The values 4-15360 are reserved to IANA. Values 15361-16384 are reserved for private use. The size of the field in the ISAKMP draft the DOI values don't match up. Easy to fix Proposal Payload # of transforms - 2 octets but look at Transform Payload # Transforms - 1 octet So the max you can send in a proposal is 1 octet worth, therefore change the Protocol ID field to 2 octets and # of Transforms to 1 octet in the Proposal Payload. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com > From owner-ipsec Fri Jan 17 11:52:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00011 for ipsec-outgoing; Fri, 17 Jan 1997 11:51:03 -0500 (EST) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" Cc: "'ipsec@tis.com'" , "'piper@tgv.com'" Subject: dido for transform ID Date: Fri, 17 Jan 1997 11:43:59 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Same problem with transform ID field in Transform payloads and those values given in the DOI for ISAKMP, ESP, and AH transform values. And as I mentioned before the ID Type field for Identification payloads. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com From owner-ipsec Sun Jan 19 01:46:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA13696 for ipsec-outgoing; Sun, 19 Jan 1997 01:36:43 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701190640.WAA25885@netcom22.netcom.com> Subject: Re: IPsec and TCP To: gnu@toad.com (John Gilmore) Date: Sat, 18 Jan 1997 22:40:08 -0800 (PST) Cc: andrade@netcom.com, karn@qualcomm.com, gnu@toad.com, ipsec@tis.com In-Reply-To: <199701161334.FAA20529@toad.com> from "John Gilmore" at Jan 16, 97 05:34:03 am Sender: owner-ipsec@ex.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: 1783 John, > > What's slow about 1 to 2 Mbytes/second? That's faster than Ethernet, > and faster by an order of magnitude than almost everyone's connection > to the Internet (1.5Mbits/sec T1 is the highest common speed). If > you were DES-encrypting main memory accesses, it would be slow; but > if you're DES-encrypting an Ethernet, it's plenty fast. It is slow. 10 Mbit/s Ethernet tops out at around 1.2 Megabytes per second using TCP/IP (assuming no collisions). That 1-2 Megabytes encryption speed means that you are using about 100% of a Pentium's 200 Mhz CPU cycles. Not much room for other processing. On top of that 100 Mbit/s Ethernet is starting to become common. It's will be at least 5 years, assuming Moore's law, before the top Intel chips will be fast enough to keep up with it doing DES. > > Optional hardware assists are quite common on Wintel platforms. The > shrinkwrap software simply probes for the hardware (or its driver). > If it's there, it uses it; if not, it runs slower in software. This > gives individual customers the option to buy the hardware if they > desire more speed. Just like the original poster said. > DES was designed a long time ago to optimize memory over speed. This made a lot of economic sense at the time. Today it doesn't and we are now struggling with it trying to retrofit it into modern high-speed networks. Saying you can throw hardware at it to speed it up doesn't make very much economic sense for most of the hosts on the Internet. Could you imagine how popular TCP/IP would be today if 15 years ago the original designers said that you had to use hardware to get it to operate fast enough? - Alex -- Alex Alten PO Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sun Jan 19 07:46:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15064 for ipsec-outgoing; Sun, 19 Jan 1997 07:42:14 -0500 (EST) Message-Id: Date: Sun, 19 Jan 1997 03:23:57 -0800 (PST) From: Phil Karn To: andrade@netcom.com CC: gnu@toad.com, andrade@netcom.com, ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199701190640.WAA25885@netcom22.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >It is slow. 10 Mbit/s Ethernet tops out at around 1.2 Megabytes >per second using TCP/IP (assuming no collisions). That 1-2 >Megabytes encryption speed means that you are using about 100% >of a Pentium's 200 Mhz CPU cycles. Not much room for other >processing. On top of that 100 Mbit/s Ethernet is starting to >become common. It's will be at least 5 years, assuming Moore's law, >before the top Intel chips will be fast enough to keep up with it >doing DES. I again: my own DES code for the Intel family does 16.9 megabits/sec on a 133 MHz Pentium. That should be 25.4 megabits/s on a 200 MHz pentium, so encrypting a 10 Mb Ethernet should leave 60% of your machine for other things -- worst case, when the net is saturated. Now I agree that 1DES is probably no longer sufficient, so these numbers aren't as applicable as they once were. >DES was designed a long time ago to optimize memory over speed. This >made a lot of economic sense at the time. Today it doesn't and we are All the modern fast software DESes, including mine, spend considerable memory to gain speed without sacrificing compatibility. The best example is the combining of the original S (substitution) and P (permutation) boxes into a single lookup table. There is a limit on this technique, however, as you don't want the lookup tables to blow out of the on-chip Pentium cache. But these SP boxes are small enough to fit. One of the interesting moments during the oral arguments the other week in my lawsuit (Karn vs Dept of State) in the DC Circuit Court of Appeals had Judge Douglas Ginsburg reading aloud from the SP initialization table in the Applied Cryptography DES code. He read hex constants like 0x12345678 as "zero times one two three four...". Of course, according to court protocol I could not say anything as I was a mere mortal in the audience... Phil From owner-ipsec Sun Jan 19 23:35:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19173 for ipsec-outgoing; Sun, 19 Jan 1997 23:31:44 -0500 (EST) Message-Id: <9701200435.AA33030@commanche.ca.boeing.com.> To: andrade@netcom.com (Andrade Software Andrade Networking) Cc: gnu@toad.com (John Gilmore), karn@qualcomm.com, ipsec@tis.com Subject: Re: IPsec and TCP In-Reply-To: (Your message of Sat, 18 Jan 97 22:40:08 -0800.) <199701190640.WAA25885@netcom22.netcom.com> Date: Sun, 19 Jan 97 20:35:20 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Just want to throw in my two cents worth of support on your state- ment in general. As Phil points out the numbers may be a bit better than yours, but in general we still seem to have a serious problem with performance with most of the DES-like complex cryptography. When we begin to scale the complex types beyond single user systems, it appears that local encryption engines may be needed to maintain reasonable ratio's of users per server. We have servers that today maintain several hundred simultaneous TCP/IP connections. Ideally within a few years all of these connections would be encrypted. I think as we begin to scale cryptography into supporting systems that support large numbers of simultaneous encrypted connections, performance will be a huge issue. For example, we have a group of proxy servers running SSL and today our code measurements show that they are running past 90% of the time in the encryption routines. In the short term, until we can get encryption engines embedded into (or near) the processors, we may need to make some reasonable choices on the weights of encryption we plan to use. In many cases, reserving heavy weight encryptions like DES for critical/sensitive connections, and using lighter weight cypher solutions to protect less critical ones my make sense. If we can't successfully use strong encryption on all connections, we'd still like to be able to encrypt all of them even if this requires use of lighter encryption forms for some. There's a couple of good reasons to do this: 1) We don't want to make it easy for someone to figure out which connections are important simply because they are the only ones encrypted. 2) If we have all connections encrypted with a mix of encryption types running, an attacker must then expend considerable resources figuring out which type of encryption the connection is protected with before attempting to crack it and then perhaps only to find it was a download of a now out of date weather map. 3) Make casual eavesdropping not quit so casual(i.e Newt). Even very light cyphers, especially if a lot of them are used, would take most of the fun out of eavesdropping with a scanner or sniffer simply by adding an element of work. Hopefully some of the developers/vendors out there will run some scaling tests soon and provide some feedback to the WG on "server" performance. I know some folks are planning to include the encryption engines with their platforms but I'd like to see some raw unassisted numbers on just large servers. It'd be a real help to those of us trying to plan large scale deployment of encryption and perhaps it would prove our performance fears with DES/3DES and similarly complex encryptions unfounded. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | 206-957-5325 | terry.l.davis@boeing.com. | --------------- Sunday January 19,1997 07:51 PM PST ------------- From owner-ipsec Mon Jan 20 10:42:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22794 for ipsec-outgoing; Mon, 20 Jan 1997 10:34:21 -0500 (EST) Message-ID: <32E38F93.284797A9@multinet.net> Date: Mon, 20 Jan 1997 10:30:27 -0500 From: graydon hoare X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2-ALPHA i386) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: IPsec DES slowdown References: <9701200435.AA33030@commanche.ca.boeing.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Terry L. Davis, Boeing Information & Support Services, Bellevue, WA wrote: > and using lighter weight cypher solutions to protect less critical > ones my make sense. If we can't successfully use strong encryption > on all connections, we'd still like to be able to encrypt all of them > even if this requires use of lighter encryption forms for some. I agree -- it's a huge waste to apply the strongest cryptography to everything that runs through your system. 99% of everything placed on an internet server is zero-security, public data. Even if you embed authentication data (eg. signatures) you don't need to make things totally unreadable unless they deal with private property (i.e. cash, secrets). To make things unsnoopable, you just need to make it sufficiently obscure where to snoop. I think you'll get the same atitude from VISA and mastercard: they have realized that it would cost them more to implement some stronger protection scheme across the board than it does to deal with the fraud & stealing. -graydon _______________________________________________________________________ well...you can study all your cranial anatomy charts and read all the textbooks, but y'know... once you get inside it all kinda looks the same Nonono don't touch that -- you never know what it might be attached to -b.banzai From owner-ipsec Mon Jan 20 12:39:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23844 for ipsec-outgoing; Mon, 20 Jan 1997 12:35:53 -0500 (EST) Date: Mon, 20 Jan 1997 11:39:28 -0600 From: jim@hosaka.smallworks.com (Jim Thompson) Message-Id: <199701201739.LAA08199@hosaka> To: andrade@netcom.com, gnu@toad.com Subject: Re: IPsec and TCP Cc: ipsec@tis.com, karn@qualcomm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Could you imagine how popular TCP/IP would be today if 15 years ago >the original designers said that you had to use hardware to get it >to operate fast enough? Well, yeah. I was there, as a matter of fact. No, the original designers didn't state that you needed hardware assist to get TCP/IP to go fast, but there were a lot of companies attempting to get the TCP/IP processing to happen on a board (sometimes the controller board(s) in an effort to make it run faster. Way back, TCP wouldn't come anywhere *near* filling an 10Mbps Ethernet. Then this nice guy named Van (and a few others through history) turned the light on... Jim From owner-ipsec Mon Jan 20 14:27:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24431 for ipsec-outgoing; Mon, 20 Jan 1997 14:23:22 -0500 (EST) Message-Id: <199701201924.LAA18380@dns1.ConsumerInfo.Com> Comments: Authenticated sender is From: "Wayne Yu" Organization: ConsumerInfo.Com, Inc. To: ipsec@tis.com, graydon hoare Date: Mon, 20 Jan 1997 11:26:36 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IPsec DES slowdown Reply-to: wyu@ConsumerInfo.Com In-reply-to: <32E38F93.284797A9@multinet.net> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Mon, 20 Jan 1997 10:30:27 -0500 > From: graydon hoare > To: ipsec@tis.com > Subject: Re: IPsec DES slowdown > Terry L. Davis, Boeing Information & Support Services, Bellevue, WA > wrote: > > > and using lighter weight cypher solutions to protect less critical > > ones my make sense. If we can't successfully use strong encryption > > on all connections, we'd still like to be able to encrypt all of them > > even if this requires use of lighter encryption forms for some. > > I agree -- it's a huge waste to apply the strongest cryptography to > everything that runs through your system. 99% of everything placed on an > internet server is zero-security, public data. Even if you embed > authentication data (eg. signatures) you don't need to make things > totally unreadable unless they deal with private property (i.e. cash, > secrets). To make things unsnoopable, you just need to make it > sufficiently obscure where to snoop. I think you'll get the same atitude > from VISA and mastercard: they have realized that it would cost them > more to implement some stronger protection scheme across the board than > it does to deal with the fraud & stealing. > > -graydon > > _______________________________________________________________________ > well...you can study all your cranial anatomy charts and read all the > textbooks, but y'know... once you get inside it all kinda looks the same > Nonono don't touch that -- you never know what it might be attached to > -b.banzai > > > There is a compnay called Rainbow Technologies. They lcoated in Irvine California. They provide a hardware encrytion solution for this problem. Can somehow the hardware solution and software solution combind together? Wayne Yu, Director of Technology ConsumerInfo.Com, Inc. Phone (714)978-0078 ext. 1010 Fax (714)978-0059 We provide personal credit information, visit us at http://www.consumerinfo.com From owner-ipsec Tue Jan 21 05:34:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA28944 for ipsec-outgoing; Tue, 21 Jan 1997 05:31:26 -0500 (EST) Message-Id: <199701211032.CAA04544@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: wyu@ConsumerInfo.Com cc: ipsec@tis.com, graydon hoare , gnu@toad.com Subject: Re: IPsec hardware accelerators (Rainbow warning) In-reply-to: <199701201924.LAA18380@dns1.ConsumerInfo.Com> Date: Tue, 21 Jan 1997 02:32:41 -0800 From: John Gilmore Sender: owner-ipsec@ex.tis.com Precedence: bulk > There is a compnay called Rainbow Technologies. They lcoated in Irvine > California. They provide a hardware encrytion solution for this problem. > Can somehow the hardware solution and software solution combind together? Thanks for the pointer. One "hardware encryption solution" Rainbow provides is the Clipper Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its follow-on products are not compatible with the IPSEC protocols, because they use an undocumented encryption algorithm and because they are designed to undermine rather than provide secure operation. Rainbow's Mykotronx "Internet Security Group" also offers a "CryptoSWIFT" PCI board that accelerates public-key protocols. This board might be useful for the high-level IPSEC key agreement protocol. It isn't advertised to help with the low-level packet encryption, though their beta-site form says they'll add DES and 3DES in 1997. The board is now in alpha or beta test. However, Rainbow's press release of December 12th announces support for the "Key Recovery Alliance" and specifically mentions the board. That and their long history with Clipper and NSA mean that company statements that the board provides "Secure key generation and storage" should be taken with a large grain of salt. It's much harder to validate the security of the guts of an ASIC than it is to validate a software key generator. And you can easily compare the binary of the production key generator code to your validated version, while you can't examine the guts of each ASIC except by physically destroying it. Techniques are known for "leaking" private keying information from a subverted cryptographic processor chip, in ways that cannot be detected except by eavesdroppers who know the secrets embedded in the chip. Rainbow/Mykotronx have a long history of collaboration with NSA on classified projects designed to subvert the information security of users. Rainbow's 1996 Q3 10-Q form (www.sec.gov) notes: Revenues from information security products [Mykotronx - gnu] for the three and nine months ended September 30, 1996 remained consistent and increased by 6%, respectively, when compared to the same periods in 1995. The Company continued to experience low growth rates due to the slower than anticipated deployment of network security products within the government. I.e. Clipper/Capstone/Fortezza aren't proving to be popular products. Gross profit from information security products for both the three months and the nine months ended September 30, 1996 was 19% and 16% of revenues compared with 21% and 23%, respectively, for the corresponding periods in 1995. The decrease in gross margin was due to the change of mix from predominantly product contracts to principally less profitable research and development contracts. These R&D contracts might well include research on building chips that "leak" private information. Such features would be relatively easy to transfer from Fortezza chips into chips that do standard public-key algorithms. (See also the Baltimore Sun articles from December 3-13, 1995, on how NSA subverted Swiss company Crypto AG's products for many years. Senior Crypto AG officials stated throughout that their products were secure and untampered.) It *may* be possible to use untrustworthy chips to build secure systems, if you only use documented encryption algorithms and don't use the chips to generate any keys or random numbers. A first step would be to only use such chips for predictable (software-duplicatable) operations, and check some tiny percentage of the transactions by rerunning them in software. The chip may still be subverting your security in other ways (e.g. broadcasting your private key at radio frequencies on unused pins in the hope that a spook with TEMPEST monitoring gear is nearby). If any working group members know of useful hardware crypto accelerators available from non-US companies (for the world market), please let me know. I'd like to see hardware acceleration supported, but not using US-only and/or likely-subverted products. John Gilmore From owner-ipsec Tue Jan 21 08:30:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00238 for ipsec-outgoing; Tue, 21 Jan 1997 08:29:26 -0500 (EST) Date: Tue, 21 Jan 1997 08:31:54 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199701211331.IAA17245@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: IPsec and TCP X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: andrade@netcom.com (Andrade Software Andrade Networking) > > DES was designed a long time ago to optimize memory over speed. This > made a lot of economic sense at the time. Today it doesn't and we are > now struggling with it trying to retrofit it into modern high-speed > networks. NIST has begun the process of selecting a replacement for DES which would be more suited to today's environment. They are now looking for public comments on the criteria by which the Advanced Encryption Standard (AES) will be selected; comments are due by April 2, and will be followed by a public selection criteria workshop on April 15. Here's an excerpt from the announcement, more info can be found at http://www.nist.gov/public_affairs/current.htm. > PROPOSED DRAFT MINIMUM ACCEPTABILITY REQUIREMENTS AND EVALUATION > CRITERIA > > The draft minimum acceptability requirements and evaluation criteria > are: > > A.1 AES shall be publicly defined. > > A.2 AES shall be a symmetric block cipher. > > A.3 AES shall be designed so that the key length may be increased as > needed. > > A.4 AES shall be implementable in both hardware and software. > > A.5 AES shall either be a) freely available or b) available under > terms consistent with the American National Standards Institute (ANSI) > patent policy. > > A.6 Algorithms which meet the above requirements will be judged based > on the following factors: > > a) security (i.e., the effort required to cryptanalyze), > b) computational efficiency, > c) memory requirements, > d) hardware and software suitability, > e) simplicity, > f) flexibility, and > g) licensing requirements. > > Comments are being sought on these draft minimum acceptability criteria > and evaluation criteria, suggestions for other criteria, and relative > importance of each individual criterion in the evaluation process. > Criteria will be finalized by NIST following the criteria workshop. From owner-ipsec Tue Jan 21 13:04:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02060 for ipsec-outgoing; Tue, 21 Jan 1997 12:56:56 -0500 (EST) Message-Id: <3.0.32.19970121124325.00a389e0@datasec.net> X-Sender: korinne@datasec.net X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) X-Priority: 1 (Highest) Date: Tue, 21 Jan 1997 12:43:26 -0500 To: ipsec@portal.ex.tis.com From: korinne@datasec.net (Korinne) Subject: DATANET SECURITY 97 PROGRAM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Conference program Datanet Security 1997 Annual International Conference and Exhibition on Wide Area Network Security FEBRUARY 17 - 18 - 19 - 20, 1997 HYATT REGENCY MIAMI HOTEL & CONVENTION CENTER All lectures and presentations have been confirmed Keynote speakers: Monday February 17, 1997 The 1997 Datanet Security conference will be opened with a keynote address by Dr. Ruth A. David, Deputy Director Science & Technology of the Central Intelligence Agency. Following the opening address, Mr. Stuart A. Baker will deliver a keynote speech "Legal Aspects of Network Security". Stuart Baker is partner with Steptoe & Johnson in Washington DC, and former lead counsel for the National Security Agency. Keynote speakers: Tuesday February 18, 1997 The second day of the Annual Datanet Security Conference is highlighted with a presentation by Dr. Rob Kolstad "Non-Security Issues Affecting the Future of the Internet". Rob Kolstad is President of BSDI Inc. "What's Slowing down Deployment of Security ?" is the title of the next keynote address by Novell's Chief Security Architect, Dr. Radia Perlman. She was featured in the 20th anniversary edition of Data Communications magazine as one of 20 most influential people in the field of computer networking. Keynote speaker: Wednesday February 19, 1997 This conference day we feature Mr. Scott Charney as a prominent keynote speaker. Scott Charney is the principal government authority on computer crime. He heads the federal prosecutors and leads the Computer Crime and Intellectual Properties Section within the Department of Justice. ADVANCED TECHNOLOGY PROGRAM Monday February 17, 1997 ELECTRONIC INTELLIGENCE "Intelligence Behind the Journal Intelligence" - Olivier Schmidt Olivier Schmidt is founding editor of several important international professional news journals and expert publications. Among these "Parapolitics", "Intelligence Newsletter" and "Intelligence". He co-authored "Intelligences Secretes" and "OSS et la Resistance Francaise". He lives and works in Paris, France. "The King of Secret Readers: Edgar Allen Poe, William Friedman, and the Logic of the Cold War" - Professor Shawn Rosenheim Shawn J. Rosenheim is Associate Professor of English at Williams College (Williamstown, Mass.), and a founding member of the Communications Technologies Research Group. His most recent publication is "The Cryptographic Imagination: Secret Writing from Edgar Poe to the Internet" (Johns Hopkins University Press, 1996) DISCUSSION PANEL Traditional versus New Technologies: A Challenge for the Intelligence Communities Session and Panel Chairman - David Whipple David Whipple is Executive Director of the Association of Former Intelligence Officers, AFIO. As no other Mr. Whipple is able to illustrate the traditional methods of information gathering. INTERNET SECURITY The Changing Role of the Firewall - Stephen Flaig Mr. Flaig is Vice President for LanOptics Inc., developers of the Guardian firewall. Network Access Flexibility through RADIUS - David Dawson David Dawson is General Manager Network Security Business Unit for Ascend Communications Inc. Previously he was Chief Executive Officer of Morningstar Technologies Inc. He holds a BS in Electrical Engineering from the US Military Academy at West Point. Internet Security and the IBM Firewall - Peter Crotty Peter Crotty is worldwide responsible for IBM's technical firewall support program. Secure Access: If you don't have security everywhere, you don't have it anywhere ! - Doug LaBorde Mr. LaBorde is Manager with the Network Security Business Unit of Ascend Communications. NT SECURITY Windows NT Security: Networked Perspectives - Charles Rutstein Charles Rutstein is Principal Consultant with Price Waterhouse, and has extensive front line computer and network security experience. He authored several books on computer viruses. His latest work, dealing with Windows NT security, has just been released. NT Internet Security - Firewalls, Web-servers, and Vulnerabilities - Bill Stout Bill Stout is network security analyst and senior systems administrator with Hitachi Data Systems. He specializes in Windows NT security issues. VIRUSES Viruses and the Internet; email, Java, Active-X; the new virus carriers - Thierry Giron Thierry Giron holds a Computer Science Hon. degree from Middlesex University (London, UK), and a Business degree from ESC in Reims, France. He joined Trend Micro in Taiwan in 1992, and is since Trend's Customer Engineering Manager for the North American offices. Minimizing the Virus Threat - Glenn Jordan Glenn Jordan is the leading virus technology expert with Dr. Solomon, and is an established member of the Computer Anti-virus Research Organization, an international network of anti-virus researchers. Mr. Jordan is a graduate of the University of North Carolina. Tuesday February 18, 1997 INTERNET SECURITY Cyber Thieves - Gregg Lebovitz Gregg Lebovitz is Director of Security Products at BBN Planet. Mr. Lebovitz spent 15 years at Carnegy-Mellon University, designing, implementing and deploying network routers and distributed applications. Accounting for Square-Root Attacks in Cryptographic Design - Michael Wiener Michael Wiener is senior cryptologist with Entrust Technologies (formerly Nortel Secure Networks). His expertise is in the area of cryptanalysis, authentication, and key-exchange protocols, public-key infrastructures, design of cryptographic systems, and high-speed implementations of public-key cryptosystems. He is agraduate of the University of Waterloo (Canada). Virtual Private Networking: Integrating Internet and Intranet Security - Tony Rosati Tony Rosati is co-founder and Vice President for TimeStep Corporation. He leads design teams ranging from the development of public-key and DES based integrated circuits to the development of system level communications security solutions utilizing cryptographic techniques. Approaching End-to-End Security - Paul Ferguson Paul Ferguson is a senior expert with Cisco Systems. His principal disciplines are Internet security, large-scale routing and design architecture. NETWORK SECURITY Assurance in Products for the Internet - Alan Borrett Alan Borrett is member of the UK IT Evaluation & Certification Scheme, under authority of Her Majesty's Government Communications Headquarters (GCHQ) Computer Security in the Third World: The Mexican Case - Prof. Guillermo Mallen Professor Mallen teaches and researches at the Ibero-Americana University in Mexico. He is a former President of the Mexican Academy of Informatics. Single Point Security: The Unisys Vision for Enterprise Security Administration - William Buffam William Buffam is software architect with Unisys Corp. His background is in operating systems, networking, and solution engineering. He holds a Computer Science degree from the University of Manchester. Security Solutions for the Internet - Eli Herscovitz Mr. Herscovitz is founder of RadGuard Ltd., provider of secure datanetwork systems. He chairs the Networking Security Standardization Committee of the Standards Institute of Israel. TUTORIAL Hacker Tools & Techniques and Intrusion Testing - A dual presentation by Edward Skoudis and Cynthia Cullen Cynthia Cullen is a senior consultant with Bell Communications Research Security and Fraud Management. Edward Skoudis is a senior expert in network security issues with Bellcore's Navesink Research Center. Wednesday February 19, 1997 COMPUTER CRIME Network Security's Future - Glenn Gianino Glenn Gianino is Vice President of Advanced Technology with Computer Associates International. His responsibilities included all systems software and hardware including micro, midrange, and mainframe systems, as well as all networking, SNA, wide area networks and Internet services. His most recent assignment involves networking security on all platforms and operating systems. Mining the Information Klondike: CINet, a tool to fight organized crime - Robert Heibel Robert Heibel is Director of the research/intelligence analyst program at Mercyhurst College (PA). A 25-year veteran of the Federal Bureau of Investigation, he served as its Deputy Chief of Counterterrorism. Mr. Heibel is also Executive Director of the Center for Information Research, Analysis, and Training at Mercyhurst. Mr. Heibel is a graduate of Georgetown University. Digital Cash is hard to regulate - Prof. Michael Froomkin Professor Michael Froomkin is associate professor at the University of Miami, School of Law at Coral Gables. He specializes in Internet law and related aspects. Professor Froomkin is a graduate of the Yale Law School, and has a M.Phil. in history of international relations from Cambridge University (UK). He is a Fellow of the Cyberspace Law Institute. Smart Cards: the Coming Wave - James Chen James Chen is founder and President of V-One Corp., a provider of network and internetwork security solutions. Previously Mr Chen was head of the ground network engineering division for Intelsat, responsible for satellite launches. Electronic Commerce on the Internet - Tom Carty Tom Carty is Director of CyberTrust, a division of GTE. Mr. Carty was responsible for the information security privacy organization and architecting key management systems with GTE. He is a graduate of the University of Connecticut and Boston University. ATM: An Emerging Network Technology - Michael Guzelian Michael Guzelian has over 15 years experience in and knowledge of authentication, bandwidth-on-demand, and security issues that face large public networks. DISCUSSION PANEL High Integrity/Mission Critical Systems Session and Panel Chairman - Donald L. Evans Presentations by: Donald Evans, Timothy Stacey and Robert Smock Donald Evans is senior security engineer and senior member of the Johnson Space Center Mission Operations Directorate AIS Security Engineering Team, providing assistance to NASA in developing and maintaining the IS security program for the Space Station and Shuttle ground based programs. He is an advisory board member for the NSA Systems Security Engineering Capability Maturity Model, and a member of the Presidential Sub-committee of the US Security Policy Board. Timothy Stacey was involved with security development for NASA's Space Shuttle and Space Station programs and software engineering in support of NASA and the US Air Force Space Command Systems. He is currently a information security expert with SAIC Space Operations. Robert Smock is head of Flight Operations Information Security Program at United Space Alliance, responsible for providing the primary government contractor support for the protection of NASA's ground-based information resources, which support Space Shuttle and Space Station flight operations at the Johnson Space Center in Houston, Texas.Mr Smock holds a degree in Computer Science. TUTORIAL Network Security: PRIVATE Communication in a PUBLIC World Dr. Radia Perlman and Charlie Kaufman Radia Perlman is Chief Security Architect for Novell, Inc. She is known for the invention of the spamming tree algorithm used by bridges, and many of the algorithms used for routing, including the design of a network that can withstand a denial of service attack. She is the author of two textbooks. She has a PhD from MIT. Charlie Kaufman is security architect for Lotus Notes/Domino. He is the chair of the web transaction security working group of the IETF. He is on the National Academy of Sciences expert panel on computer system trustworthiness. He is coauthor with Radia Perlman, of the book "Network Security: Private Communications in a Public World". Thursday February 20, 1997 INTERNET SECURITY Fighting Piracy on the Net - Peter Beruk Peter Beruk is Director of Domestic Anti-Piracy with the Software Publishers Association. Internet and Server Security - Joshua Peleg Joshua Peleg is the Director of Technical services with Memco Software. Mr. Pelegs expertise is in security, disaster recovery and system level programming. Joshua gained much of his experience while in the Israeli military defense forces. Is your Company a Hackers Help Desk ? - Steve Ritger Steve Ritger is security engineer with SRA International. His expertise is information and network security as well as fraud detection and prevention. JAVA SECURITY Security and "Live" content: A Java Perspective - Peter Coffee Peter Coffee is advanced technologies analyst for PC Week Labs. He has taught information systems management, management science and expert systems development for Pepperdine University, Chapman College, and UCLA. He is the author of "How to program Java". Mr. Coffee is a graduate of MIT and Pepperdine University. TUTORIAL World Wide Web Security Arthur Donkers Arthur Donkers is founder of Le Reseau, an independent security consulting firm in The Netherlands (Europe). He is a graduate of Delft University of Technology, and holds a degree in Electrical Engineering. He authors a monthly column on system administration and security aspects in SysAdmin Magazine. ------------0---------------- Datanet Security 97 is sponsored by the National Association of Webmasters, SysAdmin Magazine, Sprint, and CMP Network Computing Magazine. ---------------------------0-------------------------- Participation in Datanet Security 97 is $ 845. This includes admission to all conference sessions, tutorials and discussion panels, as well as lunches during the four days, a banquet, and a cruise to the Bahama islands (including breakfast, lunch, dinner and show). You can pay on-line via a secure web transaction with all major credit cards. A special hotel arrangement has been made with Hyatt Regency Miami, making discounted room rates available to all participants. The web page with full information is available at http://www.datasec.net Alternatively you can fax 941 775 1533, or email ds97@datasec.net. ========================================================================= From owner-ipsec Tue Jan 21 17:36:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03791 for ipsec-outgoing; Tue, 21 Jan 1997 17:34:14 -0500 (EST) Date: Tue, 21 Jan 97 22:34:15 GMT Standard Time From: Ran Atkinson Subject: Re: DATANET SECURITY 97 PROGRAM To: ipsec@portal.ex.tis.com, Korinne X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970121124325.00a389e0@datasec.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk It is not appropriate use of the IPsec WG mailing list to post conference announcements of that sort. Please refrain from doing so in future. Thank you, Ran rja@inet.org Co-chair, IP Security WG, IETF From owner-ipsec Wed Jan 22 07:32:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA13218 for ipsec-outgoing; Wed, 22 Jan 1997 07:30:02 -0500 (EST) Message-Id: <199701221230.HAA13218@portal.ex.tis.com> From: "John Chalk" Organization: DSI Pty Ltd To: gnu@toad.com Date: Wed, 22 Jan 1997 10:42:01 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: IPsec hardware accelerators (Rainbow warning) Reply-To: John.Chalk%datacraft.com.au@datacraft.com.au Cc: ipsec@tis.com In-Reply-To: X-Mailer: Pegasus Mail for Win32 (v2.50) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > There is a compnay called Rainbow Technologies. They lcoated in > > Irvine California. They provide a hardware encrytion solution for > > this problem. Can somehow the hardware solution and software > > solution combind together? > > Thanks for the pointer. > > One "hardware encryption solution" Rainbow provides is the Clipper > Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its > follow-on products are not compatible with the IPSEC protocols, > because they use an undocumented encryption algorithm and because > they are designed to undermine rather than provide secure operation. > > . . . much discussion of Rainbow snipped > > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > > John Gilmore > Not a working group member, but an interested lurker. A couple of years ago I worked on a project where we did application level encryption for a networked financial system using public nets, (actually the Aus. stock exchange) and we used a PC hardware card from a firm called Eracom. I don't know what the current range of products is, but last I heard they were doing a lot of stuff for banks with ATM traffic and such. They are located on the Gold Coast in Queensland, Australia and the contact info I have for them is: Tel: +61 (7) 5593 4911 Fax: +61 (7) 5593 4388 Telex: AA43943 The cards were available for well under $A1K and the technical support was great. -- John Chalk, Software Engineer, DSI Pty Ltd Tel: +61 (7) 3371 7655 Fax: +61 (7) 3870 5647 John.Chalk@datacraft.com.au From owner-ipsec Wed Jan 22 12:25:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15939 for ipsec-outgoing; Wed, 22 Jan 1997 12:20:07 -0500 (EST) Message-Id: <01BC085F.389F2380@erussell-2.ftp.com> From: "Edward A. Russell" To: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Negotiated Hash Algorithms in ISAKMP/OAKLEY Date: Wed, 22 Jan 1997 12:24:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Is this a correct interpretation of the ISAKMP/OAKLEY spec: All hashes used in messages and keying material are the NATIVE form of the negotiated hash algorithm which is either MD5 or SHA The ONLY time the HMAC version of MD5 or SHA is used is during the Oakley Phase1 authentication (specifically, in authentication with a pre-shared key, the HASH_I and HASH_R will be the HMAC version of MD5 or SHA depending on what was negotiated). Correct? (If I am incorrect and you can actually negotiate to use HMAC MD5 or NATIVE MD5 for example, then what is the Oakley number for that, does it need to be supported, and what would you use during authentication? The HMAC version of HMAC MD5 for example?????) Edward Russell erussell@ftp.com From owner-ipsec Wed Jan 22 13:01:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16207 for ipsec-outgoing; Wed, 22 Jan 1997 12:58:37 -0500 (EST) Message-Id: <199701221802.KAA05639@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Edward A. Russell" Cc: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Re: Negotiated Hash Algorithms in ISAKMP/OAKLEY In-Reply-To: Your message of "Wed, 22 Jan 1997 12:24:30 EST." <01BC085F.389F2380@erussell-2.ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jan 1997 10:02:12 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Edward, > Is this a correct interpretation of the ISAKMP/OAKLEY spec: > > All hashes used in messages and keying material are the NATIVE form of > the negotiated hash algorithm which is either MD5 or SHA No, they are the HMAC version. > The ONLY time the HMAC version of MD5 or SHA is used is during the Oakley > Phase1 authentication (specifically, in authentication with a pre-shared key, > the HASH_I and HASH_R will be the HMAC version > of MD5 or SHA depending on what was negotiated). > > Correct? Anytime you see prf it generally refers to the HMAC version of the negotiated hash function (negotiable pseudo-random functions are coming, but for now just assume prf=HMAC). These are used for mostly all hashing functions: authentication purposes and generation of key blobs (in phase1 and phase2). The only place where the native mode of the negotiated hash function is used is to generate the IV (in appendix B). > (If I am incorrect and you can actually negotiate to use HMAC MD5 or > NATIVE MD5 for example, then what is the Oakley number for that, does it > need to be supported, and what would you use during > authentication? The HMAC version of HMAC MD5 for example?????) You don't negotiate HMAC or native forms you just negotiate H: the hash function. That is then used in both native and HMAC modes. For authentication you'd use a prf (aka the HMAC version of your negotiated H) to generate a hash. That either directly authenticates the exchange or it is signed, and verified depending on your authentication method (the negotiated A, from E-H-A: encryption-hash-authentication). Dan. From owner-ipsec Wed Jan 22 16:17:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17609 for ipsec-outgoing; Wed, 22 Jan 1997 16:14:10 -0500 (EST) Message-Id: <3.0.32.19970122131705.0097aae0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 13:17:07 -0800 To: John.Chalk%datacraft.com.au@datacraft.com.au From: Bob Monsour Subject: Re: IPsec hardware accelerators (Rainbow warning) Cc: gnu@toad.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming chips will include encryption (DES/3DES/RC4) as well as compression and MAC computation (SHA/MD5). For those concerned about the processing requirements of software DES, note that the use of compression prior to encrypting reduces the workload placed on the encryptor. I included some experimental results at the Dec IPSEC wg meeting. Bob Monsour rmonsour@earthlink.net At 10:42 AM 1/22/97 +1000, John Chalk wrote: > >> > There is a compnay called Rainbow Technologies. They lcoated in >> > Irvine California. They provide a hardware encrytion solution for >> > this problem. Can somehow the hardware solution and software >> > solution combind together? >> >> Thanks for the pointer. >> >> One "hardware encryption solution" Rainbow provides is the Clipper >> Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its >> follow-on products are not compatible with the IPSEC protocols, >> because they use an undocumented encryption algorithm and because >> they are designed to undermine rather than provide secure operation. >> >> . . . much discussion of Rainbow snipped >> >> If any working group members know of useful hardware crypto >> accelerators available from non-US companies (for the world market), >> please let me know. I'd like to see hardware acceleration >> supported, but not using US-only and/or likely-subverted products. >> >> John Gilmore >> > >Not a working group member, but an interested lurker. > >A couple of years ago I worked on a project where we did application >level encryption for a networked financial system using >public nets, (actually the Aus. stock exchange) and we used a PC >hardware card from a firm called Eracom. I don't know what the >current range of products is, but last I heard they were doing a lot >of stuff for banks with ATM traffic and such. They are located on the >Gold Coast in Queensland, Australia and the contact info I have for >them is: Tel: +61 (7) 5593 4911 Fax: +61 (7) 5593 4388 > Telex: AA43943 >The cards were available for well under $A1K and the technical >support was great. > >-- >John Chalk, Software Engineer, DSI Pty Ltd >Tel: +61 (7) 3371 7655 Fax: +61 (7) 3870 5647 >John.Chalk@datacraft.com.au > > > > From owner-ipsec Thu Jan 23 07:20:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22226 for ipsec-outgoing; Thu, 23 Jan 1997 07:16:41 -0500 (EST) Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com In-reply-to: <199701221230.HAA13218@portal.ex.tis.com> (John.Chalk%datacraft.com.au@datacraft.com.au) Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 07:20:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22263 for ipsec-outgoing; Thu, 23 Jan 1997 07:20:40 -0500 (EST) From: owner-ipsec@ex.tis.com Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com In-reply-to: <199701221230.HAA13218@portal.ex.tis.com> (John.Chalk%datacraft.com.au@datacraft.com.au) Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 07:50:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22714 for ipsec-outgoing; Thu, 23 Jan 1997 07:50:11 -0500 (EST) Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 09:50:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23618 for ipsec-outgoing; Thu, 23 Jan 1997 09:45:16 -0500 (EST) Message-ID: From: Roy Pereira To: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: RE: IPsec hardware accelerators (Rainbow warning) Date: Thu, 23 Jan 1997 09:49:21 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk What has been going on with compression in ESP? I haven't heard anything since December's IETF. We talked about adding a byte in front of pad length to represent compression flags (like whether the data was compressed). >---------- >From: Bob Monsour[SMTP:rmonsour@earthlink.net] >Sent: Wednesday, January 22, 1997 4:17 PM >To: John.Chalk%datacraft.com.au@datacraft.com.au >Cc: gnu@toad.com; ipsec@tis.com >Subject: Re: IPsec hardware accelerators (Rainbow warning) > >Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming >chips will include encryption (DES/3DES/RC4) as well as compression and MAC >computation (SHA/MD5). > >For those concerned about the processing requirements of software DES, note >that the use of compression prior to encrypting reduces the workload placed >on the encryptor. I included some experimental results at the Dec IPSEC wg >meeting. > >Bob Monsour >rmonsour@earthlink.net > > > From owner-ipsec Thu Jan 23 14:28:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25606 for ipsec-outgoing; Thu, 23 Jan 1997 14:19:50 -0500 (EST) Message-Id: <3.0.32.19970123112234.009166c0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Jan 1997 11:22:47 -0800 To: Roy Pereira From: Bob Monsour Subject: RE: IPsec hardware accelerators (Rainbow warning) Cc: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In the next day or so, I will be putting together a summary of the compression issues raised at the meeting and making some specific suggestions on direction. I've been meaning to do this, but have been tied up with other things. -Bob At 09:49 AM 1/23/97 -0500, Roy Pereira wrote: >What has been going on with compression in ESP? I haven't heard >anything since December's IETF. We talked about adding a byte in front >of pad length to represent compression flags (like whether the data was >compressed). > > > >>---------- >>From: Bob Monsour[SMTP:rmonsour@earthlink.net] >>Sent: Wednesday, January 22, 1997 4:17 PM >>To: John.Chalk%datacraft.com.au@datacraft.com.au >>Cc: gnu@toad.com; ipsec@tis.com >>Subject: Re: IPsec hardware accelerators (Rainbow warning) >> >>Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming >>chips will include encryption (DES/3DES/RC4) as well as compression and MAC >>computation (SHA/MD5). >> >>For those concerned about the processing requirements of software DES, note >>that the use of compression prior to encrypting reduces the workload placed >>on the encryptor. I included some experimental results at the Dec IPSEC wg >>meeting. >> >>Bob Monsour >>rmonsour@earthlink.net >> >> >> > > From owner-ipsec Thu Jan 23 17:02:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26620 for ipsec-outgoing; Thu, 23 Jan 1997 16:59:54 -0500 (EST) Date: Thu, 23 Jan 1997 17:02:44 -0500 Message-Id: <9701232202.AA16974@ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: isakmp-oakley@cisco.com, ipsec@tis.com From: Naganand Doraswamy Subject: 8 byte aligement in ISAKMP Sender: owner-ipsec@ex.tis.com Precedence: bulk When the ISAKMP packet is not 8 byte aligned, we pad it with zero's to make it 8 byte aligned before we encrypt it during Oakley QM. Some packets require that we calculate hash on the payloads so that the other end can also authenticate us. When we calculate, do we also consider the padding? It is better that we consider the padding as well as it will be easier to verify on the other end. All we have to do is to calculate the length of the data on which to calcuate hash is (payload_len - isakmp header_len - hash payload_len - hash_data_len). We dont have to parse the ISAKMP payload to find out the lenght of the data on which to calculate hash. That way, if the hash fails we can drop the packet immediatly. On the other hand, if we dont use the pad in calculating hash, then the last byte of the hash should represent the lenght of the pad as that will help in calculating the lenght of the data on which to calculate hash. Comments? Naganand From owner-ipsec Thu Jan 23 17:10:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26703 for ipsec-outgoing; Thu, 23 Jan 1997 17:10:22 -0500 (EST) Message-Id: <199701232213.OAA06902@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Naganand Doraswamy Cc: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Re: 8 byte aligement in ISAKMP In-Reply-To: Your message of "Thu, 23 Jan 1997 17:02:44 EST." <9701232202.AA16974@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jan 1997 14:13:10 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand Doraswamy wrote: > When the ISAKMP packet is not 8 byte aligned, we pad it with zero's to make > it 8 byte aligned before we encrypt it during Oakley QM. Some packets > require that we calculate hash on the payloads so that the other end can > also authenticate us. When we calculate, do we also consider the padding? It > is better that we consider the padding as well as it will be easier to > verify on the other end. All we have to do is to calculate the length of the > data on which to calcuate hash is (payload_len - isakmp header_len - hash > payload_len - hash_data_len). We dont have to parse the ISAKMP payload to > find out the lenght of the data on which to calculate hash. That way, if the > hash fails we can drop the packet immediatly. > > On the other hand, if we dont use the pad in calculating hash, then the last > byte of the hash should represent the lenght of the pad as that will help in > calculating the lenght of the data on which to calculate hash. You have to run a sanity check on the ISAKMP payload before you process it anyway (and this processing includes verifying the hash). This check will allow you to determine the true (minus the pad) length of the message. If you don't run a sanity check you'd not only not be compliant with the draft, you'd open yourself up to attack. I could send you a SA offer which contained a TLV attribute with a huge, incorrect size. When you tried to process this you'd jump off into never-never land and most likely crash. The pad is not included in the hash that authenticates quick mode and this shouldn't case anyone any grief since the true size can be determined from normal payload processing-- validate, then process. Dan. From owner-ipsec Thu Jan 23 17:29:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26839 for ipsec-outgoing; Thu, 23 Jan 1997 17:29:24 -0500 (EST) Message-Id: <3.0.32.19970123143228.009826b0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Jan 1997 14:32:30 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Compression in ESP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At the December IETF meeting, the IPSEC working group consensus was to undertake compression as a work item. Recapping the motivation for putting compression in IPSEC: (1) PPP compression will be rendered ineffective on encrypted IPSEC payloads, (2) compression can reduce encryption and MAC processing, (3) compression can reduce the likelihood of packet fragmentation. Two proposals were presented at the meeting and a number of issues were raised regarding the best technical approach to use. I will attempt to summarize the issues that were raised and describe the available alternatives. I comments and suggestions from the group. Note that while no editors have been assigned to this task as of yet, I think it is important to get some input from the working group to keep the process from dying. The April meeting is Memphis will be here before we know it. TWO PROPOSALS 1. Make compression an optional feature of ESP 2. Create a separate (IPSEC independent) transform to support compression METHOD 1: OPTIONAL FEATURE OF ESP DRAFTS: draft-sabin-esp-des3-lzs-md5-00.txt draft-sabin-lzs-payload-00.txt In this method, compression would be added as an optional feature of ESP. The compression algorithm would be determined through KMP negotiation for each connection. It was proposed that a single byte field be used to determine whether or not the payload data is compressed (prior to encrypting). This byte would use a single bit to indicate compressed/not-compressed. Other bits could be assigned in the future to support additional compression functionality. Issue 1: Placement of the single byte field There were significant objections to the proposed placement of the byte at the start of the payload data for word-alignment reasons. Options for placement: 1. Steve Kent suggested that it could be placed at the end of the payload, between the Pad Length and the Payload Type bytes. 2. There was a suggestion that a byte not be used at all, but that an upper bit of the Pad Length field be allocated for this purpose. I recall reading that the padding can be up to 255 bytes (I think this was in the des-cbc-hmac-replay draft), so this would prevent us from using option 2. If that is not the case, then we could indeed use one of those upper bits. I would prefer to have two bits available for possible future use. I'd appreciate input on this. At this time, my recommendation would be to go for option 1 (place a byte between Pad Length and Payload Type). Issue 2: Negotiating compression The only issue here is that ISAKMP and the DOI drafts will need to support the negotiation of a compression algorithm and enabling compression for a specific SA. Given that the working group has decided to proceed with taking up compression as a work item, the necessary changes to the ISAKMP and DOI drafts could be made at any time. METHOD 2: SEPARATE TRANSFORM DRAFT: draft-thayer-seccomp-00.txt In this method, a separate transform is used. It has an overhead of 8 bytes (vs. 1 byte for the ESP optional feature) for each compressed payload. The separate transform has the ability to be used in non-secure environments. PROPOSAL I propose that the working group adopt Method 1. While the Method 1 drafts describe the LZS compression algorithm, the general approach can support any compression algorithm. LZS is a patented algorithm and as such, the proposed draft would ultimately become an Informational RFC. Hi/fn is the owner of the LZS patents and has provided a no-cost license to a C version of the algorithm for use in PPP implementations. Hi/fn has agreed to make a similar license available for IPSEC implementors. Prior to proceeding with additional work on a compression draft, the working group co-chairs must assign an editor or editors to the task. I encourage them to do so in time for a new draft to be produced in time for discussion at the April meeting. Thanks for listening and I look forward to your feedback. Bob Monsour rmonsour@hifn.com From owner-ipsec Mon Jan 27 14:47:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24923 for ipsec-outgoing; Mon, 27 Jan 1997 14:34:11 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: mobile-ip@smallworks.com, ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-ft-req-00.txt Date: Mon, 27 Jan 1997 13:35:25 -0500 Message-ID: <9701271335.aa01593@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Firewall Traversal for Mobile IP: Goals and Requirements Author(s) : V. Gupta, S. Glass Filename : draft-ietf-mobileip-ft-req-00.txt Pages : 10 Date : 01/24/1997 This document discusses problems arising out of the use of Mobile IP in a security conscious Internet and presents a list of solution requirements deemed important. These problems may need to be resolved in several stages. A priority order in which these problems should be solved is also proposed. All firewalls are assumed to implement standard mechanisms [RFCs 1825,1826,1827] for authentication and encryption proposed by the IPSec working group of the IETF. 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-mobileip-ft-req-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ft-req-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ft-req-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970124171433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ft-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ft-req-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970124171433.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jan 29 02:33:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06560 for ipsec-outgoing; Wed, 29 Jan 1997 02:26:55 -0500 (EST) Hops: 0 Host: clinet.fi. Posted-Date: Wed, 29 Jan 1997 09:28:04 -0200 (GMT) Message-Id: <199701290729.JAA12749@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com Subject: Reminder: Release 0.4 of my Linux IPSEC code is out. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 09:29:36 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk A few days ago I released version 0.4 of my Linux IPSEC code. It can be found in ftp://ftp.funet.fi/pub/unix/security/net/ip/. New in this release is support for all the currently defined transforms; of particular interest should be AH-HMAC-SHA1 and ESP-3DES-MD5. Release 0.4 is by no means perfect; it still has to undergo a lot of work before it can be something a nonexpert user can just install and have work right out of the box. For that, I need your help. If you find bugs, please report them; if you can provide a fix, so much the better. The documentation file that comes with the release lists a whole bunch of areas that need work. If you can work on any of these, please tell me so. Please note that in some countries such as the USA, it is unlawful for a citizen of that country to provide technical assistance "with the intent to aid a foreign person in the development or manufacture outside the United States" of "Encryption Items". Also, in countries such as France, it is unlawful to even use cryptography without notifying the authorities. Naturally, I don't expect help from people in the USA or France, but there must be *some* people in the rest of the world who can offer some! /ji From owner-ipsec Fri Jan 31 19:03:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA29573 for ipsec-outgoing; Fri, 31 Jan 1997 18:55:57 -0500 (EST) Hops: 0 Host: tis.com. Date: Sat, 1 Feb 1997 01:55:52 -0200 (GMT) From: John Ioannidis Posted-Date: Sat, 1 Feb 1997 01:55:52 -0200 (GMT) Message-Id: <199702010355.BAA13897@prometheus.hol.gr> To: ietf-sectest@toad.com, ipsec@tis.com Subject: one-time release of IPSEC code for BSDI and NetBSD Sender: owner-ipsec@ex.tis.com Precedence: bulk I've finally released Angelos Keromytis' (kermit@forthnet.gr) port to NetBSD of my old BSDI code, along with features from my Linux release. You can find it in ftp://ftp.funet.fi/pub/unix/security/net/ip/ in a day or so. This is NOT supported code. It may or may not work for you. If you can make it work, fine; if you find bugs AND have a bug-fix, please send me mail about them. Requests for handholding will be silently ignored. USE IT AT YOUR OWN RISK! That said, I hope you find it useful. /ji