From owner-ipsec Thu Jan 2 11:16:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15043 for ipsec-outgoing; Thu, 2 Jan 1997 11:07:12 -0500 (EST) Message-Id: <199701021610.LAA00681@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: dennis.glatting@plaintalk.bellevue.wa.us Cc: phan@itd.nrl.navy.mil, cmetz@inner.net, danmcd@eng.sun.com, ipsec@tis.com Subject: Re: Comment regarding draft-mcdonald-pf-key-v2-00.txt In-Reply-To: dennis.glatting's message of Tue, 31 Dec 1996 17:47:17 -0800. <199701010147.RAA02144@imo.plaintalk.bellevue.wa.us> Date: Thu, 02 Jan 1997 11:10:03 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Assuming the kernel is supposed to generate the IV, why not > allow the PF_KEY interface transfer an IV? It seems to me, if an > external hardware were available, random data would be best > obtained by a user level application rather than the kernel. I don't agree. 1) Assuming we're talking about UNIX-like systems (monolithic large kernel), I'm not sure this statement is really true.. especially given the work by Don Davis and others sampling randomness from disk drives and Ted Ts'o's /dev/random driver for linux (which also exports a kernel-internal API for kernel code which needs strong randomness). 2) even if it were true, I don't think PF_KEY is the right place to put a "deliver random bitstream to kernel" interface. For any number of reasons, you really want a "pipe" of randomness, not a request-response protocol. - Bill From owner-ipsec Thu Jan 2 12:40:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15775 for ipsec-outgoing; Thu, 2 Jan 1997 12:39:05 -0500 (EST) Message-Id: <199701021742.JAA00730@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 2 Jan 97 09:41:59 -0800 To: Bill Sommerfeld Subject: Re: Comment regarding draft-mcdonald-pf-key-v2-00.txt cc: dennis.glatting@plaintalk.bellevue.wa.us, phan@itd.nrl.navy.mil, cmetz@inner.net, danmcd@eng.sun.com, ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701021610.LAA00681@thunk.orchard.medford.ma.us> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Assuming the kernel is supposed to generate the IV, why not > > allow the PF_KEY interface transfer an IV? It seems to me, if an > > external hardware were available, random data would be best > > obtained by a user level application rather than the kernel. > > I don't agree. > > 1) Assuming we're talking about UNIX-like systems > (monolithic large kernel), I'm not sure this statement is > really true.. especially given the work by Don Davis and others > sampling randomness from disk drives and Ted Ts'o's > /dev/random driver for linux (which also exports a > kernel-internal API for kernel code which needs strong > randomness). > Yes, a UNIX like system: Mach. > 2) even if it were true, I don't think PF_KEY is the right place to > put a "deliver random bitstream to kernel" interface. For any > number of reasons, you really want a "pipe" of randomness, not a > request-response protocol. > The reasons I think query/response is a reasonable alternative are: * I do not have source for my kernel (and not likely to ever get it) thus probing interfaces and buffers is somewhat problematic. Not having kernel source requires the operating system vendor to implement a PF_KEY domain. I think this is a little too ambitious and less likely to happen for legacy systems. Not having source forces me to diverge from the spec. Perhaps a reasonable alternative to creating a socket in the PF_KEY domain is to open a device? * One of my random data sources is an open mic indirectly accessible via /dev. To use that device I have to implement some mechanism to tell the kernel it (or another) may be available as a random data source. Also, its interface is through a given API not usable within the kernel. -dpg From owner-ipsec Fri Jan 3 09:14:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22005 for ipsec-outgoing; Fri, 3 Jan 1997 09:09:16 -0500 (EST) Date: Fri, 3 Jan 1997 00:22:52 -0500 From: Ran Canetti Message-Id: <9701030522.AA17553@ornavella.watson.ibm.com> To: hughes@nsco.network.com, narten@raleigh.ibm.com Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard Cc: ipsec@tis.com Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk >From: "James Hughes" >Message-Id: > >>> > 1. (Optional step) Decrypt the first bock of data using the >>> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- >>> > ity check" of the count. > ... > >Since the count is encrypted (and assuming the attacker does not have the >DES key and therefore can not create known non-duplicate counts), detecting >someone trying to clog can be performed by decrypting the first block and >seeing -if- the decrypted count is reasonably valid (since the attacker can >not control what the data looks like after the decryption step). > -This may not always hold: Note that in DES-CBC the first block of the ciphertext is computed as C = DES(M + IV) where + denotes XOR and M is the first block of the message. (Here M includes the replay prevention counter.) Therefore, when the IV is specified in the header it is easy to "spoof" the quick-check that decrypts only the first block and verifies that the replay counter value is "reasonable": In order to generate a packet that looks like it has a counter value close to the current one, keep the ciphertext the same, but slightly modify the appropriate bits of the IV. (Ofcourse, when the entire packet is derypted and the HMAC is verified the spoofing will be revealed...) Ran Canetti BTW, if the replay counter were always in the second (or subsequent) 64-bit block then the above attack would be impossible. From owner-ipsec Fri Jan 3 09:59:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22358 for ipsec-outgoing; Fri, 3 Jan 1997 09:58:00 -0500 (EST) Message-Id: <3.0.16.19970103095702.364738dc@pop3.pn.com> X-PGP-Key: http://www.shore.net/~sable/info/rltkey.htm X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 03 Jan 1997 09:58:50 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: pf_key comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I am looking into implementing PF_KEY and I have some comments on this too: 1. I like the idea of sending the IV down from an application. I think that an application is a reasonable place to do the random number generation because - -- I too don't have all my kernel sources - -- I don't think the kernel IPSEC component should be using other parts of the kernel in weird ways as randomization sources 2. I wish there was some a notification mechanism for events. As per 2026 we have agreed it's germaine and legitimate to think about network management when developing Internet components. I have a requirement to generate events under certain conditions like perhaps when there is an encryption failure. Therefore I suggest there be two new messages, SADB_REGISTER_EVENT and SADB_MANAGEMENT_EVENT. SADB_REGISTER_EVENT works like SADB_REGISTER. SADB_MANAGEMENT_EVENT returns a base message followed by a proper SNMPv2 style trap message (this is chosen to be 2026 compliant!) I think it's appropriate to put this here because there isn't any other place to get these events, and the existing messages don't do this, and I believe we need network management. 3. I suggest we *not* claim SADB_DUMP be removed in the future. It's very useful for network managment. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMs0eLcKmlvJNktGxAQGzggQAmLaNHP9bJDtKI74UxbAMWZahuKjmIo+Y vjVEFqQ7J8hd4nlE0XNmCkyF1JdY/z9SQQ4eD0cfIxkdhvc9TVhfwgHpsRl8HA0M VeQu9SRZfLpOID0h0Om15kbf1kELhIl/iz31pHJY4sEKLq+lUT+nF6dbjwH4xu+5 E4Vhzg/S0vM= =wDB/ -----END PGP SIGNATURE----- Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Fri Jan 3 12:05:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23230 for ipsec-outgoing; Fri, 3 Jan 1997 12:01:08 -0500 (EST) Message-Id: <199701031703.MAA10942@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Rodney Thayer cc: ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 09:58:50 EST." <3.0.16.19970103095702.364738dc@pop3.pn.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 12:03:53 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > I am looking into implementing PF_KEY and I have some comments on this too: > > 1. I like the idea of sending the IV down from an application. I think > that an application is a reasonable place to do the random number > generation because Its completely unreasonable to send the IV from the application. Since IVs have to be sent on every packet, that would mean you would need to do a PF_KEY operation on every packet. This is not going to be feasable. Perry From owner-ipsec Fri Jan 3 12:29:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23355 for ipsec-outgoing; Fri, 3 Jan 1997 12:29:37 -0500 (EST) Message-Id: <3.0.16.19970103122103.2907efd0@pop3.pn.com> X-PGP-Key: http://www.shore.net/~sable/info/rltkey.htm X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 03 Jan 1997 12:30:22 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: pf_key comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I thought people were generating the IV once at the initialization of the S-A but I realize that could be wrong. The scheme still applies for generating the random seed for an IV, though, doesn't it? At 12:03 PM 1/3/97 -0500, you wrote: > >Rodney Thayer writes: >> I am looking into implementing PF_KEY and I have some comments on this too: >> >> 1. I like the idea of sending the IV down from an application. I think >> that an application is a reasonable place to do the random number >> generation because > >Its completely unreasonable to send the IV from the application. Since >IVs have to be sent on every packet, that would mean you would need to >do a PF_KEY operation on every packet. This is not going to be >feasable. > >Perry > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Fri Jan 3 13:18:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23662 for ipsec-outgoing; Fri, 3 Jan 1997 13:17:16 -0500 (EST) Message-Id: <2.2.32.19970103182640.00ba6404@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 1997 13:26:40 -0500 To: perry@piermont.com From: Naganand Doraswamy Subject: Re: pf_key comments Cc: Rodney Thayer , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, >Its completely unreasonable to send the IV from the application. Since >IVs have to be sent on every packet, that would mean you would need to >do a PF_KEY operation on every packet. This is not going to be >feasable. > IV is optional field. This is used in cases where we use a constant IV. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Jan 3 13:23:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23740 for ipsec-outgoing; Fri, 3 Jan 1997 13:23:37 -0500 (EST) Message-Id: <199701031826.KAA01494@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Fri, 3 Jan 97 10:26:20 -0800 To: perry@piermont.com Subject: Re: pf_key comments cc: Rodney Thayer , ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701031703.MAA10942@jekyll.piermont.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I am looking into implementing PF_KEY and I have some comments on this too: > > > > 1. I like the idea of sending the IV down from an application. I think > > that an application is a reasonable place to do the random number > > generation because > > Its completely unreasonable to send the IV from the > application. Since IVs have to be sent on every packet, that > would mean you would need to do a PF_KEY operation on every > packet. This is not going to be feasable. > There is no need to do an operation for every packet. The kernel could ask for a block of random data and use it as it wishes. -dpg From owner-ipsec Fri Jan 3 14:42:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24348 for ipsec-outgoing; Fri, 3 Jan 1997 14:41:38 -0500 (EST) Message-Id: <199701031944.LAA01547@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Fri, 3 Jan 97 11:44:18 -0800 To: dennis.glatting@plaintalk.bellevue.wa.us Subject: Re: pf_key comments cc: perry@piermont.com, Rodney Thayer , ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701031703.MAA10942@jekyll.piermont.com> <199701031826.KAA01494@imo.plaintalk.bellevue.wa.us> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > I am looking into implementing PF_KEY and I have some comments on this too: > > > > > > 1. I like the idea of sending the IV down from an application. I think > > > that an application is a reasonable place to do the random number > > > generation because > > > > Its completely unreasonable to send the IV from the > > application. Since IVs have to be sent on every packet, that > > would mean you would need to do a PF_KEY operation on every > > packet. This is not going to be feasible. > > > > There is no need to do an operation for every packet. The kernel > could ask for a block of random data and use it as it wishes. > However, if we assume a 100mbs ethernet link ~85% efficient and 1024 byte packets (and enough CPU juice to handle that data :), that's ~10k packets per second. Using 8 bytes of random IV for each packet the kernel will require ~80k of random IV per second. It seems unreasonable for the kernel to acquire that amount of data from a user level process each second; however, I wonder whether pseudo random data generators can produce that amount of data at that rate too. If not, then pseudo random IV is useful for slow packet rates in which case it may be reasonable for the kernel to request random data from a user level process. -dpg From owner-ipsec Fri Jan 3 14:54:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24461 for ipsec-outgoing; Fri, 3 Jan 1997 14:54:08 -0500 (EST) Message-Id: <199701031956.OAA01250@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: pf_key comments In-Reply-To: rodney's message of Fri, 03 Jan 1997 12:30:22 -0500. <3.0.16.19970103122103.2907efd0@pop3.pn.com> Date: Fri, 03 Jan 1997 14:56:38 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I thought people were generating the IV once at the initialization of the > S-A but I realize that could be wrong. my understanding is that, for best security, the IV should be different for each packet. - Bill From owner-ipsec Fri Jan 3 15:05:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24548 for ipsec-outgoing; Fri, 3 Jan 1997 15:05:10 -0500 (EST) Message-Id: <199701032008.PAA11490@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dennis.glatting@plaintalk.bellevue.wa.us cc: ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 11:44:18 PST." <199701031944.LAA01547@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 15:08:12 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > However, if we assume a 100mbs ethernet link ~85% efficient and > 1024 byte packets (and enough CPU juice to handle that data :), > that's ~10k packets per second. Using 8 bytes of random IV for > each packet the kernel will require ~80k of random IV per > second. > > It seems unreasonable for the kernel to acquire that amount of > data from a user level process each second; however, I wonder > whether pseudo random data generators can produce that amount > of data at that rate too. If you can't crank a block cipher fast enough to generate a random sequence good enough for IVs, then you can't crank it fast enough to encrypt the plaintext, either. > If not, then pseudo random IV is useful > for slow packet rates in which case it may be reasonable for the > kernel to request random data from a user level process. I don't understand. If the kernel can't crank a cipher at a given rate, why would userland? Perry From owner-ipsec Fri Jan 3 16:29:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24993 for ipsec-outgoing; Fri, 3 Jan 1997 16:24:04 -0500 (EST) Message-Id: <97Jan3.162331est.30785-2@janus.border.com> To: Bill Sommerfeld cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments References: <199701031956.OAA01250@thunk.orchard.medford.ma.us> In-reply-to: sommerfeld's message of "Fri, 03 Jan 1997 14:56:38 -0500". <199701031956.OAA01250@thunk.orchard.medford.ma.us> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 3 Jan 1997 16:22:06 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199701031956.OAA01250@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > > my understanding is that, for best security, the IV should be > different for each packet. Question: Does the IV have to be *unpredictably* different, or just different? (The NRL code, for example, simply increments the IV after each packet). -- C. Harald Koch chk@border.com From owner-ipsec Fri Jan 3 17:17:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25260 for ipsec-outgoing; Fri, 3 Jan 1997 17:17:15 -0500 (EST) Message-Id: <199701032220.RAA01331@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "C. Harald Koch" Cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments In-Reply-To: chk's message of Fri, 03 Jan 1997 16:22:06 -0500. <97Jan3.163527est.30870-1@janus.border.com> Date: Fri, 03 Jan 1997 17:20:09 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Does the IV have to be *unpredictably* different, or just different? The part of me which is a Paranoid Cryptographic Protocol Engineer would generate it with a CPRNG. The IV is sent in the clear. I don't think it makes a difference how different it is, but I'm not a Real Cryptographer(tm). - Bill From owner-ipsec Fri Jan 3 17:17:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25254 for ipsec-outgoing; Fri, 3 Jan 1997 17:16:25 -0500 (EST) Message-Id: <199701032217.RAA11629@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Bill Sommerfeld cc: Rodney Thayer , ipsec@tis.com Subject: Re: pf_key comments In-reply-to: Your message of "Fri, 03 Jan 1997 14:56:38 EST." <199701031956.OAA01250@thunk.orchard.medford.ma.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 03 Jan 1997 17:17:50 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > I thought people were generating the IV once at the initialization of the > > S-A but I realize that could be wrong. > > my understanding is that, for best security, the IV should be > different for each packet. Absolutely. The whole point of an IV is to assure that identical data doesn't encrypt identically. If you use the same IV each time, you've already lost. Perry From owner-ipsec Fri Jan 3 18:36:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25564 for ipsec-outgoing; Fri, 3 Jan 1997 18:35:15 -0500 (EST) From: hoodr@livingston.com Message-Id: <199701032338.PAA27813@server.livingston.com> Date: Fri, 3 Jan 1997 15:37:23 -0800 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Bill Sommerfeld , "C. Harald Koch" Subject: Re: pf_key comments Cc: Rodney Thayer , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Does the IV have to be *unpredictably* different, or just different? > >The part of me which is a Paranoid Cryptographic Protocol Engineer >would generate it with a CPRNG. > >The IV is sent in the clear. I don't think it makes a difference how >different it is, but I'm not a Real Cryptographer(tm). My understanding of CBC, was that the IV for each block was the output of the last CBC block (except of course for the very first block). I've just been carrying the last block over from the previous packet, and making that the next IV for the new packet. Since this is exactly whats happening within each packet, I figured (read guessed) that it was just as secure to extend it to the next packet. Obviously, I'm not a Real Cryptographer(tm) either :) From owner-ipsec Sun Jan 5 04:37:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA03376 for ipsec-outgoing; Sun, 5 Jan 1997 04:30:20 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701050933.BAA00135@netcom17.netcom.com> Subject: Re: IPsec and TCP To: ipsec@tis.com Date: Sun, 5 Jan 1997 01:33:17 -0800 (PST) Cc: naganand@ftp.com, ho@earth.hpc.org In-Reply-To: <199612202305.SAA10850@earth.hpc.org> from "Hilarie Orman" at Dec 20, 96 06:05:21 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 634 This is interesting. I knew that TCP/IP will be miserably slow when you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I forgot about the impact of key exchange performance. You'd be lucky to see 5 keys exchanged a second with Diffie-Hellman. Has anyone measured (or at least estimated) the performance metrics for IPsec routers (and hosts) to exchange/update keys? And on total IPsec routing performance, say with a mixture of clear and encrypted links, using various key update intervals. - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sun Jan 5 14:44:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05821 for ipsec-outgoing; Sun, 5 Jan 1997 14:42:58 -0500 (EST) Date: Sun, 5 Jan 1997 14:44:53 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199701051944.OAA10022@earth.hpc.org> To: andrade@netcom.com Cc: ipsec@tis.com, naganand@ftp.com In-reply-to: Yourmessage <199701050933.BAA00135@netcom17.netcom.com> Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie From owner-ipsec Sun Jan 5 16:24:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06166 for ipsec-outgoing; Sun, 5 Jan 1997 16:23:29 -0500 (EST) Date: Sun, 5 Jan 97 21:16:21 GMT Standard Time From: Ran Atkinson Subject: Re: IPsec and TCP To: Andrade Software Andrade Networking Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199701050933.BAA00135@netcom17.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Between a pair of 586/90 boxes running BSDI, NRL IPsec, and cisco's ikmpd(8), there is not a huge performance problem due to key management with the kinds of things I normally do (telnet, ftp, rlogin). In any event, a clever key mgmt implementation would acquire more than one IPsec SA at a time and cache the extra SAs in the key engine for future use. In such a case, there would generally be zero startup latency when locality holds (note that when locality does not hold, any inline key management scheme would also have a startup delay due to initial exchange of master keys (KEK) and algorithm information). Since the source to cisco's daemon is available (modulo export controls), anyone could add that feature to the daemon if they wished to do so. Since cisco's competitors are building products around the freely distributable cisco daemon, it would be unwise for cisco to spend lots of time optimising performance of its UNIX key management daemon. However, I speculate that if someone else did such performance optimisations, cisco might well be willing to incorporate context diffs. One would need to ask the maintainer of cisco's daemon to ascertain their policy on contributions of course. A couple of router vendors have implemented dynamic key management schemes based on D-H in their products. In both of the cases that I'm aware of, the D-H overhead is not a significant performance issue (probably in part due to thoughtful implementations). Ran rja@inet.org From owner-ipsec Sun Jan 5 16:47:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06293 for ipsec-outgoing; Sun, 5 Jan 1997 16:46:28 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sun, 05 Jan 1997 14:49:30 -0700 From: John Kennedy To: ho@earth.hpc.org, andrade@netcom.com Cc: naganand@ftp.com, ipsec@tis.com Subject: Diffie-Hellman Performance Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me add that careful choice of a secret exponent size commensurate with the size of the modulus, any underlying subgroup q, and the target algorithm you are deriving keying material for is also important. Using 160-bit or 256-bit exponents can be quite reasonable in many cases. Especially if the DH exchange at hand is only to provide bits for forward secrecy purposes. Compare this to using, say, a 1024-bit exponent, and things are going to be relatively zippy. For example, what purpose does it serve to use 1024-bit parameters if the algorithm you need keying material for is 40-bit DES? (Hilarie, maybe you could give a pointer to the presentation you gave at the Dallas IETF meeting on this.) For routers, servers, and other high-throughput machines, look for specialized co-processors dedicated to this purpose. Quite a few different companies have these in development for release this year and the economics and market are pulling the market in this direction. Look for 100 connections-per-second or so, including authentication, in the not-to-distant future. Besides, compared with all the other delays in building a connection over the Internet these days, this is a fraction of a second I'm willing to put up with. (Of course, your mileage may vary...) Even without the special silicon DH-based key agreement can be implemented quite efficiently. Using assembly-language optimized libraries and keeping your key and group parameter sizes realistic is the way to go. Using 2048-bit parameters when 512 bits is more appropirate is an easy mistake to make in any public-key application if you don't take the time to understand the attacks on the mechanisms you are using and the real security requirements and risks for your system. -John Kennedy jkennedy@novell.com >>> Hilarie Orman 01/05/97 12:44pm >>> > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie Received: from portal.ex.tis.com by prv1-mx.provo.novell.com ; 5 JAN 97 13:39:15 MDT Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05821 for ipsec-outgoing; Sun, 5 Jan 1997 14:42:58 -0500 (EST) Message-ID: <199701051944.OAA10022@earth.hpc.org> In-reply-to: Yourmessage <199701050933.BAA00135@netcom17.netcom.com> Content-Length: 989 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Sun, 05 Jan 1997 12:44:53 -0700 From: Hilarie Orman To: andrade@netcom.com Cc: naganand@ftp.com, ipsec@tis.com Subject: Re: IPsec and TCP > You'd be lucky > to see 5 keys exchanged a second with Diffie-Hellman. Has anyone > measured (or at least estimated) the performance metrics for IPsec > routers (and hosts) to exchange/update keys? And on total IPsec > routing performance, say with a mixture of clear and encrypted links, > using various key update intervals. Luck has very little to do with it; modulus size and implementation are more relevant. Also key lifetime and number of different SA's needed per unit time. You can do much better than 200 msec for a reasonably secure DH, but there's no question that it imposes a severe computational burden, and you also need to add the cost of authentication. In cases where the participants are static, it shouldn't be necessary to do DH very often. In the case of a server machine establishing hundreds(?) of different client connections per second, the authenticated keying might well swamp the machine, leading to need for a second processor. Hilarie From owner-ipsec Mon Jan 6 14:02:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01208 for ipsec-outgoing; Mon, 6 Jan 1997 13:46:22 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: "Waterhouse, Richard" To: "'IPSEC Working Group'" Subject: Multi-DOI Messages Date: Mon, 6 Jan 1997 13:50:13 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipsec@ex.tis.com Precedence: bulk General question. I see nothing in the ISAKMP Draft that precludes including Payloads in the same message which apply to SAs negotiated under different DOIs. For example, if I have two SAs to which different DOIs apply I can have two Delete Payloads, one for each SA, included in the same Message. Is this a correct reading of the ISAKMP Standard. begin 600 WINMAIL.DAT M>)\^(A 2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0``# $IV_```#``80#"8)B0,` M!Q ;`0``'@`($ $```!E````1T5.15)!3%%515-424].25-%14Y/5$A)3D=) M3E1(14E304M-4$1204945$A!5%!214-,541%4TE.0TQ51$E.1U!!64Q/0413 M24Y42$5304U%34534T%'15=(24-(05!03%E43P`````#`! 0``````,`$1 ! M`````@$)$ $```")`0``A0$``&$"``!,6D9UUTR)F/\`"@$/`A4"I /D!>L" M@P!0$P-4`@!C: K FAE; ,@1&SZ9P* M?0J ",\)V0* "H&##;$+8&YG,3 S%"#G"PH2\@'0($<)\ 20!T!$('$*4'-T M:0(@+A,*A0J%22 1\&4@;DAO=&@+@&<@"X @`QPP&_!)4T%+35"O%3 :``& M'+%A!4!P%G!^8PI #; $( N 'E(<4E!D87D6`&%D'J( ( >!(&!G M&_!WHQQ $; @87 +4'D,05 %G ?L!Q2]F\F(!S)4P&0(R +$1K-!161 M`#,``````P#Q/PD$```#`"8```````,`-@```````@%'``$````L````8SU5 M4SMA/2 [<#U'5$4[;#U.1$A-,#8M.3`/@_`0```!0` M``!7871E From: Brett Howard To: "'C. Harald Koch'" Cc: "'ipsec@tis.com'" Subject: RE: pf_key comments Date: Mon, 6 Jan 1997 13:02:43 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald Koch writes: > Does the IV have to be *unpredictably* different, or just different? > > (The NRL code, for example, simply increments the IV after each packet). Just different. If you look at the nature of the feedback in CBC for any chained blocks, the IV is simply the last data-cipher block, which is "public" information. The only danger I've ever heard of incrementing an IV from one chain to the next is that the IV bits are almost identical at the start of each chain; but to my knowledge, this has never been exploited. Brett TimeStep Corporation From owner-ipsec Mon Jan 6 14:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01358 for ipsec-outgoing; Mon, 6 Jan 1997 14:12:19 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: "Waterhouse, Richard" To: "'IPSEC Working Group'" Subject: DOI in the Header Date: Mon, 6 Jan 1997 14:16:38 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipsec@ex.tis.com Precedence: bulk Back on Dec 18 Elfed T. Weaver proposed moving DOI up to the Header. I've just become convinced that this must be done. Protocol-ID can only be interpreted in the context of a DOI. (Section A.2.2) SPI can only be interpreted in the context of a Protocol-ID. In a Delete Payload all you have is Protocol-ID and SPI. But by the above this can only be interpreted in the context of a DOI. And the DOI doesn't appear in the Delete Payload or its Header. begin 600 WINMAIL.DAT M>)\^(BD3`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0`' ``0```!(```!$3TD@:6X@=&AE($AE861E<@````(! M<0`!````%@````&[_ :!''[WD$-GMA'0MMX``, 2G;\```,`!A#Q")'.`P`' M$&$!```>``@0`0```&4```!"04-+3TY$14,Q.$5,1D5$5%=%059%4E!23U!/ M4T5$34]624Y'1$])55!43U1(14A%041%4DE614I54U1"14-/345#3TY624Y# M14142$%45$A)4TU54U1"141/3D504D]43T-/``````,`$! ``````P`1$ $` M```"`0D0`0```+P!``"X`0``^0(``$Q:1G6GH))>_P`*`0\"%0*D`^0%ZP*# M`% 3`U0"`&-H"L!S973N,@8`!L,"@S(#Q@<3`H,2,Q,/9C0/>FAE;-$#($1L M9P* ?0J ",\?"=D"@ J!#;$+8&YG,3PP,Q0@"PH2\@'0($(Y`-!K( (@%F % MD" Q'C@*X0MD%"(:P45L9@$)@"!4+B!796&2=@20(' #8'!O$? K'1 $8'8+ M@&<68$])P"!U<"!T;Q\P%B"<($@=< 2!'4!))QV0T"!J=7,%0&(%D0> :B % MH&X>@6,=`1]P89\%0!]P! `>4""4(&0"(.QE+@J%"H50`V ?0!<1."U)1"$P M`Y$"(&QY^R+""X!T!) =T!(`'0$+@!1%C L,20@87FO M%S ?T"> %D%Y"& @$<#_(%$B420Z`' =$"K!'4 :X/YU(+$KTB,`B0>0;B<%0&%P4OO06Q:70$(!^U M"R-<%L$`/( #`/$_"00```,`)@```````P`V```````"`4<``0```"P```!C M/553.V$](#MP/4=413ML/4Y$2$TP-BTY-S Q,#8Q.3$V,SA:+3$R,S(X``(! M^3\!````1P````````#`#T``0````$`````````"P`I``$````+ M`",```````(!?P`!````10```#QC/553)6$]7R5P/4=4125L/4Y$2$TP-BTY M-S Q,#8Q.3$V,SA:+3$R,S(X0&YD:&TP-BYN9&AM+F=T96=S8RYC;VT^```` #`( To: bhoward@TimeStep.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199701061923.MAA24523@baskerville.CS.Arizona.EDU> Subject: RE: pf_key comments Sender: owner-ipsec@ex.tis.com Precedence: bulk > Harald Koch writes: > > Does the IV have to be *unpredictably* different, or just > different? > > > > (The NRL code, for example, simply increments the IV after each > packet). > Just different. If you look at the nature of the feedback in CBC for > any chained blocks, the IV is simply the last data-cipher block, which > is "public" information. The only danger I've ever heard of > incrementing an IV from one chain to the next is that the IV bits are > almost identical at the start of each chain; but to my knowledge, this > has never been exploited. Phil Rogaway has pointed out that if the IV and the first data block are both changing so as to cause their xor to be constant, the purpose of the IV is defeated. I don't know if this has ever been observed in practice, but it is something to keep in mind (I suppose someone now will try to design this into a protocol as some kind of optimization!). Hilarie From owner-ipsec Mon Jan 6 15:25:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01739 for ipsec-outgoing; Mon, 6 Jan 1997 15:25:19 -0500 (EST) Date: Mon, 6 Jan 1997 15:25:54 -0500 (EST) Message-Id: <199701062025.PAA01101@gabber.multinet.net> From: graydon hoare To: ipsec@tis.com Subject: Thinkin' about identifiers... Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been looking over the material on security topics currently available, and have become a little concerned. While it's true that identification and authentication systems are slowly stabilizing through the analysis of the members of the IETF and security-related companies, one issue which remains to be dealt with properly (from my perspective) is that of the naming system. It does not seem effective to rely on the DNSSEC (basically email) or X.500/LDAP architectures, because under these systems an identifier is logically connected to an authority for other, non authentication-related information This looks like a small problem, but as time goes on it blossoms into a whole bunch of problems. The key concern is that your name tells other principals a lot about you as a principal (not just humans -- organizations and software agents too) If a principal has information about your name, it partially or fully denies you the option of acting anonymously. In DNS or X.500, having an obscure or hard-to-remember identifier invalidates the point of the databases. But making names easy to remember means associating them with real-world things, such as the place you work, the place you get your email, the country you live in etc. Furthermore since DNS and X.500 are both used to store other identifying information, having multiple DNS or X.500 names does not preclude the possibility of someone matching them up (for instance, by given name). While this may not annoy you much when it comes to junk email or the like, having control over joinable database keys will make your life a lot more pleasant as interoperability increases. And even if you have complete trust in the harmlessness of data collecting and indexing based on things you don't want to change (your name) or can't realistically deny (that you got your name in a certain country), there is this horrible problem of a hierarchical name space being tied to real world organizational hierarchies. If everyone who works for the military gets their keys stashed under the mil hierarchy, guess which machine an attacker is going to try to compromise? SOA (or "keyserver") for mil. Although you need a hierarchical name space for a good distributed system, you don't need to be spelling out what is represented in each branch of the hierarchy. Finally, as you may be aware, the dynamic creation and assignment of DNS names is being intentionally slowed (60 days is a suggested wait time) in order to make trademark conflicts less troublesome. It is an admirable effort, but I would prefer for a system responsible for network-wide authentication to be extremely robust and therefore make use of any host with any spare CPU cycles for replication and distribution. I am considering implementing a portable, low-overhead identification and certificate server. It will be similar to OSPF/gated or named, but will not couple with internet names or addresses internally -- I'm assuming that many things in the world will be able to store identifiers without necessarily being "on the net" all the time. The design is very clear and modular and has strong controls for cache consistency and replication. Its records are mobile and reasonably hard to track, and there is maximum effort put into keeping the identifiers anonymous. The communication protocol is based on certificate-exchange protocols previously defined by IETF, and should work with various authentication systems already in place. The goal of this implementation is to create a framework in which strong cryptosystems and authorization schemes can flourish. I am not smart enough to invent any such schemes myself, but I do see that the name system, in order to be useful, should be lowest-common-denominator equipment. If they are kept at the level they are being proposed at today, the options for speed, efficiency, and anonymity are severely hampered. I will make available an RFC as soon as I put one together. It's pretty straightforward. I am interested in keeping identifiers as "out of the way" as possible across the entire network. I work for an ISP, and am all too familliar with the accounting and authorization nightmare that inconsistent identities beings up. I am not a C expert, nor a crypto expert, nor a distributed systems expert. Furthermore I am working full-time, so I really only have my evenings free. I would appreciate any assistance from others who are interested in helping. graydon@pobox.com From owner-ipsec Mon Jan 6 16:00:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01922 for ipsec-outgoing; Mon, 6 Jan 1997 15:59:52 -0500 (EST) From: Uri Blumenthal Message-Id: <9701062102.AA194199@hawpub.watson.ibm.com> Subject: Re: pf_key comments To: ho@earth.hpc.org (Hilarie Orman) Date: Mon, 6 Jan 1997 16:02:56 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199701062024.PAA03400@earth.hpc.org> from "Hilarie Orman" at Jan 6, 97 03:24:52 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie Orman says: >>> Does the IV have to be *unpredictably* different, or just different? >> >> Just different. > > Phil Rogaway has pointed out that if the IV and the first data block are > both changing so as to cause their xor to be constant, the purpose of > the IV is defeated. Cute! > I don't know if this has ever been observed in practice, but it > is something to keep in mind (I suppose someone now will try to design > this into a protocol as some kind of optimization!). (:-) Considering that IV has nothing to do with the data block, I'd say the chance to see this in practice is nil. Could anybody comment on this? Was/is there ever a case when IV was somehow data-dependent? Oh, and when you use the last ciphertext from the last message as the IV for the next message, due to ciphertext properties of any semi-decent cipher this should be a no-issue. Correct? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Mon Jan 6 22:20:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03805 for ipsec-outgoing; Mon, 6 Jan 1997 22:18:33 -0500 (EST) Date: Mon, 6 Jan 1997 19:20:50 -0800 (PST) From: Phil Karn Message-Id: <199701070320.TAA03077@servo.qualcomm.com> To: andrade@netcom.com CC: ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org In-reply-to: <199701050933.BAA00135@netcom17.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >This is interesting. I knew that TCP/IP will be miserably slow when >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I I don't know where you get such pessimistic figures. My own DES (in a mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) MHz Pentium, and in triple DES mode gets about 6 megabits as I recall. The source is free by email to anybody who will state that they're a US citizen or permanent resident physically in the US. I routinely encrypt just about all of my remote login/X sessions and file copies with SSH in the 3DES or IDEA mode, and I hardly notice the encryption overhead. Phil From owner-ipsec Tue Jan 7 00:16:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA04442 for ipsec-outgoing; Tue, 7 Jan 1997 00:15:33 -0500 (EST) Message-Id: <199701070516.VAA18319@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Mon, 6 Jan 97 21:16:55 -0800 To: Phil Karn Subject: Re: IPsec and TCP cc: andrade@netcom.com, ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199701070320.TAA03077@servo.qualcomm.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > >This is interesting. I knew that TCP/IP will be miserably slow when > >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > > I don't know where you get such pessimistic figures. My own DES > (in a mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 > (not 200) MHz Pentium, and in triple DES mode gets about 6 > megabits as I recall. The source is free by email to anybody who > will state that they're a US citizen or permanent resident > physically in the US. > This is what I get on a 133 under NeXTSTEP 3.3 against libdes-3.23 > > % speed > > Doing set_key for 10 seconds > > 819602 set_key's in 8.77 seconds > > Doing des_ecb_encrypt's for 10 seconds > > 1277920 des_ecb_encrypt's in 8.84 second > > Doing des_cbc_encrypt on 8192 byte blocks for 10 seconds > > 1307 des_cbc_encrypt's of 8192 byte blocks in 9.31 second > > Doing des_ede_cbc_encrypt on 8192 byte blocks for 10 seconds > > 485 des_ede_cbc_encrypt's of 8192 byte blocks in 9.34 second > > Doing crypt for 10 seconds > > 47930 crypts in 9.31 second > > set_key per sec = 93501.83 ( 10.7uS) > > DES ecb bytes per sec = 1155998.30 ( 6.9uS) > > DES cbc bytes per sec = 1149738.95 ( 7.0uS) > > DES ede cbc bytes per sec = 425216.86 ( 18.8uS) > > crypt per sec = 5146.85 (194.3uS) > > > -dpg From owner-ipsec Tue Jan 7 07:59:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06752 for ipsec-outgoing; Tue, 7 Jan 1997 07:55:19 -0500 (EST) Date: Mon, 6 Jan 1997 18:01:12 -0500 (EST) From: graydon hoare To: ipsec@tis.com Subject: RE: Thinkin' about identifiers... In-Reply-To: <01BBFBF3.B6A1C3A0@erussell-2.ftp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 6 Jan 1997, Edward A. Russell wrote: > to services and machines incorporated with a public key infrastructure. > I should be able to walk up to any PC and authenticate myself (via smart > card or secure key/cert package downloaded from my server) and then gain > access to all things I am allowed access to. But fundamental to this is > WHO AM I? What is my name. I agree 100%. The notion of having to carry around multiple IDs is getting stale my the minute. Have you read about IBM's little "personal area networks"? Forget smart cards -- we're talking about smart shoes now ;) > > I would also like to see user-based IPSEC where machines authenticate a > session based on a user certificate, not a DNS machine certificate. > Again, what is the namespace here. > > I disagree with the need for hiding information about where I work or > the country I live in however - that is too paranoid for my own taste - > the concept of "anonymous authentication" makes no sense to me. However Personally, yeah. I don't see knowledge of my identity interfering with me getting my work done on a daily basis... "anonymous authentication" is very normal though, you just need to use non-binding identifiers. You can use the pub-key to "authenticate" that I am who I claim to be. Who do I claim to be? Rudolph the red-nosed raindeer. Who cares? If you trust the person you use to verify the identifier, you don't need to know who the person you talk to is. it would be nice to have the option, keep it available, like say if I use one smartcard to buy illegal merchandise (using the first virtual bank of the underworld ;), I don't want ANY personal data that the first secret service database may also know about me available when the criminal database is eventually compromised. Simpler context: if I want 1 company to know my phone number (cause they provide a useful service through the phone) but I do not want the direct-marketing department of my grocery store to get my phone number cause they'll call me at 2:33am and ask if my lettuce is crispy enough, how do I realistically prevent them from doing a merge on my name once they sell each other their databases? if my name is not bound by reality, I can keep multiple identifiers and they can't be easily connected to one another. I keep one for people I want to have my phone number, and one for people I do not want to have it. ta da. Multiple-identity management should be the responsibility of an individual, not of viacrypt. > > You talk about an implementation, but what are your ideas for a > namespace? Doesn't it have to be hierarchial and to that extent don't > you eventually wind up with X.500 Distinguished names anyway? > I've been thinking about a fixed-length binary string around 18-24 bytes. Maybe so big as 30, cause there's no point having to come up with a whole new distributed naming database for software agents, consumer electronics, and whatnot. Still, playing with a calculator for a minute it's not hard to see that you are fine within 24 bytes. It would definitely have to be hierarchical, but the nice thing is that there need not be any organizational tie to the outside world as far as Authority of Service. Therefore, if you introduce a new server into the system and it advertizes to its nearest peer, it should be reasonable for the peers to begin loading any old data they feel like into the new peer's allocated storage. There are no trademarks to worry about in 24-byte binary jumbles (god I hope there aren't ;) so why should you care whose names you're serving? Part of the intended reliability is the fact that anyone with a reasonably reliable machine can download the software, get some sort of trusted key out of band from another peer, and then add their collective resources to the pool immediately. I sorta prefer the trust-web to the CA model, but probably a healthy mixture of the two will evolve. I don't _dislike_ X.500... I bet it will help me find my friends' email addresses. The problem is that if I write down their DN, and they move, their DN doesn't yield their certificate anymore. If they signed one of my certificates, like in a trust web, then the authority they bestowed on me is broken until I figure out where they moved to. It's an incomplete solution. Particularly if you start dealing with comsumer electronics which need to authenticate. Is the Hitachi X.500 server supposed to handle the load for all of them? What if you compromise that server? Every VCR in the world is under your control .. worse, if you make a business keep track of its own hardware, you only need to do a denial-of-service attack on their key server to shut down all business operations. ugly! I just think the identifier <-> certificate table should be spread far and wide all over the net, and the IDs need to be rock-solid. -graydon From owner-ipsec Tue Jan 7 08:29:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA07242 for ipsec-outgoing; Tue, 7 Jan 1997 08:29:15 -0500 (EST) Message-Id: <199701071332.NAA07888@inner.net> To: Phil Karn cc: ipsec@tis.com, naganand@ftp.com, ho@earth.hpc.org Subject: Re: IPsec and TCP In-reply-to: Your message of "Mon, 06 Jan 1997 19:20:50 PST." <199701070320.TAA03077@servo.qualcomm.com> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Tue, 07 Jan 1997 08:32:27 -0500 From: Craig Metz Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199701070320.TAA03077@servo.qualcomm.com>, you write: >>This is interesting. I knew that TCP/IP will be miserably slow when >>you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > >I don't know where you get such pessimistic figures. My own DES (in a >mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) In a *highly* unscientific experiment, I was able to move a 100MB file via FTP (TCP/IPv4) between a P120 and a P90 with both ESP DES-CBC and AH HMAC-SHA on every packet and got an average throughput of about 3.18Mb/s. This is with a software implementation that is unoptimized and has lots of debug code in place. It would not at all surprise me if a well-optimized implementation could at least double that. You want faster? Use hardware assists for the crypto. -Craig From owner-ipsec Tue Jan 7 10:30:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08259 for ipsec-outgoing; Tue, 7 Jan 1997 10:28:50 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199701071531.KAA79270@mailhub1.watson.ibm.com> Date: Tue, 7 Jan 97 10:31:29 EST To: bhoward@TimeStep.com, chk@border.com, URI@watson.ibm.com cc: ipsec@tis.com Subject: pf_key comments (predictable IVs) Sender: owner-ipsec@ex.tis.com Precedence: bulk The traditional motivation for IVs is to cause two encryptions of the same plaintext to result in two different cipheretexts. For such a use just different (even if predicatable) IVs are enough. However, there is more functionality built into IVs. They are intended to randomize plaintext before encryption for a variety of other reasons. Especially, against chosen message attacks. Consider, for example, an attacker that builds a table with encryptions of the all-zero message under the 2^56 DES keys. How does the guy gets an encryption of zero under the victim's key? If the attcker can mount a chosen plaintext attack it could ask for the encryption of the zero message. But if the encryptor chooses an IV before encrypting then the attacker gets DES(K,IV) rather than DES(K,0). On the other hand, if the IV is known to the attacker before hand (e.g., the IV is an incrementing counter or the last block of ciphertext from the *previous* message) then the task for the attacker is easy. He just chooses the message to encrypt to be equal to the next IV. The ciphertext he will see is DES(K, IV XOR IV) = DES(K,0) ! If instead, the IV is chosen *after* the plaintext is fixed (in a way which is unpredictable to the attacker) then the attacker has little to do to get DES(K,0). I hope this helps in clarifying the issue of predictable vs unpredictable IVs. In particular, IVs known *before* choosing/fixing the message to be encrypted or *after*. Another example from Phil Rogaway (draft-rogaway-ipsec-comments-00.txt): "...suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000001 is recognizably distinct from a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000000. Clearly this violates violates the notion of a secure encryption sketched in Section 2." [You can find the full Rogaway's draft in http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html A related one in the same page is: draft-rogaway-cbc-encrypt-00.txt (April 27, 1995)] Hugo From owner-ipsec Tue Jan 7 10:30:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08266 for ipsec-outgoing; Tue, 7 Jan 1997 10:30:20 -0500 (EST) Date: Tue, 7 Jan 1997 10:29:55 -0500 (EST) From: graydon hoare To: Ron Rivest cc: ipsec@tis.com Subject: Re: [graydon@gabber.multinet.net: Thinkin' about identifiers...] In-Reply-To: <199701062134.AA22448@swan.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 6 Jan 1997, Ron Rivest wrote: > > I'd be interested in seeing what you come up with. > > If you haven't seen our paper on SDSI, please take a peek at it > (http://theory.lcs.mit.edu/~rivest, publications); it deals with > similar stuff, a bit differently... > > Cheers, > Ron Rivest I have just read your paper on SDSI; happily it seems we are working on projects which complement each other well. My original intrest in a strong naming scheme grew out of my intrest in publicly implementing stanford's ontology server project, which uses KIF to represent local-name-scope knowledge bases in a (possibly) distributed system. The possibilities for machine-learning and CMC within such a setting are immense and quite inspiring. I thought I'd get to work making a friendly client and possibly porting their server, in order to make the effort to build a good sized KB as public as possible. I totally support the exported-lexical-scope notion for building local bindings. The problem which arose, and which I believe still plagues the name systems you have included thus far in your "well known roots" list, which gets used when exported relationships either do not exist or have failed, is that these global name systems are too heavily influenced by other uses, other application-domains. As a result of being tied to a domain which is unrelated to principal identity, such a global name is not under individual control. Furthermore you're placing the burden of resolving multiple name-types on the clients, which likely already have to deal with multiple hashing algorithms and multiple security paradigms. Also, it becomes tricky to decide where (physically) SDSI auto-cert servers go, when they live in multiple namespaces. What if your X.500 organization borders fon't follow your DNS borders? Where do you put certificates for principals in one office with both email names and X.500 names? How do you co-ordinate the databases? Who is running your server? SDSI seems extremely advanced and flexible, but basically requires a powerful recursive S-expression evaluation engine (like say, libguile) to be embedded in each implementation. While this is a desirable scenario for all software, it's not likely given today's programmers and today's market -- particularly not in consumer electronics or embedded systems. I don't expect all secure devices will have the patience or resources to do a full SDSI implementation. All I'm proposing is an identifier-distribution and association network. The certificate-authentication interface of my implementation will be quite generic, and will likely be amenable to SDSI as well as X.509, PGP, and hopefully some low-overhead schemes which consumer electronics can use to work securely even given limited memory. It is neither my concern nor remotely within my ability to code such security systems. I'm focusing on making an identifier system which is an order of magnitude more reliable and flexible than DNS, which requires virtually no maintenance and which has no identifiable attack points. You should be able to walk up to any system, connected to the internet in even the thinnest possible way, and say "I am bleh-bleh, and I have someone here who says they are blah-blah-blah... give me some credentials so I can prove it". This includes the special case of "I am bleh-bleh, here are some personal credentials, I want access to everything I am authorized to do, from this new location". It's up to them what sorts of extended credentials they use, and it is up to an external module of the server software to decide what sort of inter-peer communication security / update authorization system gets used. My plan is to rip off the structure of IP6 secure-OSPF code for the server-location and database concurrency module, I'll probably just wrap data-conversion code around berkeley DB for the actual records, and then present pluggable generic security and communication layer APIs to handle the outside world. I'm using a very simple protocol.. most of the thinking work gets done by client libraries living above the name service (like SDSI). I definitely like what you've done so far. It's cool. It's essentially the set of security predicates which were missing from early KIF/KQML designs. Hopefully they can be more tightly integrated in the future. You might try re-coding your predicates in KIF, as ARPA likes it so much ;) In the meantime I am going to go ahead with designing my little identfier/credential daemon. I'll publish it widely as soon as I have even a fragment of code that compiles (some of us really suck at anything system-level ;) I'm working on an internet-draft that spells out my motives a little better. I think I have most of the glaring technical details covered. I'll post it when I'm done. Thanks for your response. -graydon From owner-ipsec Tue Jan 7 17:26:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10780 for ipsec-outgoing; Tue, 7 Jan 1997 17:11:38 -0500 (EST) Date: Tue, 7 Jan 97 22:10:03 GMT Standard Time From: Ran Atkinson Subject: [Admin] New Editor for IPsec Base Specs To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm pleased to announce that Steve Kent has agreed to take over editing the IPsec Base Specifications (IP Security Architecture, AH, ESP). Comments on revising those drafts should be sent directly to him or to the IPsec mailing list . Ran rja@inet.org From owner-ipsec Thu Jan 9 07:52:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24023 for ipsec-outgoing; Thu, 9 Jan 1997 07:43:43 -0500 (EST) Message-Id: <199701091243.HAA24023@portal.ex.tis.com> To: ipsec@tis.com Subject: Draft des-md5 v3 Date: Thu, 09 Jan 1997 01:22:46 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- While implementing the DES-MD5 transform as of draft v3, i noticed that the algorithm that checks the replay counter window that's given would not work correctly with the draft's specification; the algorithm assumes that the initial value of the replay counter is 1 (or 0), but the draft has the counter initialized to some arbitrary value (an MD5 result). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMtSOtL0pBjh2h1kFAQEAwAP9FpNuPvjdM9ZT9qgLB2ach8BAW3PLs5M1 hP/gRLm2c7TQgw/pfJ47k9u7WldWpvtmSp59+IcGn9Thgrr0KUYZDn400flKFnGE I4m+jQAK6IhG/2Z1uXLf/qvXsdJzQB5q8tnIAqO4zcJIUSevCLgsI9Jb3XTFG9Ui 1nRxFwf9vj0= =Q6VJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 9 08:47:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA24422 for ipsec-outgoing; Thu, 9 Jan 1997 08:45:14 -0500 (EST) Message-Id: <199701091348.FAA04890@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Rodney Thayer cc: ipsec@tis.com, gnu@toad.com Subject: Re: pf_key comments (random number generation) In-reply-to: <3.0.16.19970103095702.364738dc@pop3.pn.com> Date: Thu, 09 Jan 1997 05:48:34 -0800 From: John Gilmore Sender: owner-ipsec@ex.tis.com Precedence: bulk > 1. I like the idea of sending the IV down from an application. I think > that an application is a reasonable place to do the random number > generation On the PF_KEY question I'm not qualified to answer. But the question reminded me of a randomness issue for overall security that wasn't addressed in RFC 1750. In looking at the harm that can be done to cryptographic protocols by attacking their random numbers, I have some tentative rules of thumb: * Randomness should be mixed in from a variety of sources, at different levels (e.g. application, kernel, hardware). * This mixing must be deterministic or verifiable, so that it can be detected if subverted. For example, if software feeds random values to black box hardware, and the black box hardware then outputs a "mixed" random number, you have no idea if the output was actually chosen to subvert the process, since you couldn't see the hardware's random input to the mixer before you handed it the software input to the mixer. If instead the hardware outputs a random value, then SOFTWARE mixes it with other software-generated values, you can at least examine that mixing software with debuggers, logic analyzers, oscilloscopes and tweezers to see if the mixing has been subverted. * Relying on a hardware black box ALONE to generate your random numbers is foolish. Mixing the output of such a box with your software random numbers probably improves them; even if the box knows your software "random number" algorithm, it probably can't see all the inputs to it, so it probably can't reduce (subtract out) the entropy the software found. Young and Yung did a great paper for Crypto '96 on how to subvert protocols with bad random black-boxes (like how malicious random number hardware could hide your RSA private-key inside your published "random" RSA public-key, in a subliminal channel such that only those who knew a secret could detect it). John From owner-ipsec Thu Jan 9 10:01:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25084 for ipsec-outgoing; Thu, 9 Jan 1997 10:00:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199701091348.FAA04890@toad.com> References: <3.0.16.19970103095702.364738dc@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Jan 1997 10:03:47 -0500 To: John Gilmore From: Stephen Kent Subject: Re: pf_key comments (random number generation) Cc: Rodney Thayer , ipsec@tis.com, gnu@toad.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, If one has a good hardware RNG, nothing you do with the output in software is likely to improve on the output, and many things that you do could degrade the result. I acknowledge that if you lack confidence in the hardware RNG output, then you have a problem, and then it might be appropriate to try to improve on the output with good software (although use of a second hardware RNG would be better). However, we have many more examples of bad software PRNGs than bad hardware RNGs. I also am very skeptical that application-based PRNG sources are an improvement over good, kernel PRNG sources; I suspect the opposite is true in most cases. I'd rather not see an API based on the assumption that the kernel code can't get it right and the application code will do better. Should we ever evolve to more secure OSs, the likelihood is much greater that Trojan Horse software will be able to degrade the application environment PRNG than a kernel-based PRNG. Also, we are ultimately dependent on the security of kernel code anyway, to protect user traffic from disclosure. So, I tend to think that suggestion of making specific API provisions for application-supplied PRNG data is questionable. In a more general vein, while I too do not profess to have examined the pf_key interface in detail, I am puzzled by several of the suggestions I have seen in this thread. - Making a kernel call to get an IV (or a sequence of IVs), which the application would pass back with a packet to be protected, seems very odd to me. IV generation si a side effect of IPSEC (ESP) use, and is dependent on the algorithm and the mode being employed. So, it seems appropriate to let the IPSEC implementation handle the IV generation and use, to hide the details from applications. - The discussions about user vs. kernel performance for the IV generation task also struck me as odd. In general, I don't think we want to make user code knowledgable about the crypto details of IPSEC, so IV management really should be hidden in the IPSEC code, not visible to the caller. - As others have pointed out, after an initial IV has been generated for a CBC session, one can just use the last ciphertext block from packet N as the IV for packet N+1, just as one dies within the context of a single packet. The specs for use of DES in this mode do allow re-use of the first IV for subsequent packets, but that always struck me as a bandwidth-saving measure that was not worth the potential security downside. However, the same spec points to the need to protect the first IV against modification attacks, e.g., by encrypting it using ECB mode, on the assumption that a constant IV is used for every packet. The reasons for this are left as an exercise for the reader, and for explication by the list members who do not shrink from being called cryptographers! Steve From owner-ipsec Thu Jan 9 13:38:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26856 for ipsec-outgoing; Thu, 9 Jan 1997 13:37:38 -0500 (EST) Message-Id: <2.2.16.19970109154134.0cdf27c8@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jan 1997 10:41:34 -0500 To: ipsec@ex.tis.com From: John Burke Subject: Various difficulties in ISAKMP ver-06 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have found a number of points which ISAKMP draft ver-06 still seems to leave up in the air, most of which I would call obstacles to interworking. So here they are: o Initiator should be allowed to send both ID's in all exchanges. The drafts seem to forget the firewall/router case, which is the more general case and so should be the target of the drafts. Note that the original Oakley, and Harkins/Carrell Quick Mode, do have this provision. Of course this makes the ID payload order dependent and the exchange has to say which is which. o It is not clear which payload the SA names as Next Payload: the Proposal or the next load after the proposals and transforms. There are contradictory indications which need to be fixed; I assume option 1 is correct and 2 is a mistake: 1) Description of SA Payload (p. 26) specifies that Next Payload may be zero. This implies that the Next-Payload is the next major payload, after all the proposals and transforms. This would conform with the Payload Size of the SA. 2) The example exchange picture in 4.1.1 (ver-02 p. 42) shows the Next-Payload of the SA contains "Proposal". (Also this picture does not show an actual payload-size value.) o Ambiguity about correct use of Notification: The description of the Notify payload (ver-02 p.37) starts out saying, that a Notification in phase 1 is identified by the cookies in the message header, and a Notification in phase 2 is identified by the cookies and the Message ID. (It also mentions "the SPI associated with the current negotiation"; this phrase has no connection to the rest of the section; if it is meant to convey something particular, it has to be clarified.) But the Notification always contains the SPI field; and there is the provision for the Informational Exchange which permits a fresh Exchange to carry a Notification. This implies that the SPI in the Payload is ALWAYS the defining identifier for the SA being acted upon. Surely it is permitted to send Notification within a message of an exchange in progress, and surely the Notification will contain the SPI which the message applies to? This should be stated. It would seem silly to permit sending the Notify "Connected" in a separate Informational Exchange; it would be unreasonable to require that it MUST be sent in the separate exchange. I recommend it be allowed only on the cookies/ID of the original exchange. Is it forbidden to send Notification for SA B in a message whose cookies/msg ID name SA A, when the Exchange Type is not "Informational"? I would want and expect it to be forbidden, but it doesn't have to be that way; needs to be spelled out. Is it required in any circumstances that a Notify MUST be sent in a new Informational Exchange and not with the cookies/ID and type of the Exchange in progress? If this requirement applies in common cases, it will use up the space of Message ID's twice as fast as otherwise. Is it valid to retain the Message ID of an Informational Exchange and send further Notifications over time for various SA's? In both directions? Is it valid to send a Notification applying to a User SA, when the ISAKMP SA is Up, in a message with: The ISAKMP SA cookies Exchange Type = "Informational" Message ID = zero o Ambiguity in the correct use of Delete The questions above on Notification apply to Delete too. One would think that after a connection completes successfully, the Delete SHOULD be sent in a separate Informational Exchange, but we have to provide for a necessary ambiguity here. Consider: the state of setup is unclear in the partner who has sent the last message of the Exchange until it receives something valid over the SPI; meanwhile this side doesn't know whether the other side has completed. The above implies that a Delete MUST be permitted to arrive in a separate Informational Exchange for an incomplete connection. o Requirements for an adequate cookie should be stated. Karn's cookie is noted as existing but its features are not said to be required. o Ordering of payloads There is no statement on whether payloads within one message must appear in exactly a given order. The diagrams show a specific ordering on the face of it, but this is an inadequate basis for the reader to deduce a requirement, and the very existence of payload types makes it reasonable to allow any order. Precision on this point is especially needed wherever a hash or signature is prescribed to be over all the content of a message. o Notifications sent in the clear: Does the draft want to address whether a Notification should be sent in the clear at all when it says the connection failed, considering this is a vulnerability to attack? o The term "string" is not defined, e.g. for domain names. People can conclude with equal reasonableness, a) that it means with zero terminator, or b) all characters included in the count are significant content. o Alignment o General: It appears clear to me that all payloads in messages may appear unaligned, since some can have a size of odd bytes. The text should state this, since the pictures show several things as being four bytes wide though this is not required by the text. If we do want alignment it has to be stated explictly, and as "aligned at 4-byte multiples" or "2-byte". o TLV Attributes: The discussion of TLV Attribute format specifies "word alignment"; "word" is not a precise term. Two-octet? Four? And the wording of this section does not actually say alignment is required, but it sounds like it wants to. It unequivocally says any padding must be by leading zeroes; this gives no guidance to someone who invents a character attribute. o Lifetime Attributes The use of "Lifetime Type" and "Lifetime Duration" attribute pairs introduces an unnecessary complication and, as it is now, an ambiguity. What is the correct procedure for pairing up the attributes, since the draft does not specify what order they have to be sent in? Is it absolutely required that each "Lifetime Type" appear before its respective "Lifetime Duration"? Also, question: can one supply both a KB life limit and a time life limit? I think the draft should say Yes". I would rather see the simple answer: change to have a separate attribute each for: ESP life in seconds; ESP life in KB, AH life in seconds, AH life in KB, etc. I see no argument against this, and it will save us all a hunk of just plain useless implementation code. From owner-ipsec Thu Jan 9 14:57:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27574 for ipsec-outgoing; Thu, 9 Jan 1997 14:55:27 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701091957.LAA01904@netcom11.netcom.com> Subject: Re: IPsec and TCP To: karn@qualcomm.com (Phil Karn) Date: Thu, 9 Jan 1997 11:57:00 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199701070320.TAA03077@servo.qualcomm.com> from "Phil Karn" at Jan 6, 97 07:20:50 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 855 > >This is interesting. I knew that TCP/IP will be miserably slow when > >you throw DES into it (about 1 Mbit/sec @ 200 Mhz on a Pentium) but I > > I don't know where you get such pessimistic figures. My own DES (in a > mix of C and 386 assembler) gets 15.9 megabits/sec on a 133 (not 200) > MHz Pentium, and in triple DES mode gets about 6 megabits as I > recall. The source is free by email to anybody who will state that > they're a US citizen or permanent resident physically in the US. > Sorry. I meant about 1 MByte (still slow). Using a pure C implementation by Richard Outbridge (D3DES) I am getting about 0.9 Mbytes on a Pentium Pro 200 Mhz. Your numbers seem to indicate a speedup of 2x is possible (still quite slow). - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu Jan 9 15:07:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27640 for ipsec-outgoing; Thu, 9 Jan 1997 15:07:25 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701092009.MAA02614@netcom11.netcom.com> Subject: Re: IPsec and TCP To: cmetz@inner.net (Craig Metz) Date: Thu, 9 Jan 1997 12:09:02 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199701071332.NAA07888@inner.net> from "Craig Metz" at Jan 7, 97 08:32:27 am Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 818 > > In a *highly* unscientific experiment, I was able to move a 100MB > file via FTP (TCP/IPv4) between a P120 and a P90 with both ESP DES-CBC and AH > HMAC-SHA on every packet and got an average throughput of about 3.18Mb/s. This > is with a software implementation that is unoptimized and has lots of debug > code in place. It would not at all surprise me if a well-optimized > implementation could at least double that. You want faster? Use hardware > assists for the crypto. > Do you mean 3.18 Mbits/s or 3.18 Mbytes/s? Unfortunately hardware assists are not possible for economic or other reasons. In particular if you wish to deliver shrinkwrap software to a Win95/Intel type platform. - Alex -- Alex Alten 7677 Chestnut Way Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu Jan 9 16:22:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28121 for ipsec-outgoing; Thu, 9 Jan 1997 16:19:56 -0500 (EST) Message-ID: From: "Waterhouse, Richard" To: "'IPSEC WG'" Subject: re: Delete (in John Burke's recent message) Date: Thu, 9 Jan 1997 16:24:47 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk "The above implies that a Delete MUST be permitted to arrive in a separate Informational Exchange for an incomplete connection." > This would imply the rules for the Delete must be different for Phase 1 and Phase 2. "Deletion of a Security Association MUST always be performed under the protection of an ISAKMP SA." (Section 5.13) would prohibit implementation of your suggestion for Phase 1. From owner-ipsec Thu Jan 9 18:58:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28949 for ipsec-outgoing; Thu, 9 Jan 1997 18:57:17 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: IPSEC DOI doc and Identification Payload Date: Thu, 9 Jan 1997 18:54:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry if this has already come up... The Identification Type is specified as 1 octet, yet gives values ranging from 0 to 512. Bye. From owner-ipsec Thu Jan 9 21:28:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA29888 for ipsec-outgoing; Thu, 9 Jan 1997 21:27:35 -0500 (EST) Message-Id: <2.2.16.19970109233152.0f2f046c@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jan 1997 18:31:52 -0500 To: ipsec@ex.tis.com From: John Burke Subject: re: Delete (in John Burke's recent message) Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:24 PM 1/9/97 -0500, "Waterhouse, Richard" wrote: > > "The above implies that a Delete MUST be permitted to arrive in > a separate Informational Exchange for an incomplete connection." > >> This would imply the rules for the Delete must be different for Phase 1 and >Phase 2. > >"Deletion of a Security Association MUST always be performed under the >protection of an ISAKMP SA." (Section 5.13) would prohibit >implementation of your suggestion for Phase 1. Yes, that's right; I was not considering that point. As you say, this is a difference between Phase 1 and Phase 2. I believe it's necessarily so; and in fact it appears to me the same logic applies to any Notify that signals failure. Best regards, John Burke From owner-ipsec Fri Jan 10 17:28:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA06826 for ipsec-outgoing; Fri, 10 Jan 1997 17:15:43 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: Deletes and cookies - problem Date: Fri, 10 Jan 1997 17:12:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Under Section 2.4 Identifying Security Associations "ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs." I take this to mean that the combined cookies identify the SA, there is wording elsewhere in the draft which supports this. Under Section 2.5.3 Anti-Clogging Token (Cookie) Creation of the ISAKMP draft (page 21)it states: "ISAKMP requires that the cookie be unique for each SA establishment, SA Notify, and SA Delete to help prevent replay attacks." Does this imply that the new cookies are for the new ISAKMP SA which must be negotiated in order to delete the old ISAKMP SA or does this mean that for each establishment and informational exchange the cookies must be unique. If it is the former then the statement is redundant and misleading and should only state "ISAKMP requires that the cookie be unique for each ISAKMP SA establishment or SA Notifies sent when SA establishment has failed." If it is the latter (how I interpret it) there are problems. Referring to section 4.8 Informational Exchange (page 51): "Once an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under protection provided by the ISAKMP SA." If a new cookie is generated for the Delete(Informational exchange) how are we supposed to identify what SA (ie the encryption algorithm, key) that is being used to protect the remainder of the packet? It would seem clear that if the combined cookies are to be used to identify ISAKMP SAs, that they cannot change from ISAKMP SA establishment to SA delete (for any protocol). Since a delete will only ever be sent after an SA has been established there is never a case to generate a new cookie when sending deletes. For Notify messages where an ISAKMP phase one negotiation has failed a new cookie should be generated, otherwise the message is sent under protection of the SA and therefore the original cookies are needed to identify the SA used to protect it. If I am missing something let me know. Thanks Bye. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Fri Jan 10 18:52:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07176 for ipsec-outgoing; Fri, 10 Jan 1997 18:43:45 -0500 (EST) Message-Id: Date: Thu, 9 Jan 1997 19:22:12 -0800 (PST) From: Phil Karn To: andrade@netcom.com CC: ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199701091957.LAA01904@netcom11.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk My code is based on Outerbridge's. It's a hand-optimized, manual translation of the core of his code to 386/486/Pentium assembler. Phil From owner-ipsec Fri Jan 10 19:07:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07266 for ipsec-outgoing; Fri, 10 Jan 1997 19:02:44 -0500 (EST) Message-Id: <9701110001.AA23417@sol.hq.tis.com> To: cat-ietf@MIT.EDU, e-payment@bellcore.com, firewalls@greatcircle.com, ids@uow.edu.au, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-tls@w3.org, ietf@cnri.reston.va.us, ipsec@ans.net, pem-dev@tis.com, psrg@isi.edu, sndss-authors@isi.edu, sndss-chairs@tis.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: 2ND ANNOUNCEMENT: ISOC 97 SYMP NETWORK & DISTRIBUTED SYSTEM SECURITY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23400.852940884.1@tis.com> Date: Fri, 10 Jan 1997 19:01:26 -0500 From: "David M. Balenson" Sender: owner-ipsec@ex.tis.com Precedence: bulk PLEASE NOTE THE EARLY REGISTRATION AND HOTEL ROOM AVAILABILITY AND SPECIAL RATES DEADLINES ARE APPROACHING!! RESERVATIONS AT THE PRINCESS RESORT MUST BE MADE NO LATER THAN JAN 13TH FOR THE GOVERNMENT RATE, AND NO LATER THAN JAN 20TH FOR THE REDUCED GROUP RATE. EARLY REGISTRATION FOR THE SYMPOSIUM MUST BE POSTMARKED NO LATER THAN JAN 22ND. --------------------------------------------------------------------------- THE INTERNET SOCIETY 1997 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '97) 10-11 FEBRUARY 1997 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA This fourth annual symposium will bring together researchers, implementors, and users of network and distributed system security technologies to discuss today's important security issues and challenges. It will provide a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. We hope to foster the exchange of technical information and encourage the Internet community to deploy available security technologies and develop new solutions to unsolved problems. WHY YOU SHOULD ATTEND The use of the Internet is rapidly growing and expanding into all aspects of our society. Commercial organizations are coming under increasing pressure to make their services available on-line. This in turn is increasing the need for rapid and widespread deployment of usable and effective network and distributed system security technologies. High visibility attacks on the Internet underscore the vulnerabilities of the Internet and the need to solve its security problems. There is growing concern for securing the network infrastructure itself. Recent trends in software distribution (such as Java and ActiveX technologies) have made certain attacks easier to carry out. Privacy has become an important issue for the Internet. NDSS '97 will bring together researchers, implementors, and users of network and distributed system technologies to discuss today's important security issues and challenges. We have selected the technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. Topics to be addressed include Internet infrastructure and routing security, security for the World Wide Web, Java and ActiveX security, cryptographic protocols, public key management, and protection of privacy. The symposium will have a positive impact on the state of Internet security. You will have the opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues during the panel sessions, and let other participants know of your requirements, observations, and experience in this important area. We hope to encourage the wide-scale deployment of security technologies and to promote new research that can address the currently unmet security needs of the Internet community. CONTENTS Preliminary Program Organizing Committee San Diego Princess Resort Registration Information Registration Form --------------------------------------------------------------------------- P R E L I M I N A R Y P R O G R A M SUNDAY, FEBRUARY 9 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MONDAY, FEBRUARY 10 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: THINGS THAT GO BUMP IN THE NET Chair: Stephen T. Kent (BBN Corporation, USA) Experimental Results of Covert Channel Elimination in One-Way Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard Schroeppel, Sean O'Malley, and Oliver Spatscheck (University of Arizona, USA) Blocking Java Applets at the Firewall, David M. Martin Jr., Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA) Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection & Configuration Analysis, Abdelaziz Mounji and Baudouin Le Charlier (Institut D'Informatique, Namur, BELGIUM) 10:30 A.M. BREAK 11:00 A.M. SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT Chair: Aviel Rubin (AT&T Research Labs, USA) Panelists: Li Gong (JavaSoft, USA), Jim Roskind (Netscape, USA), Edward W. Felten (Princeton University, USA) and Peter G. Neumann (SRI International, USA) 12:30 NOON LUNCH 2:00 P.M. SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS Chair: Christoph Schuba (Purdue University, USA) An Interface Specification Language for Automatically Analyzing Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA) Probable Plaintext Cryptanalysis of the IP Security Protocols, Steven M. Bellovin (AT&T Research, USA) Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford (Purdue University, USA) 3:30 P.M. BREAK 4:00 P.M. SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE Chair: Russ Mundy (Trusted Information Systems, USA) Panelists: Paul Lambert (Oracle, USA), Jeff Schiller (MIT, USA), Olafur Gudmundsson (Trusted Information Systems, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TUESDAY, FEBRUARY 11 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: ROUTING SECURITY Chair: Hilarie Orman (DARPA, USA) Securing the Nimrod Routing Architecture, Karen E. Sirois and Stephen T. Kent (BBN Corporation, USA) Securing Distance-Vector Routing Protocols, Bradley R. Smith, Shree Murthy and J.J. Garcia-Luna-Aceves (University of California Santa Cruz, USA) Reducing the Cost of Security in Link-State Routing, R. Hauser, A. Przygienda and G. Tsudik (IBM and USC/ISI, USA) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) Securing Web Access with DCE, Brian C. Schimpf (Gradient Technologies, USA) PANEL: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) 12:00 A.M. LUNCH 1:30 P.M. SESSION 7: PUBLIC KEY MANAGEMENT Chair: Jonathan Trostle (CyberSafe, USA) Hierarchical Organization of Certification Authorities for Secure Environments, Lourdes Lopez and Justo Carracedo (Universidad Politecnica de Madrid, SPAIN) Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic (Univeristy of Salford, UNITED KINGDOM) Distributed Authentication in Kerberos Using Public Key Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie Mellon University, USA) 3:00 P.M. BREAK 3:30 P.M. SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY Chair: Clifford Neuman (USC Information Sciences Institute, USA) --------------------------------------------------------------------------- O R G A N I Z I N G C O M M I T T E E GENERAL CHAIR David Balenson, Trusted Information Systems PROGRAM CHAIRS Clifford Neuman, USC Information Sciences Institute Matt Bishop, University of California at Davis PROGRAM COMMITTEE Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Verisign Richard Graveman, Bellcore Li Gong, JavaSoft Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Hilarie Orman, DARPA/ITO Michael Roe, University of Cambridge Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research PUBLICATIONS CHAIR Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR Thomas Hutton, San Diego Supercomputer Center REGISTRATIONS CHAIR Torryn Brazell, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group SPONSORED BY THE INTERNET SOCIETY Donald M. Heath, President & CEO Martin Burack, Executive Director --------------------------------------------------------------------------- S A N D I E G O P R I N C E S S R E S O R T LOCATION The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. Plan to visit La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. HOUSING INFORMATION We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio Rooms $ 81* Lanai Garden Rooms $114 * This represents the Government Rate for San Diego. A limited number of rooms are available at this rate. Reservations must be made no later than January 13, 1997. You must present a valid government id upon check-in. Based on room type and space availability, the special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. TO MAKE A RESERVATION Contact the San Diego Princess Resort at +1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1997. To receive the special goverment rate, you must make your reservation by January 13, 1997. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate, although, occasionally it rains. --------------------------------------------------------------------------- R E G I S T R A T I O N I N F O R M A T I O N FEES ISOC Non- Members Member* Early registration (postmarked on/before Jan. 22) $305 $345 Late registration $375 $415 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks * Non-Member fee includes one year Internet Society membership. FOR MORE INFORMATION Contact Carol Gray at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. WEB PAGE Additional information about the symposium and San Diego, plus on-line registration, are available via the Web at: http://www.isoc.org/conferences/ndss97 SPONSORSHIP OPPORTUNITIES AVAILABLE! Contact Torryn Brazell at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. --------------------------------------------------------------------------- R E G I S T R A T I O N F O R M INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887, send it via E-mail to Ndss97reg@isoc.org, or mail it to NDSS97, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA PERSONAL INFORMATION __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: ________________________________ MI: ____________________ Family Name: ___________________________________ __Sr __Jr __II __III Badge Name: __________________________________________________________ Please enter your name as you would like it to appear on your name tag. CONTACT INFORMATION Title: _______________________________________________________________ Organization: ________________________________________________________ Street address: ______________________________________________________ ______________________________________________________________________ City: ________________________________________________________________ State/Province: ___________________________ Postal Code: ____________ Country: _____________________________________________________________ Telephone Number (work): _____________________________________________ Telephone Number (home): _____________________________________________ Fax Number: __________________________________________________________ E-mail address: ______________________________________________________ SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?) ______________________________________________________________________ ______________________________________________________________________ APPEAR ON REGISTRANTS LIST? ___ Please check here if you would NOT like your name included in the list of registrants. PAYMENT INFORMATION All Payments must be in United States Dollars. Conference Fee -------------- If you are an Internet Society member, you are eligible for a reduced conference registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: On/Before After January 22 January 22 ---------- ---------- ___ Internet Society Member Fee US$ 305.00 US$ 375.00 ___ Non-Member Fee US$ 345.00 US$ 415.00 Method of Payment ----------------- Payment must be received on/before February 7, 1997 or we will be unable to pre-register you. 1. ___ Check. Make payable to the Internet Society. 2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard Name on Credit Card: ____________________________________ Credit Card Number: _____________________________________ Expiration Date: ________________________________________ 3. ___ CyberCash. Account Number: _____________________________ 4. ___ First Virtual. Account Number: _________________________ 5. ___ Wire Transfer* Bank ABA Number: 054000030 Account Number: Internet Society 148 387 10 Riggs National Bank of Virginia 950 Herndon Parkway Herndon, VA 20171 USA Wire Transfer Confirmation Number: ______________________ * Please process wire transfer before sending registration form. 6. ___ U.S. Government Purchase Order* P.O. Number: ____________________________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds (less a $25 processing fee) will be issued for cancellations received on/before February 7, 1997. No refunds will be issued after February 7, 1997. ------------------------------------------------------------------------ From owner-ipsec Tue Jan 14 08:08:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03027 for ipsec-outgoing; Tue, 14 Jan 1997 07:56:30 -0500 (EST) Date: Tue, 14 Jan 97 04:15:03 GMT Standard Time From: Ran Atkinson Subject: change of address To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk IPsec folks, My email address has changed to from . Should anyone need to reach me via email, please be sure to use the new address. Thanks very much, Ran rja@inet.org Co-chair, IPsec WG, IETF From owner-ipsec Tue Jan 14 13:49:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05447 for ipsec-outgoing; Tue, 14 Jan 1997 13:43:10 -0500 (EST) Date: 14 Jan 97 13:46:36 -0500 Subject: Re: Draft des-md5 v3 From: "James Hughes" To: ipsec@tis.com, "Angelos D. Keromytis" X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > While implementing the DES-MD5 transform as of draft v3, i noticed > that the algorithm that checks the replay counter window that's given > would not work correctly with the draft's specification; the algorithm > assumes that the initial value of the replay counter is 1 (or 0), but > the draft has the counter initialized to some arbitrary value (an MD5 > result). The counter must be "aliased" to 0 by subtracting the received value from the initial value. Unsigned arithemetic works just fine for this. jim From owner-ipsec Tue Jan 14 20:57:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07725 for ipsec-outgoing; Tue, 14 Jan 1997 20:55:43 -0500 (EST) Hops: 0 Host: clinet.fi. Posted-Date: Wed, 15 Jan 1997 03:57:03 -0200 (GMT) Message-Id: <199701150158.DAA14112@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com Subject: Release 0.4 of my Linux IPSEC code is out. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 03:58:37 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk It should appear in ftp://ftp.funet.fi/pub/unix/security/net/ip/ within a day. The impatient can get it from http://prometheus.hol.gr/~ji/ipsec/. /ji From owner-ipsec Wed Jan 15 15:00:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13716 for ipsec-outgoing; Wed, 15 Jan 1997 14:56:04 -0500 (EST) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" , "'isakmp-oakley'" , "'IETF Security Test mailing list'" Subject: 64-bit replay counters Date: Wed, 15 Jan 1997 14:59:51 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [AH-HMAC-MD5] and [AH-HMAC-SHA1] state that the replay counter is 64 bits, but it points to the [ESP-DES-MD5] draft for an exmple of a 32-bit replay counter source code. Could it provide more information on how to transform that 32-bit code to handle the newer 64-bit counters. -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 15:00:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13692 for ipsec-outgoing; Wed, 15 Jan 1997 14:51:34 -0500 (EST) Message-ID: From: Roy Pereira To: "'Derrell Piper'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: negotiating IVs Date: Wed, 15 Jan 1997 14:56:07 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [IPSEC-DOI] doesn't include a method to negotiate whether or not to use an explicit IV and what size to use. RFC1829 [ESP-DES] and RFC1851 [ESP-DES3] state that the IV is always 64 octets, but the newer ESP transform drafts [draft-ietf-ipsec-esp-des-md5-03.txt] state that the explicit IV is optional and should be negotiated. Should [IPSEC-DOI] be updated ? -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 15:05:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13792 for ipsec-outgoing; Wed, 15 Jan 1997 15:02:34 -0500 (EST) Message-Id: From: Roy Pereira To: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" , "'Daniel Harkins'" Subject: ISAKMP/Oakley algorithms Date: Wed, 15 Jan 1997 15:05:44 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-ietf-ipsec-isakmp-oakley-02.txt it lists encryption and hash algorithms that are not listed with draft-ietf-ipsec-doi-02.txt (IDEA, Blowfish, Tiger). Should we try and keep all protocols the same between both levels or at least try and include the same commone core algorithms. Basically, I'd like to see DES3 added to this list as well a reference that points to these other les common algorithms. -------------------- Securing your Internet ------------------------- Roy Pereira TimeStep Corporation rpereira@timestep.com Ottawa, Ontario 613-599-3610 x 4808 http://www.timestep.com From owner-ipsec Wed Jan 15 16:53:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14540 for ipsec-outgoing; Wed, 15 Jan 1997 16:51:20 -0500 (EST) Date: Wed, 15 Jan 1997 16:53:50 -0500 Message-Id: <9701152153.AA01140@ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: isakmp-oakley@cisco.com, ipsec@tis.com From: Naganand Doraswamy Subject: Key Material Sender: owner-ipsec@ex.tis.com Precedence: bulk When we negotiate Key Material using Oakley QM, we could negotiate for both ESP and AH using two proposals under the same SA payload. The keying material we come up with is the same as they are not in separate SA payload. Once we come with a keying material, we dont say how the proposals will use them for generating keys. Should we be worried about wierd interaction between authentication and encryption algorithms if both end up using the first few bits of the key material. If this is an issue, then we should probably say that for each proposal we will come up with different keying materail as we do in the case of multiple SA's. Comments? Naganand From owner-ipsec Wed Jan 15 18:49:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15080 for ipsec-outgoing; Wed, 15 Jan 1997 18:47:53 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: SA payloads and Next payload Date: Wed, 15 Jan 1997 18:46:22 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello All, Could those in the know please clarify the next payload for SA payloads. In the examples it is always set to PROPOSAL, but from the wording of the ISAKMP doc it suggests otherwise and my opinion is that it should be otherwise, the next NON SA related payload ( ie in aggresive mode it would be KE, NONE for Main Mode). Section 4.1 SA Establishment (Page 41 first paragraph) ..."An SA establishment message consists of a single SA payload followed by AT LEAST one and possible many proposal and transform payloads." so there isn't a need to look to the next payload of the SA header to know that the data in the SA payload is in fact a proposal. Since this is in the ISAKMP doc I would assume that this would have to hold up across any DOI. Section 4.1 SA Establishment (Page 42 first paragraph) ..."Note that the Next Payload field of the proposal payload points to another Proposal (if it exists)." same section last paragraph ..."Note that the Next Payload field of the Transform payload points to another Transform payload or 0." So if we can't get it from the proposal or transform(which I don't think would be a good idea anyways) then we have to get it from the SA header. Thanks. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com From owner-ipsec Wed Jan 15 19:17:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15217 for ipsec-outgoing; Wed, 15 Jan 1997 19:16:54 -0500 (EST) Date: Wed, 15 Jan 1997 19:19:06 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199701160019.TAA02181@earth.hpc.org> To: naganand@ftp.com Cc: ipsec@tis.com, isakmp-oakley@cisco.com In-reply-to: Yourmessage <9701152153.AA01140@ftp.com> Subject: Re: Key Material Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmmm. I suppose you could include the key from the previous proposal as input to the hash for computing the key for the current proposal. Hilarie From owner-ipsec Thu Jan 16 08:22:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA18977 for ipsec-outgoing; Thu, 16 Jan 1997 08:17:58 -0500 (EST) Date: Thu, 16 Jan 97 08:29:52 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9701161329.AA27488@dolphin.ncsc.mil> To: ipsec@tis.com, carterg@entrust.com Subject: Re: SA payloads and Next payload Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, The Last Call for ISAKMP has completed. I am working on making editorial changes based on comments from several people. Here's the latest on your question, so feel free to let me know if you (or anyone) disagrees. > Could those in the know please clarify the next payload for SA > payloads. In the examples it is always set to PROPOSAL, but from the > wording of the ISAKMP doc it suggests otherwise and my opinion is that > it should be otherwise, the next NON SA related payload ( ie in > aggresive mode it would be KE, NONE for Main Mode). The Next Payload field of an SA payload will point to the next payload of the message (if one exists) and not to the Proposal payload as version 6 of the draft specifies. > Section 4.1 SA Establishment (Page 41 first paragraph) > ..."An SA establishment message consists of a single SA payload followed > by AT LEAST one and possible many proposal and transform payloads." > > so there isn't a need to look to the next payload of the SA header to > know that the data in the SA payload is in fact a proposal. Since this > is in the ISAKMP doc I would assume that this would have to hold up > across any DOI. Correct. > Section 4.1 SA Establishment (Page 42 first paragraph) > ..."Note that the Next Payload field of the proposal payload points to > another Proposal (if it exists)." > > same section last paragraph > ..."Note that the Next Payload field of the Transform payload points to > another Transform payload or 0." > > So if we can't get it from the proposal or transform(which I don't think > would be a good idea anyways) then we have to get it from the SA header. Correct. Regards, Doug From owner-ipsec Thu Jan 16 12:30:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20189 for ipsec-outgoing; Thu, 16 Jan 1997 12:20:55 -0500 (EST) Message-Id: <199701161724.JAA00461@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: Re: ISAKMP/Oakley algorithms In-Reply-To: Your message of "Wed, 15 Jan 1997 15:05:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 09:24:14 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In draft-ietf-ipsec-isakmp-oakley-02.txt it lists encryption and hash > algorithms that are not listed with draft-ietf-ipsec-doi-02.txt (IDEA, > Blowfish, Tiger). Should we try and keep all protocols the same between > both levels or at least try and include the same commone core > algorithms. Those algorithms are used to protect ISAKMP-ISAKMP communication and are not bound by the IPsec DOI. Ideally, a draft-ietf-ipsec-isakmp-oakley-02.txt compatible peer can negotiate more than just IPsec. I don't want to remove these algorithms to "keep all protocols the same" but that goal can also be realized by writing an AH-Tiger-HMAC document, and an ESP-IDEA-CBC-REPLAY-et-al document, etc. (insert emoticon here). > Basically, I'd like to see DES3 added to this list as well a reference > that points to these other les common algorithms. Applied Cryptography references IDEA and Blowfish. I can add a reference to Tiger. Dan. ------------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (408) 526-4952 San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W ------------------------------------------------------------------------------- For your safety and the safety of others: concealed carry, and strong crypto ------------------------------------------------------------------------------- From owner-ipsec Thu Jan 16 12:35:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA20256 for ipsec-outgoing; Thu, 16 Jan 1997 12:31:26 -0500 (EST) Message-Id: <2.2.32.19970116173456.00b51d70@mailhost> X-Sender: jtardo@mailhost X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 09:34:56 -0800 To: wdm@epoch.ncsc.mil (W. Douglas Maughan) From: Joe Tardo Subject: Re: SA payloads and Next payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:29 AM 1/16/97 EST, you wrote: >The Last Call for ISAKMP has completed. Doug: When did this happen, and on which mailing list? Thanks, Joe From owner-ipsec Thu Jan 16 14:14:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20956 for ipsec-outgoing; Thu, 16 Jan 1997 14:11:15 -0500 (EST) Date: Thu, 16 Jan 97 19:06:16 GMT Standard Time From: Ran Atkinson Subject: IPsec WG Last Call over To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Just a reminder... The IPsec WG Last Call period for ISAKMP/Oakley ended as scheduled during the first week of January and is now over. There were a number of editorial clarifications requested and the editors are now off making those editorial changes to their drafts. I anticipate that revised drafts will appear online soon. Anyone who has any remaining editorial suggestions should send those directly to the appropriate document editor(s) immediately. As reminder to folks not familiar with IETF procedures, I'll mention that unlike ANSI/IEEE there is no requirement for a formal response to each input sent to the list or to the co-chairs because we aren't tallying votes or voting. Each input is, however, considered. Paul and I are comparing notes in case someone sent mail to one of us but not to the other of us. Result of the Last Call should be out soon to this list. Ran rja@inet.org Co-Chair, IPsec WG From owner-ipsec Thu Jan 16 16:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22087 for ipsec-outgoing; Thu, 16 Jan 1997 16:46:45 -0500 (EST) Message-Id: <199701162150.NAA00798@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Naganand Doraswamy Cc: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Re: Key Material In-Reply-To: Your message of "Wed, 15 Jan 1997 16:53:50 EST." <9701152153.AA01140@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 13:50:07 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > When we negotiate Key Material using Oakley QM, we could negotiate for both > ESP and AH using two proposals under the same SA payload. The keying > material we come up with is the same as they are not in separate SA payload. > Once we come with a keying material, we dont say how the proposals will use > them for generating keys. Good point. The solution to this problem also convieniently solves another problem: how to force the 2 SA's that result from a single SA negotiation (one inbound, one outbound) to have different keys. The solution is to hash the SPI into KEYMAT using the negotiated hash function. This will be noted in the next version of the draft. regards, Dan. From owner-ipsec Fri Jan 17 11:35:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29697 for ipsec-outgoing; Fri, 17 Jan 1997 11:29:06 -0500 (EST) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" Cc: "'piper@tgv.com'" , "'ipsec@tis.com'" Subject: Inconsistencies between values and field size Date: Fri, 17 Jan 1997 11:26:00 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know if has been pointed out yet, please ignore if it has... ISAKMP Draft 6 Proposal Payloads Protocol ID - 1 octet DOI Draft 2 (Dec 9) The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI. ... The values 4-15360 are reserved to IANA. Values 15361-16384 are reserved for private use. The size of the field in the ISAKMP draft the DOI values don't match up. Easy to fix Proposal Payload # of transforms - 2 octets but look at Transform Payload # Transforms - 1 octet So the max you can send in a proposal is 1 octet worth, therefore change the Protocol ID field to 2 octets and # of Transforms to 1 octet in the Proposal Payload. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com > From owner-ipsec Fri Jan 17 11:52:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00011 for ipsec-outgoing; Fri, 17 Jan 1997 11:51:03 -0500 (EST) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" Cc: "'ipsec@tis.com'" , "'piper@tgv.com'" Subject: dido for transform ID Date: Fri, 17 Jan 1997 11:43:59 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Same problem with transform ID field in Transform payloads and those values given in the DOI for ISAKMP, ESP, and AH transform values. And as I mentioned before the ID Type field for Identification payloads. Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com From owner-ipsec Sun Jan 19 01:46:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA13696 for ipsec-outgoing; Sun, 19 Jan 1997 01:36:43 -0500 (EST) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199701190640.WAA25885@netcom22.netcom.com> Subject: Re: IPsec and TCP To: gnu@toad.com (John Gilmore) Date: Sat, 18 Jan 1997 22:40:08 -0800 (PST) Cc: andrade@netcom.com, karn@qualcomm.com, gnu@toad.com, ipsec@tis.com In-Reply-To: <199701161334.FAA20529@toad.com> from "John Gilmore" at Jan 16, 97 05:34:03 am Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1783 John, > > What's slow about 1 to 2 Mbytes/second? That's faster than Ethernet, > and faster by an order of magnitude than almost everyone's connection > to the Internet (1.5Mbits/sec T1 is the highest common speed). If > you were DES-encrypting main memory accesses, it would be slow; but > if you're DES-encrypting an Ethernet, it's plenty fast. It is slow. 10 Mbit/s Ethernet tops out at around 1.2 Megabytes per second using TCP/IP (assuming no collisions). That 1-2 Megabytes encryption speed means that you are using about 100% of a Pentium's 200 Mhz CPU cycles. Not much room for other processing. On top of that 100 Mbit/s Ethernet is starting to become common. It's will be at least 5 years, assuming Moore's law, before the top Intel chips will be fast enough to keep up with it doing DES. > > Optional hardware assists are quite common on Wintel platforms. The > shrinkwrap software simply probes for the hardware (or its driver). > If it's there, it uses it; if not, it runs slower in software. This > gives individual customers the option to buy the hardware if they > desire more speed. Just like the original poster said. > DES was designed a long time ago to optimize memory over speed. This made a lot of economic sense at the time. Today it doesn't and we are now struggling with it trying to retrofit it into modern high-speed networks. Saying you can throw hardware at it to speed it up doesn't make very much economic sense for most of the hosts on the Internet. Could you imagine how popular TCP/IP would be today if 15 years ago the original designers said that you had to use hardware to get it to operate fast enough? - Alex -- Alex Alten PO Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sun Jan 19 07:46:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15064 for ipsec-outgoing; Sun, 19 Jan 1997 07:42:14 -0500 (EST) Message-Id: Date: Sun, 19 Jan 1997 03:23:57 -0800 (PST) From: Phil Karn To: andrade@netcom.com CC: gnu@toad.com, andrade@netcom.com, ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199701190640.WAA25885@netcom22.netcom.com> (andrade@netcom.com) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >It is slow. 10 Mbit/s Ethernet tops out at around 1.2 Megabytes >per second using TCP/IP (assuming no collisions). That 1-2 >Megabytes encryption speed means that you are using about 100% >of a Pentium's 200 Mhz CPU cycles. Not much room for other >processing. On top of that 100 Mbit/s Ethernet is starting to >become common. It's will be at least 5 years, assuming Moore's law, >before the top Intel chips will be fast enough to keep up with it >doing DES. I again: my own DES code for the Intel family does 16.9 megabits/sec on a 133 MHz Pentium. That should be 25.4 megabits/s on a 200 MHz pentium, so encrypting a 10 Mb Ethernet should leave 60% of your machine for other things -- worst case, when the net is saturated. Now I agree that 1DES is probably no longer sufficient, so these numbers aren't as applicable as they once were. >DES was designed a long time ago to optimize memory over speed. This >made a lot of economic sense at the time. Today it doesn't and we are All the modern fast software DESes, including mine, spend considerable memory to gain speed without sacrificing compatibility. The best example is the combining of the original S (substitution) and P (permutation) boxes into a single lookup table. There is a limit on this technique, however, as you don't want the lookup tables to blow out of the on-chip Pentium cache. But these SP boxes are small enough to fit. One of the interesting moments during the oral arguments the other week in my lawsuit (Karn vs Dept of State) in the DC Circuit Court of Appeals had Judge Douglas Ginsburg reading aloud from the SP initialization table in the Applied Cryptography DES code. He read hex constants like 0x12345678 as "zero times one two three four...". Of course, according to court protocol I could not say anything as I was a mere mortal in the audience... Phil From owner-ipsec Sun Jan 19 23:35:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19173 for ipsec-outgoing; Sun, 19 Jan 1997 23:31:44 -0500 (EST) Message-Id: <9701200435.AA33030@commanche.ca.boeing.com.> To: andrade@netcom.com (Andrade Software Andrade Networking) Cc: gnu@toad.com (John Gilmore), karn@qualcomm.com, ipsec@tis.com Subject: Re: IPsec and TCP In-Reply-To: (Your message of Sat, 18 Jan 97 22:40:08 -0800.) <199701190640.WAA25885@netcom22.netcom.com> Date: Sun, 19 Jan 97 20:35:20 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Just want to throw in my two cents worth of support on your state- ment in general. As Phil points out the numbers may be a bit better than yours, but in general we still seem to have a serious problem with performance with most of the DES-like complex cryptography. When we begin to scale the complex types beyond single user systems, it appears that local encryption engines may be needed to maintain reasonable ratio's of users per server. We have servers that today maintain several hundred simultaneous TCP/IP connections. Ideally within a few years all of these connections would be encrypted. I think as we begin to scale cryptography into supporting systems that support large numbers of simultaneous encrypted connections, performance will be a huge issue. For example, we have a group of proxy servers running SSL and today our code measurements show that they are running past 90% of the time in the encryption routines. In the short term, until we can get encryption engines embedded into (or near) the processors, we may need to make some reasonable choices on the weights of encryption we plan to use. In many cases, reserving heavy weight encryptions like DES for critical/sensitive connections, and using lighter weight cypher solutions to protect less critical ones my make sense. If we can't successfully use strong encryption on all connections, we'd still like to be able to encrypt all of them even if this requires use of lighter encryption forms for some. There's a couple of good reasons to do this: 1) We don't want to make it easy for someone to figure out which connections are important simply because they are the only ones encrypted. 2) If we have all connections encrypted with a mix of encryption types running, an attacker must then expend considerable resources figuring out which type of encryption the connection is protected with before attempting to crack it and then perhaps only to find it was a download of a now out of date weather map. 3) Make casual eavesdropping not quit so casual(i.e Newt). Even very light cyphers, especially if a lot of them are used, would take most of the fun out of eavesdropping with a scanner or sniffer simply by adding an element of work. Hopefully some of the developers/vendors out there will run some scaling tests soon and provide some feedback to the WG on "server" performance. I know some folks are planning to include the encryption engines with their platforms but I'd like to see some raw unassisted numbers on just large servers. It'd be a real help to those of us trying to plan large scale deployment of encryption and perhaps it would prove our performance fears with DES/3DES and similarly complex encryptions unfounded. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | 206-957-5325 | terry.l.davis@boeing.com. | --------------- Sunday January 19,1997 07:51 PM PST ------------- From owner-ipsec Mon Jan 20 10:42:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22794 for ipsec-outgoing; Mon, 20 Jan 1997 10:34:21 -0500 (EST) Message-ID: <32E38F93.284797A9@multinet.net> Date: Mon, 20 Jan 1997 10:30:27 -0500 From: graydon hoare X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2-ALPHA i386) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: IPsec DES slowdown References: <9701200435.AA33030@commanche.ca.boeing.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Terry L. Davis, Boeing Information & Support Services, Bellevue, WA wrote: > and using lighter weight cypher solutions to protect less critical > ones my make sense. If we can't successfully use strong encryption > on all connections, we'd still like to be able to encrypt all of them > even if this requires use of lighter encryption forms for some. I agree -- it's a huge waste to apply the strongest cryptography to everything that runs through your system. 99% of everything placed on an internet server is zero-security, public data. Even if you embed authentication data (eg. signatures) you don't need to make things totally unreadable unless they deal with private property (i.e. cash, secrets). To make things unsnoopable, you just need to make it sufficiently obscure where to snoop. I think you'll get the same atitude from VISA and mastercard: they have realized that it would cost them more to implement some stronger protection scheme across the board than it does to deal with the fraud & stealing. -graydon _______________________________________________________________________ well...you can study all your cranial anatomy charts and read all the textbooks, but y'know... once you get inside it all kinda looks the same Nonono don't touch that -- you never know what it might be attached to -b.banzai From owner-ipsec Mon Jan 20 12:39:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23844 for ipsec-outgoing; Mon, 20 Jan 1997 12:35:53 -0500 (EST) Date: Mon, 20 Jan 1997 11:39:28 -0600 From: jim@hosaka.smallworks.com (Jim Thompson) Message-Id: <199701201739.LAA08199@hosaka> To: andrade@netcom.com, gnu@toad.com Subject: Re: IPsec and TCP Cc: ipsec@tis.com, karn@qualcomm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Could you imagine how popular TCP/IP would be today if 15 years ago >the original designers said that you had to use hardware to get it >to operate fast enough? Well, yeah. I was there, as a matter of fact. No, the original designers didn't state that you needed hardware assist to get TCP/IP to go fast, but there were a lot of companies attempting to get the TCP/IP processing to happen on a board (sometimes the controller board(s) in an effort to make it run faster. Way back, TCP wouldn't come anywhere *near* filling an 10Mbps Ethernet. Then this nice guy named Van (and a few others through history) turned the light on... Jim From owner-ipsec Mon Jan 20 14:27:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24431 for ipsec-outgoing; Mon, 20 Jan 1997 14:23:22 -0500 (EST) Message-Id: <199701201924.LAA18380@dns1.ConsumerInfo.Com> Comments: Authenticated sender is From: "Wayne Yu" Organization: ConsumerInfo.Com, Inc. To: ipsec@tis.com, graydon hoare Date: Mon, 20 Jan 1997 11:26:36 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IPsec DES slowdown Reply-to: wyu@ConsumerInfo.Com In-reply-to: <32E38F93.284797A9@multinet.net> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Mon, 20 Jan 1997 10:30:27 -0500 > From: graydon hoare > To: ipsec@tis.com > Subject: Re: IPsec DES slowdown > Terry L. Davis, Boeing Information & Support Services, Bellevue, WA > wrote: > > > and using lighter weight cypher solutions to protect less critical > > ones my make sense. If we can't successfully use strong encryption > > on all connections, we'd still like to be able to encrypt all of them > > even if this requires use of lighter encryption forms for some. > > I agree -- it's a huge waste to apply the strongest cryptography to > everything that runs through your system. 99% of everything placed on an > internet server is zero-security, public data. Even if you embed > authentication data (eg. signatures) you don't need to make things > totally unreadable unless they deal with private property (i.e. cash, > secrets). To make things unsnoopable, you just need to make it > sufficiently obscure where to snoop. I think you'll get the same atitude > from VISA and mastercard: they have realized that it would cost them > more to implement some stronger protection scheme across the board than > it does to deal with the fraud & stealing. > > -graydon > > _______________________________________________________________________ > well...you can study all your cranial anatomy charts and read all the > textbooks, but y'know... once you get inside it all kinda looks the same > Nonono don't touch that -- you never know what it might be attached to > -b.banzai > > > There is a compnay called Rainbow Technologies. They lcoated in Irvine California. They provide a hardware encrytion solution for this problem. Can somehow the hardware solution and software solution combind together? Wayne Yu, Director of Technology ConsumerInfo.Com, Inc. Phone (714)978-0078 ext. 1010 Fax (714)978-0059 We provide personal credit information, visit us at http://www.consumerinfo.com From owner-ipsec Tue Jan 21 05:34:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA28944 for ipsec-outgoing; Tue, 21 Jan 1997 05:31:26 -0500 (EST) Message-Id: <199701211032.CAA04544@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: wyu@ConsumerInfo.Com cc: ipsec@tis.com, graydon hoare , gnu@toad.com Subject: Re: IPsec hardware accelerators (Rainbow warning) In-reply-to: <199701201924.LAA18380@dns1.ConsumerInfo.Com> Date: Tue, 21 Jan 1997 02:32:41 -0800 From: John Gilmore Sender: owner-ipsec@ex.tis.com Precedence: bulk > There is a compnay called Rainbow Technologies. They lcoated in Irvine > California. They provide a hardware encrytion solution for this problem. > Can somehow the hardware solution and software solution combind together? Thanks for the pointer. One "hardware encryption solution" Rainbow provides is the Clipper Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its follow-on products are not compatible with the IPSEC protocols, because they use an undocumented encryption algorithm and because they are designed to undermine rather than provide secure operation. Rainbow's Mykotronx "Internet Security Group" also offers a "CryptoSWIFT" PCI board that accelerates public-key protocols. This board might be useful for the high-level IPSEC key agreement protocol. It isn't advertised to help with the low-level packet encryption, though their beta-site form says they'll add DES and 3DES in 1997. The board is now in alpha or beta test. However, Rainbow's press release of December 12th announces support for the "Key Recovery Alliance" and specifically mentions the board. That and their long history with Clipper and NSA mean that company statements that the board provides "Secure key generation and storage" should be taken with a large grain of salt. It's much harder to validate the security of the guts of an ASIC than it is to validate a software key generator. And you can easily compare the binary of the production key generator code to your validated version, while you can't examine the guts of each ASIC except by physically destroying it. Techniques are known for "leaking" private keying information from a subverted cryptographic processor chip, in ways that cannot be detected except by eavesdroppers who know the secrets embedded in the chip. Rainbow/Mykotronx have a long history of collaboration with NSA on classified projects designed to subvert the information security of users. Rainbow's 1996 Q3 10-Q form (www.sec.gov) notes: Revenues from information security products [Mykotronx - gnu] for the three and nine months ended September 30, 1996 remained consistent and increased by 6%, respectively, when compared to the same periods in 1995. The Company continued to experience low growth rates due to the slower than anticipated deployment of network security products within the government. I.e. Clipper/Capstone/Fortezza aren't proving to be popular products. Gross profit from information security products for both the three months and the nine months ended September 30, 1996 was 19% and 16% of revenues compared with 21% and 23%, respectively, for the corresponding periods in 1995. The decrease in gross margin was due to the change of mix from predominantly product contracts to principally less profitable research and development contracts. These R&D contracts might well include research on building chips that "leak" private information. Such features would be relatively easy to transfer from Fortezza chips into chips that do standard public-key algorithms. (See also the Baltimore Sun articles from December 3-13, 1995, on how NSA subverted Swiss company Crypto AG's products for many years. Senior Crypto AG officials stated throughout that their products were secure and untampered.) It *may* be possible to use untrustworthy chips to build secure systems, if you only use documented encryption algorithms and don't use the chips to generate any keys or random numbers. A first step would be to only use such chips for predictable (software-duplicatable) operations, and check some tiny percentage of the transactions by rerunning them in software. The chip may still be subverting your security in other ways (e.g. broadcasting your private key at radio frequencies on unused pins in the hope that a spook with TEMPEST monitoring gear is nearby). If any working group members know of useful hardware crypto accelerators available from non-US companies (for the world market), please let me know. I'd like to see hardware acceleration supported, but not using US-only and/or likely-subverted products. John Gilmore From owner-ipsec Tue Jan 21 08:30:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00238 for ipsec-outgoing; Tue, 21 Jan 1997 08:29:26 -0500 (EST) Date: Tue, 21 Jan 1997 08:31:54 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199701211331.IAA17245@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: IPsec and TCP X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: andrade@netcom.com (Andrade Software Andrade Networking) > > DES was designed a long time ago to optimize memory over speed. This > made a lot of economic sense at the time. Today it doesn't and we are > now struggling with it trying to retrofit it into modern high-speed > networks. NIST has begun the process of selecting a replacement for DES which would be more suited to today's environment. They are now looking for public comments on the criteria by which the Advanced Encryption Standard (AES) will be selected; comments are due by April 2, and will be followed by a public selection criteria workshop on April 15. Here's an excerpt from the announcement, more info can be found at http://www.nist.gov/public_affairs/current.htm. > PROPOSED DRAFT MINIMUM ACCEPTABILITY REQUIREMENTS AND EVALUATION > CRITERIA > > The draft minimum acceptability requirements and evaluation criteria > are: > > A.1 AES shall be publicly defined. > > A.2 AES shall be a symmetric block cipher. > > A.3 AES shall be designed so that the key length may be increased as > needed. > > A.4 AES shall be implementable in both hardware and software. > > A.5 AES shall either be a) freely available or b) available under > terms consistent with the American National Standards Institute (ANSI) > patent policy. > > A.6 Algorithms which meet the above requirements will be judged based > on the following factors: > > a) security (i.e., the effort required to cryptanalyze), > b) computational efficiency, > c) memory requirements, > d) hardware and software suitability, > e) simplicity, > f) flexibility, and > g) licensing requirements. > > Comments are being sought on these draft minimum acceptability criteria > and evaluation criteria, suggestions for other criteria, and relative > importance of each individual criterion in the evaluation process. > Criteria will be finalized by NIST following the criteria workshop. From owner-ipsec Tue Jan 21 13:04:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02060 for ipsec-outgoing; Tue, 21 Jan 1997 12:56:56 -0500 (EST) Message-Id: <3.0.32.19970121124325.00a389e0@datasec.net> X-Sender: korinne@datasec.net X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) X-Priority: 1 (Highest) Date: Tue, 21 Jan 1997 12:43:26 -0500 To: ipsec@portal.ex.tis.com From: korinne@datasec.net (Korinne) Subject: DATANET SECURITY 97 PROGRAM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Conference program Datanet Security 1997 Annual International Conference and Exhibition on Wide Area Network Security FEBRUARY 17 - 18 - 19 - 20, 1997 HYATT REGENCY MIAMI HOTEL & CONVENTION CENTER All lectures and presentations have been confirmed Keynote speakers: Monday February 17, 1997 The 1997 Datanet Security conference will be opened with a keynote address by Dr. Ruth A. David, Deputy Director Science & Technology of the Central Intelligence Agency. Following the opening address, Mr. Stuart A. Baker will deliver a keynote speech "Legal Aspects of Network Security". Stuart Baker is partner with Steptoe & Johnson in Washington DC, and former lead counsel for the National Security Agency. Keynote speakers: Tuesday February 18, 1997 The second day of the Annual Datanet Security Conference is highlighted with a presentation by Dr. Rob Kolstad "Non-Security Issues Affecting the Future of the Internet". Rob Kolstad is President of BSDI Inc. "What's Slowing down Deployment of Security ?" is the title of the next keynote address by Novell's Chief Security Architect, Dr. Radia Perlman. She was featured in the 20th anniversary edition of Data Communications magazine as one of 20 most influential people in the field of computer networking. Keynote speaker: Wednesday February 19, 1997 This conference day we feature Mr. Scott Charney as a prominent keynote speaker. Scott Charney is the principal government authority on computer crime. He heads the federal prosecutors and leads the Computer Crime and Intellectual Properties Section within the Department of Justice. ADVANCED TECHNOLOGY PROGRAM Monday February 17, 1997 ELECTRONIC INTELLIGENCE "Intelligence Behind the Journal Intelligence" - Olivier Schmidt Olivier Schmidt is founding editor of several important international professional news journals and expert publications. Among these "Parapolitics", "Intelligence Newsletter" and "Intelligence". He co-authored "Intelligences Secretes" and "OSS et la Resistance Francaise". He lives and works in Paris, France. "The King of Secret Readers: Edgar Allen Poe, William Friedman, and the Logic of the Cold War" - Professor Shawn Rosenheim Shawn J. Rosenheim is Associate Professor of English at Williams College (Williamstown, Mass.), and a founding member of the Communications Technologies Research Group. His most recent publication is "The Cryptographic Imagination: Secret Writing from Edgar Poe to the Internet" (Johns Hopkins University Press, 1996) DISCUSSION PANEL Traditional versus New Technologies: A Challenge for the Intelligence Communities Session and Panel Chairman - David Whipple David Whipple is Executive Director of the Association of Former Intelligence Officers, AFIO. As no other Mr. Whipple is able to illustrate the traditional methods of information gathering. INTERNET SECURITY The Changing Role of the Firewall - Stephen Flaig Mr. Flaig is Vice President for LanOptics Inc., developers of the Guardian firewall. Network Access Flexibility through RADIUS - David Dawson David Dawson is General Manager Network Security Business Unit for Ascend Communications Inc. Previously he was Chief Executive Officer of Morningstar Technologies Inc. He holds a BS in Electrical Engineering from the US Military Academy at West Point. Internet Security and the IBM Firewall - Peter Crotty Peter Crotty is worldwide responsible for IBM's technical firewall support program. Secure Access: If you don't have security everywhere, you don't have it anywhere ! - Doug LaBorde Mr. LaBorde is Manager with the Network Security Business Unit of Ascend Communications. NT SECURITY Windows NT Security: Networked Perspectives - Charles Rutstein Charles Rutstein is Principal Consultant with Price Waterhouse, and has extensive front line computer and network security experience. He authored several books on computer viruses. His latest work, dealing with Windows NT security, has just been released. NT Internet Security - Firewalls, Web-servers, and Vulnerabilities - Bill Stout Bill Stout is network security analyst and senior systems administrator with Hitachi Data Systems. He specializes in Windows NT security issues. VIRUSES Viruses and the Internet; email, Java, Active-X; the new virus carriers - Thierry Giron Thierry Giron holds a Computer Science Hon. degree from Middlesex University (London, UK), and a Business degree from ESC in Reims, France. He joined Trend Micro in Taiwan in 1992, and is since Trend's Customer Engineering Manager for the North American offices. Minimizing the Virus Threat - Glenn Jordan Glenn Jordan is the leading virus technology expert with Dr. Solomon, and is an established member of the Computer Anti-virus Research Organization, an international network of anti-virus researchers. Mr. Jordan is a graduate of the University of North Carolina. Tuesday February 18, 1997 INTERNET SECURITY Cyber Thieves - Gregg Lebovitz Gregg Lebovitz is Director of Security Products at BBN Planet. Mr. Lebovitz spent 15 years at Carnegy-Mellon University, designing, implementing and deploying network routers and distributed applications. Accounting for Square-Root Attacks in Cryptographic Design - Michael Wiener Michael Wiener is senior cryptologist with Entrust Technologies (formerly Nortel Secure Networks). His expertise is in the area of cryptanalysis, authentication, and key-exchange protocols, public-key infrastructures, design of cryptographic systems, and high-speed implementations of public-key cryptosystems. He is agraduate of the University of Waterloo (Canada). Virtual Private Networking: Integrating Internet and Intranet Security - Tony Rosati Tony Rosati is co-founder and Vice President for TimeStep Corporation. He leads design teams ranging from the development of public-key and DES based integrated circuits to the development of system level communications security solutions utilizing cryptographic techniques. Approaching End-to-End Security - Paul Ferguson Paul Ferguson is a senior expert with Cisco Systems. His principal disciplines are Internet security, large-scale routing and design architecture. NETWORK SECURITY Assurance in Products for the Internet - Alan Borrett Alan Borrett is member of the UK IT Evaluation & Certification Scheme, under authority of Her Majesty's Government Communications Headquarters (GCHQ) Computer Security in the Third World: The Mexican Case - Prof. Guillermo Mallen Professor Mallen teaches and researches at the Ibero-Americana University in Mexico. He is a former President of the Mexican Academy of Informatics. Single Point Security: The Unisys Vision for Enterprise Security Administration - William Buffam William Buffam is software architect with Unisys Corp. His background is in operating systems, networking, and solution engineering. He holds a Computer Science degree from the University of Manchester. Security Solutions for the Internet - Eli Herscovitz Mr. Herscovitz is founder of RadGuard Ltd., provider of secure datanetwork systems. He chairs the Networking Security Standardization Committee of the Standards Institute of Israel. TUTORIAL Hacker Tools & Techniques and Intrusion Testing - A dual presentation by Edward Skoudis and Cynthia Cullen Cynthia Cullen is a senior consultant with Bell Communications Research Security and Fraud Management. Edward Skoudis is a senior expert in network security issues with Bellcore's Navesink Research Center. Wednesday February 19, 1997 COMPUTER CRIME Network Security's Future - Glenn Gianino Glenn Gianino is Vice President of Advanced Technology with Computer Associates International. His responsibilities included all systems software and hardware including micro, midrange, and mainframe systems, as well as all networking, SNA, wide area networks and Internet services. His most recent assignment involves networking security on all platforms and operating systems. Mining the Information Klondike: CINet, a tool to fight organized crime - Robert Heibel Robert Heibel is Director of the research/intelligence analyst program at Mercyhurst College (PA). A 25-year veteran of the Federal Bureau of Investigation, he served as its Deputy Chief of Counterterrorism. Mr. Heibel is also Executive Director of the Center for Information Research, Analysis, and Training at Mercyhurst. Mr. Heibel is a graduate of Georgetown University. Digital Cash is hard to regulate - Prof. Michael Froomkin Professor Michael Froomkin is associate professor at the University of Miami, School of Law at Coral Gables. He specializes in Internet law and related aspects. Professor Froomkin is a graduate of the Yale Law School, and has a M.Phil. in history of international relations from Cambridge University (UK). He is a Fellow of the Cyberspace Law Institute. Smart Cards: the Coming Wave - James Chen James Chen is founder and President of V-One Corp., a provider of network and internetwork security solutions. Previously Mr Chen was head of the ground network engineering division for Intelsat, responsible for satellite launches. Electronic Commerce on the Internet - Tom Carty Tom Carty is Director of CyberTrust, a division of GTE. Mr. Carty was responsible for the information security privacy organization and architecting key management systems with GTE. He is a graduate of the University of Connecticut and Boston University. ATM: An Emerging Network Technology - Michael Guzelian Michael Guzelian has over 15 years experience in and knowledge of authentication, bandwidth-on-demand, and security issues that face large public networks. DISCUSSION PANEL High Integrity/Mission Critical Systems Session and Panel Chairman - Donald L. Evans Presentations by: Donald Evans, Timothy Stacey and Robert Smock Donald Evans is senior security engineer and senior member of the Johnson Space Center Mission Operations Directorate AIS Security Engineering Team, providing assistance to NASA in developing and maintaining the IS security program for the Space Station and Shuttle ground based programs. He is an advisory board member for the NSA Systems Security Engineering Capability Maturity Model, and a member of the Presidential Sub-committee of the US Security Policy Board. Timothy Stacey was involved with security development for NASA's Space Shuttle and Space Station programs and software engineering in support of NASA and the US Air Force Space Command Systems. He is currently a information security expert with SAIC Space Operations. Robert Smock is head of Flight Operations Information Security Program at United Space Alliance, responsible for providing the primary government contractor support for the protection of NASA's ground-based information resources, which support Space Shuttle and Space Station flight operations at the Johnson Space Center in Houston, Texas.Mr Smock holds a degree in Computer Science. TUTORIAL Network Security: PRIVATE Communication in a PUBLIC World Dr. Radia Perlman and Charlie Kaufman Radia Perlman is Chief Security Architect for Novell, Inc. She is known for the invention of the spamming tree algorithm used by bridges, and many of the algorithms used for routing, including the design of a network that can withstand a denial of service attack. She is the author of two textbooks. She has a PhD from MIT. Charlie Kaufman is security architect for Lotus Notes/Domino. He is the chair of the web transaction security working group of the IETF. He is on the National Academy of Sciences expert panel on computer system trustworthiness. He is coauthor with Radia Perlman, of the book "Network Security: Private Communications in a Public World". Thursday February 20, 1997 INTERNET SECURITY Fighting Piracy on the Net - Peter Beruk Peter Beruk is Director of Domestic Anti-Piracy with the Software Publishers Association. Internet and Server Security - Joshua Peleg Joshua Peleg is the Director of Technical services with Memco Software. Mr. Pelegs expertise is in security, disaster recovery and system level programming. Joshua gained much of his experience while in the Israeli military defense forces. Is your Company a Hackers Help Desk ? - Steve Ritger Steve Ritger is security engineer with SRA International. His expertise is information and network security as well as fraud detection and prevention. JAVA SECURITY Security and "Live" content: A Java Perspective - Peter Coffee Peter Coffee is advanced technologies analyst for PC Week Labs. He has taught information systems management, management science and expert systems development for Pepperdine University, Chapman College, and UCLA. He is the author of "How to program Java". Mr. Coffee is a graduate of MIT and Pepperdine University. TUTORIAL World Wide Web Security Arthur Donkers Arthur Donkers is founder of Le Reseau, an independent security consulting firm in The Netherlands (Europe). He is a graduate of Delft University of Technology, and holds a degree in Electrical Engineering. He authors a monthly column on system administration and security aspects in SysAdmin Magazine. ------------0---------------- Datanet Security 97 is sponsored by the National Association of Webmasters, SysAdmin Magazine, Sprint, and CMP Network Computing Magazine. ---------------------------0-------------------------- Participation in Datanet Security 97 is $ 845. This includes admission to all conference sessions, tutorials and discussion panels, as well as lunches during the four days, a banquet, and a cruise to the Bahama islands (including breakfast, lunch, dinner and show). You can pay on-line via a secure web transaction with all major credit cards. A special hotel arrangement has been made with Hyatt Regency Miami, making discounted room rates available to all participants. The web page with full information is available at http://www.datasec.net Alternatively you can fax 941 775 1533, or email ds97@datasec.net. ========================================================================= From owner-ipsec Tue Jan 21 17:36:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03791 for ipsec-outgoing; Tue, 21 Jan 1997 17:34:14 -0500 (EST) Date: Tue, 21 Jan 97 22:34:15 GMT Standard Time From: Ran Atkinson Subject: Re: DATANET SECURITY 97 PROGRAM To: ipsec@portal.ex.tis.com, Korinne X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970121124325.00a389e0@datasec.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk It is not appropriate use of the IPsec WG mailing list to post conference announcements of that sort. Please refrain from doing so in future. Thank you, Ran rja@inet.org Co-chair, IP Security WG, IETF From owner-ipsec Wed Jan 22 07:32:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA13218 for ipsec-outgoing; Wed, 22 Jan 1997 07:30:02 -0500 (EST) Message-Id: <199701221230.HAA13218@portal.ex.tis.com> From: "John Chalk" Organization: DSI Pty Ltd To: gnu@toad.com Date: Wed, 22 Jan 1997 10:42:01 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: IPsec hardware accelerators (Rainbow warning) Reply-To: John.Chalk%datacraft.com.au@datacraft.com.au Cc: ipsec@tis.com In-Reply-To: X-Mailer: Pegasus Mail for Win32 (v2.50) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > There is a compnay called Rainbow Technologies. They lcoated in > > Irvine California. They provide a hardware encrytion solution for > > this problem. Can somehow the hardware solution and software > > solution combind together? > > Thanks for the pointer. > > One "hardware encryption solution" Rainbow provides is the Clipper > Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its > follow-on products are not compatible with the IPSEC protocols, > because they use an undocumented encryption algorithm and because > they are designed to undermine rather than provide secure operation. > > . . . much discussion of Rainbow snipped > > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > > John Gilmore > Not a working group member, but an interested lurker. A couple of years ago I worked on a project where we did application level encryption for a networked financial system using public nets, (actually the Aus. stock exchange) and we used a PC hardware card from a firm called Eracom. I don't know what the current range of products is, but last I heard they were doing a lot of stuff for banks with ATM traffic and such. They are located on the Gold Coast in Queensland, Australia and the contact info I have for them is: Tel: +61 (7) 5593 4911 Fax: +61 (7) 5593 4388 Telex: AA43943 The cards were available for well under $A1K and the technical support was great. -- John Chalk, Software Engineer, DSI Pty Ltd Tel: +61 (7) 3371 7655 Fax: +61 (7) 3870 5647 John.Chalk@datacraft.com.au From owner-ipsec Wed Jan 22 12:25:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15939 for ipsec-outgoing; Wed, 22 Jan 1997 12:20:07 -0500 (EST) Message-Id: <01BC085F.389F2380@erussell-2.ftp.com> From: "Edward A. Russell" To: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Negotiated Hash Algorithms in ISAKMP/OAKLEY Date: Wed, 22 Jan 1997 12:24:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Is this a correct interpretation of the ISAKMP/OAKLEY spec: All hashes used in messages and keying material are the NATIVE form of the negotiated hash algorithm which is either MD5 or SHA The ONLY time the HMAC version of MD5 or SHA is used is during the Oakley Phase1 authentication (specifically, in authentication with a pre-shared key, the HASH_I and HASH_R will be the HMAC version of MD5 or SHA depending on what was negotiated). Correct? (If I am incorrect and you can actually negotiate to use HMAC MD5 or NATIVE MD5 for example, then what is the Oakley number for that, does it need to be supported, and what would you use during authentication? The HMAC version of HMAC MD5 for example?????) Edward Russell erussell@ftp.com From owner-ipsec Wed Jan 22 13:01:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16207 for ipsec-outgoing; Wed, 22 Jan 1997 12:58:37 -0500 (EST) Message-Id: <199701221802.KAA05639@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Edward A. Russell" Cc: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Re: Negotiated Hash Algorithms in ISAKMP/OAKLEY In-Reply-To: Your message of "Wed, 22 Jan 1997 12:24:30 EST." <01BC085F.389F2380@erussell-2.ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jan 1997 10:02:12 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Edward, > Is this a correct interpretation of the ISAKMP/OAKLEY spec: > > All hashes used in messages and keying material are the NATIVE form of > the negotiated hash algorithm which is either MD5 or SHA No, they are the HMAC version. > The ONLY time the HMAC version of MD5 or SHA is used is during the Oakley > Phase1 authentication (specifically, in authentication with a pre-shared key, > the HASH_I and HASH_R will be the HMAC version > of MD5 or SHA depending on what was negotiated). > > Correct? Anytime you see prf it generally refers to the HMAC version of the negotiated hash function (negotiable pseudo-random functions are coming, but for now just assume prf=HMAC). These are used for mostly all hashing functions: authentication purposes and generation of key blobs (in phase1 and phase2). The only place where the native mode of the negotiated hash function is used is to generate the IV (in appendix B). > (If I am incorrect and you can actually negotiate to use HMAC MD5 or > NATIVE MD5 for example, then what is the Oakley number for that, does it > need to be supported, and what would you use during > authentication? The HMAC version of HMAC MD5 for example?????) You don't negotiate HMAC or native forms you just negotiate H: the hash function. That is then used in both native and HMAC modes. For authentication you'd use a prf (aka the HMAC version of your negotiated H) to generate a hash. That either directly authenticates the exchange or it is signed, and verified depending on your authentication method (the negotiated A, from E-H-A: encryption-hash-authentication). Dan. From owner-ipsec Wed Jan 22 16:17:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17609 for ipsec-outgoing; Wed, 22 Jan 1997 16:14:10 -0500 (EST) Message-Id: <3.0.32.19970122131705.0097aae0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 13:17:07 -0800 To: John.Chalk%datacraft.com.au@datacraft.com.au From: Bob Monsour Subject: Re: IPsec hardware accelerators (Rainbow warning) Cc: gnu@toad.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming chips will include encryption (DES/3DES/RC4) as well as compression and MAC computation (SHA/MD5). For those concerned about the processing requirements of software DES, note that the use of compression prior to encrypting reduces the workload placed on the encryptor. I included some experimental results at the Dec IPSEC wg meeting. Bob Monsour rmonsour@earthlink.net At 10:42 AM 1/22/97 +1000, John Chalk wrote: > >> > There is a compnay called Rainbow Technologies. They lcoated in >> > Irvine California. They provide a hardware encrytion solution for >> > this problem. Can somehow the hardware solution and software >> > solution combind together? >> >> Thanks for the pointer. >> >> One "hardware encryption solution" Rainbow provides is the Clipper >> Chip. (Rainbow bought Mykotronx in 1985.) The Clipper Chip and its >> follow-on products are not compatible with the IPSEC protocols, >> because they use an undocumented encryption algorithm and because >> they are designed to undermine rather than provide secure operation. >> >> . . . much discussion of Rainbow snipped >> >> If any working group members know of useful hardware crypto >> accelerators available from non-US companies (for the world market), >> please let me know. I'd like to see hardware acceleration >> supported, but not using US-only and/or likely-subverted products. >> >> John Gilmore >> > >Not a working group member, but an interested lurker. > >A couple of years ago I worked on a project where we did application >level encryption for a networked financial system using >public nets, (actually the Aus. stock exchange) and we used a PC >hardware card from a firm called Eracom. I don't know what the >current range of products is, but last I heard they were doing a lot >of stuff for banks with ATM traffic and such. They are located on the >Gold Coast in Queensland, Australia and the contact info I have for >them is: Tel: +61 (7) 5593 4911 Fax: +61 (7) 5593 4388 > Telex: AA43943 >The cards were available for well under $A1K and the technical >support was great. > >-- >John Chalk, Software Engineer, DSI Pty Ltd >Tel: +61 (7) 3371 7655 Fax: +61 (7) 3870 5647 >John.Chalk@datacraft.com.au > > > > From owner-ipsec Thu Jan 23 07:20:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22226 for ipsec-outgoing; Thu, 23 Jan 1997 07:16:41 -0500 (EST) Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com In-reply-to: <199701221230.HAA13218@portal.ex.tis.com> (John.Chalk%datacraft.com.au@datacraft.com.au) Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 07:20:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22263 for ipsec-outgoing; Thu, 23 Jan 1997 07:20:40 -0500 (EST) From: owner-ipsec@ex.tis.com Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com In-reply-to: <199701221230.HAA13218@portal.ex.tis.com> (John.Chalk%datacraft.com.au@datacraft.com.au) Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 07:50:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22714 for ipsec-outgoing; Thu, 23 Jan 1997 07:50:11 -0500 (EST) Date: Wed, 22 Jan 1997 15:07:02 -0800 (PST) Message-Id: <199701222307.PAA17588@descartes.veriweb.com> To: ipsec@tis.com CC: gnu@toad.com Subject: Re: IPsec hardware accelerators (Rainbow warning) From: Jeremey Barrett Organization: VeriWeb Internet Corp. Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > If any working group members know of useful hardware crypto > accelerators available from non-US companies (for the world market), > please let me know. I'd like to see hardware acceleration > supported, but not using US-only and/or likely-subverted products. > Lintel (in Belgium) produces DES and RSA chips and ISA bus cards. They also apparently are owned by Vasco Data Security, a U.S. company. Vasco sells Lintel's products in the U.S. Lintel - http://www.lintel.com Vasco - http://www.vdsi.com - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeremey Barrett Senior Software Engineer jeremey@veriweb.com VeriWeb Internet Corp. http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.txt "less is more." -- Mies van de Rohe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMuadfS/fy+vkqMxNAQG9JwP8D8T5kynBxfh6BteJHPOPQUSYlOnD0KeO kbECC7rndohktGdUyi8IE9JhmJ4v8lzZe1d+6NDBxskPQShonXf75YTQdvHYhlbE b/XC7xfKTE3ThX8LeMnb7Xxodko+lUVzMl9vgYBc77bv3aRhiM3VV5zGWSpR0uOP K4Kk/kL+Cnk= =d/NJ -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 23 09:50:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23618 for ipsec-outgoing; Thu, 23 Jan 1997 09:45:16 -0500 (EST) Message-ID: From: Roy Pereira To: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: RE: IPsec hardware accelerators (Rainbow warning) Date: Thu, 23 Jan 1997 09:49:21 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk What has been going on with compression in ESP? I haven't heard anything since December's IETF. We talked about adding a byte in front of pad length to represent compression flags (like whether the data was compressed). >---------- >From: Bob Monsour[SMTP:rmonsour@earthlink.net] >Sent: Wednesday, January 22, 1997 4:17 PM >To: John.Chalk%datacraft.com.au@datacraft.com.au >Cc: gnu@toad.com; ipsec@tis.com >Subject: Re: IPsec hardware accelerators (Rainbow warning) > >Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming >chips will include encryption (DES/3DES/RC4) as well as compression and MAC >computation (SHA/MD5). > >For those concerned about the processing requirements of software DES, note >that the use of compression prior to encrypting reduces the workload placed >on the encryptor. I included some experimental results at the Dec IPSEC wg >meeting. > >Bob Monsour >rmonsour@earthlink.net > > > From owner-ipsec Thu Jan 23 14:28:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25606 for ipsec-outgoing; Thu, 23 Jan 1997 14:19:50 -0500 (EST) Message-Id: <3.0.32.19970123112234.009166c0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Jan 1997 11:22:47 -0800 To: Roy Pereira From: Bob Monsour Subject: RE: IPsec hardware accelerators (Rainbow warning) Cc: "'IETF Security Test mailing list'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In the next day or so, I will be putting together a summary of the compression issues raised at the meeting and making some specific suggestions on direction. I've been meaning to do this, but have been tied up with other things. -Bob At 09:49 AM 1/23/97 -0500, Roy Pereira wrote: >What has been going on with compression in ESP? I haven't heard >anything since December's IETF. We talked about adding a byte in front >of pad length to represent compression flags (like whether the data was >compressed). > > > >>---------- >>From: Bob Monsour[SMTP:rmonsour@earthlink.net] >>Sent: Wednesday, January 22, 1997 4:17 PM >>To: John.Chalk%datacraft.com.au@datacraft.com.au >>Cc: gnu@toad.com; ipsec@tis.com >>Subject: Re: IPsec hardware accelerators (Rainbow warning) >> >>Another encryption hardware vendor is Hi/fn (www.hifn.com). Forthcoming >>chips will include encryption (DES/3DES/RC4) as well as compression and MAC >>computation (SHA/MD5). >> >>For those concerned about the processing requirements of software DES, note >>that the use of compression prior to encrypting reduces the workload placed >>on the encryptor. I included some experimental results at the Dec IPSEC wg >>meeting. >> >>Bob Monsour >>rmonsour@earthlink.net >> >> >> > > From owner-ipsec Thu Jan 23 17:02:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26620 for ipsec-outgoing; Thu, 23 Jan 1997 16:59:54 -0500 (EST) Date: Thu, 23 Jan 1997 17:02:44 -0500 Message-Id: <9701232202.AA16974@ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: isakmp-oakley@cisco.com, ipsec@tis.com From: Naganand Doraswamy Subject: 8 byte aligement in ISAKMP Sender: owner-ipsec@ex.tis.com Precedence: bulk When the ISAKMP packet is not 8 byte aligned, we pad it with zero's to make it 8 byte aligned before we encrypt it during Oakley QM. Some packets require that we calculate hash on the payloads so that the other end can also authenticate us. When we calculate, do we also consider the padding? It is better that we consider the padding as well as it will be easier to verify on the other end. All we have to do is to calculate the length of the data on which to calcuate hash is (payload_len - isakmp header_len - hash payload_len - hash_data_len). We dont have to parse the ISAKMP payload to find out the lenght of the data on which to calculate hash. That way, if the hash fails we can drop the packet immediatly. On the other hand, if we dont use the pad in calculating hash, then the last byte of the hash should represent the lenght of the pad as that will help in calculating the lenght of the data on which to calculate hash. Comments? Naganand From owner-ipsec Thu Jan 23 17:10:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26703 for ipsec-outgoing; Thu, 23 Jan 1997 17:10:22 -0500 (EST) Message-Id: <199701232213.OAA06902@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Naganand Doraswamy Cc: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Re: 8 byte aligement in ISAKMP In-Reply-To: Your message of "Thu, 23 Jan 1997 17:02:44 EST." <9701232202.AA16974@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jan 1997 14:13:10 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand Doraswamy wrote: > When the ISAKMP packet is not 8 byte aligned, we pad it with zero's to make > it 8 byte aligned before we encrypt it during Oakley QM. Some packets > require that we calculate hash on the payloads so that the other end can > also authenticate us. When we calculate, do we also consider the padding? It > is better that we consider the padding as well as it will be easier to > verify on the other end. All we have to do is to calculate the length of the > data on which to calcuate hash is (payload_len - isakmp header_len - hash > payload_len - hash_data_len). We dont have to parse the ISAKMP payload to > find out the lenght of the data on which to calculate hash. That way, if the > hash fails we can drop the packet immediatly. > > On the other hand, if we dont use the pad in calculating hash, then the last > byte of the hash should represent the lenght of the pad as that will help in > calculating the lenght of the data on which to calculate hash. You have to run a sanity check on the ISAKMP payload before you process it anyway (and this processing includes verifying the hash). This check will allow you to determine the true (minus the pad) length of the message. If you don't run a sanity check you'd not only not be compliant with the draft, you'd open yourself up to attack. I could send you a SA offer which contained a TLV attribute with a huge, incorrect size. When you tried to process this you'd jump off into never-never land and most likely crash. The pad is not included in the hash that authenticates quick mode and this shouldn't case anyone any grief since the true size can be determined from normal payload processing-- validate, then process. Dan. From owner-ipsec Thu Jan 23 17:29:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26839 for ipsec-outgoing; Thu, 23 Jan 1997 17:29:24 -0500 (EST) Message-Id: <3.0.32.19970123143228.009826b0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Jan 1997 14:32:30 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Compression in ESP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At the December IETF meeting, the IPSEC working group consensus was to undertake compression as a work item. Recapping the motivation for putting compression in IPSEC: (1) PPP compression will be rendered ineffective on encrypted IPSEC payloads, (2) compression can reduce encryption and MAC processing, (3) compression can reduce the likelihood of packet fragmentation. Two proposals were presented at the meeting and a number of issues were raised regarding the best technical approach to use. I will attempt to summarize the issues that were raised and describe the available alternatives. I comments and suggestions from the group. Note that while no editors have been assigned to this task as of yet, I think it is important to get some input from the working group to keep the process from dying. The April meeting is Memphis will be here before we know it. TWO PROPOSALS 1. Make compression an optional feature of ESP 2. Create a separate (IPSEC independent) transform to support compression METHOD 1: OPTIONAL FEATURE OF ESP DRAFTS: draft-sabin-esp-des3-lzs-md5-00.txt draft-sabin-lzs-payload-00.txt In this method, compression would be added as an optional feature of ESP. The compression algorithm would be determined through KMP negotiation for each connection. It was proposed that a single byte field be used to determine whether or not the payload data is compressed (prior to encrypting). This byte would use a single bit to indicate compressed/not-compressed. Other bits could be assigned in the future to support additional compression functionality. Issue 1: Placement of the single byte field There were significant objections to the proposed placement of the byte at the start of the payload data for word-alignment reasons. Options for placement: 1. Steve Kent suggested that it could be placed at the end of the payload, between the Pad Length and the Payload Type bytes. 2. There was a suggestion that a byte not be used at all, but that an upper bit of the Pad Length field be allocated for this purpose. I recall reading that the padding can be up to 255 bytes (I think this was in the des-cbc-hmac-replay draft), so this would prevent us from using option 2. If that is not the case, then we could indeed use one of those upper bits. I would prefer to have two bits available for possible future use. I'd appreciate input on this. At this time, my recommendation would be to go for option 1 (place a byte between Pad Length and Payload Type). Issue 2: Negotiating compression The only issue here is that ISAKMP and the DOI drafts will need to support the negotiation of a compression algorithm and enabling compression for a specific SA. Given that the working group has decided to proceed with taking up compression as a work item, the necessary changes to the ISAKMP and DOI drafts could be made at any time. METHOD 2: SEPARATE TRANSFORM DRAFT: draft-thayer-seccomp-00.txt In this method, a separate transform is used. It has an overhead of 8 bytes (vs. 1 byte for the ESP optional feature) for each compressed payload. The separate transform has the ability to be used in non-secure environments. PROPOSAL I propose that the working group adopt Method 1. While the Method 1 drafts describe the LZS compression algorithm, the general approach can support any compression algorithm. LZS is a patented algorithm and as such, the proposed draft would ultimately become an Informational RFC. Hi/fn is the owner of the LZS patents and has provided a no-cost license to a C version of the algorithm for use in PPP implementations. Hi/fn has agreed to make a similar license available for IPSEC implementors. Prior to proceeding with additional work on a compression draft, the working group co-chairs must assign an editor or editors to the task. I encourage them to do so in time for a new draft to be produced in time for discussion at the April meeting. Thanks for listening and I look forward to your feedback. Bob Monsour rmonsour@hifn.com From owner-ipsec Mon Jan 27 14:47:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24923 for ipsec-outgoing; Mon, 27 Jan 1997 14:34:11 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: mobile-ip@smallworks.com, ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-ft-req-00.txt Date: Mon, 27 Jan 1997 13:35:25 -0500 Message-ID: <9701271335.aa01593@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Firewall Traversal for Mobile IP: Goals and Requirements Author(s) : V. Gupta, S. Glass Filename : draft-ietf-mobileip-ft-req-00.txt Pages : 10 Date : 01/24/1997 This document discusses problems arising out of the use of Mobile IP in a security conscious Internet and presents a list of solution requirements deemed important. These problems may need to be resolved in several stages. A priority order in which these problems should be solved is also proposed. All firewalls are assumed to implement standard mechanisms [RFCs 1825,1826,1827] for authentication and encryption proposed by the IPSec working group of the IETF. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-ft-req-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ft-req-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ft-req-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970124171433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ft-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ft-req-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970124171433.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jan 29 02:33:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06560 for ipsec-outgoing; Wed, 29 Jan 1997 02:26:55 -0500 (EST) Hops: 0 Host: clinet.fi. Posted-Date: Wed, 29 Jan 1997 09:28:04 -0200 (GMT) Message-Id: <199701290729.JAA12749@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com Subject: Reminder: Release 0.4 of my Linux IPSEC code is out. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 09:29:36 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk A few days ago I released version 0.4 of my Linux IPSEC code. It can be found in ftp://ftp.funet.fi/pub/unix/security/net/ip/. New in this release is support for all the currently defined transforms; of particular interest should be AH-HMAC-SHA1 and ESP-3DES-MD5. Release 0.4 is by no means perfect; it still has to undergo a lot of work before it can be something a nonexpert user can just install and have work right out of the box. For that, I need your help. If you find bugs, please report them; if you can provide a fix, so much the better. The documentation file that comes with the release lists a whole bunch of areas that need work. If you can work on any of these, please tell me so. Please note that in some countries such as the USA, it is unlawful for a citizen of that country to provide technical assistance "with the intent to aid a foreign person in the development or manufacture outside the United States" of "Encryption Items". Also, in countries such as France, it is unlawful to even use cryptography without notifying the authorities. Naturally, I don't expect help from people in the USA or France, but there must be *some* people in the rest of the world who can offer some! /ji From owner-ipsec Fri Jan 31 19:03:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA29573 for ipsec-outgoing; Fri, 31 Jan 1997 18:55:57 -0500 (EST) Hops: 0 Host: tis.com. Date: Sat, 1 Feb 1997 01:55:52 -0200 (GMT) From: John Ioannidis Posted-Date: Sat, 1 Feb 1997 01:55:52 -0200 (GMT) Message-Id: <199702010355.BAA13897@prometheus.hol.gr> To: ietf-sectest@toad.com, ipsec@tis.com Subject: one-time release of IPSEC code for BSDI and NetBSD Sender: owner-ipsec@ex.tis.com Precedence: bulk I've finally released Angelos Keromytis' (kermit@forthnet.gr) port to NetBSD of my old BSDI code, along with features from my Linux release. You can find it in ftp://ftp.funet.fi/pub/unix/security/net/ip/ in a day or so. This is NOT supported code. It may or may not work for you. If you can make it work, fine; if you find bugs AND have a bug-fix, please send me mail about them. Requests for handholding will be silently ignored. USE IT AT YOUR OWN RISK! That said, I hope you find it useful. /ji From owner-ipsec Sun Feb 2 21:21:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12782 for ipsec-outgoing; Sun, 2 Feb 1997 21:13:21 -0500 (EST) Message-Id: <3.0.32.19970202153751.009b8540@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 02 Feb 1997 20:15:33 -0500 To: ji@hol.gr, linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com From: Robert Moskowitz Subject: Re: Reminder: Release 0.4 of my Linux IPSEC code is out. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:29 AM 1/29/97 +0200, John Ioannidis wrote: > >Please note that in some countries such as the USA, it is unlawful for a >citizen of that country to provide technical assistance "with the intent to >aid a foreign person in the development or manufacture outside the United >States" of >"Encryption Items". I think there is a partial 'out'. If a US company is attempting to interoperate with your code and fails, they can point to the part of a public specification related to the failure. Such as our implementations failed to interoperate related to section n.m.o of rfc wxyz. But I am not a lawyer, only heard this explaination 3rd hand from a lawyer. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Mon Feb 3 10:24:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17586 for ipsec-outgoing; Mon, 3 Feb 1997 10:22:36 -0500 (EST) Message-Id: <199702031526.QAA13659@digicash.com> From: "Niels Ferguson" To: Subject: Q: test vectors for HMAC-SHA-1 Date: Mon, 3 Feb 1997 16:27:22 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have implemented HMAC using SHA-1 as hash function. I have found test vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test vectors? If not, I would be happy to help create them. Niels ---------------------------------------------------------------------------- --- Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies) ...Of shoes, and ships, and sealing-wax, of cabbages, and kings, And why the sea is boiling hot, and whether pigs have wings... [Carroll] From owner-ipsec Thu Feb 6 07:56:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10784 for ipsec-outgoing; Thu, 6 Feb 1997 07:41:50 -0500 (EST) Message-Id: <9702060420.AA79343@aurora.cis.upenn.edu> To: ipsec@tis.com Subject: Path MTU Discovery Date: Wed, 05 Feb 1997 23:20:02 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I originally sent this message to Steve Kent, who asked me to forward to the list for comments, corrections etc. Path-mtu discovery breaks in the presence of multiple IPsec encapsulation(*) (it might even break in the presence of ONE intermediate encapsulating entity). We could make a requirement of IPsec that it shouldn't; here's a suggested algorithm: a) a host that does encapsulation and cannot forward the packet due to DF bit set, should send back to the source of the packet (original source or previous encapsulating entity) a normal ICMP, with enough payload length to include the SPI of the packet received. This can be done by copying the first XXX bytes of the packet in a separate buffer/mbuf-chain if the DF bit is set, process it normally, and if it fails send back the ICMP based on the copy kept (so no decapsulation is necessary). b) uppon receipt of an ICMP Unreachable-need fragmentation, if the protocol on the internal header is AH or ESP, validate the destination/SPI pair and keep the value of next_mtu as reported. If a packet arrives that would use this SPI and the size is larger than the mtu value, subtract the overhead this host imposed on the packet and send back an ICMP (as per bullet -a-). c) Alternatively, an IPsec implementation could keep a table with ip_id|SPI sent (a circular buffer of fixed size, preferably dependent on the total speed of the network interfaces) where each time an IPsec packet is sent out, the ip_id and the SPI is kept. Uppon receipt of an ICMP fragneeded, check the ip_id in the internal IP header against the table, and find the relevant SPI. Proceed as per bullet -b-. It might seem complicated, but all it really needs is a little more book-keeping on behalf of an implementation. This still doesn't address the problem of the original TCP mtu (the mtu of the outgoing interface could be less than that reported on the kernel structure, depending on whether a packet will be IPsec'ed or not). But i doubt we can mandate a solution for that. Also, there's the case of whether we accept as valid ICMPs from anyone in between (which means anyone) or just two encapsulating entities (e.g. two tunneling firewalls). The network-correct approach is anyone; the security correct is next enc entity. - -Angelos (*) Steve Kent replied that it shouldn't break for an end host; however, the 4.4BSD TCP code checks the outgoing interface MTU directly to determine the size of the packets, if the route entry does not have an mtu (check tcp_input.c, tcp_mss()). This means that either TCP is patched, or fragmentation will happen. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMvlb8b0pBjh2h1kFAQH4VgP/c6m7K8UqUPbzZImhsUjZj6wRmphKsldP 0TcbhC9Rf7CrZcrG7spjCecM2I+c3hxG04G8r6XeXR9ajY7KqtphUxz+5xDH+B/N /8U44zoNEyVQZbxvzeXSe/U93AIq+sgDcsy1BmGDXMq2MxYTefYIU1QOgTGIv7JT aSG04Yy2vS8= =l0al -----END PGP SIGNATURE----- From owner-ipsec Thu Feb 6 10:56:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11964 for ipsec-outgoing; Thu, 6 Feb 1997 10:53:12 -0500 (EST) Message-Id: <3.0.32.19970206095433.00b2f100@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Feb 1997 09:54:38 -0500 To: "Niels Ferguson" , From: Robert Moskowitz Subject: Re: Q: test vectors for HMAC-SHA-1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote: >I have implemented HMAC using SHA-1 as hash function. I have found test >vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test >vectors? If not, I would be happy to help create them. > No one has actual tests.. But what a lot of us have done is run our HMAC SHA routines over the same data that was included in the HMAC MD5 draft. We've compared our results and most seem to match. I'll post the results when I get back to my office. -Rob Adams Cisco Systems Santa Cruz, CA 95060 From owner-ipsec Thu Feb 6 12:26:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12471 for ipsec-outgoing; Thu, 6 Feb 1997 12:25:14 -0500 (EST) Message-Id: <01BC1429.F844BBC0@localhost> From: Edward Russell To: "'ipsec@tis.com'" Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 12:33:16 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote: >I have implemented HMAC using SHA-1 as hash function. I have found test >vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test >vectors? If not, I would be happy to help create them. > At the interoperability event in Dallas, it appears that the BSAFE SHA is incompatible with the CYLINK SHA. In addition it appears that BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman We compiled our (FTP Software) implementation of ISAKMP with either BSAFE or CYLINK libraries and tested against different vendors and got compatiblity or incompatibility based on which library we compiled with. That being said, I wrote a test program for both SHA and HMAC SHA and compiled it with CYLINK and then with BSAFE. The results are posted below. HMAC KEY = 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b HMAC KEY LENGTH = 16 DATA "Hi There" DATA LENGTH = 8 DIGESTs: BSAFE HMAC SHA: 67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9 CYLINK HMAC SHA: BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3 BSAFE SHA: 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C CYLINK SHA: 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B Edward Russell FTP Software erussell@ftp.com From owner-ipsec Thu Feb 6 13:18:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12807 for ipsec-outgoing; Thu, 6 Feb 1997 13:17:42 -0500 (EST) Message-Id: <3.0.32.19970206121837.00b2ad80@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Feb 1997 12:18:48 -0500 To: Edward Russell , "'ipsec@tis.com'" From: Robert Moskowitz Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:33 PM 2/6/97 -0500, Edward Russell wrote: > >At the interoperability event in Dallas, it appears that >the BSAFE SHA is incompatible with the CYLINK SHA. BTW, I will be working hard to get the results out from this week late next week or early the following week. But based on what we accomplished this week, and the AIAG's need for IPsec with Oakley/ISAKMP, we are working on setting up a larger interoperability March 24-27. I am working on facilities (larger than these) and expect to have the information by the end of next week. March 24th was chosen to allow time to recover and then attend IETF (plus me to get the report done to present at IETF). Tentatively there will be one more week, most likely the 1st week in May (before INTEROP). Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Feb 6 13:22:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12870 for ipsec-outgoing; Thu, 6 Feb 1997 13:22:45 -0500 (EST) X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Edward Russell , "'ipsec@tis.com'" From: Michael Sabin Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 18:26:36 +0000 Message-ID: <19970206182634.AAA26435@LOCALNAME> Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:33 PM 2/6/97 +0000, Edward Russell wrote: > >At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote: >>I have implemented HMAC using SHA-1 as hash function. I have found test >>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test >>vectors? If not, I would be happy to help create them. >> > >At the interoperability event in Dallas, it appears that >the BSAFE SHA is incompatible with the CYLINK SHA. > >In addition it appears that >BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman > >We compiled our (FTP Software) implementation of ISAKMP with either >BSAFE or CYLINK libraries and tested against different vendors and >got compatiblity or incompatibility based on which library we compiled >with. > >That being said, I wrote a test program for both SHA and HMAC SHA >and compiled it with CYLINK and then with BSAFE. The results are >posted below. > >HMAC KEY = >0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b > >HMAC KEY LENGTH = 16 >DATA "Hi There" >DATA LENGTH = 8 > >DIGESTs: > >BSAFE HMAC SHA: >67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9 > >CYLINK HMAC SHA: >BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3 > > >BSAFE SHA: >4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > >CYLINK SHA: >4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B I ran this data through my own implementation of SHA and SHA-HMAC, based on my own interpretation of the standards. Here are my results: SHA 4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c HMAC-SHA 67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9 My results agree with the BSAFE results. I have also tested my SHA implementation against the AH-SHA implementation in the NRL IPSEC code and gotten agreement. mike From owner-ipsec Thu Feb 6 13:50:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13010 for ipsec-outgoing; Thu, 6 Feb 1997 13:49:13 -0500 (EST) Message-Id: <97Feb6.135047est.30800-3@janus.border.com> To: Edward Russell cc: "'ipsec@tis.com'" Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News References: <01BC1429.F844BBC0@localhost> In-reply-to: Your message of "Thu, 06 Feb 1997 12:33:16 -0500". <01BC1429.F844BBC0@localhost> 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: Thu, 6 Feb 1997 13:53:02 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > BSAFE SHA: > 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > > CYLINK SHA: > 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B I've seen this before. There are two different representations of hash codes floating around; "big endian" and "little endian". Note that the above hashes are identical with the *bytes* listed in the opposite order. I couldn't tell you which one is 'correct' though :-) -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy From owner-ipsec Thu Feb 6 14:21:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13207 for ipsec-outgoing; Thu, 6 Feb 1997 14:20:44 -0500 (EST) From: Robert Glenn Date: Thu, 6 Feb 1997 14:24:13 -0500 (EST) Message-Id: <199702061924.OAA03287@sloth.ncsl.nist.gov> To: erussell@ftp.com Subject: RE: test vectors for HMAC-SHA-1 - Test Data Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I just ran the exact same tests you described below against the NIST reference implementation of SHA-1. The results match the BSAFE SHA and BSAFE HMAC-SHA results. NIST SHA-1 Alg. Results: HMAC-SHA 67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9 SHA 4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c Rob G. In article <01BC1429.F844BBC0@localhost>, Edward Russell writes: > >At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote: >>I have implemented HMAC using SHA-1 as hash function. I have found test >>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test >>vectors? If not, I would be happy to help create them. >> > >At the interoperability event in Dallas, it appears that >the BSAFE SHA is incompatible with the CYLINK SHA. > >In addition it appears that >BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman > >We compiled our (FTP Software) implementation of ISAKMP with either >BSAFE or CYLINK libraries and tested against different vendors and >got compatiblity or incompatibility based on which library we compiled >with. > >That being said, I wrote a test program for both SHA and HMAC SHA >and compiled it with CYLINK and then with BSAFE. The results are >posted below. > >HMAC KEY = >0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b > >HMAC KEY LENGTH = 16 >DATA "Hi There" >DATA LENGTH = 8 > >DIGESTs: > >BSAFE HMAC SHA: >67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9 > >CYLINK HMAC SHA: >BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3 > > >BSAFE SHA: >4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > >CYLINK SHA: >4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B > > >Edward Russell >FTP Software >erussell@ftp.com > From owner-ipsec Thu Feb 6 14:37:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13303 for ipsec-outgoing; Thu, 6 Feb 1997 14:37:14 -0500 (EST) Message-Id: <3.0.16.19970206142958.1e4fcd3a@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 06 Feb 1997 14:39:06 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Excuse me but in fairness I would like to point out that I believe Cylink has been made aware of this issue -- I for one don't want to grumble, I want to interoperate... If anyone from Cylink sees this and doesn't think they have been contacted, consider yourself pinged... >X-Sender: mike.sabin@postoffice.worldnet.att.net >To: Edward Russell , "'ipsec@tis.com'" >From: Michael Sabin >Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News >Date: Thu, 6 Feb 1997 18:26:36 +0000 >Sender: owner-ipsec@ex.tis.com > >At 05:33 PM 2/6/97 +0000, Edward Russell wrote: >> >>At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote: >>>I have implemented HMAC using SHA-1 as hash function. I have found test >>>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test >>>vectors? If not, I would be happy to help create them. >>> >> >>At the interoperability event in Dallas, it appears that >>the BSAFE SHA is incompatible with the CYLINK SHA. >> >>In addition it appears that >>BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman >> >>We compiled our (FTP Software) implementation of ISAKMP with either >>BSAFE or CYLINK libraries and tested against different vendors and >>got compatiblity or incompatibility based on which library we compiled >>with. >> >>That being said, I wrote a test program for both SHA and HMAC SHA >>and compiled it with CYLINK and then with BSAFE. The results are >>posted below. >> >>HMAC KEY = >>0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, >0x0b, 0x0b, 0x0b, 0x0b >> >>HMAC KEY LENGTH = 16 >>DATA "Hi There" >>DATA LENGTH = 8 >> >>DIGESTs: >> >>BSAFE HMAC SHA: >>67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9 >> >>CYLINK HMAC SHA: >>BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3 >> >> >>BSAFE SHA: >>4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C >> >>CYLINK SHA: >>4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B > >I ran this data through my own implementation of SHA and SHA-HMAC, based on >my own interpretation of the standards. Here are my results: > >SHA >4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c > >HMAC-SHA >67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9 > >My results agree with the BSAFE results. I have also tested my SHA >implementation against the AH-SHA implementation in the NRL IPSEC code and >gotten agreement. > >mike > > > 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 Thu Feb 6 15:17:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13624 for ipsec-outgoing; Thu, 6 Feb 1997 15:17:13 -0500 (EST) Message-Id: <3.0.32.19970206141123.00b0e840@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Feb 1997 14:18:51 -0500 To: Rodney Thayer , ipsec@tis.com From: Robert Moskowitz Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:39 PM 2/6/97 -0500, Rodney Thayer wrote: >I for one don't want to grumble, I >want to interoperate... Which is one of the reasons for running interoperablity sessions in person. More can be done in a reasonable time frame. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Feb 6 15:17:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13618 for ipsec-outgoing; Thu, 6 Feb 1997 15:16:44 -0500 (EST) Message-Id: <01BC1441.F2502660@localhost> From: Edward Russell To: "'chk@border.com'" , "'Edward Russell'" Cc: "'ipsec@tis.com'" Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 15:03:26 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >C. Harald Koch (chk@border.com) said on 2/6/97 at 1:53 PM >In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: >> >> BSAFE SHA: >> 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C >> >> CYLINK SHA: >> 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B > >I've seen this before. There are two different representations of hash codes >floating around; "big endian" and "little endian". Note that the above >hashes are identical with the *bytes* listed in the opposite order. > >I couldn't tell you which one is 'correct' though :-) > >-- O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what should have been obvious to us. But understand, we're running on only a handful of hours of sleep trying to get us all to interoperate. :-) I don't think I would characterize this as an "endian" problem though as that as more to do with byte arrangement within shorts and longs - I doubt the problem is caused by one platform compiled with the wrong byte order defined. This is good news in that we won't need cryptographers and mathematicians to analyze or hand perform the correct results. We just need a decision on which way is to be deemed the "correct" way. I have a coin... We'll try to establish if the same is true at the end of a Diffie Hellman exchange, but that will be a little trickier. From owner-ipsec Thu Feb 6 15:36:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST) Message-Id: <01BC1444.9CEF6E80@localhost> From: Edward Russell To: "'ipsec@tis.com'" Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 15:44:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > > >We'll try to establish if the same is true at the end of a Diffie Hellman exchange, >but that will be a little trickier. > It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is not just a simple reversal. The cryptographers will have to tackle that one. From owner-ipsec Thu Feb 6 15:49:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13876 for ipsec-outgoing; Thu, 6 Feb 1997 15:49:42 -0500 (EST) From: pau@watson.ibm.com Date: Thu, 6 Feb 1997 15:40:06 -0500 Message-Id: <9702062040.AA22906@secpwr.watson.ibm.com> To: ipsec@tis.com Subject: HMAC-SHA test results Cc: niels@DigiCash.com, glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: PzrXJjenso3/eEQWKlwM6g== Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hellow, I and Neils Anderson used the following 3 test vectors to test HMAC-SHA (SHA1) and get the same results. Hugo and I would like to put them in the upcoming HMAC RFC. Though it may be late for RFC, please check the results any way because it is always nice to have common test vectors. The test vectors are the same as those in HMAC-MD5 draft; except that the key lengths in vectors 1 and 3 are expanded to 20 bytes. My code uses big-endian conversion as specified in FIPS 180-1. Thank you. Pau-Chen ----------------------------------------------------------------------------- Set 1 : key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b key_len = 20 bytes data = "Hi There" (Trailing '\0' not included in test) data_len = 8 bytes digest = 0xb617318655057264e28bc0b6fb378c8ef146be00 Set 2: key = "Jefe" (Trailing '\0' not included in test) data = "what do ya want for nothing?" data_len = 28 bytes digest = 0xeffcdf6ae5eb2fa2d27416d5f184df9c259a7c79 Set 3 : key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA key_len 20 bytes data = 0xDDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD... ..DDDDDDDDDDDDDDDDDDDD data_len = 50 bytes digest = 0x125d7342b9ac11cd91a39af48aa17b4f63f175d3 ------------------------------------------------------------------------------- From owner-ipsec Thu Feb 6 15:50:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13893 for ipsec-outgoing; Thu, 6 Feb 1997 15:50:42 -0500 (EST) From: owner-ipsec@ex.tis.com Date: Thu, 6 Feb 1997 15:55:29 -0500 Message-Id: <9702062055.AA23448@secpwr.watson.ibm.com> To: ipsec@tis.com, niels@DigiCash.com Subject: Re: HMAC-SHA test results Cc: glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: DkvKuCCbEH1zBC/r1t9HiA== Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > From pau@secpwr.watson.ibm.com Thu Feb 6 15:40:07 1997 > From: pau@secpwr.watson.ibm.com > Date: Thu, 6 Feb 1997 15:40:06 -0500 > Message-Id: <9702062040.AA22906@secpwr.watson.ibm.com> > To: ipsec@tis.com > Subject: HMAC-SHA test results > Cc: niels@DigiCash.com, glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com > Mime-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > Content-Md5: PzrXJjenso3/eEQWKlwM6g== > Content-Length: 1640 > Status: RO > > Hellow, > > I and Neils Anderson used the following 3 test vectors to test HMAC-SHA Oops! I meant Niels Ferguson. Sorry, Niels. Pau-Chen > (SHA1) and get the same results. Hugo and I would like to put them in the > upcoming HMAC RFC. Though it may be late for RFC, please check the results > any way because it is always nice to have common test vectors. > > > > From owner-ipsec Thu Feb 6 15:54:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13942 for ipsec-outgoing; Thu, 6 Feb 1997 15:54:42 -0500 (EST) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199702062058.MAA22972@kebe.eng.sun.com> Subject: Re: Path MTU Discovery To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis) Date: Thu, 6 Feb 1997 12:58:32 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <9702060420.AA79343@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 5, 97 11:20:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Path-mtu discovery breaks in the presence of multiple IPsec > encapsulation(*) (it might even break in the presence of ONE > intermediate encapsulating entity). Are you sure it totally breaks? It doesn't work as well, for sure, but I don't see total breakage. An encrypting router often has a "tunnel interface" that'll have properties like: tun0: 10.69.0.0/16 --> 10.9.1.25 Interfaces have MTU associated with them. A combination of PathMTU discovery from the router to the tunnel endpoint, and knowledge of the algorithms used, etc. can give this tunnel interface a reasonable MTU estimate. Reasonable enough that an MTU too large message for datagrams bound for 10.69.0.0/16 can be sent. BTW, by PathMTU discovery to the endpoint, I mean that the router (because it is originating packets now, from its address to the tunnel endpoint) has a cache-entry/host-route/whatever for the tunnel endpoint. That entry can be a repository for intermediate Path MTU information. Incoming IP data Outgoing forward result -- src 10.8.20.69 --> ROUTER (ifaddr) -> src 10.10.20.20 dst 10.69.21.12 <-(10.8.20.2) dst 10.9.1.25 proto=TCP (10.10.20.20)-> proto=ESP (with IP inside) Figure 1: Demonstration of "originating packets". Now let's say there's ANOTHER layer of encryption between the router above and its tunnel endpoint of 10.9.1.25. THAT router may send an ICMP toobig to OUR router (10.10.20.20), saying the path to 10.9.1.25 has a smaller MTU than what I think. Now, because of the multiple nestings of IP, I can't percolate that ICMP toobig all the way back to the originator, but it will eventually percolate back. It will take N dropped messages for N layers of tunelling. So if there's an intermediate node's worth of encapsulation, the first message will be dropped, then when the first subsequent message hits the cranked-down tunnel endpoint, THEN a toobig can be sent back. Using the above figure 1 as an example, if a router says the path MTU to 10.9.1.25 is less, then the router's tunnel interface will ratchet down its mtu. The original packet from the source host 10.8.20.69 will just be dropped, because the router doesn't really want to go digging deep for the originator. The next IP datagram from 10.8.20.69 will generate an ICMP toobig from the router, because it now has the ratcheted-down MTU on its tunneling interface, and so with one dropped datagram, the node 10.8.20.69 knows the whole path MTU. If messages drop occasionally, that's fine. This is IP. Sure it's a performance hit, but security and performance are sometimes (note my choice of words) opposites in a tradeoff. I don't think your solution about keeping SPIs helps a whole lot here. It seems to be unnecessary implementation cruft. If there's any flaws in what I've said, however, I'd certainly like to know. > This still doesn't address the problem of the original TCP mtu (the > mtu of the outgoing interface could be less than that reported on the > kernel structure, depending on whether a packet will be IPsec'ed or > not). But i doubt we can mandate a solution for that. As for original TCP MSS, which needs to be set, IP must be able to send a hint to the particular TCP session indicating that IP security will lower the effective MSS for this TCP connection. I say it must only alter a single TCP session because IP security should use per-endpoint security properties where possible. See Bellovin's USENIX Security '96 conference paper for details on why. See draft-mcdonald-simple-ipsec-api-00.txt for how an application may exploit this. > Also, there's the case of whether we accept as valid ICMPs from anyone > in between (which means anyone) or just two encapsulating entities > (e.g. two tunneling firewalls). The network-correct approach is > anyone; the security correct is next enc entity. Good point, and it applies to ICMP messages of all shapes, sizes, and flavors. It's possible an intermediate router could send an ICMP with AH on it, that way I have reasonable assurance it came from a router with that IP address. > (*) Steve Kent replied that it shouldn't break for an end host; He is right. > however, the 4.4BSD TCP code checks the outgoing interface MTU > directly to determine the size of the packets, if the route entry does not > have an mtu (check tcp_input.c, tcp_mss()). This means that either TCP > is patched, or fragmentation will happen. Stock 4.4 is broken w.r.t. trying to perform Path MTU discovery. FreeBSD has one solution for doing this with IPv4. The NRL IPv6 code has another solution that it implements on the IPv6 side of things. Dan From owner-ipsec Thu Feb 6 16:11:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14039 for ipsec-outgoing; Thu, 6 Feb 1997 16:10:59 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Feb 1997 14:13:27 -0700 From: John Kennedy To: chk@border.com, erussell@ftp.com Cc: ipsec@tis.com Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply Sender: owner-ipsec@ex.tis.com Precedence: bulk I also ran the "Hi There" message through a SHA-1 utility I developed independently and got the same answer that BSAFE gives. As far as the "endian-ness" convention goes, the BSAFE answer is compliant with the test vectors given in the FIPS standard. Thus, I would contend that the BSAFE answer is the "correct" one. I also suspect this representation issue has something to do with the Diffie-Hellman compatibility problem. -John Kennedy NOVELL, Inc. >>> "C. Harald Koch" 02/06/97 11:53am >>> In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > BSAFE SHA: > 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > > CYLINK SHA: > 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B I've seen this before. There are two different representations of hash codes floating around; "big endian" and "little endian". Note that the above hashes are identical with the *bytes* listed in the opposite order. I couldn't tell you which one is 'correct' though :-) -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy Received: by provo.mx.relay with Novell_GroupWise; Thu, 06 Feb 1997 13:03:22 -0700 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13010 for ipsec-outgoing; Thu, 6 Feb 1997 13:49:13 -0500 (EST) Message-Id: <97Feb6.135047est.30800-3@janus.border.com> References: <01BC1429.F844BBC0@localhost> In-reply-to: Your message of "Thu, 06 Feb 1997 12:33:16 -0500". <01BC1429.F844BBC0@localhost> 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 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 06 Feb 1997 11:53:02 -0700 From: "C. Harald Koch" To: erussell@ftp.com Cc: ipsec@tis.com Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > BSAFE SHA: > 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > > CYLINK SHA: > 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B I've seen this before. There are two different representations of hash codes floating around; "big endian" and "little endian". Note that the above hashes are identical with the *bytes* listed in the opposite order. I couldn't tell you which one is 'correct' though :-) -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy From owner-ipsec Thu Feb 6 16:22:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14110 for ipsec-outgoing; Thu, 6 Feb 1997 16:21:46 -0500 (EST) Date: Thu, 6 Feb 1997 15:17:55 -0600 (CST) From: Tom Markham Message-Id: <199702062117.PAA23596@jasmin.sctc.com> To: ipsec@tis.com Subject: RE: test vectors for HMAC-SHA-1 Sender: owner-ipsec@ex.tis.com Precedence: bulk > O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what > should have been obvious to us. I would suggest that keys be picked which will identify problems with byte ordering in the keys. The key below is the same for big endian and little endian. Thus, the Cylink results are correct if you reverse the byte ordering of the key and results. >HMAC KEY = >0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b I suggest using a key such as 0x00 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f I've been bit by this dog before, Tom Markham From owner-ipsec Thu Feb 6 16:37:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14181 for ipsec-outgoing; Thu, 6 Feb 1997 16:35:45 -0500 (EST) Message-ID: From: Greg Carter To: "'chk%border.com'" , "'erussell@ftp.com'" Cc: "'ipsec%tis.com'" Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 16:29:41 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk The string and digest are taken from FIPS PUB 180-1. Our code comes up with same as BSAFE... and conforms to the test vectors give here... // Test vectors static const char k_testString[] = // Must be declared char for UNIX compiler "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"; static const BYTE k_correctDigest[SHA_DIGEST_SIZE] = { 0x84, 0x98, 0x3E, 0x44, 0x1C, 0x3B, 0xD2, 0x6E, 0xBA, 0xAE, 0x4A, 0xA1, 0xF9, 0x51, 0x29, 0xE5, 0xE5, 0x46, 0x70, 0xF1 }; ---- Greg Carter Entrust Technologies carterg@entrust.com > >O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what >should have been obvious to us. But understand, we're running on only a >handful of hours of sleep trying to get us all to interoperate. :-) I don't >think >I would characterize this as an "endian" problem though as that as more >to do with byte arrangement within shorts and longs - I doubt the problem >is caused by one platform compiled with the wrong byte order defined. > >This is good news in that we won't need cryptographers and mathematicians >to analyze or hand perform the correct results. We just need a decision on >which way is to be deemed the "correct" way. I have a coin... > >We'll try to establish if the same is true at the end of a Diffie Hellman >exchange, >but that will be a little trickier. > > > From owner-ipsec Thu Feb 6 17:05:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14325 for ipsec-outgoing; Thu, 6 Feb 1997 17:05:45 -0500 (EST) Message-Id: <97Feb6.170648est.30818-3@janus.border.com> To: Edward Russell cc: "'ipsec@tis.com'" Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News References: <01BC1441.F2502660@localhost> In-reply-to: erussell's message of "Thu, 06 Feb 1997 15:03:26 -0500". <01BC1441.F2502660@localhost> 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: Thu, 6 Feb 1997 17:08:58 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <01BC1441.F2502660@localhost>, Edward Russell writes: > > O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what > should have been obvious to us. But understand, we're running on only a > handful of hours of sleep trying to get us all to interoperate. :-) I don't think > I would characterize this as an "endian" problem though as that as more > to do with byte arrangement within shorts and longs - I doubt the problem > is caused by one platform compiled with the wrong byte order defined. Thanks for the award :-) I agree that it's not strictly an endian problem. I first discovered it when comparing the results for some public-domain MD5 code between a SPARC machine (big-endian) and an Intel machine (little-endian), and so the problem has been tagged "endian" in my brain ever since. > We'll try to establish if the same is true at the end of a Diffie Hellman exchange, > but that will be a little trickier. I'm crossing my fingers... -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy From owner-ipsec Thu Feb 6 17:19:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14487 for ipsec-outgoing; Thu, 6 Feb 1997 17:19:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Feb 1997 15:22:40 -0700 From: John Kennedy To: erussell@ftp.com, ipsec@tis.com Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply Sender: owner-ipsec@ex.tis.com Precedence: bulk Oh, I don't think we need to call out the cryptographic "Big Guns" yet. I'm willing to bet the problem is with the output, transfer, and subsequent input at the receiving end of the public numbers. I doubt it is a fundamental problem with the underlying big integer arithmetic libraries. More like one library interpreting the numbers LSByte first and the other one MSByte first. If each library was not consistent in its interpretation of the data, the math wouldn't work for two implementations using the same library. -John Kennedy NOVELL, Inc. >>> Edward Russell 02/06/97 01:44pm >>> >In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > > >We'll try to establish if the same is true at the end of a Diffie Hellman exchange, >but that will be a little trickier. > It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is not just a simple reversal. The cryptographers will have to tackle that one. Received: by provo.mx.relay with Novell_GroupWise; Thu, 06 Feb 1997 14:39:19 -0700 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST) Message-Id: <01BC1444.9CEF6E80@localhost> Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 06 Feb 1997 13:44:02 -0700 From: Edward Russell To: ipsec@tis.com Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News >In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > > >We'll try to establish if the same is true at the end of a Diffie Hellman exchange, >but that will be a little trickier. > It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is not just a simple reversal. The cryptographers will have to tackle that one. From owner-ipsec Thu Feb 6 18:46:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14985 for ipsec-outgoing; Thu, 6 Feb 1997 18:46:17 -0500 (EST) X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: From: Michael Sabin Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News Date: Thu, 6 Feb 1997 23:50:04 +0000 Message-ID: <19970206235002.AAA26138@LOCALNAME> Sender: owner-ipsec@ex.tis.com Precedence: bulk I figured this thread was a good chance to weigh in once again with the suggestion that every ESP and AH draft include an example datagram that nails down these pesky details about byte ordering, etc. That'll go a long way to ensuring that a spec is unambiguously interpreted. Below is a copy of a previous posting. Jim Hughes responded that the upcoming draft of the combined DES-CBC-HMAC-replay draft would include such an example. mike >Date: Fri, 20 Dec 1996 20:44:23 >To: hughes@nsco.network.com >From: Michael Sabin >Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard >Cc: iesg@ietf.org, ipsec@tis.com > >I went through the exercise of coding up an example datagram as per the >draft. My goal was to chase down details about byte/bit orderings in and >out of the DES, MD5, HMAC, and replay-count operations. I felt that >most of the details were resolvable using the description in the draft >and the cited references. However, in a few cases I felt I was >guessing. > >One suggestion I have is that the draft include an example datagram, >before and after encryption. This will unambiguously nail down all >details about bit/byte ordering. Note that the individual specs for DES >[FIPS-41], MD5 [RFC-1321], and HMAC [Krawczyk] include such examples. > >Below is the example I came up with. (If anybody is inclined to verify >the example, I'd sure appreciate it. :-) ) Items marked with (*) are >places where I felt I was guessing about byte/bit orderings; some >clarification about these may be desirable. > >mike >--------------------------------- > >EXAMPLE > >Suppose the "master key" K from the key managment layer is: > > K = > 01 23 45 67 89 ab cd ef 23 45 67 89 ab cd ef 01 > 45 67 89 ab cd ef 01 23 67 89 ab cd ef 01 23 45 > 89 ab cd ef 01 23 45 67 ab cd ef 01 23 45 67 89 > cd ef 01 23 45 67 89 ab ef 01 23 45 67 89 ab cd > >K consists of 512 octets. Octet 0 is 0x01, octet 1 is 0x23, octet 511 >is 0xcd. > >K is used to compute the following quantities: > > DES_Key_I = a4 34 41 46 f6 dc 8b 1d > IV_Key_I = c8 44 86 79 51 a6 83 cc > HMAC_Key_I = 98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 dd 4f 1c 8d > RP_Key_I = d3 1f e3 42 > >Each of these quantities is a sequence of octets numbered 0, 1, 2, ..., >with octet 0 listed first. > >Here is an example datagram prior to encryption, including the HMAC: > > 1f 2e 3d 4c // SPI > d3 1f e3 42 // replay count > 4e 6f 77 20 // payload > 69 73 20 74 // payload > 68 65 20 74 // payload > 69 6d 65 20 // payload > 66 6f 72 20 // payload > 61 6c 6c 20 // payload > f6 0f 02 06 // padding, pad length, payload type > 8a 85 2a 16 // HMAC > 2a 6a 0d de // HMAC > 30 b1 e5 fa // HMAC > a6 e1 fc c1 // HMAC > >(*) The initial value of the replay count, from RP_Key_I, is: > > initial replay count = 0xd31fe342 = 3,542,082,370 > >(*) When computing the HMAC, the octets of the datagram are digested in >network order: 0x1f, 0x2e, 0x3d, ..., 0x0f, 0x02, 0x06. > >The HMAC key, from HMAC_Key_I, is [98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 >dd 4f 1c 8d]; 0x98 is octet 0, and 0x8d is octet 15. > >(*) The output of the HMAC calculation is inserted into the datagram in >network order: 0x8a is octet 0, and 0xc1 is octet 15. > > >Here is the datagram after encryption: > > 1f 2e 3d 4c // SPI > ff 30 bf 0a // replay count > 46 bd b7 94 // payload > 33 ff 84 0e // payload > d9 aa 76 7a // payload > cb 20 da d8 // payload > 87 8e bf 0f // payload > 27 70 2c 99 // payload > 2f e3 ce a2 // padding, pad length, payload type > b1 cc 9a 6e // HMAC > 34 b8 50 3a // HMAC > 51 92 be 7f // HMAC > e0 cb ba 05 // HMAC > >(*) The DES encryption key, prior to parity correction, is [a4 34 41 >46 f6 dc 8b 1d], from DES_Key_I. > >(*) The IV is [c8 44 86 79 51 a6 83 cc], from IV_Key_I. > >(*) The first input block to the DES-CBC encryption is [d3 1f e3 42 4e >6f 77 20]. > From owner-ipsec Fri Feb 7 02:24:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA17154 for ipsec-outgoing; Fri, 7 Feb 1997 02:23:17 -0500 (EST) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199702070727.XAA24969@kebe.eng.sun.com> Subject: Re: Path MTU Discovery To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis) Date: Thu, 6 Feb 1997 23:27:27 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <9702070346.AA07074@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 6, 97 10:46:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > >An encrypting router often has a "tunnel interface" that'll have properties > >like: > > > > tun0: 10.69.0.0/16 --> 10.9.1.25 > > Not necessarilly. Virtual interfaces might not be used, or you might > have more than one SPIs using the same interface. Per SPI(-chain) MTUs > need to be kept. If you have a router that behaves as you describe, > then you don't need any other provision. Hmmm. In a router-to-host tunneling case, you MIGHT be right. Let's consider one other property about router-to-* tunneling. Since the router is the _originator_ of the outermost packet, it does not need to obey the inner packet's "Don't fragment" bit. Remember, I'm originating the packet. There's one faulty assumption you make below. I'll point it out in a bit. This may explain why we aren't agreeing here. > Which is the same as keeping that information on a per-SPI(-chain) > basis, if you don't use ViFs. Could you illustrate a non-VIF case? Granted, in the NRL code, there's an "encrypting route," but even there, I just don't see any of the MTU problems. > Another point is that fragmentation checking should be done before any > IPsec handling takes place (easier and faster). WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme quote: >> 3.1 AUTHENTICATION HEADER >> Fragmentation occurs after the Authentication Header processing for >> outbound packets and prior to Authentication Header processing for >> inbound packets. The receiver verifies the correctness of the There actually isn't text in the ESP section, but I'll bet small sums that either Ran A. or Steve K. will back me up on this one. If you meant inbound packets, my bad. > Only if you can associate a packet "flow" with the ICMP message; easy > to do if you use a ViF for each tunnel. Any implementors out there not doing this? I can only see this in the router-to-host tunnel. > So TCP has to "forsee" whether a packet will go through IPsec, and if > so what will be the size overhead. It'll know. Before that SYN or SYN/ACK gets sent, it can consult endpoint state (socket, pcb, whatever) and make an appropriate guess. Dan From owner-ipsec Fri Feb 7 07:27:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18505 for ipsec-outgoing; Fri, 7 Feb 1997 07:24:50 -0500 (EST) Message-Id: <9702070347.AA07084@aurora.cis.upenn.edu> To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: Path MTU Discovery Date: Thu, 06 Feb 1997 22:47:21 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199702062058.MAA22972@kebe.eng.sun.com>, Dan McDonald writes: > >An encrypting router often has a "tunnel interface" that'll have properties >like: > > tun0: 10.69.0.0/16 --> 10.9.1.25 Not necessarilly. Virtual interfaces might not be used, or you might have more than one SPIs using the same interface. Per SPI(-chain) MTUs need to be kept. If you have a router that behaves as you describe, then you don't need any other provision. >BTW, by PathMTU discovery to the endpoint, I mean that the router (because it >is originating packets now, from its address to the tunnel endpoint) has a >cache-entry/host-route/whatever for the tunnel endpoint. That entry can be a >repository for intermediate Path MTU information. Which is the same as keeping that information on a per-SPI(-chain) basis, if you don't use ViFs. Another point is that fragmentation checking should be done before any IPsec handling takes place (easier and faster). >Now let's say there's ANOTHER layer of encryption between the router above >and its tunnel endpoint of 10.9.1.25. THAT router may send an ICMP toobig to >OUR router (10.10.20.20), saying the path to 10.9.1.25 has a smaller MTU than >what I think. Now, because of the multiple nestings of IP, I can't percolate >that ICMP toobig all the way back to the originator, but it will eventually >percolate back. Only if you can associate a packet "flow" with the ICMP message; easy to do if you use a ViF for each tunnel. >As for original TCP MSS, which needs to be set, IP must be able to send a >hint to the particular TCP session indicating that IP security will lower the >effective MSS for this TCP connection. I say it must only alter a single TCP >session because IP security should use per-endpoint security properties where >possible. See Bellovin's USENIX Security '96 conference paper for details on >why. See draft-mcdonald-simple-ipsec-api-00.txt for how an application may >exploit this. Agreed. I just raised this because i'm not sure how many implementations actually do this. >Good point, and it applies to ICMP messages of all shapes, sizes, and >flavors. It's possible an intermediate router could send an ICMP with AH on >it, that way I have reasonable assurance it came from a router with that IP >address. That would mean establishing SPIs with all intermediate routers in advance (on the fly might be too slow an approach). An then there's the issue of verifying that the router is actually in the path (and not some random "router" that established an SPI with us). >Stock 4.4 is broken w.r.t. trying to perform Path MTU discovery. FreeBSD has >one solution for doing this with IPv4. The NRL IPv6 code has another >solution that it implements on the IPv6 side of things. I was actually refering to initial mss (although i guess the interface MTU is also used for PathMTU discovery - have to check the code). So TCP has to "forsee" whether a packet will go through IPsec, and if so what will be the size overhead. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMvqlyL0pBjh2h1kFAQHsaQP+KIPs/A05ehCPeYAnsy+VcCZCWqSnJSNI RV7xkSb8parnQ5AyUybzWRB6bfubcqZ4qXEoOLdW8ErfUes0ei6eIgvW08Hs+uBQ b3VsB0k1isVVzpQG+zxTjP8Jgd7GaqU76zon2OGcXOvoyXu6Fnx5gyJnvanlxu4B qmAV4ltrPH4= =Cx6g -----END PGP SIGNATURE----- From owner-ipsec Fri Feb 7 07:29:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18596 for ipsec-outgoing; Fri, 7 Feb 1997 07:29:51 -0500 (EST) Message-Id: <9702070842.AA79320@aurora.cis.upenn.edu> To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: Path MTU Discovery Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5711.855304913.1@dsl.cis.upenn.edu> Date: Fri, 07 Feb 1997 03:41:53 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199702070727.XAA24969@kebe.eng.sun.com>, Dan McDonald writes: >Let's consider one other property about router-to-* tunneling. Since the >router is the _originator_ of the outermost packet, it does not need to obey >the inner packet's "Don't fragment" bit. Remember, I'm originating the >packet. Well, wouldn't ignoring the DF bit defeat the original endpoint's PathMTU ? >WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme >quote: > >>> 3.1 AUTHENTICATION HEADER > > > >>> Fragmentation occurs after the Authentication Header processing for >>> outbound packets and prior to Authentication Header processing for >>> inbound packets. The receiver verifies the correctness of the > >There actually isn't text in the ESP section, but I'll bet small sums that >either Ran A. or Steve K. will back me up on this one. > >If you meant inbound packets, my bad. My phrasing was "fragmentation checking", not fragmentation; what i mean is that one should check whether a packet, after the overhead imposed by IPsec, would be fragmented. If so, don't apply the transforms but drop it and send back an ICMP toobig. Sorry if i was not clear enough. >Any implementors out there not doing this? I can only see this in the >router-to-host tunnel. JI and me have an implementation that does not use multiple ViFs. SOS Corp. as well, last i checked. Don't know about others. So, the way our implementation works is that a ViF is really used as a way to force packets to go into the IPsec engine uppon receiving (actually, just the IP-in-IP packets - the rest is handled by ip_input()) Changing the ip_input() a bit would make those unnecessary too. So one can establish multiple tunnels to different (or the same) hosts and use the same ViF. In this case, if you receive an ICMP toobig, you don't know who if "belongs" to until you parse the internal packet a bit and check the destination/SPI of the original packet. And then of course you can't (shouldn't) change the "MTU" of the ViF. Q: does the NRL implementation create ViFs dynamically (as needed) ? I have a fairly old copy of it (1 year+) - available at idea.dsi.unimi.it:/pub/security/crypt/code/IPv6-domestic.tar.gz for those wondering how i got a copy of it :-) >It'll know. Before that SYN or SYN/ACK gets sent, it can consult endpoint >state (socket, pcb, whatever) and make an appropriate guess. Well, that's what i'm saying too. That we should make it a requirement. In fact, even what you've been saying about ViFs is non-standard; keeping track of ICMP toobigs and back-propagating that value is not standard behaviour and not specified anywhere. -Angelos From owner-ipsec Fri Feb 7 09:19:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19402 for ipsec-outgoing; Fri, 7 Feb 1997 09:16:02 -0500 (EST) Date: Fri, 7 Feb 1997 09:20:08 -0500 Message-Id: <9702071420.AA27311@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: ipsec@tis.com From: Naganand Doraswamy Subject: Replay field size in AH Sender: owner-ipsec@ex.tis.com Precedence: bulk The replay field size in AH is 64 bits. It is 32 bits in ESP drafts. We can change the AH draft to use only 32 bits for replay and make the other 4 bytes reserved if we are concerned about the 64bit boundary alignment? Naganand From owner-ipsec Fri Feb 7 09:52:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19648 for ipsec-outgoing; Fri, 7 Feb 1997 09:52:08 -0500 (EST) Message-Id: <3.0.16.19970207094329.1c2fbda4@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 07 Feb 1997 09:54:05 -0500 To: John Kennedy From: Rodney Thayer Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In thinking about this I believe the problem has crossed "endian" boundries already so I don't think this is it. I'm going to rerun the DH tests on a non-intel box to see if that changes things. I know the code Ed and I were originally discussing was running on an Intel machine. I don't know for sure if the Cylink code was running on an Intel box. At 03:22 PM 2/6/97 -0700, you wrote: >Oh, I don't think we need to call out the cryptographic "Big Guns" yet. I'm >willing to bet the problem is with the output, transfer, and subsequent >input at the receiving end of the public numbers. I doubt it is a >fundamental problem with the underlying big integer arithmetic libraries. >More like one library interpreting the numbers LSByte first and the other >one MSByte first. If each library was not consistent in its interpretation >of the data, the math wouldn't work for two implementations using the >same library. > >-John Kennedy > NOVELL, Inc. > >>>> Edward Russell 02/06/97 01:44pm >>> >>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: >> >> >> >>We'll try to establish if the same is true at the end of a Diffie Hellman >exchange, >>but that will be a little trickier. >> > >It would appear the Diffie Hellman discrepancy between Cylink and >Bsafe is >not just a simple reversal. The cryptographers will have to tackle that >one. > > > > > > > >Received: by provo.mx.relay > with Novell_GroupWise; Thu, 06 Feb 1997 14:39:19 -0700 >Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST) >Message-Id: <01BC1444.9CEF6E80@localhost> >Sender: owner-ipsec@ex.tis.com >Precedence: bulk >Date: Thu, 06 Feb 1997 13:44:02 -0700 >From: Edward Russell >To: ipsec@tis.com >Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News > >>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: >> >> >> >>We'll try to establish if the same is true at the end of a Diffie Hellman exchange, >>but that will be a little trickier. >> > >It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is >not just a simple reversal. The cryptographers will have to tackle that one. > > > > > > > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sat Feb 8 04:11:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24709 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:09 -0500 (EST) Message-Id: <199702071930.TAA01491@inner.net> To: "Angelos D. Keromytis" cc: ipsec@tis.com Subject: Re: Path MTU Discovery In-reply-to: Your message of "Thu, 06 Feb 1997 22:47:21 EST." <9702070347.AA07084@aurora.cis.upenn.edu> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 07 Feb 1997 14:30:42 -0500 From: Craig Metz Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9702070347.AA07084@aurora.cis.upenn.edu>, you write: >Another point is that fragmentation checking should be done before any >IPsec handling takes place (easier and faster). All IPsec processing must be done above fragmentation. -Craig From owner-ipsec Sat Feb 8 04:11:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24779 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:30 -0500 (EST) From: Uri Blumenthal Message-Id: <9702071637.AA38491@hawpub.watson.ibm.com> Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News To: chk@border.com (C. Harald Koch) Date: Fri, 7 Feb 1997 11:37:21 -0500 (EST) Cc: erussell@ftp.com, ipsec@tis.com In-Reply-To: <97Feb6.135047est.30800-3@janus.border.com> from "C. Harald Koch" at Feb 6, 97 01:53:02 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 C. Harald Koch says: > > BSAFE SHA: > > 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C > > CYLINK SHA: > > 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B > > I've seen this before. There are two different representations of hash codes > floating around; "big endian" and "little endian". Note that the above > hashes are identical with the *bytes* listed in the opposite order. > I couldn't tell you which one is 'correct' though :-) Well, by the spirit of SHA document (even though it would have been better for the designers to explicitely say such things) BIG endian is the correct one. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Sat Feb 8 04:11:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24570 for ipsec-outgoing; Sat, 8 Feb 1997 04:06:20 -0500 (EST) Date: Sat, 8 Feb 97 02:56:12 GMT Standard Time From: Ran Atkinson Subject: Re: Path MTU Discovery To: "Angelos D. Keromytis" , Dan McDonald Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199702070727.XAA24969@kebe.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McD is correct (and the RFC-1827 ESP spec has a bug). Fragmentation processing occurs _after_ all outbound IPsec processing and _before_ all inbound IPsec processing. This should be for ESP as well as for AH. Ideally this will get corrected in the new ESP spec. Mea Culpa. Ran rja@inet.org From owner-ipsec Sat Feb 8 04:11:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24724 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:14 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702071815.KAA01378@kebe.eng.sun.com> Subject: Re: Path MTU Discovery To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis) Date: Fri, 7 Feb 1997 10:15:13 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <9702070842.AA79320@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 7, 97 03:41:53 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Well, wouldn't ignoring the DF bit defeat the original endpoint's > PathMTU ? DF applies to the IP datagram on which it is set. DF is not inherited by any encapsulating IP headers. A packet arrives looking like: src 10.8.20.69 dst 10.69.51.50 proto = tcp bits = DF The router then encapsulates: src 10.20.20.20 dst 10.9.1.25 proto = ip This outer packet is now a datagram originating from the router. It can fragment as it sees fit. Yes, it may violate the spirit of no intermediate fragmentation, but it certainly is legal. This is legal in IPv6 too, where there is an implicit DF bit on all packets. > My phrasing was "fragmentation checking", not fragmentation; what i > mean is that one should check whether a packet, after the overhead > imposed by IPsec, would be fragmented. If so, don't apply the > transforms but drop it and send back an ICMP toobig. Sorry if i was > not clear enough. That explains things a little better, thanks. > So one can establish multiple tunnels to different (or the same) hosts and > use the same ViF. In this case, if you receive an ICMP toobig, you don't > know who if "belongs" to until you parse the internal packet a bit and > check the destination/SPI of the original packet. And then of course you > can't (shouldn't) change the "MTU" of the ViF. I question your choice of abstraction. How do you configure these multiple tunnels? Or are they automatic tunnels ala. IPv6's :: syntax? Since you probably have to configure the tunnels, you might as well provide a halfway decent abstraction to take into account Path MTU ratcheting down. > Q: does the NRL implementation create ViFs dynamically (as needed) ? > I have a fairly old copy of it (1 year+) - available at > idea.dsi.unimi.it:/pub/security/crypt/code/IPv6-domestic.tar.gz for > those wondering how i got a copy of it :-) Glad to see the code has slipped out elsewhere. Funny thing is, last time I touched the code was about 1 year+ ago. It does not do automatic tunneling, IIRC. > Well, that's what i'm saying too. That we should make it a > requirement. In fact, even what you've been saying about ViFs is > non-standard; keeping track of ICMP toobigs and back-propagating that > value is not standard behaviour and not specified anywhere. OTOH it uses defined behavior and available underspecifications to make implementations (IMHO) less complex. Security holes come out of complexity, just ask any sendmail user. Dan From owner-ipsec Sat Feb 8 13:40:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27339 for ipsec-outgoing; Sat, 8 Feb 1997 13:32:08 -0500 (EST) Message-Id: <199702081836.KAA15585@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: John Kennedy , ipsec@tis.com Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply In-Reply-To: Your message of "Fri, 07 Feb 1997 09:54:05 EST." <3.0.16.19970207094329.1c2fbda4@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Feb 1997 10:36:06 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer wrote: > In thinking about this I believe the problem has crossed "endian" boundries > already so I don't think this is it. I'm going to rerun the DH tests on a > non-intel box to see if that changes things. I know the code Ed and I were > originally discussing was running on an Intel machine. I don't know for > sure if the Cylink code was running on an Intel box. It was running on both. The laptop we were using was little-endian and the router was big-endian. Both could interoperate with other implementations which shared the same crypto lib pedigree (i.e. the cylink one). Dan. From owner-ipsec Sat Feb 8 14:12:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27495 for ipsec-outgoing; Sat, 8 Feb 1997 14:08:40 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9702071420.AA27311@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 8 Feb 1997 14:13:47 -0500 To: Naganand Doraswamy From: Stephen Kent Subject: Re: Replay field size in AH Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd like to hear from Jeff Schiller and the WG chairs re this still open issue. My recollection is that there was supposed to be a small meetng to reolve this after the last IPSEC WG meeting in San Jose. I observed that we had two variables affecting aligmment: sequence number size and HMAC size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to reduce the number of variables affecting alignment, but I don't recall a decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to nail this down so that the grand unified AH and ESP specs can proceed. Steve From owner-ipsec Sat Feb 8 16:22:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28030 for ipsec-outgoing; Sat, 8 Feb 1997 16:18:40 -0500 (EST) Message-ID: <01BC15D4.23743680@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: naganand@ftp.com (Naganand Doraswamy), kent@bbn.com ('Stephen Kent') cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: Replay field size in AH Date: Sat, 8 Feb 1997 15:23:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarless of what we do about alignment, a 64 bit replay field seems simply wrong. 2^64 packets before you wrap? 2^32 seems more than sufficient. The choice of replay field length should not be linked to any alignment issues. If we need to align the packet differently, we should add reserved or mbz fields. The size of the replay counter should be useful and correct for replay alone, and not be sized based on any other issues. -Rob ---------- From: Stephen Kent[SMTP:kent@bbn.com] Sent: Saturday, February 08, 1997 11:13 AM To: Naganand Doraswamy Cc: ipsec@tis.com Subject: Re: Replay field size in AH I'd like to hear from Jeff Schiller and the WG chairs re this still open issue. My recollection is that there was supposed to be a small meetng to reolve this after the last IPSEC WG meeting in San Jose. I observed that we had two variables affecting aligmment: sequence number size and HMAC size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to reduce the number of variables affecting alignment, but I don't recall a decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to nail this down so that the grand unified AH and ESP specs can proceed. Steve From owner-ipsec Sat Feb 8 18:05:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28532 for ipsec-outgoing; Sat, 8 Feb 1997 18:02:12 -0500 (EST) Date: Sat, 8 Feb 97 22:59:38 GMT Standard Time From: Ran Atkinson Subject: Re: Replay field size in AH To: Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I was not informed about any small meeting that did occur or should have occurred. Perhaps the Security AD can provide more data. I'll ask him for instructions. Ran rja@inet.org From owner-ipsec Sat Feb 8 19:44:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28943 for ipsec-outgoing; Sat, 8 Feb 1997 19:40:41 -0500 (EST) Message-Id: <199702090044.QAA04984@fluffy.cisco.com> To: ipsec@tis.com Subject: replay field size Date: Sat, 08 Feb 1997 16:44:44 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk There was clear consensus at the ANX IPSEC bakeoff last week to make the size of the replay field 32-bits for both AH and ESP. If we _must_ have alignment for IPv4 IPSEC then the additional bits should be specified as alignment. No one wants to do 64-bit math for replay computation. It's silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I don't see the point of aligning the fields just to keep the protocol consistent with IPv6. I don't think this issue needs the Security AD to resolve. I think we already have consensus. Let's hear now from anyone who absolutely must have 64 bits or else move to revise AH and ESP to reflect consensus. We have much more interesting things to argue about. Derrell From owner-ipsec Sun Feb 9 11:14:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02596 for ipsec-outgoing; Sun, 9 Feb 1997 11:05:19 -0500 (EST) Message-Id: <3.0.16.19970209105421.3847cd10@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sun, 09 Feb 1997 11:07:14 -0500 To: Stephen Kent From: Rodney Thayer Subject: Re: Replay field size in AH Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk And what is the state of the Grand Unified ESP spec? (Is there ANY AH spec anymore? I thought there wasn't.) At 02:13 PM 2/8/97 -0500, you wrote: >I'd like to hear from Jeff Schiller and the WG chairs re this still open >issue. My recollection is that there was supposed to be a small meetng to >reolve this after the last IPSEC WG meeting in San Jose. I observed that >we had two variables affecting aligmment: sequence number size and HMAC >size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to >reduce the number of variables affecting alignment, but I don't recall a >decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to >nail this down so that the grand unified AH and ESP specs can proceed. > >Steve > > > > 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 Sun Feb 9 15:45:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03674 for ipsec-outgoing; Sun, 9 Feb 1997 15:36:57 -0500 (EST) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Derrell Piper'" Subject: RE: replay field size Date: Sun, 9 Feb 1997 15:42: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 ESP ad AH _should_ be very similar and thus utilize the same features. Having one use a 32-bit replay counter and the other use a 64-bit one is silly as Derrell stated. If 64-bit alignment is required, as in IPv6, then padding should be appended to the end of the header if it is needed due to the size of the digest algorithm used. Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention) released with a 64-bit replay counter if so many of us objected? Furthermore, why wasn't a generic digest algorithm RFC released (HMAC-x Authentication) instead? We must standardize the common elements of our IPSEC protocols. Things like Replay Counter, HMAC, Digest Algorithms, Cipher Algorithms, generation of Keys from keying material. All of these common elements should be the same for all 'transforms' and not have to be re-defined/re-invented in every transform RFC. Can you imagine every cipher algorithm defining a different way to generate its keys and IV from the keying material? We should be able to just plug in a new cipher algorithm and a new digest algorithm without having to re-invent the wheel. Just plug in their identifiers and go...The common RFCs (ESP, AH, IPSEC-DOI) should define how to this without having to write a new transform RFC. This way we do not need to create a new transform RFC for every combination of parameters. For example, 3DES-Replay-HMAC-SHA1-LZS, has five parameters; cipher algorithm, replay, keyed function, digest algorithm, and compression algorithm. With five parameters we can have quite a lot of transform RFCs. Cipher Algorithm: None, DES, 3DES, RC5, Blowfish, IDEA Replay Protection: No Replay, Replay Keyed Function: None, Keyed, HMAC Digest Algorithm: None, MD5, SHA1, Tiger Compression Algorithm: None, LZS, GZIP 6 * 2 * 3 * 4 * 3 = 432 different transform RFC combinations!!! ---------- From: Derrell Piper[SMTP:piper@tgv.com] Sent: Saturday, February 08, 1997 7:45 PM To: ipsec@tis.com Subject: replay field size There was clear consensus at the ANX IPSEC bakeoff last week to make the size of the replay field 32-bits for both AH and ESP. If we _must_ have alignment for IPv4 IPSEC then the additional bits should be specified as alignment. No one wants to do 64-bit math for replay computation. It's silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I don't see the point of aligning the fields just to keep the protocol consistent with IPv6. I don't think this issue needs the Security AD to resolve. I think we already have consensus. Let's hear now from anyone who absolutely must have 64 bits or else move to revise AH and ESP to reflect consensus. We have much more interesting things to argue about. Derrell From owner-ipsec Sun Feb 9 18:27:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04393 for ipsec-outgoing; Sun, 9 Feb 1997 18:22:25 -0500 (EST) Date: Sun, 9 Feb 97 22:57:21 GMT Standard Time From: Ran Atkinson Subject: RE: replay field size To: "'ipsec@tis.com'" Cc: rja@inet.org X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Sun, 9 Feb 1997 15:42:07 -0500 Roy Pereira wrote: > Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention) > released with a 64-bit replay counter if so many of us objected? Because contrary to your assertions, there were NOT (repeat NOT) many objections to the 64-bit counter _during WG Last Call_. A very small number of people do NOT constitute "many". Process aside, the technical merit is slight. The amount of code needed for 2 replay sizes is clearly small (evidence some of the conforming implementations that existed prior to Last Call). The reason last call exists is to provide a "last" opportunity to object before things move forward to standards-track status. Input needs to arrive during the Last Call period, not afterwards. Participants are expected to remain current with the drafts all the time, last calls live at least a week so that folks can have a chance to re-read the draft before it proceeeds. If folks do not take the time to make their specific issues known to the WG chairs during last call, that is the choice of those individuals not the fault of the chair(s). > Furthermore, why wasn't a generic digest algorithm RFC released > (HMAC-x Authentication) instead ? The WG chose to proceed in the way it has. The changes Steve Kent has proposed would increase the fixed structure to both AH and ESP. If the WG decides to accept his edited drafts for Draft Standard, then a different approach can be employed down the road. At this point, a crucial consideration is avoiding making existing conforming implementations suddenly non-conforming by issuance of new RFCs. My understanding has always been that Steve's changes don't make existing conforming implementations suddenly non-conforming. > We should be able to just plug in a new cipher algorithm and a new > digest algorithm without having to re-invent the wheel. Just plug in > their identifiers and go... There _is_ more to it than just identifiers. Different algorithms have different modes and different resulting data sizes and IVs and so forth. With AH HMAC SHA-1 there was the question raised of using the standard 160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output. If one truncates, then the method/process of truncation needs to be openly and clearly specified. Just assigning identifiers will tend NOT lead to interoperable implementations. Additional structure to the base specifications will help, but is probably not a panacea. Ran rja@Inet.org From owner-ipsec Sun Feb 9 18:28:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04401 for ipsec-outgoing; Sun, 9 Feb 1997 18:24:55 -0500 (EST) Date: Sun, 9 Feb 97 23:23:24 GMT Standard Time From: Ran Atkinson Subject: Re: Replay field size in AH To: ipsec@tis.com Cc: rja@inet.org, Rodney Thayer X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.16.19970209105421.3847cd10@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, My understanding has never been that AH would go away. AH and the proposed "ESP without encryption" do not have identical semantics. My understanding has always been that existing conforming implementations of AH/ESP would not be made non-conforming by any of the changes that Steve Kent is proposing. Ran rja@Inet.org From owner-ipsec Sun Feb 9 20:36:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA04949 for ipsec-outgoing; Sun, 9 Feb 1997 20:31:59 -0500 (EST) Message-Id: <3.0.32.19970209202505.00688254@netrix.lkg.dec.com> X-Sender: mthomas@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Sun, 09 Feb 1997 20:25:34 -0500 To: ipsec@tis.com From: Matt Thomas Subject: Re: replay field size Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:44 PM 2/8/97 -0800, Derrell Piper wrote: >There was clear consensus at the ANX IPSEC bakeoff last week to make the >size of the replay field 32-bits for both AH and ESP. If we _must_ have >alignment for IPv4 IPSEC then the additional bits should be specified as >alignment. No one wants to do 64-bit math for replay computation. It's >silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I >don't see the point of aligning the fields just to keep the protocol >consistent with IPv6. IPv6 headers need to be 8-byte aligned. Thus AH header must be a multiple of 8-bytes in length. For IPv4, a multiple of 4-bytes is fine. The AH data doesn't have to be 8-byte aligned. [The destination option header comes after the AH and can contain options that require 8-byte alignment]. >I don't think this issue needs the Security AD to resolve. I think we >already have consensus. Let's hear now from anyone who absolutely must >have 64 bits or else move to revise AH and ESP to reflect consensus. We >have much more interesting things to argue about. All I want is that the AH header in IPv6 packets to be a multiple of 8-bytes in length. A 32-bit replay field is fine. I don't even care where the padding is (it would be nice if it were in a standard place), just that it exists. -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sun Feb 9 21:28:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05177 for ipsec-outgoing; Sun, 9 Feb 1997 21:25:00 -0500 (EST) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Ran Atkinson'" Subject: RE: replay field size Date: Sun, 9 Feb 1997 21:30:05 -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 >> We should be able to just plug in a new cipher algorithm and a new >> digest algorithm without having to re-invent the wheel. Just plug in >> their identifiers and go... >There _is_ more to it than just identifiers. Different algorithms have >different modes and different resulting data sizes and IVs and so forth. >With AH HMAC SHA-1 there was the question raised of using the standard >160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output. >If one truncates, then the method/process of truncation needs to >be openly and clearly specified. Just assigning identifiers will >tend NOT lead to interoperable implementations. Additional structure >to the base specifications will help, but is probably not a panacea. Ran, my point was that a very large portion of the existing transform drafts contain the exact same words and definitions. Yes, more than an identifier would be required for some algorithms, but again there exists quite a lot of the specification wording that overlap. Rules for such things as truncating a digest (or padding it) would be better defined in a common draft (ESP and/or AH). If there was a common method to obtain a variable length IV and variable length keys from keying material, then this information would not have to be in every transform draft. Why should all ESP transform drafts list the ESP structure, define replay protection, and define how to obtain keying? These common specification sections only need to be specified once. From owner-ipsec Sun Feb 9 23:43:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05776 for ipsec-outgoing; Sun, 9 Feb 1997 23:37:04 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Feb 1997 23:36:18 -0500 To: Roy Pereira From: Stephen Kent Subject: RE: replay field size Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, The goal of producing the new AH and ESP specs is to avoid the need for each transform to include all of the repetitive text that you identified as redundant. To that end, I endorse the notion of adopting uniform counter sizes, padding, IV specification options, etc. We are trying to do that in the new specs and that's why I wanted to get a definitive answer re the replay counter size. Steve From owner-ipsec Sun Feb 9 23:43:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05775 for ipsec-outgoing; Sun, 9 Feb 1997 23:37:03 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.16.19970209105421.3847cd10@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Feb 1997 23:33:32 -0500 To: Rodney Thayer From: Stephen Kent Subject: Re: Replay field size in AH Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The AH and ESP specs have been redone, but need another pass to deal with some outstanding issues, e.g., the counter size issue that is still being debated in messages from this weekend. The IPSEC architecture document needs considerably more work. As for AH, no, it is not going away, since, as Ran pointed out, it still offers slightly different features as compared to ESP without encryption. However, the motivations for using AH re more narrow than before, due to the changes in ESP. Steve From owner-ipsec Mon Feb 10 08:29:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08436 for ipsec-outgoing; Mon, 10 Feb 1997 08:23:38 -0500 (EST) Message-Id: <9702072051.AA79389@aurora.cis.upenn.edu> To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: Path MTU Discovery Date: Fri, 07 Feb 1997 15:50:42 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199702071815.KAA01378@kebe.eng.sun.com>, Dan McDonald writes: > >This outer packet is now a datagram originating from the router. It can >fragment as it sees fit. Yes, it may violate the spirit of no intermediate >fragmentation, but it certainly is legal. This is legal in IPv6 too, where >there is an implicit DF bit on all packets. I didn't question its legality. If the endpoint is trying to do PathMTU discovery and we care to respect this and we must copy the DF bit. If we don't, we can just ignore it and none will be the wiser; however, i can see (pathological maybe) situations where fragmentation happens between every tunnel endpoint because noone respects the DF bit. >I question your choice of abstraction. How do you configure these multiple >tunnels? Or are they automatic tunnels ala. IPv6's :: syntax? >Since you probably have to configure the tunnels, you might as well provide a >halfway decent abstraction to take into account Path MTU ratcheting down. Extended routing entries. All the relevant information (for IP encapsulation, the IP addresses; for AH/ESP the SPIs) is contained in the routing table. Or you mean something different >OTOH it uses defined behavior and available underspecifications to make >implementations (IMHO) less complex. Security holes come out of complexity, >just ask any sendmail user. I doubt either approach (ViF-MTU or "my" way) is overly complex. And i would argue that it is necessary for good network behaviour. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMvuVor0pBjh2h1kFAQG4BAP/cGxO5qo+0SVgnNJGCFc/2UUEX8oikPup jusn2O6EcX2tOwWXom50sqbM9iVaACU1QvXdJPnxafhXsxUkrqG9P8fJrtVc5y/W EZHz/4Udr36gZgwK98VoU3BIX6TkgwDZbmch/OfKAG/+zDwB1rV8ZelPHxuYNGTk zy0Gv06+b/Q= =Rt2u -----END PGP SIGNATURE----- From owner-ipsec Mon Feb 10 08:34:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08504 for ipsec-outgoing; Mon, 10 Feb 1997 08:31:36 -0500 (EST) Date: Sat, 8 Feb 1997 07:37:08 -0500 (EST) Message-Id: <199702081237.HAA24954@carp.morningstar.com> From: Ben Rogers To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis), ipsec@tis.com Subject: Re: Path MTU Discovery Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > > Well, wouldn't ignoring the DF bit defeat the original endpoint's > > PathMTU ? > > DF applies to the IP datagram on which it is set. DF is not inherited by any > encapsulating IP headers. Hate to be picky, but RFC1853 states: Don't Fragment copied from the inner IP header. This allows the originator to control the level of performance tradeoffs. See "Tunnel MTU Discovery". So, in fact, the IP-in-IP header requires that DF bit be set, and neither AH, nor ESP will touch this part of the header. Of course, if you would like to tunnel using a protocol other than IP in IP, that is your prerogative... Are there people who do this? > > > So one can establish multiple tunnels to different (or the same) hosts and > > use the same ViF. In this case, if you receive an ICMP toobig, you don't > > know who if "belongs" to until you parse the internal packet a bit and > > check the destination/SPI of the original packet. And then of course you > > can't (shouldn't) change the "MTU" of the ViF. > > I question your choice of abstraction. How do you configure these multiple > tunnels? Or are they automatic tunnels ala. IPv6's :: syntax? > Since you probably have to configure the tunnels, you might as well provide a > halfway decent abstraction to take into account Path MTU ratcheting down. Hopefully, if each tunnel properly supports Path MTU and "soft state", the MTU should propagate upwards. Personally I wonder what the point is in requiring Path MTU be done, while only recommending that soft state be kept. (Perhaps RFC1853 should be updated to require the keeping of soft state?) Then, we would see everything perform nicely, a la: Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ... Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24 bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes. Packet 1: 1500 bytes, DF set Tunneled by R1 (1544 bytes) (Dropped) Packet 2: 1500 bytes, DF set R1 sends ICMP too big with size limit 1456 to host Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a "growing" MTU) Packet 3: 1456 bytes, DF set Tunneled by R1 (1500 bytes) Tunneled by R2 (1544 bytes) (Dropped) Packet 4: 1456 bytes, DF set Tunneled by R1 (1500 bytes) R2 sends ICMP too big with size limit 456 to R1 Tunneled by R2 (1544 bytes) (Dropped) Packet 4: 1456 bytes, DF set R1 sends ICMP too big with size limit 412 to host Tunneled by R1 (1500 bytes) R2 sends ICMP too big with size limit 456 to R1 Tunneled by R2 (1544 bytes) (Dropped) Packet 5: 412 bytes, DF set Tunneled by R1 (456 bytes) Tunneled by R2 (500 bytes) Received. ben From owner-ipsec Mon Feb 10 08:58:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08699 for ipsec-outgoing; Mon, 10 Feb 1997 08:55:42 -0500 (EST) Message-Id: <3.0.32.19970208220940.00695cc8@netrix.lkg.dec.com> X-Sender: mthomas@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Sat, 08 Feb 1997 22:10:27 -0500 To: Derrell Piper From: Matt Thomas Subject: Re: replay field size Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:44 PM 2/8/97 -0800, Derrell Piper wrote: >There was clear consensus at the ANX IPSEC bakeoff last week to make the >size of the replay field 32-bits for both AH and ESP. If we _must_ have >alignment for IPv4 IPSEC then the additional bits should be specified as >alignment. No one wants to do 64-bit math for replay computation. It's >silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I >don't see the point of aligning the fields just to keep the protocol >consistent with IPv6. IPv6 headers need to be 8-byte aligned. Thus AH header must be a multiple of 8-bytes in length. For IPv4, a multiple of 4-bytes is fine. The AH data doesn't have to be 8-byte aligned. [The destination option header comes after the AH and can contain options that require 8-byte alignment]. >I don't think this issue needs the Security AD to resolve. I think we >already have consensus. Let's hear now from anyone who absolutely must >have 64 bits or else move to revise AH and ESP to reflect consensus. We >have much more interesting things to argue about. All I want is that the AH header in IPv6 packets to be a multiple of 8-bytes in length. A 32-bit replay field is fine. I don't even care where the padding is (it would be nice if it were in a standard place), just that it exists. Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Mon Feb 10 11:07:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09945 for ipsec-outgoing; Mon, 10 Feb 1997 11:05:32 -0500 (EST) X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Mon, 10 Feb 1997 09:01:08 -0700 (MST) From: Oliver Spatscheck To: Ben Rogers cc: Dan McDonald , "Angelos D. Keromytis" , ipsec@tis.com Subject: Re: Path MTU Discovery In-Reply-To: <199702081237.HAA24954@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sat, 8 Feb 1997, Ben Rogers wrote: > >Then, we would see everything perform nicely, a la: > >Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ... > >Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24 >bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes. This example only works for IPv4. IPv6 requires a MINIMUM MTU of 576 Octets. Which requieres your second router to do link specific fragmentation. This schouldn't be a problem in your scenario since r2 has to do link specific fragmentation anyway (MTU 500 Byte) . However if you assume a tunneling router with a link MTU of 580 byte and you add IP in IP the router suddenly has to do link specific fragmentation. Something he didn't do before. Oliver > >Packet 1: 1500 bytes, DF set > Tunneled by R1 (1544 bytes) (Dropped) > >Packet 2: 1500 bytes, DF set > R1 sends ICMP too big with size limit 1456 to host > Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a > "growing" MTU) > >Packet 3: 1456 bytes, DF set > Tunneled by R1 (1500 bytes) > Tunneled by R2 (1544 bytes) (Dropped) > >Packet 4: 1456 bytes, DF set > Tunneled by R1 (1500 bytes) > R2 sends ICMP too big with size limit 456 to R1 > Tunneled by R2 (1544 bytes) (Dropped) > >Packet 4: 1456 bytes, DF set > R1 sends ICMP too big with size limit 412 to host > Tunneled by R1 (1500 bytes) > R2 sends ICMP too big with size limit 456 to R1 > Tunneled by R2 (1544 bytes) (Dropped) > >Packet 5: 412 bytes, DF set > Tunneled by R1 (456 bytes) > Tunneled by R2 (500 bytes) > Received. > > > >ben > -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMv9GRjnVPgUZ7uZJAQGDWwP/aFlUYlzPN0AqyknfCEF4jKK/TWtGPn9H PU12zESdKmmzA2pRyZMo7EEFLU30Z2256WeuZsVVlbbJD4zZ4vJvNhIl31WCDFPX o6WBv+jLFemTSQOKfF8dlUtJRhQr4erh73pPL4IFxy2Xw5g4gyRXQuqG0mJvvdR/ 8U3NDPUFHdE= =j/qJ -----END PGP SIGNATURE----- From owner-ipsec Mon Feb 10 11:32:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10166 for ipsec-outgoing; Mon, 10 Feb 1997 11:31:06 -0500 (EST) From: Tim Bass (IETF) Message-Id: <199702101632.LAA00253@linux.silkroad.com> Subject: Re: replay field size To: ipsec@tis.com Date: Mon, 10 Feb 1997 11:32:50 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >From the RFCs: For IPv6, options (with padding) must be on 64 bit (8 byte boundaries). For IPv4, multibyte options are not required to adhere to an alignment specification. Tim From owner-ipsec Mon Feb 10 20:08:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13246 for ipsec-outgoing; Mon, 10 Feb 1997 20:02:39 -0500 (EST) Message-ID: <01BC1774.B4080180@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com'), rja@inet.org ('Ran Atkinson') Subject: RE: replay field size Date: Mon, 10 Feb 1997 17:05:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Roy here.. I first objected to this in a post to the list on September 26th 1996. Derrell Piper complained in a post on October 3rd. C. J. Lee posted on 27 Nov. saying, "To me, different replay counter size for different AH/ESP transforms would definitely complicated an IPsec implementation in terms of storing and using the per session (SA) replay checking state ..." Ran, you made some argument about alignment (which is irrelevant to replay) on the 9th of December. You claimed then that you explained your objection on the list, but I couldn't find it in the digest. Then Roy complained again on the 15th of January. Now Naganand is questioning it. And I argued with you, Ran, in private mail about this and the need for negotiating replay window size. I also recall most people implementing it, at least that I knew, questioning a 64 bit replay field. The only defense of this I found in the digest was by Ran. I don't know of anyone else actually implementing this who ever thought a 64 bit replay field was a good idea.... Granted my exposure is limited, but not that limited. >>Process aside, the technical merit is slight. The amount of code >>needed for 2 replay sizes is clearly small This is a matter of opinion and is also irrelevant. Any amount of code added to support a "feature" that a majority of implementers think is wrong is too much code. >>Process aside, the technical merit is slight. The technical merit for doing a 64 bit replay field? Sorry I couldn't resist, but it does lead me to my next point. It seems to me that the process here is broken, and I don't know what to do about it. When people complain about an annoyance that has no valid merit that anyone can think of, and the annoyance goes through anyway, then we have a broken process. And I know I'm going to get flamed for saying that it is an annoyance, but it is. If you're not implementing this on a 64 bit architecture and you're trying to share your replay code with ESP, then it is a real pain, plain and simple. It think that a lot of people implementing the transforms will be in this boat. This shouldn't have made it to last call. In fact, I have a process question. I found the last call announcement in the archives on for the AH documents and it was on 7 Aug 96. The document that went to last call was draft-ietf-ipsec-ah-hmac-md5-01. I happen to have a copy of that document and it has a 32 bit replay field... hmmmm... Then an update was posted on the 30th of August. This contained the 64 bit replay field. The update said the -02 documents were based on comments received during last call. A 64 bit replay field was not discussed on the list, and of course no one complained because it was a 32 bit field as far as we knew. What do you do if a document goes through revisions like this after last call? I bet if we took a vote by people implementing the transforms of a 64 bit vs. a 32 bit replay field, we'd find results different than what is in the documents. -Rob Adams Cisco Systems ---------- From: Ran Atkinson[SMTP:rja@inet.org] Sent: Sunday, February 09, 1997 2:57 PM To: 'ipsec@tis.com' Cc: rja@inet.org Subject: RE: replay field size --- On Sun, 9 Feb 1997 15:42:07 -0500 Roy Pereira wrote: > Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention) > released with a 64-bit replay counter if so many of us objected? Because contrary to your assertions, there were NOT (repeat NOT) many objections to the 64-bit counter _during WG Last Call_. A very small number of people do NOT constitute "many". Process aside, the technical merit is slight. The amount of code needed for 2 replay sizes is clearly small (evidence some of the conforming implementations that existed prior to Last Call). The reason last call exists is to provide a "last" opportunity to object before things move forward to standards-track status. Input needs to arrive during the Last Call period, not afterwards. Participants are expected to remain current with the drafts all the time, last calls live at least a week so that folks can have a chance to re-read the draft before it proceeeds. If folks do not take the time to make their specific issues known to the WG chairs during last call, that is the choice of those individuals not the fault of the chair(s). > Furthermore, why wasn't a generic digest algorithm RFC released > (HMAC-x Authentication) instead ? The WG chose to proceed in the way it has. The changes Steve Kent has proposed would increase the fixed structure to both AH and ESP. If the WG decides to accept his edited drafts for Draft Standard, then a different approach can be employed down the road. At this point, a crucial consideration is avoiding making existing conforming implementations suddenly non-conforming by issuance of new RFCs. My understanding has always been that Steve's changes don't make existing conforming implementations suddenly non-conforming. > We should be able to just plug in a new cipher algorithm and a new > digest algorithm without having to re-invent the wheel. Just plug in > their identifiers and go... There _is_ more to it than just identifiers. Different algorithms have different modes and different resulting data sizes and IVs and so forth. With AH HMAC SHA-1 there was the question raised of using the standard 160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output. If one truncates, then the method/process of truncation needs to be openly and clearly specified. Just assigning identifiers will tend NOT lead to interoperable implementations. Additional structure to the base specifications will help, but is probably not a panacea. Ran rja@Inet.org From owner-ipsec Mon Feb 10 21:01:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13472 for ipsec-outgoing; Mon, 10 Feb 1997 20:55:39 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702110156.RAA06362@kebe.eng.sun.com> Subject: Re: replay field size To: ipsec@tis.com Date: Mon, 10 Feb 1997 17:56:28 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I came in on this one late, folks. Apparently I was shoved on the TIS "bounce" list. P*sses me off when I miss things. If I rehash anything here, I apologize. Anyway, w.r.t. replay counters, and what have you. Please keep in mind a couple of things: 1.) Rememember that when a replay counter wraps, you must rekey. I dunno how fast 2^32 packets happens, but is that enough for a given key lifetime? 2.) IPv6 options MUST, I repeat MUST be 8-byte aligned. A 32-bit SPI + a 32-bit replay + a 160-bit SHA output is NOT 32-bit aligned. OTOH if you change the replay to 64-bits, you're 64-bit aligned. 3.) I'm assuming replay counter size is a property of the Security Association being used. Since I have to parse the rest of the AH based on SA information, why is the bit of code to handle replay counters any different than the code handling the authentication data, or whether there's replay protection in the first place? I'll admit replay protection isn't where my attention is currently, but I just don't see it as that hard of a problem. Just bang together the rocks together, guys! Dan From owner-ipsec Mon Feb 10 22:52:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14089 for ipsec-outgoing; Mon, 10 Feb 1997 22:52:16 -0500 (EST) Date: Tue, 11 Feb 97 03:46:02 GMT Standard Time From: Ran Atkinson Subject: Re: Path MTU Discovery To: Ben Rogers , Dan McDonald Cc: "Angelos D. Keromytis" , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199702081237.HAA24954@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP RFCs. This is not an accident. With IPsec, one is not performing IP-in-IP. Rather, one is performing IP-in-AH or IP-in-ESP. The IP-in-IP RFCs don't include IPsec within their scope. It was quite intentional that this was done. It is equally intentional that the IPsec RFCs haven't been citing the IP-in-IP RFCs. In effect, ESP tunnel mode uses the outer IP as a link-layer. Copying DF bit is not prohibited for IPsec tunneling, but neither is it required for IPsec tunneling. Ran rja@inet.org who wrote the relevant IPsec RFCs... From owner-ipsec Mon Feb 10 23:59:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA14341 for ipsec-outgoing; Mon, 10 Feb 1997 23:57:47 -0500 (EST) Date: Tue, 11 Feb 97 03:53:56 GMT Standard Time From: Ran Atkinson Subject: RE: replay field size To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <01BC1774.B4080180@Tastid.Cisco.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 10 Feb 1997 17:05:26 -0800 Rob Adams wrote: > I first objected to this in a post to the list on September 26th 1996. > Derrell Piper complained in a post on October 3rd. C. J. Lee posted on > 27 Nov. saying, "To me, different replay counter size for different AH/ESP > transforms would definitely complicated an IPsec implementation in terms of > storing and using the per session (SA) replay checking state ..." The document was gone from the WG and into the IESG's hands prior to any of the comments that you cite. > Then Roy complained again > on the 15th of January. Now Naganand is questioning it. > And I argued with you, Ran, in private mail about this and > the need for negotiating replay window size. I also > recall most people implementing it, at least that I knew, > questioning a 64 bit replay field. The notes from you, CJ Lee, and more recently Naganand and Roy were all _after_ the IESG had already approved the draft for Proposed Standard RFC. At that point, the document was in the hands of the IESG, not within the jurisdiction of the co-chair(s). The reason for the delayed publication is that the RFC Editor has a very long latency between approval and publication just now (which I'm told is being fixed so that the latency will diminish in future). > The technical merit for doing a 64 bit replay field? A 64-bit replay field permits longer times between rekey intervals. This can be useful if one has a strong algorithm. If one has a weak algorithm, a shorter time between rekey intervals might be preferable. Replay size and rekey intervals are not entirely unrelated. It is up to the WG to decide whether the benefit/cost ratio makes sense. Let me also specifically disclaim that the 64-bit replay or the variable-size replay was my idea. Neither was my idea or my proposal It was proposed by someone else. > It seems to me that the process here is broken, > and I don't know what to do about it. Talk with either of the co-chairs and/or the Security AD, Jeff Schiller . Within reason, I'm happy to telephone people within the US/Canada if provided with a time and phone number to telephone and a topic. Alternately, one could raise this as a matter for the POISED WG to take up in revising the process documents. > When people complain about an annoyance that has > no valid merit that anyone can think of, and the > annoyance goes through anyway, then we have a > broken process. By your count, there were 4 complaints to the list in a working group having something like 70 participants. This is not a large percentage. This is one reason why it IS important for people to speak up on the list so that the consensus is readily clear right away. When few people comment either way on any issue, it can be very difficult to evaluate where consensus lies. > It think that a lot of people implementing the > transforms will be in this boat. This shouldn't > have made it to last call. Last Call is a mechanism for people to raise objections to documents moving forward. Not all Last Calls go forward; some fail, including some in this WG. It is very very important that people speak up during the Last Call period, not afterwards. One voice of complaint to the WG list during a Last Call does not represent a clear consensus. It is also important to note that Last Call comments aren't required to be sent to the list. Unicast comments to the Chairs during WG Last Call do get considered as well. I don't recall many comments during either of the AH HMAC WG Last Calls. There are 2 separate Last Calls before a standards-track document goes out as RFC from a Working Group. The first is done by the WG Chair(s) at the point the chair(s) believe there is probably rough consensus within WG members that a document should advance to standards- track RFC. If that proves to be true, then the chair(s) pass the document (I-D) on to the appropriate IESG Area Director for their review and for the review of the IESG as a whole. The IESG holds a formal IETF Last Call before they vote (yes, the IESG formally votes on each I-D). Based on input received by the IESG (often privately, not necessarily from any mailing list), a draft can change after IESG Last Call and prior to publication. In many cases, changes happen -- usually for editorial reasons. > In fact, I have a process question. I found the last call announcement > in the archives on for the AH documents and it was on 7 Aug 96. > The document that went to last call was draft-ietf-ipsec-ah-hmac-md5-01. > I happen to have a copy of that document and it has a 32 bit replay field... > hmmmm... Then an update was posted on the 30th of August. This > contained the 64 bit replay field. The update said the -02 documents > were based on comments received during last call. A 64 bit replay field > was not discussed on the list, and of course no one complained because > it was a 32 bit field as far as we knew. > > What do you do if a document goes through revisions like this after last call? Talk with the IESG, it was their Last Call that was announced on 7 August 1996. By the way, another revision that happened is that AH HMAC SHA-1 became elective-to-implement because the IESG objected to having both AH HMAC MD5 and AH HMAC SHA-1 as mandatory-to-implement. This fact was also reflected in the revised I-Ds that went out last Fall and hasn't been a secret of any sort. In some cases, documents change as a result of WG Last Call before proceeding to IETF Last Call. In those cases, new I-Ds are issued online and announced to the IETF list and normally to the WG list as well so that people know the drafts have changed. Once a document is in the IESG's hands, it is out of the hands of the WG chair(s). Just a guess, but if this was bothersome, the closed room process by which the IPv6 spec came out of thin air (IPv6 being not exactly any of the IPng proposals on the table at the time) must have also been fairly annoying to you. > I bet if we took a vote by people implementing the > transforms of a 64 bit vs. a 32 bit replay field, > we'd find results different than what is in the documents. Well, the IETF doesn't officially "vote", but it does seems constructive to have a Straw Poll on this to try to put it to bed. If people would please send email to me and Paul Lambert on this, we'll try to settle it now. It is not a requirement that one be an implementer to participate in the straw poll, but it is a requirement that one be an active member of the IPsec WG. Attendance at IETF meetings is not required, though that certainly does indicate activity. While we're at it, it also seems like a good time to measure the consensus on the matter of SHA-1 truncation. Hugo has proposed trucating the SHA-1 output to 128 bits from 160 bits for use with AH. There wasn't much discussion on this on the list, thought Hugo raised the question at the last IETF meeting. The questions are: Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) If they have a fixed size counter, what size should it be? (32 bits/64 bits) Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Please send your response within the next week. Please DO send a response so that consensus is crystal clear. We need to resolve this issue so that Steve Kent's documents can be edited accordingly. Paul or I will post a summary about a week from now. Note that if changes are made, it could easily take another 4-6 months for a revised RFC to appear online after IESG approval. Also, the revised drafts will need to go through WG Last Call again. I don't think any of these are problems, but I don't want people to be surprised and feel like they need to send out heated email. :-) Best wishes, Ran rja@inet.org From owner-ipsec Tue Feb 11 00:03:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14384 for ipsec-outgoing; Tue, 11 Feb 1997 00:02:19 -0500 (EST) Date: Tue, 11 Feb 97 04:58:44 GMT Standard Time From: Ran Atkinson Subject: Re: Path MTU Discovery To: "Angelos D. Keromytis" , Ran Atkinson Cc: Ben Rogers , Dan McDonald , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <9702110403.AA85679@aurora.cis.upenn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 10 Feb 1997 23:02:35 -0500 "Angelos D. Keromytis" wrote: > I think that, if not mandate copying the DF bit, the new drafts should > at least present the benefits of doing so and provide guidelines to > anyone who wants to have his implementation allow PathMTU. Or it could > be a separate document altogether. If one treats the outer IP/ESP as a link-layer, then not copying the DF bit does not break Path MTU Discovery. The MTU of the IPsec tunnel is defined by the IPsec implementation at present. In any event, I think it would be useful for the next set of drafts to be clear on this matter. I'm personally indifferent about what the final result is. Ran rja@inet.org speaking only for himself From owner-ipsec Tue Feb 11 07:46:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16786 for ipsec-outgoing; Tue, 11 Feb 1997 07:44:54 -0500 (EST) Date: Tue, 11 Feb 1997 07:44:54 -0500 (EST) Message-Id: <9702110403.AA85679@aurora.cis.upenn.edu> To: Ran Atkinson Cc: Ben Rogers , Dan McDonald , ipsec@tis.com Subject: Re: Path MTU Discovery From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , Ran Atkinson wri tes: > > In effect, ESP tunnel mode uses the outer IP as a link-layer. Copying >DF bit is not prohibited for IPsec tunneling, but neither is it required >for IPsec tunneling. I think that, if not mandate copying the DF bit, the new drafts should at least present the benefits of doing so and provide guidelines to anyone who wants to have his implementation allow PathMTU. Or it could be a separate document altogether. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMv/vWr0pBjh2h1kFAQGX4gQAqWztVD0sSQ5Mn12W3Vq1IWg94XhA29Eo X424Vc0se7CMe8SKaHoMlH6KekOazcI6wK/UPj3xnGPCJCNXf8jSf9/JjlONchTo 1jKch48MWPRC2NaeHpc05Zay9lIR7Ett7S22ZhrPHU1tOKCRlEWs+zxGdKo2T5QA +rCt1gpl5NY= =0AT2 -----END PGP SIGNATURE----- From owner-ipsec Tue Feb 11 07:46:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16800 for ipsec-outgoing; Tue, 11 Feb 1997 07:46:23 -0500 (EST) Date: Tue, 11 Feb 1997 17:17:48 +1100 (EST) From: Kent Fitch X-Sender: fit106@commsun To: ipsec@tis.com Subject: ANX IPSEC bakeoff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 04:44 PM 2/8/97 -0800, Derrell Piper wrote: > >There was clear consensus at the ANX IPSEC bakeoff last week to ... Are there any details available of what happened at this bakeoff? Kent Fitch Ph: +61 6 276 6711 ITS CSIRO Canberra Australia kent.fitch@its.csiro.au From owner-ipsec Tue Feb 11 09:16:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17389 for ipsec-outgoing; Tue, 11 Feb 1997 09:14:02 -0500 (EST) Date: Tue, 11 Feb 1997 09:17:01 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702111417.JAA10584@argon.ncsc.mil> To: rja@inet.org, palamber@us.oracle.com Subject: RE: replay field size straw poll Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The questions are: > > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) > If they have a fixed size counter, what size should it be? (32 bits/64 bits) > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) > 1) AH and ESP should have a fixed size replay counter (Yes). Rationale: I don't see any incremental benefit in being able to negotiate a replay counter size online, or in allowing different transform documents to specify different sizes. The KISS principle says make it fixed. 1a) AH and ESP should have the same fixed size. Rationale: no benefit in different sizes. 64 bit alignment can be achieved by MBZ pad fields. 2) The fixed size should be 32 bits. Rationale: is there any incremental benefit in replay protection beyond 4G packets? (4K seconds, or over an hour, at 1M packets/second). Is it too big a burden to refresh keys every 4G packets, even if you believe the crypto algorithm is strong enough to use for longer? 3) SHA should be truncated to 128 bits. (Yes) Rationale: I'm not a cryptographer, but I am persuaded by Hugo's arguments that truncating HMAC-SHA to 128 bits is beneficial to security robustness. At worst, I don't believe truncating SHA could possibly result in a less secure HMAC than using MD5. From owner-ipsec Tue Feb 11 09:51:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17590 for ipsec-outgoing; Tue, 11 Feb 1997 09:51:13 -0500 (EST) Message-Id: <3.0.32.19970211084836.009117e0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 08:54:20 -0500 To: Kent Fitch , ipsec@tis.com From: Robert Moskowitz Subject: Re: ANX IPSEC bakeoff Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:17 PM 2/11/97 +1100, you wrote: >> At 04:44 PM 2/8/97 -0800, Derrell Piper wrote: >> >There was clear consensus at the ANX IPSEC bakeoff last week to ... > >Are there any details available of what happened at this bakeoff? > They will be posted early next week. We first want a group review of our report and consensus signoff by all parties on what we learned. Our lawyers tell us this is the way of business ;) Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Feb 11 15:39:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19770 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:13 -0500 (EST) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Ran Atkinson'" Subject: RE: replay field size Date: Tue, 11 Feb 1997 14:32:50 -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 > >>Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't >>Care) Yes. >>If they have a fixed size counter, what size should it be? (32 bits/64 bits) Don't Care. Although, a 32-bit replay field might be easier to code on a 32-bit CPU than a 64-bit replay. I'm not sure since I haven't seen any sample code for 64-bit replay protection. >>Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't >>Care) No, I don't think that the digest size should be truncated to fit a 64-bit alignment. That is not what the digest is intended to provide. Padding would be preferable. From owner-ipsec Tue Feb 11 15:39:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19741 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:01 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702111417.JAA10584@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 14:50:39 -0500 To: dpkemp@missi.ncsc.mil (David P. Kemp) From: Stephen Kent Subject: RE: replay field size straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk David, I concurr with all three of your points re anti-replay field size and hash size. I'd also like to add the observation that I think we will have errors in implementations of the anti-replay windows, because of the need for the modular arithmetic (since we are not starting the counters at 0 or 1). So, having a single size counter for both AH and ESP may further minimize the time it will take to get the bugs out of this code. As editor for the AH and ESP specs, based on the traffic I've seen this last 2 weeks, I'm planing to go with 32-bit counters for both and to assume that the HMAC value will be 128 bits, to help resolve the alignment problem. If there are strong objections to this tact, I'd like to hear by 2/14. Steve From owner-ipsec Tue Feb 11 15:39:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19797 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:18 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702111926.LAA13021@kebe.eng.sun.com> Subject: RE: replay field size To: ipsec@tis.com Date: Tue, 11 Feb 1997 11:26:45 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't > Care) No. Listen folks, it ain't that hard to build. Replay counter size is a function of what is negotiated in the SA. You have all the data right there. Use the information in the association and set your pointers accordingly. The annoyance of checking for variable-sized replay counters is lost in the noise of a CPU-hungry HMAC calculation. Even if you have hardware-assist on the HMAC, the memory access time will at least be dominant, if not overwhelming. Let's not forget IPv6 alignment requirements, too! Though admittedly, creative padding can fix this problem. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't > Care) Yes, simply because I trust Hugo's opinion on this. Dan From owner-ipsec Tue Feb 11 15:41:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19968 for ipsec-outgoing; Tue, 11 Feb 1997 15:39:02 -0500 (EST) From: Robert Glenn Date: Tue, 11 Feb 1997 15:43:11 -0500 (EST) Message-Id: <199702112043.PAA00838@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: Re: replay field size Cc: rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk 1. Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) I'm in favor of making replay prevention optional. I realize that this isn't keeping with KISS, but I remained unconvinced of the utility of replay prevention within IP and I'm concerned about the added complexity this field adds to the IPSEC process. Making this field optional can be done by making the field a fixed size and simply ignoring it when not in use instead of excluding it (non-fixed size=0). So for now, ...Don't Care with an inclination toward Yes. 2. If they have a fixed size counter, what size should it be? (32 bits/64 bits) I'd rather have 64 bits with the ability to negotiate the number of bits out of the 64 to use for re-keying purposes. Along these lines, 0 would be an allowable value. This could even be worded that you MUST support 0-32 bits and SHOULD support 33-64 bits. 3. Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Actually, I don't care, but I'm inclined to go with truncation. Rob G. From owner-ipsec Tue Feb 11 16:32:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20578 for ipsec-outgoing; Tue, 11 Feb 1997 16:29:38 -0500 (EST) Date: Tue, 11 Feb 97 16:27:43 EST From: mjo@tycho.ncsc.mil (Michael J. Oehler) Message-Id: <9702112127.AA27443@tarius.tycho.ncsc.mil> To: ipsec@tis.com Subject: RE: replay field size Cc: rja@inet.org, palamber@us.oracle.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >From: Ran Atkinson Date: Tue, 11 Feb 97 03:53:56 > > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) > If they have a fixed size counter, what size should it be? (32 bits/64 bits) > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) > 1. Permit optional replay counter. 2. 64 bit Replay Counter. A 64 bit replay field does not preclude an implementation from preforming a re-key sooner. The AH header will be 64 bit aligned without adding a reserved field which wastes bandwidth and in that spirit (in addition to Hugo's technical input). 3. Truncate the SHA-1 to 128 bits The format for MD5 and SHA will then be identical. Another conundrum -Mike From owner-ipsec Tue Feb 11 17:16:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20867 for ipsec-outgoing; Tue, 11 Feb 1997 17:13:43 -0500 (EST) Message-Id: <199702112214.RAA09176@smb.research.att.com> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs To: Stephen Kent cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: replay field size straw poll Date: Tue, 11 Feb 1997 14:14:20 -0800 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk I concurr with all three of your points re anti-replay field size and hash size. I'd also like to add the observation that I think we will have errors in implementations of the anti-replay windows, because of the need for the modular arithmetic (since we are not starting the counters at 0 or 1). So, having a single size counter for both AH and ESP may further minimize the time it will take to get the bugs out of this code. Since this isn't a sliding window counter (as the TCP sequence number is), I suspect that the two's-complement arithmetic that is now universally used will make most implementations just work. It wouldn't hurt to include a sample two lines of code showing the right way to do the comparison, however... From owner-ipsec Tue Feb 11 17:50:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21049 for ipsec-outgoing; Tue, 11 Feb 1997 17:47:16 -0500 (EST) Date: Tue, 11 Feb 97 17:48:33 EST From: "Whelan, Bill" Message-Id: <9701118557.AA855712066@netx.nei.com> To: ben@ascend.com, Dan.McDonald@Eng.sun.com, Ran Atkinson Cc: angelos@aurora.cis.upenn.edu, ipsec@tis.com Subject: Re[2]: Path MTU Discovery Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, >Ben, > > It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP >RFCs. This is not an accident. With IPsec, one is not performing IP-in-IP. >Rather, one is performing IP-in-AH or IP-in-ESP. The IP-in-IP RFCs don't >include IPsec within their scope. > >It was quite intentional that this was done. It is equally intentional >that the IPsec RFCs haven't been citing the IP-in-IP RFCs. Funny, but a couple of months back when I started a mailing list discussion due to my confusion about how to implement AH on a secure gateway, someone pointed me to IP-in-IP. Then it all made sense to me. The model I've been using is to compare the source and destination addresses to the tunnel end points. If they are not equal, use IP-in-IP then apply ESP/AH transport mode. You're right that the IPSec RFCs do not cite RFC 1853 specifically, but the text surrounding tunnel mode IPSec (as well as a lot of the mailing list discussion) sure looks like IP-in-IP to me! Bill Whelan From owner-ipsec Wed Feb 12 01:06:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA23069 for ipsec-outgoing; Wed, 12 Feb 1997 01:01:22 -0500 (EST) Date: Tue, 11 Feb 1997 22:04:54 -0800 (PST) From: Phil Karn Message-Id: <199702120604.WAA21035@servo.qualcomm.com> To: mjo@tycho.ncsc.mil CC: ipsec@tis.com, rja@inet.org, palamber@us.oracle.com In-reply-to: <9702112127.AA27443@tarius.tycho.ncsc.mil> (mjo@tycho.ncsc.mil) Subject: RE: replay field size Sender: owner-ipsec@ex.tis.com Precedence: bulk My opinions: Make the replay counters 32 bits for both AH and ESP. Should be plenty for any rational key lifetime, and the arithmetic is easier on compilers without "long long" data types... Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than MD-5... Phil From owner-ipsec Wed Feb 12 08:18:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25623 for ipsec-outgoing; Wed, 12 Feb 1997 08:15:32 -0500 (EST) Message-Id: <199702121320.OAA09687@digicash.com> From: "Niels Ferguson" To: Subject: Re: replay field size Date: Wed, 12 Feb 1997 14:21:00 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Michael J. Oehler > 3. Truncate the SHA-1 to 128 bits > The format for MD5 and SHA will then be identical. I'm a bit concerned with all the people that are happy to truncate hash values to shorter sizes. This should only be done if there is a thorough understanding of the threats and desired security level. In particular, SHA has a 160 bit output _because_ a 128-bit output was deemed too short. If you truncate SHA to 128 bits, the work effort to create a collision goes down from 2^80 to 2^64. Depending on the design lifetime of this stuff, 2^64 probably isn't enough, and one could question the wisdom of limiting the future security to 2^80 operations. Is there really such a shortage of bits that we have to reduce bitcounts everywhere? In general, 128-bit hash values are safe enough at the moment, but will probably be insecure in the forseeable future. MAC codes, which are computed with a shared secret key, can generally be truncated to half the length of the hash; but this all depends on a detailed analysis of the protocols. One other note: complexity is one of the major enemies of security. Most security systems fail because of bugs, and the number of bugs grows with some high order of the complexity. So let us try to avoid complexity wherever possible. In particular, negotiated field length add complexity to save a few bits. Is this worth it? Niels -------------------------------------------------------------------------- Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies) ...Of shoes, and ships, and sealing-wax, of cabbages, and kings, And why the sea is boiling hot, and whether pigs have wings... [Carroll] From owner-ipsec Wed Feb 12 08:58:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25887 for ipsec-outgoing; Wed, 12 Feb 1997 08:56:34 -0500 (EST) Date: Wed, 12 Feb 1997 15:59:41 +0200 From: roy@CheckPoint.COM (Roy Shamir) Message-Id: <9702121359.AA02547@dana.checkpoint.com> To: ipsec@tis.com Subject: RE: replay field size X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) Yes. > If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32 bits. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Yes, trucate to 128. *************************************************************************** Roy Shamir roy@checkpoint.com Tel: + 972 3 6131833 extension 178 --------------------------------------------------------------------------- Check Point Software Technologies Ltd. 3A Jabotinsky St. | Tel: + 972 3 6131833 Ramat-Gan 52511 Israel | Fax: + 972 3 5759256 http://www.checkpoint.com From owner-ipsec Wed Feb 12 09:55:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26237 for ipsec-outgoing; Wed, 12 Feb 1997 09:54:40 -0500 (EST) From: Germano Caronni Message-Id: <199702121457.PAA18846@kom30.ethz.ch> Subject: Re: replay field size To: ipsec@tis.com Date: Wed, 12 Feb 1997 15:57:57 +0100 (MET) In-Reply-To: <9702121359.AA02547@dana.checkpoint.com> from "Roy Shamir" at Feb 12, 97 03:59:41 pm X-Mailer: ELM [version 2.4 PL25 PGP7] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk straw poll > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) > Yes. > If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32 bits. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) > Yes, truncate to 128. Germano Caronni From owner-ipsec Wed Feb 12 10:10:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26350 for ipsec-outgoing; Wed, 12 Feb 1997 10:10:11 -0500 (EST) From: Robert Glenn Date: Wed, 12 Feb 1997 10:14:14 -0500 (EST) Message-Id: <199702121514.KAA01123@sloth.ncsl.nist.gov> To: kent@bbn.com Subject: RE: replay field size straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > As editor for the AH and ESP specs, based on the traffic I've seen >this last 2 weeks, I'm planing to go with 32-bit counters for both and to >assume that the HMAC value will be 128 bits, to help resolve the alignment >problem. If there are strong objections to this tact, I'd like to hear by >2/14. Unless there is a significant change to the AH header, a 32 bit non-optional counter and a 128 bit HMAC value will not resolve the alignment problem. 01234567012345670123456701234567 +------+-------+-------+-------+ | NH | Len | Reserved | 32 bits +------+-------+-------+-------+ | SPI | 32 bits +------+-------+-------+-------+ | Replay Prev. Counter | 32 bits +------+-------+-------+-------+ | | | HMAC | | Value | 128 bits | | +------+-------+-------+-------+ total: 224 bits --- not multiple of 64 Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad trailer, or 3) a 160 bit HMAC Value. Rob G. From owner-ipsec Wed Feb 12 10:51:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26634 for ipsec-outgoing; Wed, 12 Feb 1997 10:50:57 -0500 (EST) Date: Wed, 12 Feb 1997 16:51:54 +0100 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199702121551.AA01751@orfeo.gc.ssr.upm.es> To: ipsec@tis.com Subject: Truncation (was Re: replay field size) Sender: owner-ipsec@ex.tis.com Precedence: bulk I think many of us must re-read the archives before to talk about the convenience/danger of truncation. I include the relevant mails of Hugo to this list, and the reference in RFC-2104: ------------------------------- Begin Include message: From ipsec-request@neptune.tis.com Sat Aug 10 00:46:39 1996 Date: Fri, 9 Aug 1996 16:16:53 -0400 From: "H.Krawczyk" To: iesg@ietf.org Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA) Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Content-Length: 4040 > > 2. HMAC-SHA IP Authentication with Replay Prevention > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996. I propose the following change to the above draft (page 6). Replace: > (7) apply SHA to the stream generated in step (6) > (8) The sender then zero pads the resulting hash to a 64-bit boundary > for word alignment. The receiver compares the generated 160-bit hash > to the first 160-bits of authentication data contained in the AH. With: (7) apply SHA to the stream generated in step (6) and output the first (leftmost) 128 bits of the result. -------- Thus, I am proposing that instead of padding the 160 bits of SHA output to 192 bits, truncate the result to 128 bits. Beyond the advantage for bandwidth, this truncation is plausible to add to the security. In general, it is an old practice to truncate MACs. In the context of keyed-hash this has been explicitely proposed by Preneel and van Oorschot (Crypto'95). I do not know of any *proof* that truncating adds to the security. However, there are examples of attacks where this is the case. And as long as you do not truncate "too much" then everything indicates that it helps. In particular, I know of no reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario. Note: Be careful not to get confused with the unkeyed uses of SHA. There, collision resistance is usually the sacred goal and truncating the output HURTS HURTS HURTS (because of birthday attacks). For keyed-hash for message authentication the story is very different. Actually, the justification for truncation in [PV] is *exactly* because it helps *against* birthday attacks. (Yes, I know it sounds confusing but that's the way it is...) Still in the application of HMAC the 160 bits in the definition of SHA help as the length of the *intermediate* results of the compression function, but not as the final result. ANyway, truncation as a general method has an advantage (less information available to the adversary) and a disadvantage (less bits to predict for the attacker). When truncating 160 to 128 the advatage is far more significant than the disadvantage (It would be different if we truncated to 64 bits; that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my "personal minimum".) BTW, in the RFC on HMAC that I am submitting to the IETF there is a section on truncation of HMAC output. ---------- The patent issue: ..(deleted) ... Date: Thu, 31 Oct 96 19:52:21 EST To: IPSEC@TIS.COM Cc: rob.glenn@nist.gov, shu-jen.chang@nist.gov Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt Sender: ipsec-approval@neptune.tis.com Content-Length: 3592 Ref: Your note of Thu, 31 Oct 1996 19:06:38 -0500 I insist with my previous recommendation. Define hmac-sha to output 128 bits (out of the final 160 bits result). It most probably help security and saves up to 64 bits in 64-bit alignments. Hugo PS: I am appending a message that I sent to the list a couple of months ago on this issue. If anyone has a good reason against this recommendation please send it to the list. ------------- Krawczyk, et. al. Informational [Page 4] RFC 2104 HMAC February 1997 5. Truncated output A well-known practice with message authentication codes is to truncate the output of the MAC and output only part of the bits (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some analytical advantages of truncating the output of hash-based MAC functions. The results in this area are not absolute as for the overall security advantages of truncation. It has advantages (less information on the hash result available to an attacker) and disadvantages (less bits to predict for the attacker). Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). We propose denoting a realization of HMAC that uses a hash function H with t bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function and with the output truncated to 80 bits. (If the parameter t is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.) ... References [ANSI] ANSI X9.9, "American National Standard for Financial Institution Message Authentication (Wholesale)," American Bankers Association, 1981. Revised 1986. [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982. [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. End of include message ---------------------------------- Hope this helps to understand the question. Luis Saiz --------------------------------------------------------------------- Protocol cryptanalysis is essentially formalized paranoia. G. Simmons. --------------------------------------------------------------------- From owner-ipsec Wed Feb 12 11:33:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27070 for ipsec-outgoing; Wed, 12 Feb 1997 11:32:53 -0500 (EST) Date: Wed, 12 Feb 1997 11:07:35 -0500 Message-Id: <9702121607.AA10794@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Niels Ferguson" Cc: In-Reply-To: Niels Ferguson's message of Wed, 12 Feb 1997 14:21:00 +0100, <199702121320.OAA09687@digicash.com> Subject: Re: replay field size Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Niels Ferguson" Date: Wed, 12 Feb 1997 14:21:00 +0100 I'm a bit concerned with all the people that are happy to truncate hash values to shorter sizes. This should only be done if there is a thorough understanding of the threats and desired security level. In particular, SHA has a 160 bit output _because_ a 128-bit output was deemed too short. If you truncate SHA to 128 bits, the work effort to create a collision goes down from 2^80 to 2^64. Fundamentally, there's a design tradeoff going on here. If MD4, MD5 and SHA are truly random functions, then the only way to attack the hash function would be via a brute-force attack. However, those cryptoanalysis who have been working on breaking MD5 or MD4 are *not* making this assumption, and it's likely that if they do "break" either crypto hash function, it will be because they have found a way to find dependencies in the output bits. (Much like differential crypto exploited very small, probablistic dependencies in the output of DES.) So, the argument goes that with SHA-1, we can give up some amount of its protection against brute-force attacks by shortening it from 160 to 128 bits (assuming that 128 bits in length is "good enough"), and hopefully gaining some protection against the analytic attacks that cryptographers might later bring to bear on SHA-1. So this is an engineering tradeoff, trading off protection against one attack with protection against another. Furthermore, like most engineering tradeoffs, we're working with only partial knowledge of how helpful it will really be, versus how dangerous it is to allow brute force attacks against the shortened SHA-1 hash. Also note that if someone performs a brute-force attack against one off these hashes, they will only be able to break the integrity protection for one packet, not for an entire document (as in the case in more uses of this technology for digital signatures). In general, the requirements for integrity protecting an IP stream aren't quite the same as those required for digital signature in commerce. - Ted From owner-ipsec Wed Feb 12 11:38:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27099 for ipsec-outgoing; Wed, 12 Feb 1997 11:38:51 -0500 (EST) Message-Id: <199702121642.LAA00795@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Phil Karn cc: mjo@tycho.ncsc.mil, ipsec@tis.com, rja@inet.org, palamber@us.oracle.com Subject: Re: replay field size In-reply-to: Your message of "Tue, 11 Feb 1997 22:04:54 PST." <199702120604.WAA21035@servo.qualcomm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 12 Feb 1997 11:42:36 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn writes: > My opinions: > > Make the replay counters 32 bits for both AH and ESP. Should be plenty > for any rational key lifetime, and the arithmetic is easier on > compilers without "long long" data types... > > Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than > MD-5... Phil; Actually, if you've been following the MAC debates, the cryptographers say taking part of a hash makes a better MAC than taking the full one. Perry From owner-ipsec Wed Feb 12 11:52:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27327 for ipsec-outgoing; Wed, 12 Feb 1997 11:51:52 -0500 (EST) Message-ID: From: John Keating To: "'ipsec@tis.com'" Cc: "'keating@jagunet.com'" Subject: Re: replay field size Date: Wed, 12 Feb 1997 12:01:36 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) I would tend to look towards the future, and ask for negotiation. ("640K is more than anyone would ever need!") Why hardwire something that may need to be changed at some future date? Perhaps default to a minimum value, but don't lock it in. > If they have a fixed size counter, what size should it be? (32 bits/64 bits) See above, and default to 32 bits. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) I tend to lean towards leaving it at 160 bits. As some have mentioned, it was designed at that, why weaken it by truncating it? John W. Keating, III jkeating@ire.com These words are my own, and may not reflect the views of IRE, Inc. From owner-ipsec Wed Feb 12 12:25:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27524 for ipsec-outgoing; Wed, 12 Feb 1997 12:25:23 -0500 (EST) Message-Id: <199702121729.SAA18933@digicash.com> From: "Niels Ferguson" To: "Theodore Y. Ts'o" Cc: Subject: Re: replay field size Date: Wed, 12 Feb 1997 18:30:37 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Theodore Y. Ts'o > So, the argument goes that with SHA-1, we can give up some amount of its > protection against brute-force attacks by shortening it from 160 to 128 > bits (assuming that 128 bits in length is "good enough"), and hopefully > gaining some protection against the analytic attacks that cryptographers > might later bring to bear on SHA-1. So this is an engineering tradeoff, > trading off protection against one attack with protection against > another. Furthermore, like most engineering tradeoffs, we're working > with only partial knowledge of how helpful it will really be, versus how > dangerous it is to allow brute force attacks against the shortened SHA-1 > hash. Sorry, but this is not an engineering tradeoff. Note that the cryptographers could just as well have truncated SHA to 128 bits to achieve this `higher' security. What you are doing is _modifying_ the hash function. Strictly speaking, this invalidates all earlier analytical work, and you would have to re-do the entire security analysis of SHA. Note that a analitical attack that gives collision on only the first 128 bits of SHA might be possible, in which case the shortening has been very harmfull. My main argument against shortening is that 128 bits doesn't provide enough security against brute force attacks in 10 or 20 years time, and I am assuming that the design life of the protocols is at least 20 years. > Also note that if someone performs a brute-force attack against one off > these hashes, they will only be able to break the integrity protection > for one packet, not for an entire document (as in the case in more uses > of this technology for digital signatures). In general, the > requirements for integrity protecting an IP stream aren't quite the same > as those required for digital signature in commerce. What are the requirements? I havn't been part of the IPsec discussion, and I don't have very much time to spend on it, but this seems to be fairly fundamental. If integrity of a single IP packet isn't so important, then why bother at all? Of course there are levels of security, but you might end up doing 99% of all the work, and only getting 50% of the benefits. BTW, if the hash is used to ensure message integrity, and there is a separate MAC to ensure authenticity, then you could eliminate the hash. A MAC provides integrity verification as well, but it doesn't help you distinguish between a integrity violation and a key-mismatch. Unless precise error reporting is very important, you could leave the hash out. Furthermore, the MAC is more efficient, as it requires half as many bits to provide the same security level (assuming the key is secret of course). Niels -------------------------------------------------------------------------- Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies) ...Of shoes, and ships, and sealing-wax, of cabbages, and kings, And why the sea is boiling hot, and whether pigs have wings... [Carroll] From owner-ipsec Wed Feb 12 13:02:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27837 for ipsec-outgoing; Wed, 12 Feb 1997 13:01:28 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 12 Feb 1997 10:04:46 -0800 From: CJ Lee To: ipsec@tis.com Subject: RE: replay field size -Reply Sender: owner-ipsec@ex.tis.com Precedence: bulk > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) Yes. > If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32 bits. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Don't care (don't have enough knowledge to judge). In the case of 64-bits header alignment, whether it's necessitated by the optional RP counter or the length of the MAC digest, trailing pad bytes can be used. From owner-ipsec Wed Feb 12 13:33:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28068 for ipsec-outgoing; Wed, 12 Feb 1997 13:32:04 -0500 (EST) Message-Id: <199702121835.AA053382556@relay.hp.com> To: "Niels Ferguson" Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: replay field size In-Reply-To: niels's message of Wed, 12 Feb 1997 18:30:37 +0100. <199702121729.SAA18933@digicash.com> Date: Wed, 12 Feb 1997 13:35:54 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > BTW, if the hash is used to ensure message integrity, and there is a > separate MAC to ensure authenticity, then you could eliminate the hash. A > MAC provides integrity verification as well, but it doesn't help you > distinguish between a integrity violation and a key-mismatch. We are discussing HMAC-SHA1, which is a MAC built out of SHA1, not pure SHA1, which is an unkeyed hash. See: http://www.ietf.org/html.charters/ipsec-charter.html and, in particular, the following documents referenced from it: RFC's: IP Authentication Header (RFC 1826) HMAC: Keyed-Hashing for Message Authentication (RFC 2104) I-D's: HMAC-SHA IP Authentication with Replay Prevention Your time may be limited, but please read these three documents at a minimum before commenting further on this proposal; they are small... less than 70k of text. - Bill From owner-ipsec Wed Feb 12 13:35:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28075 for ipsec-outgoing; Wed, 12 Feb 1997 13:32:33 -0500 (EST) Date: Wed, 12 Feb 1997 13:36:39 -0500 Message-Id: <9702121836.AA10900@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Niels Ferguson" Cc: "Theodore Y. Ts'o" , In-Reply-To: Niels Ferguson's message of Wed, 12 Feb 1997 18:30:37 +0100, <199702121729.SAA18933@digicash.com> Subject: Re: replay field size Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Niels Ferguson" Date: Wed, 12 Feb 1997 18:30:37 +0100 What are the requirements? I havn't been part of the IPsec discussion, and I don't have very much time to spend on it, but this seems to be fairly fundamental..... BTW, if the hash is used to ensure message integrity, and there is a separate MAC to ensure authenticity, then you could eliminate the hash. A MAC provides integrity verification as well, but it doesn't help you distinguish between a integrity violation and a key-mismatch. Unless precise error reporting is very important, you could leave the hash out. Furthermore, the MAC is more efficient, as it requires half as many bits to provide the same security level (assuming the key is secret of course). The fact that you haven't been following the IPsec discussion is pretty obvious now. (Although I apologize for the loose use of terminology which has obviously confused you.) Note that what we're talking about is HMAC SHA --- so we *are* talking about a MAC, not just a hash. See draft-ietf-ipsec-ah-hmac-sha-04.txt for more details. It is computed by as follows: HMAC-SHA(K, text) = SHA (K XOR opad, SHA (K XOR ipad, text)) where ipad is the byte 0x36 repeated 64 times, and opad is the byte 0x5C repeated 64 times. The question is whether or not we should truncate the value returned by the SHA in the above question to 128 bits or not. Hugo Krawczyk, a cryptographer from IBM, has made the claim that in this case, truncating the hash result is a *good* thing, because (a) since it is a MAC, birthday attacks aren't an issue (as you commented because it only requires half as many bits), and (b) it denies information to an attacker who is trying to perform an analytic attack on the MAC. - Ted From owner-ipsec Wed Feb 12 13:36:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28082 for ipsec-outgoing; Wed, 12 Feb 1997 13:33:34 -0500 (EST) Message-Id: <2.2.32.19970212184415.009b47dc@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: Wed, 12 Feb 1997 13:44:15 -0500 To: Robert Glenn From: Naganand Doraswamy Subject: RE: replay field size straw poll Cc: kent@bbn.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Unless there is a significant change to the AH header, a 32 bit non-optional >counter and a 128 bit HMAC value will not resolve the alignment problem. > >01234567012345670123456701234567 >+------+-------+-------+-------+ >| NH | Len | Reserved | 32 bits >+------+-------+-------+-------+ >| SPI | 32 bits >+------+-------+-------+-------+ >| Replay Prev. Counter | 32 bits >+------+-------+-------+-------+ >| | >| HMAC | >| Value | 128 bits >| | >+------+-------+-------+-------+ > > total: 224 bits --- not multiple of 64 > >Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad >trailer, or 3) a 160 bit HMAC Value. > I suggest that we provide a reserved field of 32 bits, either before or after the replay counter if replay is used and also say that the transform's output should either be padded or truncated to a multiple of 64 bits. This will solve the 64 bit alignment problem for V6 and also make sure that the transforms dont have to worry about the basic AH header length to decide about 64 bit alignment. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Wed Feb 12 14:02:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28313 for ipsec-outgoing; Wed, 12 Feb 1997 14:01:39 -0500 (EST) From: Uri Blumenthal Message-Id: <9702121905.AA39146@hawpub.watson.ibm.com> Subject: Re: replay field size To: karn@qualcomm.com (Phil Karn) Date: Wed, 12 Feb 1997 14:05:43 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199702120604.WAA21035@servo.qualcomm.com> from "Phil Karn" at Feb 11, 97 10:04:54 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 Phil Karn says: > Make the replay counters 32 bits for both AH and ESP. Should be plenty > for any rational key lifetime, and the arithmetic is easier on > compilers without "long long" data types... Probably. > Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than > MD-5... Actually, 128 bits of SHA-1 will be much better than 128 bits of MD5, as it's more resistant to Preneel and van Orschott attack. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed Feb 12 15:17:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28909 for ipsec-outgoing; Wed, 12 Feb 1997 15:14:57 -0500 (EST) Message-Id: <199702122019.VAA20459@digicash.com> From: "Niels Ferguson" To: Subject: Re: Truncation (was Re: replay field size) Date: Wed, 12 Feb 1997 21:20:00 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Several people have pointed out that the discussion was about truncating the MAC value produces by HMAC, not truncating the hash value produced by SHA-1. Truncating the MAC value is, as far as I know, a very good idea. It might be worth to concider truncating the MAC to 96 bits, if this helps reducing the total overhead. This would be big enough from a security point of view. (See remark 4.8 in the HMAC paper "Keying Hash Functions for Message Authentication" by Bellare, Canetti and Krawczyk, and the resently re-posted remarks of Hugo.) My apologies for the misunderstanding, I should have checked in the archive what the discussion was about and not naively taken the messages at face value. Niels -------------------------------------------------------------------------- Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies) ...Of shoes, and ships, and sealing-wax, of cabbages, and kings, And why the sea is boiling hot, and whether pigs have wings... [Carroll] From owner-ipsec Wed Feb 12 17:15:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00226 for ipsec-outgoing; Wed, 12 Feb 1997 17:12:40 -0500 (EST) Message-ID: <01BC18EF.57BA2A80@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: rja@inet.org (rja@inet.org), palamber@us.oracle.com (palamber@us.oracle.com) cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: replay field size straw poll Date: Wed, 12 Feb 1997 14:13:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk 1) AH and ESP should have a fixed size replay counter (Yes). It should NOT be negotiable what size the replay field is. It should be optional whether you use the space or not. For all the talk about padding, which I still claim is irrelevant to the issue of replay, if we allow the field to come and go, alignment issues become even crazier. Why don't we always leave the field there but make it optional if you use it. If your negotiated SA indicates no replay, leave garbage in it and don't check it. If your negotiated SA indicates use replay, then use the space accordingly. Whatever we decide, the DOI needs to be updated to reflect the decision. 2) The fixed size should be 32 bits. 32. 3) SHA should be truncated to 128 bits? I don't know about this one. I'm not qualified to answer this question. I'm inclined to believe Hugo so..... I leave it to the experts and implement as directed, but I'm inclined to say, chop it short. Now, are we going to argue about the separate issue of padding? -Rob Adams Cisco Systems From owner-ipsec Wed Feb 12 17:15:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00233 for ipsec-outgoing; Wed, 12 Feb 1997 17:14:06 -0500 (EST) Message-Id: <199702122218.OAA07059@fluffy.cisco.com> To: ipsec@tis.com Subject: Re: replay field size In-reply-to: Your message of "Tue, 11 Feb 1997 03:53:56 EST." Date: Wed, 12 Feb 1997 14:18:07 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) Yes. I just don't see the need for a replay field that spans 4GB of packets. We can always add a negotiated option within the IPSEC DOI, should we decide that the need is there for much stronger encryption algorithms. That's the nice thing about having a negotiated key management protocol. However I do not believe that replay warrants a negotiated option. Any option, no matter how small, increases the risk of non-interoperability. ISAKMP/Oakley and IPSEC are complicated enough as it is. >If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32-bits. Add a separate padding field if you want 64-bit alignment in IPv4. You have to ask yourself though what effect aligning just these particular headers is going to have on overall processing of IPv4 IP... I think it's lost in the noise. >Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) A much harder question. Like many, I tend to want to accept Hugo's recommendation, but I'm not qualified to judge. Obviously this question should be decided on the merit of the strength of the HMAC though, and not on an alignment issue. If we decide that 128-bits probably increases the strength of the HMAC _and_ this happens to fix the alignment, great. If not, adding padding to fix the alignment is no big deal. I personally don't care about the size of the packet. It seems we really don't have concensus on whether or not 64-bit alignment is important for IPv4. My belief is that IPv4 is not inherently 64-bit aligned and forcing the IPSEC transforms to be 64-bit aligned will not fix this. I don't underestimate the importance of alignment for 64-bit RISC processors; I worked in the VMS group at DEC when we were porting to Alpha. However folks like Phil Karn have, in the past, been quite vocal about keeping the number of bytes to a minimum and 32-bits _is_ the natural alignment for the rest of IPv4. I'd like to see us come to consensus on the 64-bit alignment issue now too. What are other working groups doing with respect to IPv6/IPv4 alignment? Derrell From owner-ipsec Wed Feb 12 17:32:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00371 for ipsec-outgoing; Wed, 12 Feb 1997 17:31:09 -0500 (EST) Message-Id: <3.0.32.19970212143101.0094cb40@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 14:31:04 -0800 To: Ran Atkinson From: Bob Monsour Subject: RE: replay field size Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) Yes. >If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32-bits, using whatever padding is necessary to achieve the required alignment for IPv6 >Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Don't care (don't know enough about the underlying merits). From owner-ipsec Wed Feb 12 19:07:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00767 for ipsec-outgoing; Wed, 12 Feb 1997 19:03:10 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702130007.QAA28204@kebe.eng.sun.com> Subject: "Transforms" per se going away? To: ipsec@tis.com Date: Wed, 12 Feb 1997 16:07:09 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk While I hate to interrupt the replay-field size discussion, I have something else that needs to be brought to the attention of the general IPsec mailing list. While discussing the next round of PF_KEY tweaks, something I thought was common knowledge apparently is not. This may also explain why we haven't seen updates on ISAKMP, IPsec DOI, and other goodies yet. Anyway, lemme quote the text > By the way, if transforms are going away somebody should alert the ISAKMP > folks and Derrell Piper (IPsec DOI author). The transform payload has a > "transform id" entry (using a transform number from the DOI doc) and > attributes of that transform. The way the documents are now, ISAKMP > negotiates a transform (DES-CBC-HMAC-MD5-REPLAY) and approriate attributes > (e.g. lifetime), not a jumble of attributes (DES-CBC, lifetime, HMAC-MD5, > etc). *I* was under the impression that with the next round of base document updates, the IPsec headers would move away from the "transform" concept, and into a "pick an item off the checklist" concept. For example: For ESP Pick One from each category: Encryption: (DES/3DES/IDEA/RSA/rot13/...) Authentication: (HMAC-MD5/HMAC-SHA/none/HMAC-CRC8/...) Replay? (Yes/No) Replay size (May be a moot point...) [NOTE: There is no "none" for Encryption in ESP. This is why we have AH. Remember, some of us have to deal with export control bullsh*t.] For AH Pick One from each category: Authentication: (HMAC-MD5/HMAC-SHA/HMAC-CRC8/...) Replay? (Yes/No) Replay size (May be a moot point) Pad to 8bytes? (Yes/No) PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my shouting, that's a very important property though.) So if this is the direction we're indeed heading, we should make this clear sooner rather than later, because certain docs (ISAKMP, IPsec DOI, PF_KEY, and any Advanced BSD API work) will need to take this into account. Speaking as an implementor of IPsec in my kernel, I like the concept of the checklist, as I can make kernel-loadable _authentication_ modules and kernel-loadable _encryption_ modules. The former I can actually just attach to AH and ESP w/o tweaking separate ESP and AH versions. Any comments folks? Sorry to ruin your week with something like this. I'd much rather be writing more code myself, but this seemed important. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 <*> + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | Solaris Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From owner-ipsec Wed Feb 12 20:46:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01229 for ipsec-outgoing; Wed, 12 Feb 1997 20:42:12 -0500 (EST) Message-Id: <199702130146.RAA17392@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: "Transforms" per se going away? In-Reply-To: Your message of "Wed, 12 Feb 1997 16:07:09 PST." <199702130007.QAA28204@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 17:46:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald wrote: > *I* was under the impression that with the next round of base document > updates, the IPsec headers would move away from the "transform" concept, and > into a "pick an item off the checklist" concept. [example snipped] > PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH > ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my > shouting, that's a very important property though.) It will change many working ISAKMP implementations which also put bits on the wire in a well-defined manner. Doing away with the transform and making everything an attribute will change existing payloads and the way payloads are constructed and processed. Not that this is necessarily a bad thing, just that these changes are not completely editorial and everyone needs to understand that. 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 Wed Feb 12 22:52:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01768 for ipsec-outgoing; Wed, 12 Feb 1997 22:47:44 -0500 (EST) Date: Thu, 13 Feb 97 03:45:21 GMT Standard Time From: Ran Atkinson Subject: Re: replay field size To: Derrell Piper , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199702122218.OAA07059@fluffy.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, The IPng Working Group decided a long while back that all headers used with IPv6 MUST be 64-bit aligned. If the IPsec WG wants to not support 64-bit alignment, that matter would have to be also raised for discussion with the IPng Working Group for their approval (in addition to normal IESG approvals). In short, the topic of alignment is broader than just the IPsec WG and will need broader review and consensus before it changes. This is just to clarify the process, not to argue pro or con. Ran rja@inet.org From owner-ipsec Wed Feb 12 23:03:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01843 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:45 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702111926.LAA13021@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 12:09:22 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: RE: replay field size Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I agree that one can negotiate the counter size during SA negotiation, so the issues is not one of steady state overhead. The issue is one of added complexity in the implementation, which is greater if we support two counter sizes vs. a single counter size. We can debate just how much complexity is involved, but first I suggest that we explore what motivates any added complexity. Steve From owner-ipsec Wed Feb 12 23:03:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01852 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:49 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702112214.RAA09176@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 22:31:58 -0500 To: "Steven M. Bellovin" From: Stephen Kent Subject: Re: replay field size straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, This is a sort of sliding window counter, in that one accepts potentially old messages within a negotiated window and matches the sequence number against the log of received messages within that window. I agree that this is different from TCP window arithmetic, but it still strikes me as sufficiently complex as to be a likely source of bugs, at least initially. Steve From owner-ipsec Wed Feb 12 23:03:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01851 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:50 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <01BC1774.B4080180@Tastid.Cisco.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 23:01:10 -0500 To: Ran Atkinson From: Stephen Kent Subject: RE: replay field size Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Whoops! I didn't read all the way to the end of Ran's message from Tuesday, so when I responded to David Kemp's straw poll message, I didn't realize that I was proposing to make editorial decisions prior to the deadline for the straw poll (and without the benefit of the private responses to the poll). Please ignore the deadline from my message. I'll await the outcome of the straw poll, as reported by Ran and Paul, before making the necessary edits to AH and ESP. Steve From owner-ipsec Wed Feb 12 23:03:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01850 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:50 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702112043.PAA00838@sloth.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 22:29:20 -0500 To: Robert Glenn From: Stephen Kent Subject: Re: replay field size Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, The field has been proposed as an option, not a requirement (though compliant implementations would be required to support generation and processing of the option. As you observe, to simplify the alignment issue, one could always include the field even if it were not processed, at the expense of 4 or 8 bytes. The question of when to rekey really is independent of the counter size, except in so far as it not being larger than the counter space. So, I'd tend to keep these concepts separate as much as possible. Steve From owner-ipsec Wed Feb 12 23:04:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01858 for ipsec-outgoing; Wed, 12 Feb 1997 23:00:14 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702121320.OAA09687@digicash.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 22:37:19 -0500 To: "Niels Ferguson" From: Stephen Kent Subject: Re: replay field size Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Niels, It's true that a shorter hash makes it easier to find a collision, for a given packet, assuming a brute force search. However, Hugo's argument suggests that because of the way we are using the hash, truncation may make it even harder to work backwards to find the key, which poses the really significant concern in this environment. I agree with your observation that spending another 4 bytes is not so bad in the grand scheme of things, but we have made similar tradeoffs in IPSEC (look at the shortened IV techniques) before, so we have to decide why to draw the line here. Steve From owner-ipsec Thu Feb 13 08:07:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04524 for ipsec-outgoing; Thu, 13 Feb 1997 07:45:50 -0500 (EST) From: yael@radguard.com Message-Id: <9702131150.AA22479@elgamal.radguard.com> Comments: Authenticated sender is To: ipsec@tis.com Date: Thu, 13 Feb 1997 13:54:21 +0000 Subject: Re: replay field size, straw poll X-Mailer: Pegasus Mail for Windows (v2.23) Sender: owner-ipsec@ex.tis.com Precedence: bulk straw poll > Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) Yes > If they have a fixed size counter, what size should it be? (32 bits/64 bits) 32 bits > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) Yes Yael Dayan RADGUARD Ltd. From owner-ipsec Thu Feb 13 09:32:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05061 for ipsec-outgoing; Thu, 13 Feb 1997 09:12:22 -0500 (EST) Message-Id: <2.2.32.19970213140714.006bea60@bullwinkle.bbn.com> X-Sender: lsanchez@bullwinkle.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Feb 1997 09:07:14 -0500 To: rja@inet.org, palamber@us.oracle.com From: "Luis A. Sanchez" Subject: RE: replay field size straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care) > If they have a fixed size counter, what size should it be? (32 bits/64 bits) -Fixed size, 32 bits. > Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care) - Yes. Luis From owner-ipsec Thu Feb 13 09:45:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05252 for ipsec-outgoing; Thu, 13 Feb 1997 09:35:59 -0500 (EST) Message-ID: From: Roy Pereira To: "'Dan.McDonald@Eng.sun.com'" , "'Daniel Harkins'" Cc: "'ipsec@tis.com'" Subject: RE: "Transforms" per se going away? Date: Thu, 13 Feb 1997 09:40:42 -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 Daniel Harkins wrote: > >>Dan McDonald wrote: >>> *I* was under the impression that with the next round of base document >>> updates, the IPsec headers would move away from the "transform" concept, >>>and >>> into a "pick an item off the checklist" concept. > >>[example snipped] > >>> PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH >>> ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my >>> shouting, that's a very important property though.) > >>It will change many working ISAKMP implementations which also put bits on >>the wire in a well-defined manner. Doing away with the transform and making >>everything an attribute will change existing payloads and the way payloads >>are constructed and processed. Not that this is necessarily a bad thing, >>just that these changes are not completely editorial and everyone needs to >>understand that. We shuold make every effort to maintain backwards compatibility with the current transforms, but in the future we should be looking at moving away from the "Transform" concept. For IPSEC-DOI, we could create a TRANSFORM ID that allows us to define the transform's parameters (cipher alg, hash alg, replay, ...) all in attributes instead of having the transform identifier specify which parameters. This way we do not have to write hundreds of transform RFCs for every possible combination of parameters. Example: ISAKMP Transform Payload: Transform ID: TRANSFORM-ALA-CARTE Attribute 1: Cipher Alg: 3DES Attribute 2: Hash Alg: SHA1 Attribute 3: Keyed Alg: HMAC Attribute 4: Replay Protection: 32-bit From owner-ipsec Thu Feb 13 10:24:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05652 for ipsec-outgoing; Thu, 13 Feb 1997 10:23:00 -0500 (EST) Message-Id: <3.0.32.19970213103115.007179ac@pop.rv.tis.com> X-Sender: wei@pop.rv.tis.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 10:31:15 -0800 To: Naganand Doraswamy , Robert Glenn From: wei@tis.com Subject: RE: replay field size straw poll Cc: kent@bbn.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:44 PM 2/12/97 -0500, Naganand Doraswamy wrote: > >>Unless there is a significant change to the AH header, a 32 bit non-optional >>counter and a 128 bit HMAC value will not resolve the alignment problem. >> >>01234567012345670123456701234567 >>+------+-------+-------+-------+ >>| NH | Len | Reserved | 32 bits >>+------+-------+-------+-------+ >>| SPI | 32 bits >>+------+-------+-------+-------+ >>| Replay Prev. Counter | 32 bits >>+------+-------+-------+-------+ >>| | >>| HMAC | >>| Value | 128 bits >>| | >>+------+-------+-------+-------+ >> >> total: 224 bits --- not multiple of 64 >> >>Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad >>trailer, or 3) a 160 bit HMAC Value. >> > >I suggest that we provide a reserved field of 32 bits, either before or >after the replay counter if replay is used and also say that the transform's >output should either be padded or truncated to a multiple of 64 bits. This >will solve the 64 bit alignment problem for V6 and also make sure that the >transforms dont have to worry about the basic AH header length to decide >about 64 bit alignment. I think the reserved field should be used as the flag field to allow the flexible configuration of AH. The reserved field is just wasted since both the length and the flag will make the AH header for any future use and ease the inter-operatability of any AHs. From owner-ipsec Thu Feb 13 10:29:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05668 for ipsec-outgoing; Thu, 13 Feb 1997 10:27:28 -0500 (EST) Date: Thu, 13 Feb 97 15:21:16 GMT Standard Time From: Ran Atkinson Subject: Re: replay field size To: Robert Glenn , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, As you note, one can rekey more frequently than when the counter runs out. However, the counter size does present an upper bound to the rekey interval. In this way, they are related. This relationship does need to be carefully considered by the working group, IMHO. For example, I am aware of commercial encrypting router products (not cisco) that can handle a full IP stream at OC-3c rates (155 Mbps). Based on the relatively small size of a large percentage of IP datagrams (as measured on a well-known OC-3 trans-Atlantic IP link), this is not a particularly long time interval between rekeys forced by a 32-bit replay counter. By contrast, a 64-bit replay counter would not increase the size of the overall packet because it would just eliminate 32-bits of padding (that would be needed otherwise for IPv6 compliance). However, a 64-bit replay counter would very significantly increase the upper bound and make premature forced rekeying a non-issue for the overwhelming majority of cases. This argues that a 64-bit replay counter would best further the WG's goal of maintaining a set of specifications that work equally well with any cryptographic algorithm. Ran rja@inet.org From owner-ipsec Thu Feb 13 11:36:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06187 for ipsec-outgoing; Thu, 13 Feb 1997 11:35:30 -0500 (EST) Message-Id: <199702131634.IAA15027@mailsun3-fddi.us.oracle.com> Date: 13 Feb 97 00:20:56 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: Re: IPsec hardware accelerators (Rainbow warning) Cc: gnu@toad.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.25) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk An old message (Jan.) that seems to have been stuck in one of my out boxes ... Paul ------------------ John, please be fair about "compatibility": >The Clipper Chip and its follow-on >products are not compatible with the IPSEC protocols, >because they use an undocumented encryption algorithm >and because they are designed to >undermine rather than provide secure operation. Undocumented cryptographic algorithms are very compatible with IPSEC. Cryptographic flexibility is one of the main design features of this set of protocols. It is true that our IPSEC set of mandatory to implement algorithms will never contain a undocumented encryption algorithm. There is no reason that the "encapsulating" protocol (ESP) could not use anyones favorite algorithm (documented or not). The ISAKMP negotiation should allow selection of a common algorithm between two IPSEC systems. It just so happens that the "favorite" algorithms of the US Government are available in the Fortezza card. I also believe that cryptographic algorithms are "stronger" when they are not published. So, Fortezza is compatible with IPsec, it just is not the recommended IETF set of algorithms :-) Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com Security Architect - Hands on lead with strong design skills Sr. Development Manager - 6+ experience with 3+ leading teams Security Product Manager(s) - Excellent verbal and written skills with background in security. Senior SW Dev. - 6+ experience in SW development SW Developer(s) - Strong coding skills and abilities or interest in: (C++, Java, CORBA, security, X.500, etc.) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Thu Feb 13 11:36:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06180 for ipsec-outgoing; Thu, 13 Feb 1997 11:35:00 -0500 (EST) Message-Id: <199702131637.LAA02391@raptor.research.att.com> To: Ran Atkinson cc: Robert Glenn , Stephen Kent , ipsec@tis.com Subject: Re: replay field size Date: Thu, 13 Feb 1997 11:37:39 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > As you note, one can rekey more frequently than when the counter runs > out. However, the counter size does present an upper bound to the rekey > interval. In this way, they are related. This relationship does need > to be carefully considered by the working group, IMHO. > > For example, I am aware of commercial encrypting router products > (not cisco) that can handle a full IP stream at OC-3c rates (155 Mbps). > Based on the relatively small size of a large percentage of IP datagrams > (as measured on a well-known OC-3 trans-Atlantic IP link), this is not > a particularly long time interval between rekeys forced by a 32-bit > replay counter. If all packets were 40 bytes, 155Mbps is about 500K packets/second. At 2^32 packets before rekey, the interval is over 2 hours if the link were running flat-out. That's not onerous. Even at 1Gbps -- the fastest I've heard anyone discuss -- it's still 20 minutes. A router that can switch packets at that rate will likely have a moderately serious CPU for doing new key exchanges. But not all packets are that small; in fact, the mean packet size is about 250 bytes (see http://www.nlanr.net/NA/Learn/packetsizes.html) -- while tinygrams are a large percentage of the packet count, they don't account for very much of the volume by byte; what fills up OC-3 lines is the bulk tranfers. At that rate, the rekey interval is over 15 hours at OC-3 speeds. But it's worse than that. At 250 bytes/packet, there are about 2^5 DES blocks/packet, which means there are 2^37 blocks per ``full'' 32-bit security association. That's getting unpleasantly close to the point where linear cryptanalysis is feasbible. (Matsui's CRYPTO '94 paper says that with 2^38 known plaintexts, the success rate is 10% with complexity 2^50. The new ``Handbook of Applied Cryptography'' notes that ``linear cryptanalysis is possible in a ciphertext-only environment if some underlying plaintext redundancy is known (e.g., parity bits or high-order 0-bits in ASCII characters.)) I submit that we really don't want to encrypt that much plaintext with any single key -- ever. And of course, we don't know that linear cryptanalysis is the ultimate attack. Furthermore, the 2^32 packet limit is the limit for a single association. To my mind, that makes it highly improbable that it's a real limit in any event -- and if we get near it, we should rekey. > By contrast, a 64-bit replay counter would not increase the size > of the overall packet because it would just eliminate 32-bits of > padding (that would be needed otherwise for IPv6 compliance). However, > a 64-bit replay counter would very significantly increase the upper > bound and make premature forced rekeying a non-issue for the overwhelming > majority of cases. It would also mandate an 64-bit subtraction that's unpleasant on most of today's hosts. > This argues that a 64-bit replay counter would best further the WG's > goal of maintaining a set of specifications that work equally well with > any cryptographic algorithm. > > Ran > rja@inet.org From owner-ipsec Thu Feb 13 13:12:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07031 for ipsec-outgoing; Thu, 13 Feb 1997 13:11:38 -0500 (EST) Date: Thu, 13 Feb 1997 13:11:38 -0500 (EST) Message-Id: <199702131811.NAA07031@portal.ex.tis.com> To: ipsec@tis.com Subject: Straw Poll and Alignment Cc: rja@inet.org From: "C. Harald Koch" Phone: +1 418 813 2054 )@F: jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw Sender: owner-ipsec@ex.tis.com Precedence: bulk z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 13 Feb 1997 13:06:08 -0500 Sender: chk@rafael.rnd.border.com Everyone seems to be 'voting' for a 32-bit counter *and* truncating the SHA-1 output to 128 bits. However: THIS BREAKS 64 BIT ALIGNMENT!!!!! The diagram, again (thanks, Robert Glenn!): 01234567012345670123456701234567 +------+-------+-------+-------+ | NH | Len | Reserved | 32 bits +------+-------+-------+-------+ | SPI | 32 bits +------+-------+-------+-------+ | Replay Prev. Counter | 32 bits +------+-------+-------+-------+ | | | HMAC | | Value | 128 bits | | +------+-------+-------+-------+ total: 224 bits --- not multiple of 64 We can *either* have a 32-bit counter, *or* a truncated SHA-1 hash. Using both breaks alignment. (Remember, AH is required for IPv6, and IPv6 requires 64-bit alignment on all options.) I postulate that the current straw poll is meaningless, because we're ignoring the fundamental alignment problem. The options, as I see them, are: AH + SPI + 32-bit replay + 32-bit pad + HMAC-MD5 256 bits AH + SPI + 32-bit replay + HMAC-SHA-1 256 bits or AH + SPI + 64-bit replay + HMAC-MD5 256 bits AH + SPI + 64-bit replay + truncated HMAC-SHA1 256 bits All other combinations of replay and hashes break alignment, or require additional padding. If I remember correctly, the truncated SHA-1 discussion started from the fact that AH + SPI + SHA-1 == 224 bits, which is also not 64-bit aligned. The proposed solution was to truncate the SHA-1 output to 128 bits, giving a 192 bit packet (which is aligned). And that, in turn, led to the AH 64-bit replay counter; it preserves the alignment! Can we *please* start over on this straw poll now? -- C. Harald Koch chk@utcc.utoronto.ca +1 416 813 2054 (voice) "I don't suffer from insanity; I revel in it!" -Karen Murphy From owner-ipsec Thu Feb 13 13:12:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07004 for ipsec-outgoing; Thu, 13 Feb 1997 13:10:36 -0500 (EST) Message-Id: <199702131810.NAA07004@portal.ex.tis.com> Date: Thu, 13 Feb 1997 10:15:34 -0800 To: John Keating , "'ipsec@tis.com'" From: wei@tis.com Subject: Re: replay field size Cc: "'keating@jagunet.com'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:01 PM 2/12/97 -0500, John Keating wrote: >> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't >Care) > >I would tend to look towards the future, and ask for negotiation. ("640K >is more than anyone would ever need!") Why hardwire something that may >need to be changed at some future date? Perhaps default to a minimum >value, but don't lock it in. Agree. I don't see why ESP need the replay counter? The IV along with ESP header is also functioning as a replay preventor. For AH, however, it should have the replay counter. There should be a flag field in the AH header to indicate if the parket include the replay or not and other values in the future. I think the reserve field are wasted. It should be removed and used as the flag (16 bits) in stead. In this way, one can flexibly add/change any fields in the future or live along with variable AH. I strongly disagree any FIXED agreement without flexibility fields. > >> If they have a fixed size counter, what size should it be? (32 bits/64 bits) > >See above, and default to 32 bits. > >> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't >Care) With the AH flag, one can use whatever they like. > >I tend to lean towards leaving it at 160 bits. As some have mentioned, >it was designed at that, why weaken it by truncating it? Same as above. Wei Xu Trusted Information Systems, Inc From owner-ipsec Thu Feb 13 16:23:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08344 for ipsec-outgoing; Thu, 13 Feb 1997 16:20:36 -0500 (EST) Message-ID: <01BC19B1.72DCA5A0@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com (ipsec@tis.com), chk@utcc.utoronto.ca ('C. Harald Koch') cc: rja@inet.org (rja@inet.org) Subject: RE: Straw Poll and Alignment Date: Thu, 13 Feb 1997 13:25:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk No need to start the straw poll over. I don't understand our insistance on linking the size of the fields with alignment of the header. If we need to align the header, then add padding. Period. The size of a field should be appropriate for the field's use and the field's use alone. Mr. Bellovin's post this morning about a 64 vs. 32 bit replay counter should be convincing enough about an rekeying issues. Hugo et al. believe that it is more secure to truncate SHA. So, 32 bit replay makes sense for replay's sake. Truncating SHA is more secure. Therefore, 32 bit replay field, 128 bit Digest field. Now, let's talk about alignment. (also, please let us not forget that having the *existance* of the replay field be optional only further complicates alignment issues.) -Rob ---------- From: C. Harald Koch[SMTP:chk@utcc.utoronto.ca] Sent: Thursday, February 13, 1997 10:11 AM To: ipsec@tis.com Cc: rja@inet.org Subject: Straw Poll and Alignment z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 13 Feb 1997 13:06:08 -0500 Sender: chk@rafael.rnd.border.com Everyone seems to be 'voting' for a 32-bit counter *and* truncating the SHA-1 output to 128 bits. However: THIS BREAKS 64 BIT ALIGNMENT!!!!! The diagram, again (thanks, Robert Glenn!): 01234567012345670123456701234567 +------+-------+-------+-------+ | NH | Len | Reserved | 32 bits +------+-------+-------+-------+ | SPI | 32 bits +------+-------+-------+-------+ | Replay Prev. Counter | 32 bits +------+-------+-------+-------+ | | | HMAC | | Value | 128 bits | | +------+-------+-------+-------+ total: 224 bits --- not multiple of 64 We can *either* have a 32-bit counter, *or* a truncated SHA-1 hash. Using both breaks alignment. (Remember, AH is required for IPv6, and IPv6 requires 64-bit alignment on all options.) I postulate that the current straw poll is meaningless, because we're ignoring the fundamental alignment problem. The options, as I see them, are: AH + SPI + 32-bit replay + 32-bit pad + HMAC-MD5 256 bits AH + SPI + 32-bit replay + HMAC-SHA-1 256 bits or AH + SPI + 64-bit replay + HMAC-MD5 256 bits AH + SPI + 64-bit replay + truncated HMAC-SHA1 256 bits All other combinations of replay and hashes break alignment, or require additional padding. If I remember correctly, the truncated SHA-1 discussion started from the fact that AH + SPI + SHA-1 == 224 bits, which is also not 64-bit aligned. The proposed solution was to truncate the SHA-1 output to 128 bits, giving a 192 bit packet (which is aligned). And that, in turn, led to the AH 64-bit replay counter; it preserves the alignment! Can we *please* start over on this straw poll now? -- C. Harald Koch chk@utcc.utoronto.ca +1 416 813 2054 (voice) "I don't suffer from insanity; I revel in it!" -Karen Murphy From owner-ipsec Thu Feb 13 16:35:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08546 for ipsec-outgoing; Thu, 13 Feb 1997 16:35:08 -0500 (EST) Message-Id: <199702132139.QAA28429@rafael.rnd.border.com> To: adams@cisco.com (Rob Adams) cc: ipsec@tis.com (ipsec@tis.com), rja@inet.org (rja@inet.org) Subject: Re: Straw Poll and Alignment References: <01BC19B1.72DCA5A0@Tastid.Cisco.COM> In-reply-to: adams's message of "Thu, 13 Feb 1997 16:25:46 -0500". <01BC19B1.72DCA5A0@Tastid.Cisco.COM> From: "C. Harald Koch" Date: Thu, 13 Feb 1997 16:39:06 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <01BC19B1.72DCA5A0@Tastid.Cisco.COM>, Rob Adams writes: > > I don't understand our insistance on linking the size of the > fields with alignment of the header. Ok, maybe I'm over-reacting. I just think it's foolish to throw away information (the extra 32-bits of MAC) only to replace it with padding. OTOH, I admit that doing so does make MD5 and SHA-1 processing identical, which again simplifies code, which is the object of this whole process... (I'll calm down now...) > > Mr. Bellovin's post this morning about a 64 vs. 32 bit replay counter should be convincing enough > about an rekeying issues. Agreed. > Hugo et al. believe that it is more secure to truncate SHA. I think that's a bit strong. I read their messages as "it doesn't detract from the security, and it *may* increase the security". -- Harald Koch chk@utcc.utoronto.ca From owner-ipsec Thu Feb 13 17:29:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08880 for ipsec-outgoing; Thu, 13 Feb 1997 17:26:40 -0500 (EST) Date: Thu, 13 Feb 1997 17:30:43 -0500 Message-Id: <9702132230.AA11781@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "C. Harald Koch" Cc: adams@cisco.com, ipsec@tis.com, rja@inet.org In-Reply-To: C. Harald Koch's message of Thu, 13 Feb 1997 16:39:06 -0500, <199702132139.QAA28429@rafael.rnd.border.com> Subject: Re: Straw Poll and Alignment Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "C. Harald Koch" Date: Thu, 13 Feb 1997 16:39:06 -0500 In message <01BC19B1.72DCA5A0@Tastid.Cisco.COM>, Rob Adams writes: > > I don't understand our insistance on linking the size of the > fields with alignment of the header. Ok, maybe I'm over-reacting. I just think it's foolish to throw away information (the extra 32-bits of MAC) only to replace it with padding. OTOH, I admit that doing so does make MD5 and SHA-1 processing identical, which again simplifies code, which is the object of this whole process... > Hugo et al. believe that it is more secure to truncate SHA. I think that's a bit strong. I read their messages as "it doesn't detract from the security, and it *may* increase the security". No, what Hugo said is that for MAC's it's *good* to truncate the hash, because by throwing away information, you are *denying* that information to an attacker, who might use that information against you. There are more ways to attack a crypto algorythms than just brute force attacks! - Ted From owner-ipsec Thu Feb 13 18:43:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09261 for ipsec-outgoing; Thu, 13 Feb 1997 18:37:18 -0500 (EST) Message-Id: <199702132341.PAA18521@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Edward Russell Cc: "'ipsec@tis.com'" , rlfs@cisco.com, bruceg@cylink.com Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News In-Reply-To: Your message of "Thu, 06 Feb 1997 12:33:16 EST." <01BC1429.F844BBC0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Feb 1997 15:41:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Edward Russell wrote: > At the interoperability event in Dallas, it appears that > the BSAFE SHA is incompatible with the CYLINK SHA. > > In addition it appears that > BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman Both these problems are related to the underlying representation of numbers in the Cylink library as LSB first as opposed to MSB first. All numbers on the wire should be MSB first, they were not. These problems will be taken care of in the next release of Cylink's crypto library and will be in the next release of cisco's free ISAKMP reference implementation. 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 Fri Feb 14 09:22:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA14166 for ipsec-outgoing; Fri, 14 Feb 1997 09:18:30 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: Quick Mode and KE payloads Date: Fri, 14 Feb 1997 09:07:46 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk Referring to section 5.4 and Appendix A of ISAKMP\Oakley draft and Section 4.5 of DOI draft. ISAKMP\Oakley states that the group description attribute must be sent for PFS in the SA being negotiated. The appendix then states that ..."Phase two attributes are defined in the applicable DOI specification, with the exception of a group description when Quick Mode includes an ephemeral DH exchange...." The above wording has me a little confused. Attribute Classes ISAKMP\Oakley Draft Group Description 4 DOI Draft Enc Key Life Duration 4 Is it intended that a Quick Mode which is doing PFS would include a proposal payload with protocol ID of ISAKMP and that the proposal would be AND with the non-ISAKMP proposals being negotiated, in order to specify the group. Or was it intended for the Group Description attribute class to be unique across ISAKMP\Oakley and all DOIs so that it maybe included in transform payloads in non-ISAKMP SAs during Quick Mode exchanges. I prefer the latter myself. Thanks Bye. ---- Greg Carter Entrust Technologies carterg@entrust.com From owner-ipsec Fri Feb 14 10:20:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14656 for ipsec-outgoing; Fri, 14 Feb 1997 10:16:14 -0500 (EST) Message-Id: <3.0.16.19970214100530.34cf2fc4@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 14 Feb 1997 10:19:59 -0500 To: Daniel Harkins From: Rodney Thayer Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk what version of cylink's code are you using NOW and do you know of a reference (like a URL) from Cylink on this? At 03:41 PM 2/13/97 -0800, you wrote: >Edward Russell wrote: >> At the interoperability event in Dallas, it appears that >> the BSAFE SHA is incompatible with the CYLINK SHA. >> >> In addition it appears that >> BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman > >Both these problems are related to the underlying representation of numbers >in the Cylink library as LSB first as opposed to MSB first. All numbers on >the wire should be MSB first, they were not. > >These problems will be taken care of in the next release of Cylink's crypto >library and will be in the next release of cisco's free ISAKMP reference >implementation. > > 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 >--------------------------------------------------------------------------- ---- > > > 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 Feb 14 10:53:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14987 for ipsec-outgoing; Fri, 14 Feb 1997 10:53:27 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702130007.QAA28204@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Feb 1997 13:45:49 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: "Transforms" per se going away? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I don't think my intent has been to move to exactly the "list" approach you describe in your message. For example, not all combinations of encryption algorithms, modes, and IV options make sense. I was assuming that we would have a regsitered set (with the IANA) of combinations of encryption, authentication, and anti-replay options, each set of which defines a "transform" (using the curent terminology). This makes clear to implementors what combinations must be supported and allows for elimination of combinations that the community (WG?) thinks are inappropriate, i.e., don't allocate a transform ID for a combination that is considered "bad." The real goals of the new AH and ESP specs are to eliminate the need to issue a combinatorial number of transform RFCs, to centralize common definitions, etc. One can still have a fairly modular implementation as you describe, but by grouping the attributes of transforms, one also can accommodate less modular implementations as well. Steve From owner-ipsec Fri Feb 14 11:16:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15161 for ipsec-outgoing; Fri, 14 Feb 1997 11:16:35 -0500 (EST) Date: Fri, 14 Feb 97 16:13:10 GMT Standard Time From: Ran Atkinson Subject: Re: replay field size To: Ran Atkinson , Steven Bellovin Cc: ipsec@tis.com, Robert Glenn , Stephen Kent X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199702131637.LAA02391@raptor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, For the case where the algorithm is DES, I have no problems with your analysis. For the case where the algorithm is something new that appears in future that might be significantly stronger, then the limit of 2^^32 might well be a significant issue. With negotiable counter sizes or per-algorithm counter sizes, this would not be an issue. With a fixed size counter, using 2^^32 for all time is an issue IMHO. However, a 2^^64 counter space would not have that issue and would still be a fixed size counter. As to the 64-bit math, I'm not very concerned -- based on my work on several different IPv6 implementations and the currently 128-bit addresses (and the routing calculations that go along with that address size). This was NOT a problem on an Intel Pentium. Ran rja@inet.org From owner-ipsec Fri Feb 14 13:17:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16099 for ipsec-outgoing; Fri, 14 Feb 1997 13:14:10 -0500 (EST) Date: Fri, 14 Feb 1997 12:17:39 -0600 Message-Id: <199702141817.MAA25779@hosaka> From: Jim Thompson To: rja@inet.org CC: rja@inner.net, smb@research.att.com, ipsec@tis.com, glenn@snad.ncsl.nist.gov, kent@bbn.com In-reply-to: (message from Ran Atkinson on Fri, 14 Feb 97 16:13:10 GMT Standard Time) Subject: Re: replay field size Sender: owner-ipsec@ex.tis.com Precedence: bulk > For the case where the algorithm is something new that appears in > future that might be significantly stronger, then the limit of 2^^32 > might well be a significant issue. With negotiable counter sizes or > per-algorithm counter sizes, this would not be an issue. With a fixed > size counter, using 2^^32 for all time is an issue IMHO. However, > a 2^^64 counter space would not have that issue and would still be > a fixed size counter. If the application is (bulk) data xfer, then I most of the packets will be MTU-sized (or PMTU, anyway, but for high-speed, these had better match), and that for non data-xfer applications, (which generate the majority of 'small' packets, it will take quite some time to consume a 32 bit counter, when the count is packets. (e.g. 2G of these 'smaller' packets.) Since most applications of ipsec will care enough about security to re-key every couple hours as a matter of course, the 'smaller packets' shouldn't present a problem. Consider how long it would take to consume 2^32 packets with 'telnet' or a chat client. For bulk data, even at ethernet MTUs, the issue becomes: is 2^32 * 1500 bytes enough data to expose almost any algorithm? 32 bits should suffice. > As to the 64-bit math, [...] This was NOT a problem on an Intel Pentium. Not all the world is Intel. In addition, a large percentage of the world will run IPv4 for a long time to come. -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax HTML: The 3270 of the 90s From owner-ipsec Fri Feb 14 15:05:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16863 for ipsec-outgoing; Fri, 14 Feb 1997 15:02:40 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199702142006.PAA35800@mailhub1.watson.ibm.com> Date: Fri, 14 Feb 97 14:45:23 EST To: IPSEC@tis.com Subject: 32 bit counter -- 96 bit HMAC-SHA/MD5 Sender: owner-ipsec@ex.tis.com Precedence: bulk I haven't followed in detail all the votes but it seems that there is signifcant support for truncated HMAC-SHA and 32 bit counter. Even if we allow for variable/negotiable/per-algorithm counter size it seems that 32 bit will be prevalent for the near future. Therefore, for the sake of easy alignment I recommend considering going to 96-bit truncated HMAC-SHA1 and 96-bit truncated HMAC-MD5 (this is what we'd call HMAC-SHA1-96 and HMAC-MD5-96 following the terminology in RFC2104) I personally would NOT pay with security to save 32-bit padding. However, as already explained in the past, all the current evidence that we have seems to suggest that some truncation in the MAC is good. I would never go below 80 bit truncation. However, 96 bits sounds as a perfectly wise choice. We do NOT have PROOFS as for the effect of truncation. We DO have some evidence to support it. Moreover, if truncation is discovered in the future to be bad for the combination of HMAC with some specific hash function then that hash function will have to be dropped for its use even without truncation. Our analysis suggests that it will be just too weak to use with HMAC. Bottom line: today's cryptography justifies going to 96 bits (both MD5 and SHA1) and it helps alignment (with a typical 32-bit counter) Hugo PS: sorry for adding an option not covered in the straw poll... From owner-ipsec Fri Feb 14 15:24:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16971 for ipsec-outgoing; Fri, 14 Feb 1997 15:22:17 -0500 (EST) Message-Id: <199702142026.MAA19497@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News In-Reply-To: Your message of "Fri, 14 Feb 1997 10:19:59 EST." <3.0.16.19970214100530.34cf2fc4@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Feb 1997 12:26:26 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > what version of cylink's code are you using NOW and do you know of a > reference (like a URL) from Cylink on this? right NOW I'm using version 2.1 and you'll have to contact Cylink yourself for any references or URLs (besides the obvious www.cylink.com). From owner-ipsec Fri Feb 14 15:28:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16996 for ipsec-outgoing; Fri, 14 Feb 1997 15:27:20 -0500 (EST) Message-Id: <199702142031.MAA19509@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" Subject: Re: Quick Mode and KE payloads In-Reply-To: Your message of "Fri, 14 Feb 1997 09:07:46 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Feb 1997 12:31:15 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > ISAKMP\Oakley states that the group description attribute must be sent > for PFS in the SA being negotiated. The appendix then states that > ..."Phase two attributes are defined in the applicable DOI > specification, with the exception of a group description when Quick Mode > includes an ephemeral DH exchange...." > > The above wording has me a little confused. Yes, it is confusing and has been changed. The "with the exeption of..." has been stricken. All phase 2 attributes are specified by the applicable DOI document. > Attribute Classes > > ISAKMP\Oakley Draft > Group Description 4 > > DOI Draft > Enc Key Life Duration 4 and: DOI Draft Group Description 8 Quick Mode with PFS specifies the group using this attribute. Dan. From owner-ipsec Fri Feb 14 15:32:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17033 for ipsec-outgoing; Fri, 14 Feb 1997 15:30:52 -0500 (EST) To: HUGO@watson.ibm.com Cc: IPSEC@tis.com Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 References: <199702142006.PAA35800@mailhub1.watson.ibm.com> From: Derek Atkins Date: 14 Feb 1997 15:35:11 -0500 In-Reply-To: HUGO@watson.ibm.com's message of Fri, 14 Feb 97 14:45:23 EST Message-Id: Lines: 51 X-Mailer: Gnus v5.2.37/Emacs 19.30 Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd be afraid that truncating to 96 bits would make brute-force attacks too easy. We've already seen 48 bit RC5 keys falling in very short amounts of time (hours) using brute-force methods. Today. These MACs need to be secure for YEARS! I don't think that a 96-bit MAC is long-enough to survive brute-force attacks for very long. I'd be much happier with the extra 32-bits, keeping the MAC at 128. -derek HUGO@watson.ibm.com writes: > > I haven't followed in detail all the votes but it seems > that there is signifcant support for truncated HMAC-SHA > and 32 bit counter. > > Even if we allow for variable/negotiable/per-algorithm > counter size it seems that 32 bit will be prevalent for > the near future. Therefore, for the sake of easy alignment > I recommend considering going to 96-bit truncated HMAC-SHA1 and > 96-bit truncated HMAC-MD5 > (this is what we'd call HMAC-SHA1-96 and HMAC-MD5-96 > following the terminology in RFC2104) > > I personally would NOT pay with security to save 32-bit > padding. However, as already explained in the past, all the current > evidence that we have seems to suggest that some truncation > in the MAC is good. I would never go below 80 bit truncation. > However, 96 bits sounds as a perfectly wise choice. > > We do NOT have PROOFS as for the effect of truncation. > We DO have some evidence to support it. > Moreover, if truncation is discovered in the future to > be bad for the combination of HMAC with some specific hash function > then that hash function will have to be dropped for its use even > without truncation. Our analysis suggests that it will be just too weak > to use with HMAC. > > Bottom line: today's cryptography justifies going to 96 bits > (both MD5 and SHA1) and it helps alignment (with a typical 32-bit counter) > > Hugo > > PS: sorry for adding an option not covered in the straw poll... -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec Fri Feb 14 16:19:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17354 for ipsec-outgoing; Fri, 14 Feb 1997 16:16:42 -0500 (EST) Message-Id: <199702142119.QAA27941@raptor.research.att.com> To: Derek Atkins cc: HUGO@watson.ibm.com, IPSEC@tis.com Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 Date: Fri, 14 Feb 1997 16:19:13 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd be afraid that truncating to 96 bits would make brute-force attacks too easy. We've already seen 48 bit RC5 keys falling in very short amounts of time (hours) using brute-force methods. Today. These MACs need to be secure for YEARS! I don't think that a 96-bit MAC is long-enough to survive brute-force attacks for very long. No, they have to be secure for hours at best. This is for per-packet authentication; when you rekey, old packets are useless to the adversary. And there are no secrecy implications here -- my attacks assumed that the key was still live. From owner-ipsec Fri Feb 14 16:23:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17388 for ipsec-outgoing; Fri, 14 Feb 1997 16:21:46 -0500 (EST) To: Steven Bellovin Cc: HUGO@watson.ibm.com, IPSEC@tis.com Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 References: <199702142119.QAA27941@raptor.research.att.com> From: Derek Atkins Date: 14 Feb 1997 16:25:43 -0500 In-Reply-To: Steven Bellovin's message of Fri, 14 Feb 1997 16:19:13 -0500 Message-Id: Lines: 33 X-Mailer: Gnus v5.2.37/Emacs 19.30 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin writes: > > I'd be afraid that truncating to 96 bits would make brute-force > attacks too easy. We've already seen 48 bit RC5 keys falling in very > short amounts of time (hours) using brute-force methods. Today. > These MACs need to be secure for YEARS! I don't think that a 96-bit > MAC is long-enough to survive brute-force attacks for very long. > > No, they have to be secure for hours at best. This is for per-packet > authentication; when you rekey, old packets are useless to the adversary. > And there are no secrecy implications here -- my attacks assumed that > the key was still live. Let me rephrase what I meant.. These *algorithms* need to be secure for years (not the actual MAC values, of course those change relatively quickly). The problem is that as computer speed increases the amount of time required to brute-force these values will decrease. Just look at how the time to break 40-bit keys has decreased over the last year or two. I'm just afraid that a 96-bit MAC might come down into this breakable range before the algorithms get replaced. And if we limit them to 96 bits completely, eventually the brute-force mechanisms will catch up with us. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec Fri Feb 14 16:32:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17432 for ipsec-outgoing; Fri, 14 Feb 1997 16:31:19 -0500 (EST) Date: Fri, 14 Feb 1997 16:35:35 -0500 Message-Id: <9702142135.AA13130@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Derek Atkins Cc: HUGO@watson.ibm.com, IPSEC@tis.com In-Reply-To: Derek Atkins's message of 14 Feb 1997 15:35:11 -0500, Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Derek Atkins Date: 14 Feb 1997 15:35:11 -0500 I'd be afraid that truncating to 96 bits would make brute-force attacks too easy. We've already seen 48 bit RC5 keys falling in very short amounts of time (hours) using brute-force methods. Today. These MACs need to be secure for YEARS! I don't think that a 96-bit MAC is long-enough to survive brute-force attacks for very long. Derek, I'm not a cryptographer, so take my comments with a grain of salt, but my understanding is that MAC's, unlike cryptographic checksums, aren't subject to birthday attacks, since key used to generate the MAC is secret. Hence, HMAC truncated to 64 bits has an attack difficulty of O(2**64), and HMAC truncated to 96 bits has an attack difficulty of O(2**98), NOT O(2**48). - Ted From owner-ipsec Fri Feb 14 16:54:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17588 for ipsec-outgoing; Fri, 14 Feb 1997 16:53:00 -0500 (EST) Message-Id: <199702142153.QAA03394@raptor.research.att.com> To: Derek Atkins cc: HUGO@watson.ibm.com, IPSEC@tis.com Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 Date: Fri, 14 Feb 1997 16:53:30 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > No, they have to be secure for hours at best. This is for per-packet > authentication; when you rekey, old packets are useless to the adversary. > And there are no secrecy implications here -- my attacks assumed that > the key was still live. Let me rephrase what I meant.. These *algorithms* need to be secure for years (not the actual MAC values, of course those change relatively quickly). The problem is that as computer speed increases the amount of time required to brute-force these values will decrease. Just look at how the time to break 40-bit keys has decreased over the last year or two. I'm just afraid that a 96-bit MAC might come down into this breakable range before the algorithms get replaced. And if we limit them to 96 bits completely, eventually the brute-force mechanisms will catch up with us. Ah -- this makes more sense -- but I'm still not worried. Let's consider a brute-force attack. You take a known packet, crunch at possible keys, and find something where the first 96 bits of the HMAC-SHA output match the observed value. But there are many possible keys that will yield that result for this packet; most won't work for the second packet. When you find a key that works for the first two packets, will it work for the third? The fourth? I'm not certain what the exact complexity of this process is, but I'm sure that it's quite high. (I have some guesses, but I'd embarrass myself if I stated them...) Nor does the traditional collision attack apply here; you can't find two matching hash values offline per the van Oorschot/Wiener '94 paper, since the key is unknown. It would be an interesting exercise, I think, to come up with a paper design for an HMAC cracker, with the hash length, the truncation length, and the key length as input parameters. One more point -- the defense has another advantage here. As the apparent threat increases, we can cut the rekey time down. That's just a parameter of the key exchange mechanism, not code. From owner-ipsec Sun Feb 16 13:00:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28364 for ipsec-outgoing; Sun, 16 Feb 1997 12:49:52 -0500 (EST) Date: Sun, 16 Feb 1997 18:54:04 +0100 (MET) From: Bart Preneel To: IPSEC@tis.com Cc: Bart Preneel Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 In-Reply-To: <199702142153.QAA03394@raptor.research.att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-ipsec@ex.tis.com Precedence: bulk TRUNCATION of HMAC output: I support Hugo's suggestion to go for 96 bits, but would suggest myself to even go to 64 bits (MD5) or 80 bits (SHA-1). parameters: - size of key: k bits - size of result: m bits - size of internal memory: n bits 128 for MD5, 160 bits for SHA-1 and RIPEMD-160) [what is RIPEMD-160? a European alternative for SHA-1 see http://www.esat.kuleuven.ac.be/~bosselae ] We know of the following three attacks against HMAC (there might be others, but that makes life interesting): 1. Guess the value of the MAC Probability of success 2^{-m}. Even for messages of high value, 64 bits is more than sufficient for the next 10 to 15 years. 80 or 96 bits gives an ample safety margin. 2. Brute force exhaustive key search Needs about k/m known text-MAC pairs. Work factor 2^{k-1}. The work factor is essentially independent of m. (this should answer Steve's question of Fri, 14 Feb 1997 16:53:30 -0500) (same story as for exhaustive key search for encryption -- the difference is that the life time of a key is almost irrelevant - only the lifetime of the system itself is relevant). 80 bits is ok for midterm, 128 bits is ok for 20 years or more. 3. Shortcut forgery attack Needs 2^{n/2} known text-MAC pairs and 2^{n-m}$ chosen texts. This attack becomes even more unrealistic if shortening is applied (m < n), because then the number of chosen text increases. The main problem is: other attacks. If algorithm dependent attacks are ever found (extending Dobbertin's results to MACs), they are affected by m as follows: a. shortcut forgery attacks (IMHO not very probable): reducing m might make the scheme weaker b. shortcut key recovery attacks will become more difficult if less information is given away -- fewer bits of the MAC (I believe that this is a more likely scenario). Also note that key recovery attacks are more serious than forgery attacks anyway. > Date: 14 Feb 1997 15:35:11 -0500 > From: Derek Atkins > To: HUGO@watson.ibm.com > Cc: IPSEC@tis.com > Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 > I'd be afraid that truncating to 96 bits would make brute-force > attacks too easy. We've already seen 48 bit RC5 keys falling in very > short amounts of time (hours) using brute-force methods. Today. > These MACs need to be secure for YEARS! I don't think that a 96-bit > MAC is long-enough to survive brute-force attacks for very long. > I'd be much happier with the extra 32-bits, keeping the MAC at 128. > -derek I am not aware of any brute force attack on a MAC which runs in time 2^{m/2} (a MAC is not an unkeyed hash function). If you know of such an attack, let me know asap. > Date: Fri, 14 Feb 1997 16:35:35 -0500 > From: "Theodore Y. Ts'o" > To: Derek Atkins > Cc: HUGO@watson.ibm.com, IPSEC@tis.com > Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 > > Derek, > I'm not a cryptographer, so take my comments with a grain of > salt, but my understanding is that MAC's, unlike cryptographic > checksums, aren't subject to birthday attacks, since key used to > generate the MAC is secret. Hence, HMAC truncated to 64 bits has an > attack difficulty of O(2**64), and HMAC truncated to 96 bits has an > attack difficulty of O(2**98), NOT O(2**48). > > - Ted I try to be a cryptographer, and I would say MD5 (with 128-bit key) 64 bits: 2^{128} off-line for key recovery 2^{64} known and 2^{64} chosen texts for forgery 2^{64} for guessing a MAC 96 bits: 2^{128} off-line for key recovery 2^{64} known and 2^{32} chosen texts for forgery 2^{96} for guessing a MAC SHA-1 (with 128-bit key) 64 bits: 2^{128} off-line for key recovery 2^{80} known and 2^{96} chosen texts for forgery 2^{64} for guessing a MAC 96 bits: 2^{128} off-line for key recovery 2^{80} known and 2^{64} chosen texts for forgery 2^{96} for guessing a MAC These are the best attacks we know of today. Given the collision attacks on the compression function of MD5, it seems realistic to expect that a key recovery is probably easier than 2^{128} on the MD5 version (I have no attack yet). But decreasing m would only help against such an attack. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be ------------------------------------------------------------------------------- From owner-ipsec Sun Feb 16 13:12:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28472 for ipsec-outgoing; Sun, 16 Feb 1997 13:09:25 -0500 (EST) Date: Sun, 16 Feb 1997 19:13:22 +0100 (MET) From: Bart Preneel To: Steven Bellovin Cc: Ran Atkinson , Robert Glenn , Stephen Kent , ipsec@tis.com Subject: Re: replay field size In-Reply-To: <199702131637.LAA02391@raptor.research.att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-ipsec@ex.tis.com Precedence: bulk Linear cryptanalysis of DES: > Date: Thu, 13 Feb 1997 11:37:39 -0500 > From: Steven Bellovin > To: Ran Atkinson > Cc: Robert Glenn , Stephen Kent , > ipsec@tis.com > Subject: Re: replay field size > > [...] > > But it's worse than that. At 250 bytes/packet, there are about 2^5 DES > blocks/packet, which means there are 2^37 blocks per ``full'' 32-bit > security association. That's getting unpleasantly close to the point > where linear cryptanalysis is feasible. (Matsui's CRYPTO '94 paper > says that with 2^38 known plaintexts, the success rate is 10% with > complexity 2^50. The new ``Handbook of Applied Cryptography'' notes > that ``linear cryptanalysis is possible in a ciphertext-only > environment if some underlying plaintext redundancy is known (e.g., > parity bits or high-order 0-bits in ASCII characters.)) I submit that > we really don't want to encrypt that much plaintext with any single key > -- ever. And of course, we don't know that linear cryptanalysis is the > ultimate attack. As far as I know, the extension of Matsui's attack to ciphertext only (given ASCII plaintext) requires at least 2^{10} times more ciphertext (see Matsui's Eurocrypt'93 paper). So 2^{38} known plaintexts will become something like 2^{48} ciphertext only. This can probably be still improved, but it is not very serious as threat. Given the complexity of 2^{50}, it is probably much easier to build the DES key search machine -- success probability of 1.6%), which needs only 1 plaintext/ciphertext pair, rather than to collect all the data on 2^{48} ciphertexts. A complexity of 2^{40} seems more realistic to me, which implies that about 10 times more ciphertexts are required. I would be much more concerned about the `matching ciphertext' problem of the CBC-mode: information on the plaintext starts to leak after 2^{33} blocks (for 2^{38} there will be already 2000 matches). A very good reason to never encrypt more than 2^{33} plaintexts with a single key. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be ------------------------------------------------------------------------------- From owner-ipsec Mon Feb 17 19:16:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08684 for ipsec-outgoing; Mon, 17 Feb 1997 19:10:58 -0500 (EST) Message-Id: <3.0.32.19970217161428.009493c0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 16:14:33 -0800 To: ipsec@tis.com From: Bob Monsour Subject: TO COMPRESS OR NOT TO CMPRS (please reply) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Since my last posting about adding compression in the form of an "optional feature of ESP", I have received several offline inputs from wg members. Specifically, two issues arose: 1. What is the status of adding compression to ESP? I know that there are some wg members who support the use of compression, some who don't and some who haven't expressed an interest either way. Well, the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. Be sure to copy the wg list in your reply. 2. Placement of the "packet compressed/not-compressed" byte/bit Several people have suggested that rather than using a whole byte for this purpose, simply "steal" the uppermost bit of the pad length field. This is a simple solution. It was suggested to me that a maximum of 128 bytes of padding is sufficient. Note that the preferred ESP transform for the IPSEC DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of padding. There are two ways to approach this issue: (a) alter the transform draft to specify a max of 128 bytes of padding, or (b) for implementations which do not negotiate the use of compression (for a particular SA, or never), they can continue to use up to 255 bytes of padding; for those that *do* support compression, the maximum padding would be 128 bytes. INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to proceed with compression, the decision on this issue will affect the ESP draft, the latest of which has yet to be issued. So, please respond. Regards, Bob From owner-ipsec Mon Feb 17 21:27:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09533 for ipsec-outgoing; Mon, 17 Feb 1997 21:25:53 -0500 (EST) Message-Id: <199702180230.SAA21924@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Bob Monsour Cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: Your message of "Mon, 17 Feb 1997 16:14:33 PST." <3.0.32.19970217161428.009493c0@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Feb 1997 18:30:12 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > I know that there are some wg members who support the use of compression, > some who don't and some who haven't expressed an interest either way. Well, > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > Be sure to copy the wg list in your reply. I support the use of compression but not in IPsec. It should be done up higher, perhaps the transport level. It's better to compress the stream of data before it's divided into packets than to wait and compress each packet. I'd rather see 50 packets then 100 smaller ones. 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 Tue Feb 18 05:12:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA11840 for ipsec-outgoing; Tue, 18 Feb 1997 05:10:38 -0500 (EST) From: Germano Caronni Message-Id: <199702181014.LAA01115@kom30.ethz.ch> Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) To: dharkins@cisco.com (Daniel Harkins) Date: Tue, 18 Feb 1997 11:14:41 +0100 (MET) Cc: rmonsour@earthlink.net, ipsec@tis.com In-Reply-To: <199702180230.SAA21924@dharkins-ss20.cisco.com> from "Daniel Harkins" at Feb 17, 97 06:30:12 pm X-Mailer: ELM [version 2.4 PL25 PGP7] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > > I know that there are some wg members who support the use of compression, > > some who don't and some who haven't expressed an interest either way. Well, > > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > > Be sure to copy the wg list in your reply. > > I support the use of compression but not in IPsec. It should be done up > higher, perhaps the transport level. It's better to compress the stream > of data before it's divided into packets than to wait and compress each > packet. I'd rather see 50 packets then 100 smaller ones. Compression allows for saving a valuable ressource. This might be done on intermediate systems (e.g. firewalls) which also care about enterprise security and to encryption. Usually in those systems no upper layer is available. I support compression as an optional (and important) function in ESP. Germano From owner-ipsec Tue Feb 18 07:49:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12832 for ipsec-outgoing; Tue, 18 Feb 1997 07:47:49 -0500 (EST) Message-Id: <9702180229.AA00348@ebony.arl.wustl.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) X-Image-Url: http://www.tik.ee.ethz.ch/~mwa/mwa.mail.tiff In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net> X-Nextstep-Mailer: Mail 4.0 (Enhance 2.0b5) From: Marcel Waldvogel Date: Mon, 17 Feb 97 20:26:46 -0600 To: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com References: <3.0.32.19970217161428.009493c0@earthlink.net> Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 17 Feb 1997, Bob Monsour wrote: > 1. What is the status of adding compression to ESP? Bob, I think compression should officially be made an optional feature of ESP, so that there is a defined way to negotiate the use of compression. I think that otherwise (since compression is a Good Thing, IMHO), several incompatible approaches will arise. > 2. Placement of the "packet compressed/not-compressed" byte/bit > (a) alter the transform draft to specify a max of 128 bytes of padding I think it would be unwise to start introducing downward compatibility features at this early stage, where no "final" commercial (or other publicly available) versions are out yet, so it should be very easy to change them. Those not supporting compression will most likely not need a single byte of source change. - -Marcel -----BEGIN PGP SIGNATURE----- Version: 2.6 Charset: next iQCVAwUBMwkT7cqBByDTF1SlAQEV0QQA0HPJThF2eQ761N4hdeCnbo6i0W5HV034 MKVydLnlGttpk300xJypx0l0k1KF7/ZzlOZmyoMoKLNZBHwPzE0xGFvKKUPrf9kE npEHbFbHP0FviBMXqAuMwyxlLu973ZEQ8DWEUazAs0W/dTJ1JcJQRknrxNyjlP4L /l4k1Z6eYDc= =/1zz -----END PGP SIGNATURE----- From owner-ipsec Tue Feb 18 10:36:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14320 for ipsec-outgoing; Tue, 18 Feb 1997 10:35:17 -0500 (EST) Message-Id: <3.0.16.19970218102824.1e8ff476@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 18 Feb 1997 10:39:40 -0500 To: Bob Monsour From: Rodney Thayer Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I think there should be compression. I think stealing a bit sounds like an acceptable scheme. I think this should be a negotiated option in a key management context (see the DOI) to specify this. I think it should be a bit rather than a byte in deference to the 64-bit alignment issue. I believe the combination of using a bit and using negotiation allows implementations to address or ignore compression in an interoperable manner. I believe the 128-byte padding limit has no known problems, as I recall the conversations. At 04:14 PM 2/17/97 -0800, you wrote: >Since my last posting about adding compression in the form of an "optional >feature of ESP", I have received several offline inputs from wg members. >Specifically, two issues arose: > >1. What is the status of adding compression to ESP? > > I know that there are some wg members who support the use of compression, > some who don't and some who haven't expressed an interest either way. Well, > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > Be sure to copy the wg list in your reply. > >2. Placement of the "packet compressed/not-compressed" byte/bit > > Several people have suggested that rather than using a whole byte for this > purpose, simply "steal" the uppermost bit of the pad length field. This is > a simple solution. It was suggested to me that a maximum of 128 bytes of > padding is sufficient. Note that the preferred ESP transform for the IPSEC > DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of > padding. There are two ways to approach this issue: > > (a) alter the transform draft to specify a max of 128 bytes of padding, or > > (b) for implementations which do not negotiate the use of compression (for > a particular SA, or never), they can continue to use up to 255 bytes > of padding; for those that *do* support compression, the maximum >padding > would be 128 bytes. > > INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to >proceed > with compression, the decision on this issue will affect the ESP draft, >the > latest of which has yet to be issued. So, please respond. > >Regards, >Bob > > > > 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 Tue Feb 18 11:36:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14863 for ipsec-outgoing; Tue, 18 Feb 1997 11:35:38 -0500 (EST) Message-Id: <3.0.32.19970218082333.00e166c8@netcom.com> X-Sender: dpalma@netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 08:39:09 -0800 To: Germano Caronni , dharkins@cisco.com (Daniel Harkins) From: Derek Palma Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: rmonsour@earthlink.net, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:14 AM 2/18/97 +0100, Germano Caronni wrote: >Daniel Harkins wrote: >> > I know that there are some wg members who support the use of compression, >> > some who don't and some who haven't expressed an interest either way. Well, >> > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. >> > Be sure to copy the wg list in your reply. >> >> I support the use of compression but not in IPsec. It should be done up >> higher, perhaps the transport level. It's better to compress the stream >> of data before it's divided into packets than to wait and compress each >> packet. I'd rather see 50 packets then 100 smaller ones. > >Compression allows for saving a valuable ressource. This might be done on >intermediate systems (e.g. firewalls) which also care about enterprise >security and to encryption. Usually in those systems no upper layer is >available. > >I support compression as an optional (and important) function in ESP. > >Germano > > I agree. Compression is beneficial. At the very least it is able to compensate for IPSEC overhead which is nice in both end systems and intermediate systems. Derek Palma Net Research, Inc. From owner-ipsec Tue Feb 18 12:05:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15091 for ipsec-outgoing; Tue, 18 Feb 1997 12:04:54 -0500 (EST) Message-Id: <3.0.32.19970218114537.006fdd90@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 18 Feb 1997 11:51:40 -0500 To: Bob Monsour , ipsec@tis.com From: Matt Thomas Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I want to see compression included. I don't see the new for cross-packet compression. There is a need to negotiation compression algorithms. I wonder if we can handle that like we handle negotiation of transforms? (ie. if both parties agree to the same algorithm, then compression will be used. If not, it won't.) I also want to steal the top bit of the pad byte to use as the compression indication. I don't, however, care if the pad is always limited to 127 bytes. -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Tue Feb 18 12:24:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15295 for ipsec-outgoing; Tue, 18 Feb 1997 12:24:03 -0500 (EST) Message-Id: <199702181700.JAA25178@stilton.cisco.com> To: Derek Palma cc: Germano Caronni , dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com From: carrel@ipsec.org Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Tue, 18 Feb 1997 08:39:09 PST." <3.0.32.19970218082333.00e166c8@netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25176.856285219.1@cisco.com> Date: Tue, 18 Feb 1997 09:00:20 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk > I agree. Compression is beneficial. At the very least it is able to > compensate for IPSEC overhead which is nice in both end systems and > intermediate > systems. Er, no. "At the very least" compression provides no benefit in packet size and increases computational load. (I'm not sure if I'm correcting your colloquial english or your understanding of compression.) There is no guaranteed compression. In the case of interactive traffic like telnet, compression will have very little benefit. In the case of ftp data traffic (large MTU sized packets), compression _may_ save you from having to fragment when encrypting. But only if the data is not already compressed. In the case of ftp, data IS quite often already compressed. Now don't get me wrong. I'd like to see the ability to support compression. (Life is more than telnet and ftp.) But don't assume its a panacea. Dave From owner-ipsec Tue Feb 18 12:26:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15331 for ipsec-outgoing; Tue, 18 Feb 1997 12:26:35 -0500 (EST) Message-Id: <3.0.32.19970218121355.006fd66c@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 18 Feb 1997 12:14:38 -0500 To: Daniel Harkins From: Matt Thomas Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:30 PM 2/17/97 -0800, Daniel Harkins wrote: >> I know that there are some wg members who support the use of compression, >> some who don't and some who haven't expressed an interest either way. Well, >> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. >> Be sure to copy the wg list in your reply. > >I support the use of compression but not in IPsec. It should be done up >higher, perhaps the transport level. It's better to compress the stream >of data before it's divided into packets than to wait and compress each >packet. I'd rather see 50 packets then 100 smaller ones. In a perfect world, that would be the case. But not everything will be compressed. (telnet, IP tunnels, ftp, smtp, nntp, etc). But if you can compress the data, you have less to encrypt and you end up sending less bits and using less cpu to encrypt those bits. -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Tue Feb 18 12:51:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15448 for ipsec-outgoing; Tue, 18 Feb 1997 12:48:10 -0500 (EST) Message-Id: <3.0.32.19970218094734.00e13d34@netcom.com> X-Sender: dpalma@netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 09:48:26 -0800 To: carrel@ipsec.org, Derek Palma From: Derek Palma Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Germano Caronni , dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, At 09:00 AM 2/18/97 -0800, carrel@ipsec.org wrote: >> I agree. Compression is beneficial. At the very least it is able to >> compensate for IPSEC overhead which is nice in both end systems and >> intermediate >> systems. > >Er, no. "At the very least" compression provides no benefit in packet size >and increases computational load. (I'm not sure if I'm correcting your >colloquial english or your understanding of compression.) There is no >guaranteed compression. In the case of interactive traffic like telnet, >compression will have very little benefit. In the case of ftp data traffic >(large MTU sized packets), compression _may_ save you from having to >fragment when encrypting. But only if the data is not already compressed. >In the case of ftp, data IS quite often already compressed. I should not use colloquial English! You are correct. Actually, compression can cause expansion which would be "the very least". When IP all traffic traffic is considered compression can have some benefits assuming that compression can negate IPSEC overhead on larger packets. Small packets do not compress well. There is no advantage to compressing a packet which does not compress well. My point was that if you find one that does, there may be some advantage to sending it compressed. > >Now don't get me wrong. I'd like to see the ability to support >compression. (Life is more than telnet and ftp.) But don't assume its a >panacea. I agree. Derek From owner-ipsec Tue Feb 18 12:52:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15508 for ipsec-outgoing; Tue, 18 Feb 1997 12:52:41 -0500 (EST) Message-Id: <199702181756.JAA22636@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Matt Thomas Cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: Your message of "Tue, 18 Feb 1997 12:14:38 EST." <3.0.32.19970218121355.006fd66c@netrix.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 09:56:40 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt Thomas wrote: >At 06:30 PM 2/17/97 -0800, Daniel Harkins wrote: >>> I know that there are some wg members who support the use of compression, >>> some who don't and some who haven't expressed an interest either way. >Well, >>> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. >>> Be sure to copy the wg list in your reply. >> >>I support the use of compression but not in IPsec. It should be done up >>higher, perhaps the transport level. It's better to compress the stream >>of data before it's divided into packets than to wait and compress each >>packet. I'd rather see 50 packets then 100 smaller ones. >> >In a perfect world, that would be the case. But not everything will be >compressed. (telnet, IP tunnels, ftp, smtp, nntp, etc). But if you >can compress the data, you have less to encrypt and you end up sending >less bits and using less cpu to encrypt those bits. In a perfect world, that would be the case. But not everything will compress. (Sorry, I couldn't resist). And I don't buy the cpu saving argument since I have to compress the packets first and that's not free. I understand what compression does, I just think it would be *more* beneficial to be done somewhere else. There's a certain amount of overhead that has to be spent per packet (regardless of size). Compression can make a given data stream either occupy fewer packets, or it can make it occupy the same number of packets as an uncompressed stream (albeit in smaller packets). I prefer the former. Dan. From owner-ipsec Tue Feb 18 13:05:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15590 for ipsec-outgoing; Tue, 18 Feb 1997 13:04:46 -0500 (EST) Date: Tue, 18 Feb 1997 10:09:01 -0800 Message-Id: <199702181809.KAA23603@gump.eng.ascend.com> From: Karl Fox To: Derek Palma Cc: carrel@ipsec.org, Germano Caronni , dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: <3.0.32.19970218094734.00e13d34@netcom.com> References: <3.0.32.19970218094734.00e13d34@netcom.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Derek Palma writes: > When IP all traffic traffic is considered compression can have some > benefits assuming that compression can negate IPSEC overhead on > larger packets. Small packets do not compress well. This is not universally true; it depends on the compression algorithm. Consider, for example, Van Jacobson TCP/IP header compression, an algorithm which should definitely be one of those available for use within ESP. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Tue Feb 18 13:31:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15892 for ipsec-outgoing; Tue, 18 Feb 1997 13:31:04 -0500 (EST) Message-Id: <2.2.32.19970218184217.00b0cb6c@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: Tue, 18 Feb 1997 13:42:17 -0500 To: Bob Monsour From: Naganand Doraswamy Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, >1. What is the status of adding compression to ESP? > > I know that there are some wg members who support the use of compression, > some who don't and some who haven't expressed an interest either way. Well, > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > Be sure to copy the wg list in your reply. > I am open to optional compression support being added to IPsec. >2. Placement of the "packet compressed/not-compressed" byte/bit > > Several people have suggested that rather than using a whole byte for this > purpose, simply "steal" the uppermost bit of the pad length field. This is > a simple solution. It was suggested to me that a maximum of 128 bytes of > padding is sufficient. Note that the preferred ESP transform for the IPSEC > DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of > padding. There are two ways to approach this issue: > > (a) alter the transform draft to specify a max of 128 bytes of padding, or > > (b) for implementations which do not negotiate the use of compression (for > a particular SA, or never), they can continue to use up to 255 bytes > of padding; for those that *do* support compression, the maximum >padding > would be 128 bytes. > I DONT like option b. We already have too many options and I feel this will complicate it even more! From security point of view, is there any need to pad more than 127 bytes? If the answer is no from cryptographers, we should use the MSB of the pad. If the answer is yes, we should think of a better solution. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Feb 18 14:38:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16423 for ipsec-outgoing; Tue, 18 Feb 1997 14:37:14 -0500 (EST) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Bob Monsour'" Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 12:58:16 -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 While compression make some sense at a transport layer, it also make sense to implement it with IPSec as well. Certain situations do not have access to transport layer compression (ie. firewalls) and IPSec compression would greatly affect performance, expecially when you consider that in certain situations where a lot of large packets are being sent accross, adding the ESP header would cause fragmentation. When compression is used, fragmentation would not normally be required. I don't like the idea of adding it to the pad length field. Although 255 bytes of padding is more than enough, changing that fields role might break some current implementations. I like the idea presented in , whereas the compression byte field is placed as the first byte of the ESP data. After this byte, is the compressed data. We might also wish to expand this compression byte field to a small header for future growth; Eg: compression_header :== { word compression_header_length; byte flags; // 0x01 = compressed } >---------- >From: Bob Monsour[SMTP:rmonsour@earthlink.net] >Sent: Monday, February 17, 1997 7:14 PM >To: ipsec@tis.com >Subject: TO COMPRESS OR NOT TO CMPRS (please reply) > >Since my last posting about adding compression in the form of an "optional >feature of ESP", I have received several offline inputs from wg members. >Specifically, two issues arose: > >1. What is the status of adding compression to ESP? > > I know that there are some wg members who support the use of compression, > some who don't and some who haven't expressed an interest either way. >Well, > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > Be sure to copy the wg list in your reply. > >2. Placement of the "packet compressed/not-compressed" byte/bit > > Several people have suggested that rather than using a whole byte for this > purpose, simply "steal" the uppermost bit of the pad length field. This is > a simple solution. It was suggested to me that a maximum of 128 bytes of > padding is sufficient. Note that the preferred ESP transform for the IPSEC > DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of > padding. There are two ways to approach this issue: > > (a) alter the transform draft to specify a max of 128 bytes of padding, >or > > (b) for implementations which do not negotiate the use of compression >(for > a particular SA, or never), they can continue to use up to 255 bytes > of padding; for those that *do* support compression, the maximum >padding > would be 128 bytes. > > INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to >proceed > with compression, the decision on this issue will affect the ESP draft, >the > latest of which has yet to be issued. So, please respond. > >Regards, >Bob > > > From owner-ipsec Tue Feb 18 14:54:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16574 for ipsec-outgoing; Tue, 18 Feb 1997 14:54:26 -0500 (EST) Message-Id: <3.0.32.19970218115542.0069571c@pop.rv.tis.com> X-Sender: jmcwilliams@pop.rv.tis.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 11:55:43 -0500 To: paul_lambert@email.mot.com, jis@MIT.EDU, ipsec@ans.net From: John McWilliams Subject: IP SEC update query Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I am consulting on behalf of Trusted Information Systems in support of major companies who are receiving mixed messages relative to IP SEC delivery. Are you aware of any commercially avaiable, or soon to be available, IP SEC product? If you could point me in the right direction it would be deeply appreciated. Sincerely, John McWilliams Trusted Information Systems, Inc. 15204 Omega Drive, Rockville, MD 20850 Phone: (301) 527-9500 x272 Fax: (301) 527-0482 Email: jmcwilliams@tis.com From owner-ipsec Tue Feb 18 15:32:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16899 for ipsec-outgoing; Tue, 18 Feb 1997 15:32:02 -0500 (EST) Message-Id: <199702182035.MAA24381@andorra.it.earthlink.net> From: "Bob Monsour" To: "Karl Fox" , "Derek Palma" Cc: , "Germano Caronni" , "Daniel Harkins" , Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 13:33:33 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- > From: Karl Fox > Date: Tuesday, February 18, 1997 10:09 AM ...snip... > This is not universally true; it depends on the compression algorithm. > Consider, for example, Van Jacobson TCP/IP header compression, an > algorithm which should definitely be one of those available for use > within ESP. Karl, The proposed compression mechanism is aimed at the ESP payload data field and (from my limited understanding) VJ header compression operates on the segment/packet headers only. So, I don't see them as alternatives as much as complements to each other. There would certainlyh have to be agreement (perhaps KMP negotiation) between the communicating parties to perform VJ header compression. If I recall correctly, I believe that there is a draft somewhere that proposes VJ compression on IPv6 headers. -Bob From owner-ipsec Tue Feb 18 15:32:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16900 for ipsec-outgoing; Tue, 18 Feb 1997 15:32:03 -0500 (EST) Message-Id: <199702182035.MAA24359@andorra.it.earthlink.net> From: "Bob Monsour" To: "Derek Palma" , Cc: "Germano Caronni" , "Daniel Harkins" , Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 13:28:38 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Er, no. "At the very least" compression provides no benefit in packet size > and increases computational load. (I'm not sure if I'm correcting your > colloquial english or your understanding of compression.) There is no > guaranteed compression. In the case of interactive traffic like telnet, > compression will have very little benefit. In the case of ftp data traffic > (large MTU sized packets), compression _may_ save you from having to > fragment when encrypting. But only if the data is not already compressed. > In the case of ftp, data IS quite often already compressed. What I would imagine occuring at the implementation level is that you would set a threshhold packet size and any packets below the threshhold would not be compressed (due to the lack of expected benefit). Larger packets would get compressed and in the event of no compression being achieved, or worst case some expansion occuring, the implementation would send the uncompressed form of the data. These are implementation issues however and do not affect the interoperability of the proposed mechanism since there is the bit to say that the packet is compressed or not and the fact that the use of compression is negotiated between the communicating parties. -Bob From owner-ipsec Tue Feb 18 15:36:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16927 for ipsec-outgoing; Tue, 18 Feb 1997 15:36:03 -0500 (EST) Message-Id: <97Feb18.153743est.29581-2@janus.border.com> To: Germano Caronni cc: dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) References: <199702181014.LAA01115@kom30.ethz.ch> In-reply-to: caronni's message of "Tue, 18 Feb 1997 05:14:41 -0500". <199702181014.LAA01115@kom30.ethz.ch> From: "C. Harald Koch" 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: Tue, 18 Feb 1997 15:39:52 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199702181014.LAA01115@kom30.ethz.ch>, Germano Caronni writes: > > Compression allows for saving a valuable ressource. Which valuable resource is that? In my books, compression is a time-time tradeoff; the amount of time spent compressing v.s. the amount of time spent transmitting. As network bandwidths get higher and higher, compression gets more and more expensive. -- Harald Koch From owner-ipsec Tue Feb 18 15:42:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17041 for ipsec-outgoing; Tue, 18 Feb 1997 15:41:38 -0500 (EST) Message-Id: <97Feb18.154303est.29572-2@janus.border.com> To: Bob Monsour cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) References: <3.0.32.19970217161428.009493c0@earthlink.net> In-reply-to: Your message of "Mon, 17 Feb 1997 19:14:33 -0500". <3.0.32.19970217161428.009493c0@earthlink.net> From: "C. Harald Koch" 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: Tue, 18 Feb 1997 15:45:24 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970217161428.009493c0@earthlink.net>, Bob Monsour writes: > > I know that there are some wg members who support the use of compression, > some who don't and some who haven't expressed an interest either way. Well, > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. > Be sure to copy the wg list in your reply. Does anyone (perhaps PPP people?) have statistics on whether compression at the packet layer is actually effective? What percentage of packets on a real network are compressible? What compression ratios do you get? What's the extra latency of the compression? What's the tradeoff between compressing the data stream (above TCP) v.s. individual packets? (The latter transmits the same number of packets with or without compression, and some would argue that the modern internet is *not* bandwidth limited but is limited by packet-switching rates). WAGs are fun, but we're designing a Protocol Standard here, not tinkering in the basement... -- Harald Koch From owner-ipsec Tue Feb 18 16:05:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17259 for ipsec-outgoing; Tue, 18 Feb 1997 16:04:56 -0500 (EST) Message-Id: <199702182105.QAA01449@raptor.research.att.com> To: "C. Harald Koch" cc: Bob Monsour , ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 16:05:55 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Does anyone (perhaps PPP people?) have statistics on whether compression at the packet layer is actually effective? What percentage of packets on a real network are compressible? What compression ratios do you get? What's the extra latency of the compression? What's the tradeoff between compressing the data stream (above TCP) v. s. individual packets? (The latter transmits the same number of packets with or without compression, and some would argue that the modern internet is *not* bandwidth limited but is limited by packet-switching rates). WAGs are fun, but we're designing a Protocol Standard here, not tinkering in the basement... Compression is useful for the ``last mile'' -- the local connection, which is often dial-up, and hence limited to ~28.8Kbps. It might be interesting to look at the packet size and type distributions, to see just what it would buy us. After all, GIF files are not compressible, and I suspect that by volume they make up a large percentage of traffic over dial-up links. (N.B. I'm not trying to be snide about people's viewing habits; I'm alluding to the cute little pictures that seem to infest most Web pages...) From owner-ipsec Tue Feb 18 17:34:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17856 for ipsec-outgoing; Tue, 18 Feb 1997 17:33:10 -0500 (EST) Date: Tue, 18 Feb 1997 14:37:11 -0800 Message-Id: <199702182237.OAA25508@gump.eng.ascend.com> From: Karl Fox To: "C. Harald Koch" Cc: Bob Monsour , ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: <97Feb18.154303est.29572-2@janus.border.com> References: <3.0.32.19970217161428.009493c0@earthlink.net> <97Feb18.154303est.29572-2@janus.border.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Does anyone (perhaps PPP people?) have statistics on whether compression at > the packet layer is actually effective? What percentage of packets on a real > network are compressible? What compression ratios do you get? What's the > extra latency of the compression? I don't have the percentage figure, but using STAC, you can generally get 2:1 compression on average. Small GIFs in web pages don't seem to matter, but the big ones do. With a properly designed system, you actually get better latency with compression, due to the shortened packets. > What's the tradeoff between compressing the data stream (above TCP) v.s. > individual packets? Compressing at the TCP level is better, but if it doesn't exist, then it is worse. :-) -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Tue Feb 18 17:40:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17893 for ipsec-outgoing; Tue, 18 Feb 1997 17:39:40 -0500 (EST) Date: Tue, 18 Feb 1997 14:43:59 -0800 Message-Id: <199702182243.OAA25521@gump.eng.ascend.com> From: Karl Fox To: "Bob Monsour" Cc: "Derek Palma" , , "Germano Caronni" , "Daniel Harkins" , Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: <199702182035.MAA24381@andorra.it.earthlink.net> References: <199702182035.MAA24381@andorra.it.earthlink.net> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob Monsour writes: > The proposed compression mechanism is aimed at the ESP payload data field > and (from my limited understanding) VJ header compression operates on the > segment/packet headers only. So, I don't see them as alternatives as much > as complements to each other. There would certainlyh have to be agreement > (perhaps KMP negotiation) between the communicating parties to perform VJ > header compression. I guess I don't understand what you're getting at. If VJ header compression, used either by itself or in conjunction with another compression algorithm, reduces the average size of the resulting packets, isn't it a net benefit? Keep in mind that VJ compression is very low overhead, which might be very important for upgrading underpowered systems. It would also help offset the huge cost of running IPSEC over dialup links, where TELNET packets go from a few bytes (with VJ and no AH/ESP) to more like a hundred (with AH/ESP and no VJ). -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Tue Feb 18 18:35:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18276 for ipsec-outgoing; Tue, 18 Feb 1997 18:34:35 -0500 (EST) Message-ID: <01BC1DB2.0678DE60@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com (ipsec@tis.com), rmonsour@earthlink.net ('Bob Monsour') Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 15:39:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that linking compression to a specific set of transforms isn't a good idea. I would much rather see compression negotiated as part of the ISAKMP exchange and used for all traffic associated with an SA. I don't think adding any bits is necessary. As Naganand said, we already have enough bits and options. Besides, in the future, some may want to use compression with other types of transforms than just ESP. Why for instance, wouldn't I want to compress an AH packet? Granted, you won't gain very much but someone is going to argue that running a hash algorithm over less data is good! I prefer ISAKMP negotiation because it will allow me to implement it up higher in my stack than the IP layer. I think that compressing at the IP layer isn't going to buy you a whole lot in speed since you're going to be sending out the same number of packets. If I have a confirmed negotiated compression algorithm/state, my implementation can do compression in the appropriate place, above the fragmentation done by TCP. Firewalls can do compression before they encrypt or whatever, but then I'll just get a lot of small encrypted packets from a firewall. A firewall will get fully packed, compressed and encrypted packets from me. That's better than nothing. The choice of what layer to process compression at should be an implementation detail as long as it is done before encryption and decompressed after decryption. In this way, compression may be useful to things other than IPsec and ESP in particular. Lumping compression on ESP doesn't allow us a general compression solution. I'm not sure compression is that good an idea anyway, and I am not sure that we will gain very much from its use. However, if we are going to do compression, I think linking it specifically to ESP isn't very wise. Negotiating it and using it on all packets per association seems to be the only real solution to me. Adding a bit to say if a packet is compressed or not seems like overkill. Granted I don't know a ton about compression but it seems that a small minority of packets will be expanded by compression and why check every packet to see if it is compressed or not to save the processing of one decompression per n packets of compressed data. Okay, I've babbled long enough. Direct answers are in order. >>1. What is the status of adding compression to ESP? Adding compression to a transform is not good. Adding compression to the architecture may or may not be good. So don't let's add compression to ESP. Add it, if at all, to the architecture. >>2. Placement of the "packet compressed/not-compressed" byte/bit See answer to 1. No bit, no byte. I'd like to see more investigation of how useful compression is before we commit to anything though. I have a lot of questions about how much we'll gain for what kinds of traffic and over links that do hardware compression like some modems and routers. Am I the only one that feels like we're rushing this without enough information? -Rob Adams Cisco Systems. ---------- From: Bob Monsour[SMTP:rmonsour@earthlink.net] Sent: Monday, February 17, 1997 4:14 PM To: ipsec@tis.com Subject: TO COMPRESS OR NOT TO CMPRS (please reply) Since my last posting about adding compression in the form of an "optional feature of ESP", I have received several offline inputs from wg members. Specifically, two issues arose: 1. What is the status of adding compression to ESP? I know that there are some wg members who support the use of compression, some who don't and some who haven't expressed an interest either way. Well, the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION. Be sure to copy the wg list in your reply. 2. Placement of the "packet compressed/not-compressed" byte/bit Several people have suggested that rather than using a whole byte for this purpose, simply "steal" the uppermost bit of the pad length field. This is a simple solution. It was suggested to me that a maximum of 128 bytes of padding is sufficient. Note that the preferred ESP transform for the IPSEC DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of padding. There are two ways to approach this issue: (a) alter the transform draft to specify a max of 128 bytes of padding, or (b) for implementations which do not negotiate the use of compression (for a particular SA, or never), they can continue to use up to 255 bytes of padding; for those that *do* support compression, the maximum padding would be 128 bytes. INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to proceed with compression, the decision on this issue will affect the ESP draft, the latest of which has yet to be issued. So, please respond. Regards, Bob From owner-ipsec Tue Feb 18 20:36:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18896 for ipsec-outgoing; Tue, 18 Feb 1997 20:32:33 -0500 (EST) Posted-Date: Tue, 18 Feb 1997 20:33:56 +0000 Message-Id: <9702190136.AA99357@aurora.cis.upenn.edu> To: rmonsour@earthlink.net ('Bob Monsour') Cc: ipsec@tis.com (ipsec@tis.com) Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Tue, 18 Feb 1997 20:33:56 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >1. What is the status of adding compression to ESP? I'm against adding compression to a particular transform. Someone mentioned having compression as an attribute to a SAID as a whole; if we want compression (and i'm not sure it'll buy us much), i think that's how it should be done. It should certainly be optional. I should add that i'm against compression at the network layer; i feel it should be moved higher up. >2. Placement of the "packet compressed/not-compressed" byte/bit No need for this if we do (1). Otherwise, i'd rather see a different ESP transform (and don't tell me we're wasting bytes; if compression gains us about the same number of bytes as the extra ESP header or less, then clearly we shouldn't even be considering it as an option). However, just what is the model in mind ? I doubt firewalls need to perform compression; most companies have decent speed links to the Internet, so compression there wouldn't buy much. A couple more points: a) i think the only place compression would buy anything, especially networks become faster, is the "last mile" (as Steve Bellovin said); the 28.8 (or so) PPP link. Now, PPP already has compression for that link (or so i remember). Additionally, forcing compression in an ESP transform will make the two endpoints also perform encryption; i don't know about you, but i feel that there's higher chance of my data being snooped as they travel over the Internet than on the phone line from my place to the ISP. b) assuming the end user does use encryption all the way to the server somewhere on the net; forcing the server to do compression is "bad manners" IMO, since the server has probably more need of the CPU cycles than the (few ?) bytes compression will give save from the link. Establishing yet another SAID with the PPP remote endpoint to do additional compression just at the final step falls under (a), unless compression is a separate ESP transform (but again, doesn't PPP already do compression ?). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMwpYhL0pBjh2h1kFAQHYsgP/atGT5lcBVx8l+OOvbXLvIbRbiguFjM+v iqrnAKzL3rpRbhknzQkse55HxrTL6M1xy1XOdpswgZG/0ExJUSBsdmX8Iy3FXdvN yZKev/WAEzFt8IFcO1Wa1rAfBPMSnE/vKlICoh2+asbW0/Imb3Ve+si0r/s5j9S+ SsjUGzxMjyg= =YZFq -----END PGP SIGNATURE----- From owner-ipsec Tue Feb 18 22:15:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19457 for ipsec-outgoing; Tue, 18 Feb 1997 22:14:26 -0500 (EST) X-Sender: smarcus@mail.bbnplanet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: BBN Corporation USMail: 150 CambridgePark Drive, Cambridge, MA 02140, U.S.A. Phone: +1 617.873.3075 Date: Tue, 18 Feb 1997 22:18:15 -0500 To: "Angelos D. Keromytis" From: Scott Marcus Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "'Bob Monsour'" , "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Angelos: >... However, just what is the model in mind ? I doubt firewalls need to >perform compression; most companies have decent speed links to the >Internet, so compression there wouldn't buy much. One of the most likely scenarios for the use of IPSEC, I think, is between an organization's firewall and a dispersed community of users communicating over public dial-up Internet access services, with physical connectivity via phone lines or similar. Where the organization runs its servers, support would tend to be deployed in the firewall, at least initially, because the firewall represents a single point through which all external traffic passes. If compression were done at the Network Layer, then this firewall would need to "wrap" or "unwrap" the compressed data. If compression were done at the Link Layer (e.g. PPP), however, then this firewall would never see it. It compression were done in upper layers, it would pass transparently through this firewall. >A couple more points: >a) i think the only place compression would buy anything, especially > networks become faster, is the "last mile" (as Steve Bellovin > said); the 28.8 (or so) PPP link. Now, PPP already has compression > for that link (or so i remember)... If the dial-up 28.8 users are doing IPSEC, then the PPP compression will be ineffective. Not so? Cheers, -- Scott From owner-ipsec Tue Feb 18 22:32:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19570 for ipsec-outgoing; Tue, 18 Feb 1997 22:32:30 -0500 (EST) Message-Id: <3.0.32.19970218222803.006b4908@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 18 Feb 1997 22:28:13 -0500 To: "Angelos D. Keromytis" From: Matt Thomas Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:33 PM 2/18/97 +0000, Angelos D. Keromytis wrote: >>1. What is the status of adding compression to ESP? > >I'm against adding compression to a particular transform. Someone >mentioned having compression as an attribute to a SAID as a whole; if >we want compression (and i'm not sure it'll buy us much), i think >that's how it should be done. It should certainly be optional. Compression is something that should be included in the proposal and would be "independent" of any underlying transform. >>2. Placement of the "packet compressed/not-compressed" byte/bit > >No need for this if we do (1). Otherwise, i'd rather see a different >ESP transform (and don't tell me we're wasting bytes; if compression >gains us about the same number of bytes as the extra ESP header or >less, then clearly we shouldn't even be considering it as an option). If you are compressing on the fly, sometimes the compress will actually generate more data; in this case you want a flag to show even though compression is enabled it was not used on this packet. >However, just what is the model in mind ? I doubt firewalls need to >perform compression; most companies have decent speed links to the >Internet, so compression there wouldn't buy much. > >A couple more points: >a) i think the only place compression would buy anything, especially > networks become faster, is the "last mile" (as Steve Bellovin > said); the 28.8 (or so) PPP link. Now, PPP already has compression > for that link (or so i remember). Additionally, forcing compression > in an ESP transform will make the two endpoints also perform encryption; > i don't know about you, but i feel that there's higher chance of > my data being snooped as they travel over the Internet than on the phone > line from my place to the ISP. If you are using encryption, the encrypted data is going to be uncompressable so PPP level compression is not going to be useful. >b) assuming the end user does use encryption all the way to the server > somewhere on the net; forcing the server to do compression is "bad > manners" IMO, since the server has probably more need of the CPU > cycles than the (few ?) bytes compression will give save from the > link. Establishing yet another SAID with the PPP remote endpoint > to do additional compression just at the final step falls under > (a), unless compression is a separate ESP transform (but again, > doesn't PPP already do compression ?). Buy lots of Alphas as your servers. :-) -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Tue Feb 18 22:33:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19585 for ipsec-outgoing; Tue, 18 Feb 1997 22:33:32 -0500 (EST) Posted-Date: Tue, 18 Feb 1997 22:34:55 +0000 Message-Id: <9702190337.AA105869@aurora.cis.upenn.edu> To: Scott Marcus Cc: "'Bob Monsour'" , "ipsec@tis.com" Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: Your message of "Tue, 18 Feb 1997 22:18:15 EST." Date: Tue, 18 Feb 1997 22:34:55 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , Scott Marcus writes: > >>A couple more points: >>a) i think the only place compression would buy anything, especially >> networks become faster, is the "last mile" (as Steve Bellovin >> said); the 28.8 (or so) PPP link. Now, PPP already has compression >> for that link (or so i remember)... > >If the dial-up 28.8 users are doing IPSEC, then the PPP compression will be >ineffective. Not so? Touche'. I still think that forcing compression inside another ESP transform is unnecessary complexity; a different (ESP ?) transform for compression would be better (and more widely used). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMwp0370pBjh2h1kFAQG7lQP+Kk4qDNfQ0fWthnrOzopPtZ+9BqKduPQR 0WcATneYp48R4J3xHbe7Huf80S9T8kwKHRC4liVaC569gnm8yzfwX70Z9pH5Y5y8 oU0nCZnMwuGBagIWgMHNf9lABDfaTyd5LcjAxzHmW2moIWBUJ81A/dG5s9LoIx8O 6VxJ2YIIttw= =SSz/ -----END PGP SIGNATURE----- From owner-ipsec Tue Feb 18 22:45:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19626 for ipsec-outgoing; Tue, 18 Feb 1997 22:45:04 -0500 (EST) Message-Id: <199702190349.TAA00303@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 18 Feb 97 19:49:21 -0800 To: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <3.0.32.19970217161428.009493c0@earthlink.net> Sender: owner-ipsec@ex.tis.com Precedence: bulk Does anyone have any empirical data to support or refute compression within ESP? What is a fair mix of binary/text? I keep reading how the Internet is data swamped. If compression offers a reasonable reduction in packet size against a fair binary/text mix, perhaps it is worth doing. -dpg From owner-ipsec Tue Feb 18 23:40:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19868 for ipsec-outgoing; Tue, 18 Feb 1997 23:39:12 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 16:38:30 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, I'm in favor of including a compression option in ESP. As I mentioned at the last IPSEC WG meeting, I think this will be especially helpful for folks using dialup or low-speed wireless links. While I agree that this could be viewed as a separate protocol layer, and might be beneficial in non-ESP contexts, I worry that if we wait for form a new WG for this, debate the right protocol layer for providing this service, etc., that it will be a long time before we have the feature and ESP users in the contexts noted above will suffer during that time. So, I vote (oops, I just used a four letter word in the IETF context; I meat to say "I cast my straw ballot for") the inclusion of a compression option in ESP. As for your second question, I also favor stealing a bit out of the padding field for this purpose. As I recall, the motivation here is to negotiate the use of compression, and the specific algorithm, on a per SA basis. So the per-packet bit is needed to allow some packets to not be compressed, e.g., because the packets were sufficiently small that compression would not be attractive. If we add a byte for this bit of info, we will further complicate the alignment issues that are currenty consuming a lot of WG bandwidth. Since I don't think highly of using padding for trafiic flow confidentiality purposes, I'm in favor of donating the high order bit of the padding field to this compression indication purpose. Steve From owner-ipsec Wed Feb 19 00:03:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20034 for ipsec-outgoing; Wed, 19 Feb 1997 00:03:17 -0500 (EST) Message-Id: <3.0.32.19970218210258.00947440@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 21:03:06 -0800 To: Karl Fox From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "Bob Monsour" , "Derek Palma" , , "Germano Caronni" , "Daniel Harkins" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:43 PM 2/18/97 -0800, Karl Fox wrote: >Bob Monsour writes: >> The proposed compression mechanism is aimed at the ESP payload data field >> and (from my limited understanding) VJ header compression operates on the >> segment/packet headers only. So, I don't see them as alternatives as much >> as complements to each other. There would certainlyh have to be agreement >> (perhaps KMP negotiation) between the communicating parties to perform VJ >> header compression. > >I guess I don't understand what you're getting at. If VJ header >compression, used either by itself or in conjunction with another >compression algorithm, reduces the average size of the resulting >packets, isn't it a net benefit? Keep in mind that VJ compression is >very low overhead, which might be very important for upgrading >underpowered systems. It would also help offset the huge cost of >running IPSEC over dialup links, where TELNET packets go from a few >bytes (with VJ and no AH/ESP) to more like a hundred (with AH/ESP and >no VJ). After reading my response, I think we're in violent agreement (I was just being needlessly unclear). I agree that using VJ header compression *does* provide a net benefit, both in conjunction with a payload compression scheme as well as by itself. There's no reason you can't do both. I was just getting at the fact that the two sides would have to agree to do VJ, just as they have to agree to do everything else they do in IPSec. -Bob From owner-ipsec Wed Feb 19 00:05:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20040 for ipsec-outgoing; Wed, 19 Feb 1997 00:03:49 -0500 (EST) Message-Id: <3.0.32.19970218210712.0094cd00@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 21:07:14 -0800 To: "C. Harald Koch" From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Germano Caronni , dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:39 PM 2/18/97 -0500, C. Harald Koch wrote: >In message <199702181014.LAA01115@kom30.ethz.ch>, Germano Caronni writes: >> >> Compression allows for saving a valuable ressource. > >Which valuable resource is that? In my books, compression is a time-time >tradeoff; the amount of time spent compressing v.s. the amount of time spent >transmitting. As network bandwidths get higher and higher, compression gets >more and more expensive. The valuable resource is indeed bandwith. Clearly, to get the gain, you have to be able to do the compression at a rate which lets you keep the network pipe full. I would argue that as network bandwidths get higher and higher, while the cost of compression gets more expensive (in terms of CPU or dedicated coprocessors), the economic gain of the additional bandwidth provided gets larger. In today's private T1/E1 leased lines, adding compression at the PPP level provides anywhere from 2:1 to 4:1 (and some even claim more) compression, providing substantial dollar savings over an uncompressed leased line. Note that for these higher speeds, you're typically talking about a router interface or some other dedicated WAN interface box. -Bob From owner-ipsec Wed Feb 19 00:08:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20060 for ipsec-outgoing; Wed, 19 Feb 1997 00:06:47 -0500 (EST) Message-Id: <3.0.32.19970218211007.009481f0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 21:10:09 -0800 To: Roy Pereira From: Bob Monsour Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "'ipsec@tis.com'" , "'Bob Monsour'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:58 PM 2/18/97 -0500, Roy Pereira wrote: >I don't like the idea of adding it to the pad length field. Although >255 bytes of padding is more than enough, changing that fields role >might break some current implementations. Current implementations would never negotiate to turn on compression, so they "should" never receive packets with the bit turned on and if they do, they are probably talking to another "current implementation" where that bit means another 128 bytes of padding are present. I don't think this is a problem (other than the fact that I used the word "never" in the context of software and protocols...probably a mistake I never should have made). -Bob From owner-ipsec Wed Feb 19 00:28:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20156 for ipsec-outgoing; Wed, 19 Feb 1997 00:27:49 -0500 (EST) Message-Id: <3.0.32.19970218213122.00923b40@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 21:31:24 -0800 To: "C. Harald Koch" From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:45 PM 2/18/97 -0500, C. Harald Koch wrote: >Does anyone (perhaps PPP people?) have statistics on whether compression at >the packet layer is actually effective? What percentage of packets on a real >network are compressible? What compression ratios do you get? What's the >extra latency of the compression? Harold, Below I have copied the appendix from draft-sabin-lzs-payload-00.txt, one of the proposed compression drafts. It contains some results from analyzing compression ratio vs. packet size with a known set of data. Note that "your're mileage may vary" as with any compression algorithm; results vary by data type. If you look at the entry for 256 byte packets, the test data shows a ratio of 1.43:1 (i.e., packet was reduced to 70% of its original size). While the data set is not "real network" data, it is a publically available dataset used commonly for analyzing compression ratios for various algorithms. The extra latency really depends on the processor you're using. We have seen results where, in a compress/encrypt/mac scenario, achieving a 2:1 compression ratio reduces the CPU cycles required for encrypt/mac functions to the point of a net benefit (note that this includes accounting for the cost of compression). I presented some numbers relating to this at the Dec wg meeting in San Jose. 8. Appendix: Compression Efficiency versus Datagram Size The following table offers some guidance on the compression efficiency that can be achieved as a function of datagram size. Each entry in the table shows the compression ratio that was achieved when the proposed transform was applied to a test file using datagrams of a specified size. The test file was the University of Calgary Text Compression Corpus [Calgary]. The length of the file prior to compression was 3,278,000 bytes. When the entire file was compressed as a single payload, a compression ratio of 2.34 resulted. Datagram size,| 64 128 256 512 1024 2048 4096 8192 16384 bytes | --------------|---------------------------------------------------- Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14 ratio | [Calgary] Text Compression Corpus, University of Calgary, available at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus >What's the tradeoff between compressing the data stream (above TCP) v.s. >individual packets? (The latter transmits the same number of packets with or >without compression, and some would argue that the modern internet is *not* >bandwidth limited but is limited by packet-switching rates). If you could compress the data stream (as is done in PPP), you could achieve higher compression ratios since you would be retaining the compression history across each segment of a particular "session". The dilemma, however, is that once you are above IP, you cannot predictably rely on the presence of a particular protocol. Also, the presence of encryption in IP(Sec) is one element of what is driving the need for compression. In the absence of IPSec encryption, the lower-layer PPP compression will work and provide the desired result. -Bob From owner-ipsec Wed Feb 19 00:33:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20201 for ipsec-outgoing; Wed, 19 Feb 1997 00:33:22 -0500 (EST) Message-Id: <3.0.32.19970218213641.0092cc60@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 21:36:44 -0800 To: Steven Bel