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 t