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 Bellovin From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "C. Harald Koch" , 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 04:05 PM 2/18/97 -0500, Steven Bellovin wrote: ...snip >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...) Steve, While GIF files do likely make up a large percentage of traffic over dial-up links, I don't imagine that security functionality will be enabled/negotiated while viewing web pages. I would expect that security functionality would be engaged when tunneling into the corporate network over the internet. If you get your web access after establishing this tunnel and thus using the corporate net connection, then indeed the web pages would be encrypted (and optionally compressed), but I would think that once you're connected to your local ISP and have established the tunnel, you would just use the ISP to get your web access, thus only encrypting the "corporate" data traveling between the client and the corporate network. Corrections to my thinking? -Bob From owner-ipsec Wed Feb 19 01:27:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA20461 for ipsec-outgoing; Wed, 19 Feb 1997 01:26:27 -0500 (EST) Date: Wed, 19 Feb 1997 00:30:34 -0600 From: jim@hosaka.smallworks.com (Jim Thompson) Message-Id: <199702190630.AAA15148@hosaka> To: kent@bbn.com, rmonsour@earthlink.net Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Consider the issues surrounding compression patents. From owner-ipsec Wed Feb 19 01:37:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA20510 for ipsec-outgoing; Wed, 19 Feb 1997 01:36:57 -0500 (EST) Message-Id: <3.0.32.19970218224038.00952df0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 22:40:41 -0800 To: adams@cisco.com (Rob Adams) From: Bob Monsour Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com (ipsec@tis.com), rmonsour@earthlink.net ('Bob Monsour') 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 -0800, Rob Adams wrote: >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. Rob, Compression would indeed be negotiated as partof the ISAKMP exchange. Allowing selective compression on a packet by packet basis provides implementation flexibility. For example, you may want to avoid compressing packets less than 100 bytes; or want to send uncompressed data because the data expanded (was precompressed or pre-encrypted at the application layer). You could easily do this using the compressed/not-compressed bit as proposed. To avoid using the bit, you would have to have two SA's for each direction of the connection: one to use for compressed data and one to use for uncompressed data. Are system resources (SA's) that free that a potential doubling of their use is acceptable? I would argue that use of a single bit per packet (an existing bit, not an additional one) is preferable to managing two SA's per direction on each connection. Seems like comparable complexity at best. ...snip... >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. The problem, as I've stated in other responses, is that there is not a universal "higher layer" in which to do compression. It is more than an implementation detail. All parties wanting to compress would have to support it at this "higher layer" which may or may not be present. IP is the common denominator and the need for compression at the IP layer is partly because of the encryption. In the absence of encryption, for systems using PPP, the PPP compression will be effective. ...snip... >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? In a response to another message in this thread, I provided a table of compression ratios for text data, analyzed on the basis of packet size. I will work on providing similar results on other types of data, but this is publically available data used for comparing compression ratios for different compression algorithms (see draft-sabin-lzs-payload-00.txt). For links that do hardware compression (modems & routers), once you encrypt at a the IP layer, those compressors are no longer effective (encrypted data doesn't/shouldn't compress). Your questions are useful in the debate and are appreciated. -Bob From owner-ipsec Wed Feb 19 08:52:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23155 for ipsec-outgoing; Wed, 19 Feb 1997 08:48:56 -0500 (EST) Message-Id: <199702191348.IAA23155@portal.ex.tis.com> Date: Tue, 18 Feb 1997 22:16:52 -0800 To: Daniel Harkins 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 06:30 PM 2/17/97 -0800, Daniel Harkins wrote: >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, The problem that seems unsolvable when considering moving compression to a higher layer is "what higher layer?". There is not necessarily a universally used "higher layer" in all envrironments. IP is the common denominator and that's where the encryption is being done, which in turn, leads to the need for compressing. As I've said before, if there's no encryption and PPP exists at the data link layer, then there's no need to put compression at a higher layer. -Bob From owner-ipsec Wed Feb 19 09:21:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23399 for ipsec-outgoing; Wed, 19 Feb 1997 09:20:03 -0500 (EST) Message-Id: <199702191422.JAA02189@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] 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 "Tue, 18 Feb 1997 21:36:44 PST." <3.0.32.19970218213641.0092cc60@earthlink.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Feb 1997 09:22:48 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob Monsour writes: > While GIF files do likely make up a large percentage of traffic over > dial-up links, I don't imagine that security functionality will be > enabled/negotiated while viewing web pages. I see you haven't heard of SSL, eh? Security is very big on the web. People -- and I mean ordinary consumers -- want to conduct transactions over it. With a reasonable IPSec in place, SSL wouldn't have been necessary. SSL is used every day by millions of people to keep their credit card data away from prying eyes. > I would expect that security functionality would be engaged wnnhen > tunneling into the corporate network over the internet. Security is useful most of the time, actually. I suspect that someday, almost all traffic will be secure. Certainly at 28.8kbps the added CPU burden is unnoticeable, so why *not* encrypt everything? Perry From owner-ipsec Wed Feb 19 10:20:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23799 for ipsec-outgoing; Wed, 19 Feb 1997 10:14:26 -0500 (EST) Message-Id: <3.0.32.19970219071752.0094a7e0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Feb 1997 07:17:54 -0800 To: perry@piermont.com 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 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote: >I see you haven't heard of SSL, eh? I am very aware of SSL (and it provides support for compressing prior to encrypting). >Certainly at 28.8kbps the added CPU burden is unnoticeable, so why >*not* encrypt everything? The issue for doing the work is less a burden for the client than it is for the server. I completely agree that at the client end, the overhead is unnoticeable. However, at the server/aggregation points for all these clients, the workload would be substantial, if not overwhelming (i.e., without hardware assist). This is true in the case for compression today. In some routers that support PPP compression today, if the load on the router becomes too great so that the network pipe can't be kept saturated, the compression is turned off. -Bob From owner-ipsec Wed Feb 19 11:32:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24569 for ipsec-outgoing; Wed, 19 Feb 1997 11:31:33 -0500 (EST) Message-Id: <97Feb19.113700est.11652@elgreco.rnd.border.com> To: Bob Monsour cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) References: <3.0.32.19970218213122.00923b40@earthlink.net> In-reply-to: rmonsour's message of "Wed, 19 Feb 1997 00:31:24 -0500". <3.0.32.19970218213122.00923b40@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: Wed, 19 Feb 1997 11:35:48 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970218213122.00923b40@earthlink.net>, Bob Monsour writes: > > 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. Exactly why I asked for real-world data. The Internet is notorious for discovering that "test data" and "theoretical models" do not resemble "real world data". [ P.S.: To clarify, I have no opinion on the compression issue, exactly because I have no information on which to base an opinion... ] -- Harald Koch From owner-ipsec Wed Feb 19 11:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24826 for ipsec-outgoing; Wed, 19 Feb 1997 11:54:41 -0500 (EST) Message-ID: From: Roy Pereira To: "'Bob Monsour'" Cc: "'dharkins@cisco.com'" , "'ipsec@tis.com'" Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Wed, 19 Feb 1997 11:59:30 -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 To me the biggest benefit of using compression within ESP is the fact that I wont have to FRAGMENT as many packets as I would normally due to the addition of ESP's 40+ byte overhead. Fragmentation can slow down links considerably, especially when they are low-speed (28.8k), thus anything that helps prevent fragmentation is a "good thing". > From owner-ipsec Wed Feb 19 12:09:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25008 for ipsec-outgoing; Wed, 19 Feb 1997 12:09:19 -0500 (EST) Message-Id: <199702191713.MAA02610@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Roy Pereira cc: "'Bob Monsour'" , "'dharkins@cisco.com'" , "'ipsec@tis.com'" Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Wed, 19 Feb 1997 11:59:30 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Feb 1997 12:13:03 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > To me the biggest benefit of using compression within ESP is the fact > that I wont have to FRAGMENT as many packets as I would normally due to > the addition of ESP's 40+ byte overhead. > > Fragmentation can slow down links considerably, especially when they are > low-speed (28.8k), thus anything that helps prevent fragmentation is a > "good thing". I don't understand this at all. If you have path MTU discovery, why would you ever fragment? Perry From owner-ipsec Wed Feb 19 12:44:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25293 for ipsec-outgoing; Wed, 19 Feb 1997 12:42:01 -0500 (EST) Message-Id: <199702191743.JAA14968@itech.terisa.com> X-Authentication-Warning: itech.terisa.com: Host kmac.terisa.COM didn't use HELO protocol To: Bob Monsour cc: perry@piermont.com, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Wed, 19 Feb 1997 07:17:54 PST." <3.0.32.19970219071752.0094a7e0@earthlink.net> Date: Wed, 19 Feb 1997 09:47:37 -0800 From: EKR Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote: > >I see you haven't heard of SSL, eh? > > I am very aware of SSL (and it provides support for compressing prior to > encrypting). Well, sort of: There is a socket for compression to be plugged into. There are no defined compression plugs (other than null) and I don't expect there to be any for some time. -Ekr From owner-ipsec Wed Feb 19 12:44:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25321 for ipsec-outgoing; Wed, 19 Feb 1997 12:43:29 -0500 (EST) Message-Id: <3.0.1.32.19970219084908.02706ca8@ibeam.intel.com> X-Sender: jwr@ibeam.intel.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Feb 1997 08:49:08 -0800 To: Bob Monsour From: "John W. Richardson" Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:14 PM 2/17/97 -0800, you wrote: >1. What is the status of adding compression to ESP? > PLEASE RESPOND BY INDICATING YOUR POSITION. I don't support compression at the network layer. It adds significant complexity for minimal, and short-lived savings. With the exponentially increasing volume of pre-compressed traffic (graphics, multimedia, compressed archives, etc.), compression is actually happening at the (dare I say it?) presentation layer. The only way to make a rational decision about whether to compress a connection is to know whether or not the data is already compressed, and this seems to break layering. For the record, I agree with Perry and his "encrypt everything" position. Our internal IT organization is pushing for this to be the case as soon as possible, since most of our problems seem to be from internal people with legitimate access to the network doing illegitimate things. -JR ------------------------------------------------------------------------ John W. Richardson (Please note that my opinions are my own and jwr@ibeam.intel.com not necessarily shared by Intel) +1 503 264 9425 19 57 B1 04 1F 5D F9 F0 7C 2C 5E D2 DD 7A 19 A5 From owner-ipsec Wed Feb 19 13:01:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25559 for ipsec-outgoing; Wed, 19 Feb 1997 13:01:19 -0500 (EST) Message-Id: <199702191805.AA011615518@relay.hp.com> To: Roy Pereira Cc: "'Bob Monsour'" , "'dharkins@cisco.com'" , "'ipsec@tis.com'" Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: rpereira's message of Wed, 19 Feb 1997 11:59:30 -0500. Date: Wed, 19 Feb 1997 13:05:17 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > To me the biggest benefit of using compression within ESP is the fact > that I wont have to FRAGMENT as many packets as I would normally due to > the addition of ESP's 40+ byte overhead. Hmm. Wouldn't correct handling of MTU discovery/DF through the ipsec `tunnel' also handle this problem? > Fragmentation can slow down links considerably, especially when they are > low-speed (28.8k), thus anything that helps prevent fragmentation is a > "good thing". Agreed. Any time you fragment, you've begun to start losing... - Bill From owner-ipsec Wed Feb 19 13:55:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25861 for ipsec-outgoing; Wed, 19 Feb 1997 13:53:53 -0500 (EST) Message-Id: <199702191858.AA074158687@relay.hp.com> To: Bob Monsour Cc: Steven Bellovin , "C. Harald Koch" , ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: rmonsour's message of Tue, 18 Feb 1997 21:36:44 -0800. <3.0.32.19970218213641.0092cc60@earthlink.net> Date: Wed, 19 Feb 1997 13:58:06 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > While GIF files do likely make up a large percentage of traffic over > dial-up links, I don't imagine that security functionality will be > enabled/negotiated while viewing web pages. .... > Corrections to my thinking? "web access" includes access to company-internal websites, which (like all other web sites) are frequently decorated by inane little GIF's. For one, my employer is already doing a large amount of internal administrative "paperwork" and publishing over the web, saving many trees as a result... - Bill From owner-ipsec Wed Feb 19 14:06:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25948 for ipsec-outgoing; Wed, 19 Feb 1997 14:06:29 -0500 (EST) Message-Id: <97Feb19.141142est.11653@elgreco.rnd.border.com> To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) References: <199702191805.AA011615518@relay.hp.com> In-reply-to: sommerfeld's message of "Wed, 19 Feb 1997 13:05:17 -0500". <199702191805.AA011615518@relay.hp.com> From: "C. Harald Koch" 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: Wed, 19 Feb 1997 14:10:33 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199702191805.AA011615518@relay.hp.com>, Bill Sommerfeld writes: > > Hmm. Wouldn't correct handling of MTU discovery/DF through the ipsec > `tunnel' also handle this problem? Yes, but isn't that a Hard Problem (tm) unless you keep state (either "virtual interfaces" or individual packets) at the tunnel endpoints? How else do you convert an ICMP Fragmentation Required message for a tunneled (and auth'd and 'crypted) packet back into an ICMP Fragmentation Required for the original, untunnelled packet? -- Harald Koch From owner-ipsec Wed Feb 19 14:22:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26072 for ipsec-outgoing; Wed, 19 Feb 1997 14:22:07 -0500 (EST) Message-Id: <199702191926.AA116680384@relay.hp.com> To: "C. Harald Koch" Cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: chk's message of Wed, 19 Feb 1997 14:10:33 -0500. <97Feb19.141142est.11653@elgreco.rnd.border.com> Date: Wed, 19 Feb 1997 14:26:22 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, but isn't that a Hard Problem (tm) unless you keep state (either > "virtual interfaces" or individual packets) at the tunnel endpoints? Well, given that you already need per-outbound-SA state (for the session key and replay detection) this doesn't seem to be a major burden. A per-outbound-SA MTU would seem to be the Right Answer.. > How else do you convert an ICMP Fragmentation Required message for a > tunneled (and auth'd and 'crypted) packet back into an ICMP > Fragmentation Required for the original, untunnelled packet? well, one "cheat" occurs to me: don't send a "FR" when you receive a FR; instead, just record the MTU and let the packet fall on the floor; if it was important, the sender will retransmit it; when this happens, and (assuming it's too large), generate a new "fragmentation required" ICMP message. One drawback is that it takes two packets (instead of one) for a new tunnel to learn the MTU.. - Bill From owner-ipsec Wed Feb 19 14:25:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26090 for ipsec-outgoing; Wed, 19 Feb 1997 14:25:40 -0500 (EST) Message-Id: <3.0.32.19970219112532.00957950@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Feb 1997 11:25:35 -0800 To: EKR From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , perry@piermont.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:47 AM 2/19/97 -0800, EKR wrote: >> At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote: >> >I see you haven't heard of SSL, eh? >> >> I am very aware of SSL (and it provides support for compressing prior to >> encrypting). >Well, sort of: > >There is a socket for compression to be plugged into. There are >no defined compression plugs (other than null) and I don't expect >there to be any for some time. That's funny. When I made a presentation at the TLS (SSL) wg meeting at the San Jose meeting in December, the first question I asked the group (200+ in attendance) was how many thought support for compression was important for TLS. I distinctly recall that well over half of the room raised their hands. While no one is using a compression "plug" today, I wouldn't go as far as predicting that there won't "be any for some time". TLS is a case where it is above the IP layer and where the "packets" are generally larger and compression can indeed provide a bandwidth benefit. It is also the case where compression can be done across multiple packets, providing compression benefits similar to those found in the PPP environment. Again, in the TLS case, it is the use of encryption in the protocol itself which will drive the need to compress the data first, providing the benefits of security without sacrificing performance. -Bob From owner-ipsec Wed Feb 19 14:31:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26127 for ipsec-outgoing; Wed, 19 Feb 1997 14:31:13 -0500 (EST) Message-ID: <01BC1E59.0BFEC5A0@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: rmonsour@earthlink.net ('Bob Monsour'), rpereira@TimeStep.com ('Roy Pereira') cc: dharkins@cisco.com ('dharkins@cisco.com'), ipsec@tis.com ('ipsec@tis.com') Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Wed, 19 Feb 1997 11:17:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk This gets us back into the MTU issue. Shouldn't we be cranking down the MTU for a route so that we can slide in our extra 40 bytes anyway? -Rob ---------- From: Roy Pereira[SMTP:rpereira@TimeStep.com] Sent: Wednesday, February 19, 1997 8:59 AM To: 'Bob Monsour' Cc: 'dharkins@cisco.com'; 'ipsec@tis.com' Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) To me the biggest benefit of using compression within ESP is the fact that I wont have to FRAGMENT as many packets as I would normally due to the addition of ESP's 40+ byte overhead. Fragmentation can slow down links considerably, especially when they are low-speed (28.8k), thus anything that helps prevent fragmentation is a "good thing". > From owner-ipsec Wed Feb 19 14:57:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26312 for ipsec-outgoing; Wed, 19 Feb 1997 14:55:27 -0500 (EST) Message-Id: <199702191959.LAA10030@fluffy.cisco.com> To: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Wed, 19 Feb 1997 11:59:42 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm against coupling compression with IPSEC. I don't believe that this is the correct place to put it and I am not convinced that putting it there will actually improve overall performance. The burden of proof should be on those proposing this to show that there is a reasonable degree of certainty that this makes good engineering sense. I am not yet convinced. A few thoughts on the issues... Compression must be negotiated or else it cannot be deployed. This leads to want to do it as a TCP option or as an ISAKMP attribute. Doing it in IPSEC before ESP does not help with the fragmentation issue. The fragmentation issue is solved by having IPSEC manage the routing layer when it creates an association. We have implemented this in our Windows 95 IPSEC stack for both Tunnel and Transport modes of AH and ESP and it seems to work. You want to compress before TCP has fragmented the packet, not after it. >From a performance perspective, you'd much rather deal with less packets than with smaller ones. That's true both for encryption (as Dan Harkins pointed out) and TCP in general (as Bill Sommerfield observed). This is very important and implies pushing compression up into TCP. It is not clear that compressing protocols other than TCP will be a win. And with TCP, it is certain that there is a fair amount of traffic that will not benefit from compression either because it's relatively small (single-character TELNET) or because it has already been compressed at the application (graphics/video/audio). Doing compression on these packets is a waste of time. A compression algorithm might be able to tell that it's losing, but it's already wasted the cycles at that point. Whether or not compression will help is an attribute of the data that only the sending application really has a chance to assert a priori. Compression is useful indepedent of IPSEC, though in the absense of IPSEC, it's probably better handled by underlying hardware. This is leading me to believe that if we are to add this, this should be added as a negotiated TCP option along with a strong suggestion to stack vendors to implement a per-socket option to allow applications to enable or disable compression on the fly. However, I remain unconvinced that simply adding compression will be the big win some folks seem to think it will be. Just because encryption makes in infeasible to do compression afterward doesn't necessarily mean that you want to do compression beforhand. Derrell From owner-ipsec Wed Feb 19 14:59:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26331 for ipsec-outgoing; Wed, 19 Feb 1997 14:59:30 -0500 (EST) Posted-Date: Wed, 19 Feb 1997 15:00:56 +0000 Message-Id: <9702192003.AA92184@aurora.cis.upenn.edu> To: "C. Harald Koch" Cc: Bill Sommerfeld , ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: Your message of "Wed, 19 Feb 1997 14:10:33 EST." <97Feb19.141142est.11653@elgreco.rnd.border.com> Date: Wed, 19 Feb 1997 15:00:56 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <97Feb19.141142est.11653@elgreco.rnd.border.com>, "C. Harald Koch" w rites: > >Yes, but isn't that a Hard Problem (tm) unless you keep state (either >"virtual interfaces" or individual packets) at the tunnel endpoints? How >else do you convert an ICMP Fragmentation Required message for a tunneled >(and auth'd and 'crypted) packet back into an ICMP Fragmentation Required >for the original, untunnelled packet? Check the archives for a discussion on this about 2 weeks ago. I don't think this is a hard problem. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMwtb970pBjh2h1kFAQHougQAhRiBb2pCqrE1SRIt9PNvtQM+kc2QPzDZ g6+GG6DSZQpwhC2LYN54r17yPo0L26dpk+ZXmNrbLY9xcmQADZyatbXdgJGp3YOX 2wGSvFdd/4dOMqCzFr+SDvKduBThQC/CUXDDJM7EOKVgB4O/8zxwJNfQ+i1k0nSy VXdh98vYysg= =41Nw -----END PGP SIGNATURE----- From owner-ipsec Wed Feb 19 15:35:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26565 for ipsec-outgoing; Wed, 19 Feb 1997 15:34:43 -0500 (EST) Message-Id: <199702192038.MAA00732@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 19 Feb 97 12:38:52 -0800 To: EKR Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) cc: Bob Monsour , perry@piermont.com, ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199702191743.JAA14968@itech.terisa.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote: > > >I see you haven't heard of SSL, eh? > > > > I am very aware of SSL (and it provides support for compressing prior to > > encrypting). > > Well, sort of: > > There is a socket for compression to be plugged into. There are > no defined compression plugs (other than null) and I don't > expect there to be any for some time. > There is a proposed compression scheme for TLS: draft-sabin-lzs-tls-00.txt -dpg From owner-ipsec Wed Feb 19 15:37:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26580 for ipsec-outgoing; Wed, 19 Feb 1997 15:37:42 -0500 (EST) Message-Id: <9702192042.AA30402@commanche.ca.boeing.com> To: ipsec@tis.com Cc: Bob Monsour , perry@piermont.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-Reply-To: (Your message of Wed, 19 Feb 97 09:22:48 -0500.) <199702191422.JAA02189@jekyll.piermont.com> Date: Wed, 19 Feb 97 12:42:09 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry wrote: > I see you haven't heard of SSL, eh? > > Security is very big on the web. People -- and I mean ordinary > consumers -- want to conduct transactions over it. With a reasonable > IPSec in place, SSL wouldn't have been necessary. SSL is used every > day by millions of people to keep their credit card data away from > prying eyes. > Perry is right here, it is our intention to move toward full encryption on all sessions across public networks first and later toward the same on internal communications. Bob wrote: > The issue for doing the work is less a burden for the client than it is for > the server. I completely agree that at the client end, the overhead is > unnoticeable. However, at the server/aggregation points for all these > clients, the workload would be substantial, if not overwhelming (i.e., > without hardware assist). This is true in the case for compression today. > In some routers that support PPP compression today, if the load on the > router becomes too great so that the network pipe can't be kept saturated, > the compression is turned off. > Bob is right on this point. We are expecting to see lots of encryption engine products turn up allow support of encryption at the servers. Maxing a server with a single 20 megabit DES stream won't cut it if we intend to do much deployment of IPSEC. We also expect to be looking at light-weight encryption solutions for non-critical sessions. Encrypting only critical sessions is just asking for attention you don't want. >From this point, it is conceivable that some of these light-weight solutions could be not much more than compressed sessions with light topping of of hash or cypher. The solution seems to be which of these combinations has the smallest cost in cycles for the users particular session: A) Total overhead cycles = "encryption only" B) Total overhead cycles = "compression and then encryption" If I'm sending CAD, GIFs, or other barely compressable objects, it would seem likely A is the answer. On the other hand, if it is email or a few thousand pages of maintenance manual, B is probably the cheapest. (Assuming of coarse equal heavy weight encryptions for both cases) >From this perspective, being able to negotiate both the encryption and compression seem to give the end user the best ability to secure their session and manage the cost of their security. Answer in our case seems to be "optional compression". Just as another thought, someone (forgot who) in the bulk of mail on this subject, stated or implied that saving "network bandwidth" was the most important goal. I suspect that savings "server CPU cycles" will far outweight "network bandwidth" concerns in at least our case. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | Phone: 206-957-5325 | Bellevue, Washington, USA | | Email: terry.l.davis@boeing.com. | --------------- Wednesday February 19,1997 12:32 PM PST ------------- PS: Can we manage that much flexibility on day one; probably not. But on the other hand a CAD server has a certain basic profile and a manual server has another so perhaps we may do better than one would expect at first glance. From owner-ipsec Wed Feb 19 15:50:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26644 for ipsec-outgoing; Wed, 19 Feb 1997 15:49:47 -0500 (EST) Message-Id: <199702192051.MAA16577@itech.terisa.com> X-Authentication-Warning: itech.terisa.com: Host kmac.terisa.COM didn't use HELO protocol To: Bob Monsour cc: perry@piermont.com, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Wed, 19 Feb 1997 11:25:35 PST." <3.0.32.19970219112532.00957950@earthlink.net> Date: Wed, 19 Feb 1997 12:55:34 -0800 From: EKR Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 09:47 AM 2/19/97 -0800, EKR wrote: > >> At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote: > >> >I see you haven't heard of SSL, eh? > >> > >> I am very aware of SSL (and it provides support for compressing prior to > >> encrypting). > >Well, sort of: > > > >There is a socket for compression to be plugged into. There are > >no defined compression plugs (other than null) and I don't expect > >there to be any for some time. > > That's funny. When I made a presentation at the TLS (SSL) wg meeting at the > San Jose meeting in December, the first question I asked the group (200+ in > attendance) was how many thought support for compression was important for > TLS. I distinctly recall that well over half of the room raised their > hands. While no one is using a compression "plug" today, I wouldn't go as > far as predicting that there won't "be any for some time". Here's a brief summary of the situation: TLS is in the process of preparing a document that describes TLS-1.0 (3.0?). That document will not have compression in it. After that, the floor is open for TLS 1.1 (3.1?) which might or might not have compression and N other things in it, but essentially none of the details of that protocol have been hashed out, which means it won't be out for 'some time', IMHO. That's what I based my comments on. -Ekr From owner-ipsec Wed Feb 19 16:25:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26974 for ipsec-outgoing; Wed, 19 Feb 1997 16:24:05 -0500 (EST) Message-Id: <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 19 Feb 97 13:12:59 -0800 To: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199702191959.LAA10030@fluffy.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk The yes-compress/no-compression discussion is akin to comparing Pepsi and Coke. Let's put a framework in place and make it optional and negotiated. Let empirical data determine its usefulness. -dpg From owner-ipsec Wed Feb 19 17:30:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27412 for ipsec-outgoing; Wed, 19 Feb 1997 17:30:06 -0500 (EST) Message-ID: <01BC1E72.3119A300@Tastid.Cisco.COM> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com (ipsec@tis.com) Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Date: Wed, 19 Feb 1997 14:35:14 -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 concur with Derrell. Whether compression is a good thing remains to be seen. However, if we are going to do compression we should determine the appropriate way to implement it. I don't think this issue has been thought through enough byall of us to flatly say that IPsec is the right vehicle for delivering compression. I'm not against compression, I'm against doing it more than once and at all sorts of layers throughout a stack. We already have compression at the hardware link layer. We have compression of certain data by applications such as voice/video/image etc. TLS may end up with compression of its own. Now we're contemplating adding compression at a low enough level that the application won't have any control over what gets compressed. And the layer we're thinking of is low enough that we won't be able to use stateful compression algorithms because we're adding compression to a stateless protocol. We're also talking about linking compression with a specific set of IPsec transforms. This seems limiting and binding to me. Everytime we have a new set of transforms we'll have to go through this discussion again. "Where are we going to stick the bit or byte this time that indicates this packet...... " Wouldn't a framework for including compression in all transforms make more sense if we are to link compression to IPsec at all? TCP seems to be a much better place to do compression than at the IP layer for many reasons. From owner-ipsec Wed Feb 19 23:23:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29251 for ipsec-outgoing; Wed, 19 Feb 1997 23:19:05 -0500 (EST) Date: Thu, 20 Feb 97 04:13:36 GMT Standard Time From: Ran Atkinson Subject: IPsec Straw Poll results To: IPsec WG 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 All, The email I've seen, both privately and on the list, indicates that there is rough (but not smooth) consensus within the IPsec WG that: ESP/AH should use a fixed size 32 bit counter for replay detection. The IETF requirement is for rough consensus, which has been met. On the truncation question, the overwhelming response was of the form "Hugo is the expert, go with whatever Hugo recommends." So I'd like to ask Hugo to post a note with his formal recommendation with regards to truncation in AH HMAC SHA-1/MD5 so that the documents can be edited accordingly. Then perhaps the AH HMAC document editors can create new I-Ds, put them online, and perhaps present them at the Memphis IETF. I spoke on the telephone with Paul Lambert , IPsec Co-Chair, on Tuesday and he verbally concurred with the above. Ran rja@inet.org The other IPsec Co-Chair From owner-ipsec Thu Feb 20 05:54:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA01462 for ipsec-outgoing; Thu, 20 Feb 1997 05:52:58 -0500 (EST) Message-Id: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Wed, 19 Feb 1997 13:12:59 PST." <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us> Date: Thu, 20 Feb 1997 01:01:55 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Dennis" == Dennis Glatting writes: Dennis> The yes-compress/no-compression discussion is akin to Dennis> comparing Pepsi and Coke. Let's put a framework in place Dennis> and make it optional and negotiated. Let empirical data Dennis> determine its usefulness. As long as it is negotiated, I see no reason why one needs a flag to indicate compression. One simply negotiates two SPIs. One SPI is compressed, the other is not. If the data doesn't compress (or is too short to even bother trying: a TCP ACK, or telnet keystroke data) then you use the SPI that didn't have compression negotiated. My reading of the literature on high performance (parallelizing) networking says that the sooner you can categorize the packets the better you do. For TCP/UDP this means sorting by port number and *then* worrying those other things like options, fragments, etc.. For IPsec, the SPI is what I'd sort by. ] Temporarily located in balmy Helsinki, Finland | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Thu Feb 20 08:57:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA02605 for ipsec-outgoing; Thu, 20 Feb 1997 08:53:53 -0500 (EST) From: Robert Glenn Date: Thu, 20 Feb 1997 08:57:57 -0500 (EST) Message-Id: <199702201357.IAA03886@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: Re: IPsec Straw Poll results Cc: hugo@watson.ibm.com, mjo@tycho.ncsc.mil, rob.glenn@nist.gov, sjchang@snad.ncsl.nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk Great! As one of the editors, I'm very happy that this has been resolved and we can start moving forward. There are 2 small issues that I'm still not quite clear on but here is the direction I'm moving towards (and will probably be in the first cut of the new drafts). 1) The fixed size 32 bit counter will be optional such that if replay prevention is not supported the field will be zeroed and ignored upon receipt - but *WILL* still be included in the HMAC calculation. 2) To resolve the alignment problem, the HMAC Authentication data will be truncated to 96 bits as suggested earlier by both Hugo Krawczyk and Bart Preneel. Rob G. rob.glenn@nist.gov From owner-ipsec Thu Feb 20 11:03:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03796 for ipsec-outgoing; Thu, 20 Feb 1997 11:01:08 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199702201605.LAA37530@mailhub1.watson.ibm.com> Date: Thu, 20 Feb 97 10:58:15 EST To: glenn@snad.ncsl.nist.gov, ipsec@tis.com cc: mjo@tycho.ncsc.mil, rob.glenn@nist.gov, sjchang@snad.ncsl.nist.gov, pau@watson.ibm.com Subject: IPsec Straw Poll results Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Thu, 20 Feb 1997 08:57:57 -0500 (EST) (attached) > Great! As one of the editors, I'm very happy that this has been resolved > and we can start moving forward. > > There are 2 small issues that I'm still not quite clear on but here is > the direction I'm moving towards (and will probably be in the first cut of the > new drafts). 1) The fixed size 32 bit counter will be optional such that > if replay prevention is not supported the field will be zeroed and ignored > upon receipt - but *WILL* still be included in the HMAC calculation. 2) To > resolve the alignment problem, the HMAC Authentication data will be truncated > to 96 bits as suggested earlier by both Hugo Krawczyk and Bart Preneel. > > Rob G. > rob.glenn@nist.gov I definitely support the above approach. In particular, truncation to 96 bits for both HMAC-MD5 and HMAC-SHA1 (in the language of rfc2104 this will be HMAC-MD5-96 and HMAC-SHA1-96). Rob: since the test vectors for HMAC-SHA1 did not make it into rfc2104 I recommend you'll have them in the HMAC-SHA1 document. Please talk to Pau-Chen about our (tested) results. Hugo From owner-ipsec Thu Feb 20 11:50:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04207 for ipsec-outgoing; Thu, 20 Feb 1997 11:47:33 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199702201647.LAA04207@portal.ex.tis.com> To: "'niels@DigiCash.com'" , "'ipsec@TIS.COM'" Subject: HMAC with SHS Date: Thu, 20 Feb 1997 11:25:02 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA04087 Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Hi, I'm currently implementing an HMAC authentication algorithm using SHS as the primitive (based on RFC-2104). I was wondering if anyone else had done so and if there are test vectors available for SHS (the RFC only provides one test vector for MD5). Not that I think I could have gotten it wrong, but just to be on the safe side. Thanks in advance. Xavier Lévèque Nova Expertise Solutions Tél.: (514) 397-5400 (ext.: 5555) Fax: (514) 288-0486 mailto:levequex@novanet.ca mailto:levequex@videotron.ca From owner-ipsec Thu Feb 20 14:28:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05317 for ipsec-outgoing; Thu, 20 Feb 1997 14:23:50 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702201928.LAA15017@kebe.eng.sun.com> Subject: Just to be clear on truncation... To: ipsec@tis.com Date: Thu, 20 Feb 1997 11:28:18 -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 asked Hugo which bits I should chop off for a truncation. Here's his reply: Forwarded message: > From HUGO@watson.ibm.com Thu Feb 20 11:16:02 1997 > From: HUGO@watson.ibm.com > Message-Id: <199702201915.OAA23526@mailhub1.watson.ibm.com> > Date: Thu, 20 Feb 97 14:12:39 EST > To: Dan.McDonald@Eng > Subject: IPsec Straw Poll results > content-length: 2071 > > Ref: Your note of Thu, 20 Feb 1997 11:00:10 -0800 (PST) (attached) > > rfc2104 says to leave the leftmost bits, ie. chop off the low bits. > > Hugo > > PS: you're welcome to post this to ipsec (with your example) Since Hugo said to post this to IPsec, I figured I would, with my example. Let's say I start off with the following 128-bit HMAC-MD5 computation: > 0901 2504 2112 5150 1984 0311 dead beef The right thing to do is to chop off the low bits, so the above would become: > 0901 2504 2112 5150 1984 0311 (chop off low bits) Dan From owner-ipsec Thu Feb 20 15:28:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05800 for ipsec-outgoing; Thu, 20 Feb 1997 15:25:50 -0500 (EST) Message-Id: <01BC1F40.2083AE40@erussell-2.ftp.com> From: "Edward A. Russell" To: "'owner-ipsec@ex.tis.com'" , "'niels@DigiCash.com'" , "'ipsec@tis.com'" , "'(LevequeX@novanet.ca'" <"'(LevequeX@novanet.ca'"@tis.com (LevequeX@novanet.ca"'(LevequeX@novanet.ca'"<>>)>)> Subject: re: HMAC with SHS Date: Thu, 20 Feb 1997 15:09:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA05692 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Lévèque, Xavier (LevequeX@novanet.ca) said on 2/20/97 1:27 PM about RE: HMAC with SHS : : I'm currently implementing an HMAC authentication algorithm using : SHS as the primitive (based on RFC-2104). I was wondering if anyone : else had done so and : if there are test vectors available for SHS (the RFC only provides one : test vector for MD5). Not that I think I could have gotten it wrong, : but just to be on the safe side. Here are Test Vectors for SHA and HMAC SHA with both the CYLINK and BSAFE Libraries. The different results are accounted for by an LSB/MSB ordering issue. Latest word is that CYLINK will repair their code to match the BSAFE version. 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 erussell@ftp.com From owner-ipsec Thu Feb 20 16:39:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06254 for ipsec-outgoing; Thu, 20 Feb 1997 16:35:13 -0500 (EST) Message-Id: <3.0.16.19970220163456.217f7682@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 20 Feb 1997 16:39:21 -0500 To: perry@piermont.com 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 In my experience path MTU discovery is not always present. I think it should be, but since we're considering the real world here (right?) I think you can't rely on that. At 12:13 PM 2/19/97 -0500, you wrote: > >Roy Pereira writes: >> To me the biggest benefit of using compression within ESP is the fact >> that I wont have to FRAGMENT as many packets as I would normally due to >> the addition of ESP's 40+ byte overhead. >> >> Fragmentation can slow down links considerably, especially when they are >> low-speed (28.8k), thus anything that helps prevent fragmentation is a >> "good thing". > >I don't understand this at all. > >If you have path MTU discovery, why would you ever fragment? > >Perry > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Fri Feb 21 13:56:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13580 for ipsec-outgoing; Fri, 21 Feb 1997 13:46:15 -0500 (EST) Date: Fri, 21 Feb 1997 16:43:53 -0300 From: ormonde@trem.cnt.org.br (Rodrigo Ormonde) Message-Id: <9702211943.AA12998@trem.cnt.org.br> Apparently-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk From owner-ipsec Fri Feb 21 16:28:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14619 for ipsec-outgoing; Fri, 21 Feb 1997 16:23:57 -0500 (EST) Date: Fri, 21 Feb 97 16:36:01 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9702212136.AA04856@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP - New Version Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 18 All, A new version of the ISAKMP Internet Draft has been sent to press. It should be available in the near future. In the meantime, the attached document explains the changes made from version 6. Most of these changes were made based on comments received during WG Last Call. Special thanks to: Greg Carter Nortel Richard Waterhouse GTE Dennis Glatting plaintalk.bellevue.wa.us John Burke Cylink for their detailed review of version 6 of the protocol specification and the comments they provided. Doug Maughan ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: isakmp_v6_comms X-Sun-Content-Lines: 323 ISAKMP - Summary and rationale of changes based on comments received during IPSEC Working Group Last Call There were several additional minor editorial changes made that are not included in this summary. ***************************************************************************** > From carterg@nortel.ca Mon Dec 16 15:13:37 1996 > From: "Greg Carter" > I heard CRL\ARL types made it into the draft. Great! ACTION: Accepted RATIONALE: Based on agreement at December IETF LOCATION: Section 3.9 ***************************************************************************** > From Waterhouse@nt1-ndhm.chnt.gtegsc.com Tue Dec 10 08:42:16 1996 > From: "Waterhouse, Richard" > I'm confused, in Section 3.5 length of the SPI is always 8 in a Proposal > Payload. Everywhere else the length of the SPI appears to be variable > length and a function of the Protocol-Id. Why is it handled differently > in the Proposal Payload ? ACTION: Changed Proposal Payload to include a SPI Size field of 1 octet and downsized the # of Transforms field from 2 octets to 1 octet. RATIONALE: To be similar (conceptually) to the Delete and Notify Payloads and provide the ability to support multiple protocols with no restriction on SPI length. LOCATION: Section 3.5 ***************************************************************************** >From Waterhouse@nt1-ndhm.chnt.gtegsc.com Wed Dec 11 08:31:57 1996 > From: "Waterhouse, Richard" > Two questions/comments on version > 1. The distinction of Major Version and Minor Version is not clear from > the document. Why isn't there just a Version ? (In particular how should > the future processing of minor version differ from the future processing > of major version when there are multiple versions? I usually like to > provide for future probable evolution paths and the fact that you have > made this distinction seems to imply you have something in mind that > isn't explicitly stated.) > 2. If versioning is useful in ISAKMP itself it would appear to be at > least as useful at the DOI level (which I would guess would be subject > to more frequent change than is ISAKMP itself). Certainly our > application envisions an evolving DOI with provision for some level of > backward compatibility. Response from: >> From: David Carrel >> 1. The distinction of Major Version and Minor Version is not clear from the >> document. Why isn't there just a Version ? (In particular how should the >> future processing of minor version differ from the future processing of >> major version when there are multiple versions? I usually like to provide >> for future probable evolution paths and the fact that you have made this >> distinction seems to imply you have something in mind that isn't explicitly >> stated.) > There is no pre-planned use for the minor version numbers. They can be > useful, they can also go unused. Future use of them will be determined > when we come up with an incompatible change to make. > Nonetheless, your point is valid that their use is ambiguous. We should > define for now that an implementation should never accept packets with a > major OR minor number that is larger than it's own. As for accepting ones > that are smaller, that will be defined as those changes are made. > One motivation for the distinction between major and minor version is that > the old 4 bit version number just happens to occupy the same four bits as > the current major version number. So if previous implementations of ISAKMP > receive the current packets, they can easily tell they are the wrong > version. Same thing when going the other way as well. >> 2. If versioning is useful in ISAKMP itself it would appear to be at least >> as useful at the DOI level (which I would guess would be subject to more >> frequent change than is ISAKMP itself). Certainly our application >> envisions an evolving DOI with provision for some level of backward >> compatibility. > Good thought. I'll have to ponder this a bit more... ACTION: Accepted - Additional text added Response to #2 left for editor of the DOI document RATIONALE: Clarify use of Major and Minor version fields LOCATION: Section 3.1 ***************************************************************************** > From: mamros@ftp.com (Shawn Mamros) > Date: Tue, 17 Dec 1996 14:41:59 -0500 > In the isakmp-06 draft, the Notify and Delete payloads both contain > a Protocol-Id field, so that the SPI(s) contained in those payloads > can be associated with the proper protocol SA(s) in question. > However, Protocol-Id values (other than value 1, which is always used > for the ISAKMP protocol itself) are defined in the DOI document, and > there is no field in the Notify and Delete payloads which specify which > DOI is being used. (The only place the DOI is specified is in the > Security Association payload.) > I suppose that, as long as any new Protocol-Id values for any yet-to- > be-defined DOIs do not conflict with those already assigned for > IPSEC AH and IPSEC ESP, then this isn't a problem. But, if there is > a possibility of conflict, then there will have to be some way to > associate the Protocol-Id with the proper DOI. Adding a DOI field > to the Notify and Delete payloads might be one way to do this, if it's > needed. > So, I guess what I'm wondering is: Is there a possibility of conflicting > Protocol-Ids between different DOIs? And, if so, what should be done > about it for the Notify and Delete payloads? If, on the other hand, > there will be no conflicts - if all future Protocol-Ids will be unique, > regardless of DOI - then this should be stated somewhere. ACTION: Accepted - DOI field added to the Notify and Delete Payload RATIONALE: It is feasible that a user could be communicating in more than one DOI simultaneously. Therefore, deletions and notifications need to be differentiated based not only on the Protocol-ID, but on the combination of DOI and Protocol-ID. LOCATION: Sections 3.14 and 3.15 ***************************************************************************** > From: Dennis Glatting > Date: Tue, 24 Dec 96 16:12:44 -0800 >> >From Appendix A of draft-ietf-ipsec-isakmp-06.txt: >> >> > Security protocol values 2-1024 are reserved for IANA use. Values 1025- >> > 15360 are reserved for future use. Values 15360-16384 are reserved for >> > private use. >> > >> >> The future and private use protocol values overlap. Should >> private use be 15361-16384? >> > Also, if protocol values start at 0, the last possible value is > 16383, not 16384. ACTION: Accepted - Values changed accordingly RATIONALE: Correctness LOCATION: Appendix A *****************************************************************************` > From: Dennis Glatting > Date: Wed, 25 Dec 96 20:40:18 -0800 > I believe draft-ietf-ipsec-isakmp-06.txt does not specify > byte ordering of integral quantities. Is the ordering network > order? ACTION: Accepted - Text added RATIONALE: Clarification LOCATION: Section 3 *****************************************************************************` > From: "Waterhouse, Richard" > Date: Fri, 3 Jan 1997 09:54:37 -0500 > I need to confirm my understanding of your intent. > If the examples in Section 4.1.1 occurred within an Aggressive Exchange, > it would be the NP field of the last Proposal Payload, not the NP field > of the last Transform Payload, which would identify the following KE > Payload Type. > Is this correct ? Additionally .... > From: Greg Carter > Date: Wed, 15 Jan 1997 18:46:22 -0500 > 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. Response from: From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Date: Thu, 16 Jan 97 08:29:52 EST >> 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. ACTION: Accepted - Text changed and clarifications added RATIONALE: Next Payload fields of SA, Proposal, and Transform fields modified to simplify processing. LOCATION: Sections 3.4, 3.5, 3.6, 4.1.1 *****************************************************************************` > From: John Burke > Date: Thu, 09 Jan 1997 10:41:34 -0500 > 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. ACTION: Accepted - Text changed and clarifications added RATIONALE: Clarify use of the Data Attributes LOCATION: Section 3.3 *****************************************************************************` > From: John Burke > Date: Thu, 09 Jan 1997 10:41:34 -0500 > 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". ACTION: Accepted - Text added RATIONALE: Clarification LOCATION: Section 3 *****************************************************************************` ACTION: Added an additional Certificate Encoding type to diferentiate between the use of X.509 certificates for signatures and key exchange. RATIONALE: X.509 Certificates can be used for both signatures and key exchange purposes. LOCATION: Section 3.9 *****************************************************************************` ACTION: Added text to the description of the Payload Length field for the Proposal Payload. RATIONALE: In the event there are multiple proposals with the same proposal number, the length field only applies to the specific proposal payload and not to multiple proposal payloads. LOCATION: Section 3.5 *****************************************************************************` ACTION: Added text to clarify the processing of the Proposal and Transform payloads. RATIONALE: The initiator may propose multiple proposals, each with multiple transforms. THe responder chooses one of these proposal and responds to the initiator. The format of this returned information can help the protocol processing of the initiator. LOCATION: Section 4.1 *****************************************************************************` From owner-ipsec Fri Feb 21 18:36:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15333 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:08 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <01BC1E72.3119A300@Tastid.Cisco.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 15:13:32 -0500 To: adams@cisco.com (Rob Adams) From: Stephen Kent Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: ipsec@tis.com (ipsec@tis.com) Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, As you noted, compression, like encryption, can be provided at various layers. We have to make smart choices as to where to offer the function, but that doesn't mean that there is a single, right answer, no more than there is a single, right layer at which to offer encryption. Compression can be optimized at the application layer where there is knowledge of the data types being compressed, and for static, stored data (e.g., GIFs) this is great. But, not all of our traffic is of this sort, and so we cannot rely on this later of compression in all cases. Encryption at the application layer has many of the same benefits, but it also has drawbacks, e.g., the need to develop and/or integrate the mechanisms for each application (hence the motivation for GSSAPI). At the other end of the stack, we do link layer compression whereever it seems useful, at a point where we have no knowldege at all about the data types. This has proved quite useful for dialup and wireless transmission systems. It often is done in hardware and is applied selectovely, where the processing/bandwidth tradeoff analysis suggests it is useful. However, use of encrytion at any higher layer negates the effectiveness of link layer encryption, and that is one motivation for inclusion of compression at a higher layer. The IP layer is a good candidate primarily because that's where we are adding encryption (in the context of this WG) and thus we have the opportunity to help offset the effects of the encryption that we are imposing. Of course, we don't have access to data type info, so we won't be able to do as good a job as at the application layer, but we do have the benefit of being able to apply (or consider applying) compression to all the traffic we encrypt, without modifying any other protocols, i.e., by keeping within the subl-layer where we are introducing new protocols anyway. If we move up to the transport layer, there isn't any better data type knowledge, and we now are looking at making changes to each transport protocol (if we want to offer as broad a service), plus having to change a protocol that was not being modified otherwise (or adding a new sub-layer). Also, if we choose to compress because we are encrypting, compressing at the tranport layer is not consistent with the use of ESP, since ESP is a lower layer and knowledge of its use should not be visible at the transport layer. SSL, in optionally offering compression, is taking the same tact that we are exploring for ESP, and I think that is consistent. From a pragmatic perspective, if we don't offer compression in ESP, then we ought not expect it to be available anytime soon, to help counter the packet size expension effects of ESP and to help alleviate the link layer compression loss problems. Steve From owner-ipsec Fri Feb 21 18:36:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15334 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:11 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us> References: <199702191959.LAA10030@fluffy.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 14:53:02 -0500 To: dennis.glatting@plaintalk.bellevue.wa.us 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 Dennis, This discussion has been taking place entirely in the context of an optional transformation, negotiated during SA establishment. There is no intent to make use of compression mandatory. If we decide to include it as an option, one would negotiate a specific compression algorithm in conjunction with a sp[ecific encryption algorithm. There is a separate issue of whether it would be mandatory to inplement this option as part of a compliant ESP implementation, but we have not yet had that debate. Steve From owner-ipsec Fri Feb 21 18:36:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15340 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:37 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca> References: Your message of "Wed, 19 Feb 1997 13:12:59 PST." <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 15:19:18 -0500 To: Michael Richardson 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 Mike, One could use two SPIs to distinguish compressed vs. uncompressed data, but since one needs to decrypt prior to decompressing, I don't know that this different approach to demuxing is beneficial. Aloso, if we also are using anti-replay facilities, I now worry about the fact that these two portions of the same data stream have been split apart and are not synchronized. I cannot (off the top of my head) gove a good argument why this may be a problem, but it's bothersome. Steve From owner-ipsec Fri Feb 21 20:17:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15811 for ipsec-outgoing; Fri, 21 Feb 1997 20:16:08 -0500 (EST) Message-Id: <199702220120.RAA01941@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Fri, 21 Feb 97 17:20:27 -0800 To: Stephen Kent Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199702191959.LAA10030@fluffy.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk It was (is?) my impression the question was whether compression is optional or not at all, though at times I was confused because the discussion appeared to boarder mandatory inclusion. Thanks for clarifying. I am not in a position to say where compression does and does not belong. I find all of the points for and against compression interesting, enlightening (for me), and with merit. However, I believe a facility should be provided within the spec so the value of compression can be evaluated and empirical data gathered for future analysis and protocol development. My vote, for what it is worth, is inclusion. If you folks will indulge me, perhaps off-line, many on this list spoke of wasting CPU cycles compressing the uncompressible. I have seen only a brief discussion on wasting CPU cycles encrypting the encrypted. An example is encrypting SSL traffic that may or may not be strongly encrypted, or not encrypted at all. Certainly there is reason to insure via IPsec that traffic as well as other secured application traffic (e.g., snews, klogin) is strongly encrypted; however, encrypting the encrypted, I believe, not only wastes CPU cycles but (if I understand things correctly) can weaken overall data confidentiality. Comments? How is compressing the uncompressible a worse waste of time? -dpg From owner-ipsec Fri Feb 21 20:42:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15941 for ipsec-outgoing; Fri, 21 Feb 1997 20:41:36 -0500 (EST) Date: Sat, 22 Feb 1997 12:45:42 +1100 (EST) From: Kent Fitch X-Sender: fit106@commsun Reply-To: Kent Fitch To: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The W3C recently published an interesting note on the Network Performance Effects of HTTP/1.1, Cascading Style Sheets and PNG image formats which may provide more information for this debate: http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html HTTP is a major component of my organization's WAN traffic, although maybe it is not signficant for everyone. Their study of HTTP/1.0 -v- HTTP/1.1 shows that signficiant reductions in packets, bytes and response time can be expected using a persistent connection, pipelining requests on that connection. Compressing HTML in the application using zlib yielded a further small improvement. Using PNG rather than GIF was estimated as reducing payloads only slightly, but the ability to replace many images with style sheet markup provided much bigger benefits. Kent Fitch Ph: +61 6 276 6711 ITS CSIRO Canberra Australia kent.fitch@its.csiro.au From owner-ipsec Fri Feb 21 21:53:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16293 for ipsec-outgoing; Fri, 21 Feb 1997 21:52:13 -0500 (EST) Message-ID: From: Sanjay Anand To: "'ipsec@tis.com'" Subject: RE: Path MTU Discovery Date: Fri, 21 Feb 1997 17:18:32 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> 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. > >on the inbound side, what does this mean: "fragmentation occurs prior to AH >processing" >does this mean reassembly occurs prior to AH processing ? From owner-ipsec Mon Feb 24 10:18:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01913 for ipsec-outgoing; Mon, 24 Feb 1997 10:08:44 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-07.txt, .ps Date: Mon, 24 Feb 1997 09:51:32 -0500 Message-ID: <9702240951.aa13026@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-07.txt, .ps Pages : 79 Date : 02/20/1997 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-07.txt". Or "get draft-ietf-ipsec-isakmp-07.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-07.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-ipsec-isakmp-07.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19970221180031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221180031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Feb 25 09:17:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09470 for ipsec-outgoing; Tue, 25 Feb 1997 09:10:59 -0500 (EST) Message-Id: <01BC22FC.791D5640@erussell-2.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" Subject: V7 - Clarification of Alignment Date: Tue, 25 Feb 1997 09:15:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 3 of the ISAKMP Version 7 draft states: Additionally all ISAKMP payloads MUST be aligned at 4-byte multiples Is this alignment reflected in the payload length? If it is, then it is a small amount of work on the sender but V6/V7 interoperablity is assured. If it is not, then it is slightly trickier/painful for the receiver, and V6/V7 interoperability is lost. Edward Russell erussell@ftp.com From owner-ipsec Wed Feb 26 09:45:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17461 for ipsec-outgoing; Wed, 26 Feb 1997 09:31:19 -0500 (EST) Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-03.txt Date: Wed, 26 Feb 1997 09:18:45 -0500 Message-ID: <9702260918.aa14331@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: This revision includes changes as a result of WG Last Call A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-03.txt Pages : 32 Date : 02/25/1997 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.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-ipsec-isakmp-oakley-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19970225104523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970225104523.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Feb 26 19:12:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21066 for ipsec-outgoing; Wed, 26 Feb 1997 19:05:14 -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: Wed, 26 Feb 1997 18:57:41 -0500 To: S"'ipsec@tis.com'" From: Stephen Kent Subject: RE: Path MTU Discovery Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, The working with me on the AH, ESP, and IPSEC Architecture documentshave been meeting this week to work on PMTU issues. We will have an analysis of the issues available soon, addressing the questions raised on the list over the last few weeks, and providing some rationales for preferred approaches to dealing with this potentially tricky problem in both hosts and gateways. Stay tuned. Steve From owner-ipsec Thu Feb 27 20:59:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01940 for ipsec-outgoing; Thu, 27 Feb 1997 20:53:07 -0500 (EST) Date: Thu, 27 Feb 1997 17:57:20 -0800 (PST) From: Phil Karn Message-Id: <199702280157.RAA14365@servo.qualcomm.com> To: dharkins@cisco.com CC: rmonsour@earthlink.net, ipsec@tis.com In-reply-to: <199702180230.SAA21924@dharkins-ss20.cisco.com> (message from Daniel Harkins on Mon, 17 Feb 1997 18:30:12 -0800) Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk >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. I feel exactly the same way. I've seen nothing that can beat the performance of gzip-style compress up above TCP, e.g., in SSH with the -C option. The fact that gzip is widely distributed GNUware, free of patent concerns, is just icing on the cake. Phil From owner-ipsec Thu Feb 27 23:33:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA03048 for ipsec-outgoing; Thu, 27 Feb 1997 23:31:35 -0500 (EST) Date: Thu, 27 Feb 1997 20:35:29 -0800 (PST) From: Phil Karn Message-Id: <199702280435.UAA14767@servo.qualcomm.com> To: rmonsour@earthlink.net CC: karl@ascend.com, rmonsour@earthlink.net, dpalma@netcom.com, carrel@ipsec.org, caronni@tik.ee.ethz.ch, dharkins@cisco.com, ipsec@tis.com In-reply-to: <3.0.32.19970218210258.00947440@earthlink.net> (message from Bob Monsour on Tue, 18 Feb 1997 21:03:06 -0800) Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk >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 I point out that VJ TCP/IP header compression assumes in-order delivery of the compressed packets. This is true over a point-to-point link, but it is not necessarily true over the Internet as a whole. So unless you're proposing that the IPSEC reorder packets, VJ header compression is not an option there. Phil From owner-ipsec Fri Feb 28 00:03:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03278 for ipsec-outgoing; Fri, 28 Feb 1997 00:01:31 -0500 (EST) Date: Thu, 27 Feb 1997 21:05:42 -0800 (PST) From: Phil Karn Message-Id: <199702280505.VAA14844@servo.qualcomm.com> To: rmonsour@earthlink.net CC: chk@utcc.utoronto.ca, rmonsour@earthlink.net, ipsec@tis.com In-reply-to: <3.0.32.19970218213122.00923b40@earthlink.net> (message from Bob Monsour on Tue, 18 Feb 1997 21:31:24 -0800) Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk > 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 I dug up this file, specifically the archive text.compression.corpus.tar.Z and tried a few quick experiments. As compressed with "compress" the ratio was 2.4:1. When I decompressed the file and recompressed it with gzip, the ratio improved to 3.05:1. Using the strongest (most CPU intensive) gzip level, 9, the ratio improved slightly more to 3.077:1. By default, the ssh compression option uses gzip level 6. Interesting that a university group interested in compression wouldn't use the most popular and effective compression algorithm to distribute their work! :-) I think this discussion shows that compression at the packet layer is better than nothing, but the best performance is attained by using a really good stream compression algorithm above the transport layer. Phil From owner-ipsec Fri Feb 28 00:42:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03521 for ipsec-outgoing; Fri, 28 Feb 1997 00:40:03 -0500 (EST) Date: Thu, 27 Feb 1997 21:44:29 -0800 (PST) From: Phil Karn Message-Id: <199702280544.VAA15002@servo.qualcomm.com> To: perry@piermont.com CC: rmonsour@earthlink.net, ipsec@tis.com In-reply-to: <199702191422.JAA02189@jekyll.piermont.com> (perry@piermont.com) Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk >consumers -- want to conduct transactions over it. With a reasonable >IPSec in place, SSL wouldn't have been necessary. SSL is used every I used to say this too, but not any more. I now believe it's desirable to have multiple, complementary architectural approaches to security. SSL represents a transport layer approach while IPSEC represents the network layer approach. Each has its advantages and disadvantages, and I suspect that each will find their niches. Advantages of transport layer security (e.g., SSL, SSH): 1. Can operate on an end-to-end basis with existing TCP/IP stacks with existing APIs (winsock, BSD sockets, streams, etc). This is a VERY important issue with turnkey object-only systems like Windows 95. 2. More efficient over slow speed links. VJ header compression still works, and various congestion-control schemes that peek at TCP/IP headers (e.g., my TCP ack-dropping scheme) still work. 3. No special problems with fragmentation, path MTU discovery, etc. 4. Compression combined with encryption at this layer is much more effective than compression at the packet layer. Advantages of network layer security (e.g., IPSEC) 1. Can support completely unmodified end systems, though in this case encryption is no longer strictly end-to-end. 2. Particularly suitable for building virtual private networks across untrusted networks. 3. Can support transport protocols other than TCP (e.g., UDP). 4. Hides the transport layer headers from eavesdropping, providing somewhat greater protection against traffic analysis. 5. With AH and replay detection, protects against certain denial-of-service attacks based on swamping (e.g., TCP SYN attacks). I think it likely that IPSEC will find its niche in building virtual private networks, while SSL and SSH (though they may merge) will continue to be used for many end-to-end applications such as web commerce, remote login, file transfer, etc. Phil From owner-ipsec Fri Feb 28 00:44:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03568 for ipsec-outgoing; Fri, 28 Feb 1997 00:43:03 -0500 (EST) Message-Id: <3.0.32.19970227214259.0095cce0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Feb 1997 21:43:04 -0800 To: Phil Karn From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: rmonsour@earthlink.net, karl@ascend.com, rmonsour@earthlink.net, dpalma@netcom.com, carrel@ipsec.org, caronni@tik.ee.ethz.ch, dharkins@cisco.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:35 PM 2/27/97 -0800, Phil Karn wrote: >>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 > >I point out that VJ TCP/IP header compression assumes in-order >delivery of the compressed packets. This is true over a point-to-point >link, but it is not necessarily true over the Internet as a whole. So >unless you're proposing that the IPSEC reorder packets, VJ header >compression is not an option there. Agreed. In fact there is a draft titled "Header Compression for IPv6" which is specifically to do VJ header compression over point-to-point links. FYI, it is at ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-02.txt. -Bob From owner-ipsec Fri Feb 28 01:02:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03685 for ipsec-outgoing; Fri, 28 Feb 1997 01:00:35 -0500 (EST) Message-Id: <199702280605.AAA03433@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: <199702280157.RAA14365@servo.qualcomm.com> X-Nextstep-Mailer: Mail 4.0 (Enhance 2.0b5) From: Marcel Waldvogel Date: Fri, 28 Feb 97 00:04:50 -0600 To: Phil Karn Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) cc: dharkins@cisco.com, rmonsour@earthlink.net, ipsec@tis.com References: <199702280157.RAA14365@servo.qualcomm.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 27 Feb 1997, Phil Karn wrote: > >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. > > I feel exactly the same way. I've seen nothing that can beat the > performance of gzip-style compress up above TCP, e.g., in SSH with the > -C option. The fact that gzip is widely distributed GNUware, free of > patent concerns, is just icing on the cake. Phil, Daniel, undoubtedly, knowledge about the data to be compressed, be it format or the fact that it will be received reliably e.g. over TCP, can result in impressive improvements. On the other hand, the goal we're all working for --wide deployment of IPsec-- will render most currently employed Link Layer compression schemes useless. Yet many Intranets and dial-up users rely on these resulting bandwidth improvements, making IPsec deployment very hard or impossible in many places. Application Layer compression provides a viable solution. But it requires all applications to be rewritten to maintain the throughput as currently achieved using LL compression, so only applications made "IPsec-aware" using AL compression will perform well. IPsec network performance and thus acceptance will be much better if we start off with provisions for NL compression, which can be disabled on a per connection/per SA basis when applications start doing their own AL compression or know they're transmitting incompressible data. By providing NL compression, no additional burden is placed on the software developers, because many applications will want to become IPsec-aware (specifying their security requirements). For other applications that do not need full IPsec-awareness, but are just adding AL compression, the changes needed to tell IPsec to disable NL compression will be minimal. So I think NL compression will vital to IPsec. Of course, it should be configurable on a per-machine/per-connection basis by the sysadmin/application, like all other IPsec parameters. The effort of adding it once at the NL will be much less than adding compression to all applications. - -Marcel -----BEGIN PGP SIGNATURE----- Version: 2.6 Charset: next iQCVAwUBMxZ1h8qBByDTF1SlAQFbFQQAiU9OmEnnD9maOr37ErBgjmcmPcP/HvnA 0KKgoZg7Dh8rsBrS9I3HrAQ8Hl5OqOUiSaM5+Zgyj/mILJrYW7MuqYic4aiBZf84 Jk9kLTsnUl2K2lgL791+4Gg9MH7tWfpX4nngjffBuFdaNvabnVQdSYdiR98Dv8HN 0AJdekCOXDk= =kdEM -----END PGP SIGNATURE----- From owner-ipsec Fri Feb 28 13:16:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09051 for ipsec-outgoing; Fri, 28 Feb 1997 13:10:49 -0500 (EST) Date: Fri, 28 Feb 97 13:15:23 EST From: "Arthur Parkos" Message-Id: <9701288571.AA857165346@smtppc.ct.pb.com> To: ipsec@tis.com Subject: transport vs network and ipsec syn Sender: owner-ipsec@ex.tis.com Precedence: bulk Subject: Re[2]: TO COMPRESS OR NOT TO CMPRS (please reply) Author: Arthur Parkos at renpo Date: 2/28/97 12:13 PM i agree with your transport vs network security comments. i also agree that we will see both forms of implementation for the particular situations that fit them best. one question (multipart), i was not sure how ipsec addresses the syn attack: - it's not guaranteed that all connections will be attempted with ipsec authentication instantiated. therefore a host will still need to respond to the request for a connection. or will a host refuse all connect attempts from non-ipsec host. - if ipsec is implemented, the host will still need to perform an authentication on the potential partner which would eat cpu cycles. - if ipsec is there, the host receives the connect attempt and retrieves the address, so what if it was signed. couldn't a bad entity sign fake ip addresses and then send them on to a potential host to be attacked? - when will the infrastructure be in place so that a host can authenticate a connection attempt from the myriad potential connectees where certificates may have been issued by different certificate authorities ______________________________ Reply Separator _________________________________ Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Author: Phil Karn at SMTPGWY Date: 2/28/97 2:36 AM >consumers -- want to conduct transactions over it. With a reasonable >IPSec in place, SSL wouldn't have been necessary. SSL is used every I used to say this too, but not any more. I now believe it's desirable to have multiple, complementary architectural approaches to security. SSL represents a transport layer approach while IPSEC represents the network layer approach. Each has its advantages and disadvantages, and I suspect that each will find their niches. Advantages of transport layer security (e.g., SSL, SSH): 1. Can operate on an end-to-end basis with existing TCP/IP stacks with existing APIs (winsock, BSD sockets, streams, etc). This is a VERY important issue with turnkey object-only systems like Windows 95. 2. More efficient over slow speed links. VJ header compression still works, and various congestion-control schemes that peek at TCP/IP headers (e.g., my TCP ack-dropping scheme) still work. 3. No special problems with fragmentation, path MTU discovery, etc. 4. Compression combined with encryption at this layer is much more effective than compression at the packet layer. Advantages of network layer security (e.g., IPSEC) 1. Can support completely unmodified end systems, though in this case encryption is no longer strictly end-to-end. 2. Particularly suitable for building virtual private networks across untrusted networks. 3. Can support transport protocols other than TCP (e.g., UDP). 4. Hides the transport layer headers from eavesdropping, providing somewhat greater protection against traffic analysis. 5. With AH and replay detection, protects against certain denial-of-service attacks based on swamping (e.g., TCP SYN attacks). I think it likely that IPSEC will find its niche in building virtual private networks, while SSL and SSH (though they may merge) will continue to be used for many end-to-end applications such as web commerce, remote login, file transfer, etc. Phil From owner-ipsec Fri Feb 28 17:10:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10855 for ipsec-outgoing; Fri, 28 Feb 1997 17:06:08 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199702282210.OAA07972@kebe.eng.sun.com> Subject: Re: transport vs network and ipsec syn To: parkosar@pb.com (Arthur Parkos) Date: Fri, 28 Feb 1997 14:10:34 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <9701288571.AA857165346@smtppc.ct.pb.com> from "Arthur Parkos" at Feb 28, 97 01:15:23 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 > one question (multipart), i was not sure how ipsec addresses the syn attack: Phil's right in that AH with replay protection, when it's turned on, will stop SYN attacks dead. And even without replay protection, you have assurances that only the SYN for the particular connection id will be flooded if some miscreant replays a particular SYN. > - it's not guaranteed that all connections will be attempted with ipsec > authentication instantiated. therefore a host will still need to respond to > the request for a connection. or will a host refuse all connect attempts > from non-ipsec host. You are right. What you aren't clear on is that I _can_ be selective on which listening endpoints I have IPsec turned on. An example I see my customers using is: * Port 80/TCP (WWW) has no IPsec on it * Maybe port 20-21/TCP (FTP) has no IPsec on it * All other ports (telnet, etc.) have a minimum requirement of AH with replay protection. And anyone who tells you you can't implement per-endpoint IPsec policy is on drugs. I suggest you read the NRL IPsec code for a working counterexample. > - if ipsec is implemented, the host will still need to perform an > authentication on the potential partner which would eat cpu cycles. Yes, but memory isn't being slopped. BTW, in my forthcoming Simple IPsec API draft, I detail a potential denial-of-service attack that is similar to what is described above. There is a fix, BTW. > - if ipsec is there, the host receives the connect attempt and retrieves > the address, so what if it was signed. couldn't a bad entity sign fake ip > addresses and then send them on to a potential host to be attacked? In that case you're problems are probably a lot worse than a simple denial-of-service attack. > - when will the infrastructure be in place so that a host can authenticate > a connection attempt from the myriad potential connectees where > certificates may have been issued by different certificate authorities Good question. That's partially a key mgmt. question too, as the ISAKMP, Photuris, etc. have to decide if the certificate used for the key exchange is trustworthy. Thanks for the questions, I hope I answered them. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Fri Feb 28 18:32:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11367 for ipsec-outgoing; Fri, 28 Feb 1997 18:30:32 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702280544.VAA15002@servo.qualcomm.com> References: <199702191422.JAA02189@jekyll.piermont.com> (perry@piermont.com) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 1997 18:35:51 -0500 To: Phil Karn From: Stephen Kent Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: perry@piermont.com, rmonsour@earthlink.net, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil, Just a minor correction: let's not refer to SSL or SSH as "transport layer" security protocols. These protocols operate above the transport layer. I'd call SSL a session layer security protocol, if I had to attach a label. TLSP is an example of a transport layer security protocol, i.e., it is integrated into the transport layer, not layered on top. Also, one additional downside of session layer security protocols is the possible dependence on the ordering provided by the transport layer protocol. In the case of SSL, this means that an attack on TCP can quickly kill the SSL session, requiring a new SSL session to be created, while TCP thinks that everything is just fine... Steve From owner-ipsec Fri Feb 28 18:57:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11536 for ipsec-outgoing; Fri, 28 Feb 1997 18:55:37 -0500 (EST) Message-Id: <199703010000.TAA12788@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Stephen Kent cc: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Fri, 28 Feb 1997 18:35:51 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 28 Feb 1997 18:59:59 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > Just a minor correction: let's not refer to SSL or SSH as > "transport layer" security protocols. These protocols operate above the > transport layer. Indeed -- thank you for pointing this out. The misdesignation has occassionally grated when I've heard it. Perry From owner-ipsec Mon Mar 3 07:58:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00818 for ipsec-outgoing; Mon, 3 Mar 1997 07:48:21 -0500 (EST) Message-Id: <199703031252.HAA10181@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Phil Karn cc: kent@bbn.com, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Sun, 02 Mar 1997 23:40:48 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Mar 1997 07:52:54 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn writes: > I used the term "transport layer security" to refer to SSL and SSH > because that's the term in common IETF usage. Perhaps we should rename > them to "presentation layer security", because that's what it really > is. And the Internet may even have a true presentation layer for the > first time. :-) > > Your other point about being able to sabotage TCP connections when the > security is layered on top is also quite true. It all depends on your threat > model -- are you more worried about active attacks or passive eavesdropping? One has to worry about both in certain circumstances. The most canonical example is, of course, disrupting BGP connections between routers. Perry From owner-ipsec Mon Mar 3 07:58:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00929 for ipsec-outgoing; Mon, 3 Mar 1997 07:54:50 -0500 (EST) Message-Id: <199703031254.HAA00929@portal.ex.tis.com> Date: Sun, 2 Mar 1997 23:40:48 -0800 (PST) From: Phil Karn To: kent@bbn.com CC: perry@piermont.com, rmonsour@earthlink.net, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I used the term "transport layer security" to refer to SSL and SSH because that's the term in common IETF usage. Perhaps we should rename them to "presentation layer security", because that's what it really is. And the Internet may even have a true presentation layer for the first time. :-) Your other point about being able to sabotage TCP connections when the security is layered on top is also quite true. It all depends on your threat model -- are you more worried about active attacks or passive eavesdropping? Phil From owner-ipsec Mon Mar 3 08:07:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01003 for ipsec-outgoing; Mon, 3 Mar 1997 08:03:52 -0500 (EST) Message-Id: <199703031217.OAA06263@morden.ssh.fi> To: ipsec@tis.com CC: parkosar@pb.com Subject: Re: transport vs network and ipsec syn In-reply-to: Your message of "Fri, 28 Feb 1997 13:15:23 EST." <9701288571.AA857165346@smtppc.ct.pb.com> Date: Mon, 03 Mar 1997 14:16:09 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Arthur" == Arthur Parkos writes: Arthur> - it's not guaranteed that all connections will be Arthur> attempted with ipsec authentication Arthur> instantiated. therefore a host will still need to respond Arthur> to the request for a connection. or will a host refuse all Refusing non-authenticated connections is a matter of local policy. I expect many sites to start doing this. One way would that authenticated connections would get priority over non-authenticated connections when it comes to resource allocations. Or there would be seperate pools. Arthur> connect attempts from non-ipsec host. - if ipsec is Arthur> implemented, the host will still need to perform an Arthur> authentication on the potential partner which would eat The key management protocols have been carefully designed to deal with this. Arthur> cpu cycles. - if ipsec is there, the host receives the Arthur> connect attempt and retrieves the address, so what if it Arthur> was signed. couldn't a bad entity sign fake ip addresses Arthur> and then send them on to a potential host to be attacked? Yes, it might cost CPU cycles. Denial of service attacks are very difficult to prevent. The best that I think we can do is to assure that existing connections will still get their fair share of CPU. Arthur> - when will the infrastructure be in place so that a host Arthur> can authenticate a connection attempt from the myriad Arthur> potential connectees where certificates may have been Arthur> issued by different certificate authorities Different CA's? This sounds like a certificate management problem, and I suggest we take this to SPKI or PKIX. ] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMxrA/MmxxiPyUBAxAQGbyAL8DqhCtS6COfjUW7IUPEKuXKUHNs0OUL60 qCyTQb4QCbgKaNqFi5MeChsBz0oOAUO+jOKlh29Dz6vhXKK/aMEpNN3Dzb453QXP N0wNrw+5AfROqxkn4cMnXHgsi0yZk7vc =ser4 -----END PGP SIGNATURE----- From owner-ipsec Mon Mar 3 17:05:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04467 for ipsec-outgoing; Mon, 3 Mar 1997 17:01:58 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703032206.OAA29233@kebe.eng.sun.com> Subject: How many algorithms per SA/Transform? To: ipsec@tis.com Date: Mon, 3 Mar 1997 14:06:22 -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 Hi folks! I've a question about algorithms per transform/SA. The question is: Will there realistically be more than one algorithm of a given type (i.e. 2 or more ENCRYPTION algorithms or 2 or more AUTHENTICATION algorithms) in a single security association? I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 transform proves that we need at least one encryption AND one authentication algorithm in a single security association. What I'm talking about is if there will ever be: DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? It's a question that I personally think the answer to is, "no". I can't think of any good case (save perhaps protecting headers with one algorithm, and the data with another...) where you'd need more than one algorithm of each type in a single association. Any comments, opinions, etc. are welcome. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Mon Mar 3 17:05:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04488 for ipsec-outgoing; Mon, 3 Mar 1997 17:03:28 -0500 (EST) Message-ID: <01BC27DC.7D4CBA00@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: truncation Date: Mon, 3 Mar 1997 14:08:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? I think we did but I just want to be clear. Also, how does this apply to the Hughes Combined transform? Do we truncate the MD5 hash there also? I hope so for uniformity's sake. -Rob From owner-ipsec Mon Mar 3 18:23:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04901 for ipsec-outgoing; Mon, 3 Mar 1997 18:20:03 -0500 (EST) Posted-Date: Mon, 03 Mar 1997 18:18:30 +0000 Message-Id: <9703032324.AA89891@aurora.cis.upenn.edu> To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: Your message of "Mon, 03 Mar 1997 14:06:22 PST." <199703032206.OAA29233@kebe.eng.sun.com> Date: Mon, 03 Mar 1997 18:18:30 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199703032206.OAA29233@kebe.eng.sun.com>, Dan McDonald writes: > >It's a question that I personally think the answer to is, "no". I can't >think of any good case (save perhaps protecting headers with one algorithm, >and the data with another...) where you'd need more than one algorithm of >each type in a single association. > One could also have a mixed algorithm; instead of 3-DES, use DES for first round, blowfish for second, etc...i can see this used for 2 reasons: a) DES/Blowfish would be faster than 3-DES, more secure than 2-DES, and prevent the DES keysearch problem (Blowfish/DES wouldn't prevent that however - assuming the same key was used for both algorithms). b) Use a stream cipher and then DES (or the other way around) to obscure known-plaintext analysis. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMxtcRb0pBjh2h1kFAQEiCgQAjFgD5vxqdmK2ffDUTI8Lv9R86SY4pFbR PoDjUH2gNAMrg1p5q1PvU3hF49yFbxY8TfNvKo5n9xo46OFOC2Z6RHIdUOKMVBPN WiiMCZ4VR482vkzzfp7/apOnE8PmJTbcxEtS4PejmBhZ/xvYn+nIXkZmeP4jObnL 1rpxCEkh2Rk= =yeYy -----END PGP SIGNATURE----- From owner-ipsec Mon Mar 3 18:53:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA05095 for ipsec-outgoing; Mon, 3 Mar 1997 18:51:49 -0500 (EST) Date: Mon, 3 Mar 1997 18:54:14 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703032354.SAA24987@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199703032336.QAA14832@baskerville.CS.Arizona.EDU> Subject: Re: How many algorithms per SA/Transform? Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that the more creative uses of multiple algorithms should await a future "active ipsec" architecture, where packets carry authenticated applets that describe their crypto processing. The applet might be the crypto routine(s) itself (themselves). For the IETF here and now, one algorithm at a time. Hey, I never liked putting the encryption and authentication algorithms into one transform in the first place. Hilarie From owner-ipsec Mon Mar 3 21:20:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05765 for ipsec-outgoing; Mon, 3 Mar 1997 21:17:45 -0500 (EST) Date: Mon, 3 Mar 1997 21:21:54 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Dan McDonald cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: <199703032206.OAA29233@kebe.eng.sun.com> Message-Id: <97Mar3.212302est.11650@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 3 Mar 1997, Dan McDonald wrote: > I've a question about algorithms per transform/SA. The question is: > > Will there realistically be more than one algorithm of a given > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > AUTHENTICATION algorithms) in a single security association? > > I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 > transform proves that we need at least one encryption AND one authentication > algorithm in a single security association. What I'm talking about is if > there will ever be: > > DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum > > in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? > > It's a question that I personally think the answer to is, "no". I can't > think of any good case (save perhaps protecting headers with one algorithm, > and the data with another...) where you'd need more than one algorithm of > each type in a single association. > > Any comments, opinions, etc. are welcome. Recent relaxation of US export controls make DES more readily available internationally. Someone who wants more security than DES provides might well consider using AH-DES-DES-DES. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Mon Mar 3 21:53:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06014 for ipsec-outgoing; Mon, 3 Mar 1997 21:52:22 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Mar3.212302est.11650@elgreco.rnd.border.com> References: <199703032206.OAA29233@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Mar 1997 21:57:47 -0500 To: Norman Shulman From: Stephen Kent Subject: Re: How many algorithms per SA/Transform? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I'm confused by your example, specifically "AH-DES-DES-DES." We don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does not offer encryption, ESP does. But, in the broader context of this discussion, I agree with Hilarie. Let's not make this even more complex than it already is. Steve From owner-ipsec Tue Mar 4 09:50:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10113 for ipsec-outgoing; Tue, 4 Mar 1997 09:35:22 -0500 (EST) Date: Tue, 4 Mar 1997 09:40:04 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Stephen Kent cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: Message-Id: <97Mar4.094043est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 3 Mar 1997, Stephen Kent wrote: > I'm confused by your example, specifically "AH-DES-DES-DES." We > don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does > not offer encryption, ESP does. Sorry for the confusing notation. My point is that someone who has DES but not triple DES might want to use three DES transforms to achieve the effect of triple DES. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Mar 4 10:20:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10322 for ipsec-outgoing; Tue, 4 Mar 1997 10:10:40 -0500 (EST) Message-Id: <01BC2884.F8D2F420@erussell-2.ftp.com> From: "Edward A. Russell" To: "'angelos@aurora.cis.upenn.edu'" , "'Dan.McDonald@Eng.sun.com'" Cc: "'ipsec@tis.com'" Subject: RE: How many algorithms per SA/Transform? Date: Tue, 4 Mar 1997 10:15:22 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Angelos D. Keromytis (angelos@aurora.cis.upenn.edu) said on 3/3/97 6:44 PM about Re: How many algorithms per SA/Transform? -----BEGIN PGP SIGNED MESSAGE----- >One could also have a mixed algorithm; instead of 3-DES, use DES for >first round, blowfish for second, etc.. My guess is that would be labelled as a new singular transform with a definition of how it should be applied (e.g. first do DES, them blowfish, etc.) Just throwing a bunch of transforms into an SA does not give enough information for interoperability. So even if the imaginary example you give were to come into existance, it would be a single transform called the DES-BLOWS transform or something like that and have its own draft for standard implementation. Edward Russell erussell@ftp.com From owner-ipsec Tue Mar 4 11:12:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10743 for ipsec-outgoing; Tue, 4 Mar 1997 11:07:34 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-02.txt Date: Tue, 04 Mar 1997 09:49:49 -0500 Message-ID: <9703040949.aa18612@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-02.txt Pages : 20 Date : 03/03/1997 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ipsec-doi-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-02.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-ipsec-ipsec-doi-02.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: <19970303120116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970303120116.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Mar 4 14:00:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11844 for ipsec-outgoing; Tue, 4 Mar 1997 13:55:59 -0500 (EST) Message-Id: <199703041900.LAA02411@fluffy.cisco.com> To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-reply-to: Your message of "Mon, 03 Mar 1997 14:06:22 PST." <199703032206.OAA29233@kebe.eng.sun.com> Date: Tue, 04 Mar 1997 11:00:34 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, While there's probably not a strong technical argument for something like this, it's not forbidden by the architecture. It would require a base Transform ID in the IPSEC DOI, some defined set (possibly null) of associated attributes, and a draft describing the encapsulation format. (For something this "unique", I'd strongly recommend a self-describing Transform ID and a null attribute set.) FWIW, I really don't expect anyone to propose anything like this... Derrell From owner-ipsec Wed Mar 5 18:44:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21097 for ipsec-outgoing; Wed, 5 Mar 1997 18:36:06 -0500 (EST) Message-Id: <3.0.32.19970305154052.009a5100@ibeam.jf.intel.com> X-Sender: baiju@ibeam.jf.intel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Mar 1997 15:40:52 -0800 To: ipsec@tis.com From: "Baiju V. Patel" Subject: To compress or not to compress. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I vote against including compression as part of IPSEC protocol for the following reasons. If each packet is compressed individually, and the dictionary is refreshed for each and every packet, the gain in performance is not clear at all (because there are many small packets on the Internet, and there is lot of compressed content). The only gain is in compressing large data packets which are not previously compressed by the applications. So, I don't see how this will improve the performance significantly. The efficiency of compression improves with increasing data size. Therefore, one can argue for compressing many packets using a single dictionary. If such a scheme is deployed at network layer, it can lead to significant problems for TCP because loss of single packet can lead to loss of many TCP packets and timeouts. Here is an example (Assume that dictionary is updated every 10 packets.) - Host A is sending packets to B (these are TCP packets). - Host A transmits packet 1, 2 and 3 in that order to host B. - Host B receives packet 1 and decompresses it, updates its dictionary. - Packet 2 is lost and packet 3 is received successfully. The packet three cannot be correctly decompressed at B because 2 is lost. It also gets dictionary out of sinc. - After TCP timeout, host A retransmits packet 2 and 3 to B (note that these packets are compressed again because at IP layer, the compression algorithm has no knowledge that it is indeed a retransmitted packet). - since the dictionary is out of sink, the packets are incorrectly decompressed and hence discarded. - This goes on until the dictionary is updated. In conclusion, loss of single packet (or out of order delivery), can lead to serious problems for TCP traffic. Therefore, I vote ``no'' for including compression at IPSEC layer. I am all for applications compressing. Note that this not the situation with SSL where the TCP transmits compressed stream. Therefore, the compressed data is reliably received prior to decompression. (It is no different from transmitting a compressed file). So, just because it is true for SSL does not guarantee that it will work for IPSEC (as efficiently). From owner-ipsec Thu Mar 6 12:30:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26327 for ipsec-outgoing; Thu, 6 Mar 1997 12:25:30 -0500 (EST) Message-Id: <2.2.32.19970305191238.00b439bc@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, 05 Mar 1997 14:12:38 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Naganand Doraswamy Subject: Re: How many algorithms per SA/Transform? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: >Hi folks! > >I've a question about algorithms per transform/SA. The question is: > > Will there realistically be more than one algorithm of a given > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > AUTHENTICATION algorithms) in a single security association? > >I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 >transform proves that we need at least one encryption AND one authentication >algorithm in a single security association. What I'm talking about is if >there will ever be: > > DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum > >in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? > >It's a question that I personally think the answer to is, "no". I can't >think of any good case (save perhaps protecting headers with one algorithm, >and the data with another...) where you'd need more than one algorithm of >each type in a single association. > >Any comments, opinions, etc. are welcome. > I would also say NO. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Thu Mar 6 13:05:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26637 for ipsec-outgoing; Thu, 6 Mar 1997 13:03:21 -0500 (EST) Date: Thu, 6 Mar 1997 12:58:25 -0500 (EST) Message-Id: <199703061758.MAA09960@carp.morningstar.com> From: Ben Rogers To: Naganand Doraswamy Cc: Dan.McDonald@Eng.sun.com (Dan McDonald), ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand Doraswamy writes: > At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: > >Hi folks! > > > >I've a question about algorithms per transform/SA. The question is: > > > > Will there realistically be more than one algorithm of a given > > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > > AUTHENTICATION algorithms) in a single security association? >From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand that that you should never have more than one transform per SA: 1.5 Security Association Management ... A single IPsec Security Association is a simplex (unidirectional) connection with which either AH or ESP (but not both) is employed. If both AH and ESP protection is to be applied to a traffic stream, then two (or more) security associations are created to control processing of the traffic stream. To me, this seems to be a clarifcation of RFC1825, and not a change in intent. Is this not the case? ben From owner-ipsec Thu Mar 6 13:39:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26888 for ipsec-outgoing; Thu, 6 Mar 1997 13:37:08 -0500 (EST) Message-Id: <3.0.16.19970306133925.1d1f5ae8@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 06 Mar 1997 13:41:52 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: How many algorithms per SA/Transform? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Please remind me we don't ever want to be in a situation where we both encrypt and sign each packet, thus using an encryption algorithm, a signing algorithm, and an authentication algorithm.... At 02:12 PM 3/5/97 -0500, you wrote: >At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: >>Hi folks! >> >>I've a question about algorithms per transform/SA. The question is: >> >> Will there realistically be more than one algorithm of a given >> type (i.e. 2 or more ENCRYPTION algorithms or 2 or more >> AUTHENTICATION algorithms) in a single security association? >> >>I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 >>transform proves that we need at least one encryption AND one authentication >>algorithm in a single security association. What I'm talking about is if >>there will ever be: >> >> DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum >> >>in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? >> >>It's a question that I personally think the answer to is, "no". I can't >>think of any good case (save perhaps protecting headers with one algorithm, >>and the data with another...) where you'd need more than one algorithm of >>each type in a single association. >> >>Any comments, opinions, etc. are welcome. >> >I would also say NO. > >--Naganand >---------------------------------------------------------------- >naganand@ftp.com >Tel #: (508)684-6743 (O) > > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Thu Mar 6 14:21:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27139 for ipsec-outgoing; Thu, 6 Mar 1997 14:19:35 -0500 (EST) Message-Id: <97Mar6.142500est.11651@elgreco.rnd.border.com> To: ipsec@tis.com Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?) References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> <199703061758.MAA09960@carp.morningstar.com> In-reply-to: ben's message of "Thu, 06 Mar 1997 12:58:25 -0500". <199703061758.MAA09960@carp.morningstar.com> From: "C. Harald Koch" 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 Mar 1997 14:24:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199703061758.MAA09960@carp.morningstar.com>, Ben Rogers writes: > > A single IPsec Security Association is a simplex (unidirectional) > connection with which either AH or ESP (but not both) is employed. If both > AH and ESP protection is to be applied to a traffic stream, then two (or > more) security associations are created to control processing of the > traffic stream. > > To me, this seems to be a clarifcation of RFC1825, and not a change in > intent. Is this not the case? Which brings us back to an old question: what do you call the set of Security Associations that describe the actual desired results, as in "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, ------------------------------- ------------------------------------ SA 1 SA 2 and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." ----------- --------------------- SA 3 SA 4 Is this perhaps a "Security Association Bundle"? Anyone got a better name? -- Harald Koch chk@utcc.utoronto.ca From owner-ipsec Thu Mar 6 15:14:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27486 for ipsec-outgoing; Thu, 6 Mar 1997 15:12:29 -0500 (EST) Date: Thu, 6 Mar 1997 15:17:05 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: "C. Harald Koch" cc: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com> Message-Id: <97Mar6.151803est.11650@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 6 Mar 1997, C. Harald Koch wrote: > Which brings us back to an old question: what do you call the set of > Security Associations that describe the actual desired results, as in > > "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, > ------------------------------- ------------------------------------ > SA 1 SA 2 > > and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." > ----------- --------------------- > SA 3 SA 4 > > > Is this perhaps a "Security Association Bundle"? Anyone got a better name? How about just "Security Bundle" or "Security Package"? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Thu Mar 6 15:36:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27640 for ipsec-outgoing; Thu, 6 Mar 1997 15:34:41 -0500 (EST) Message-Id: <199703062034.PAA27640@portal.ex.tis.com> Date: Thu, 06 Mar 1997 15:10:49 -0500 From: Rob & Rachel Glenn Reply-To: rrglenn@erols.com X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: Rob Adams CC: ipsec@tis.com Subject: Re: truncation References: <01BC27DC.7D4CBA00@Tastid.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the "new" AH-HMAC drafts out sometime next week. I can't speak for Jim Hughes draft. Rob G. Rob Adams wrote: > > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? > I think we did but I just want to be clear. > > Also, how does this apply to the Hughes Combined transform? Do we truncate > the MD5 hash there also? I hope so for uniformity's sake. > > -Rob From owner-ipsec Thu Mar 6 15:37:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27656 for ipsec-outgoing; Thu, 6 Mar 1997 15:36:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199703062036.PAA27656@portal.ex.tis.com> Subject: question about draft semantics To: ipsec@tis.com Date: Thu, 6 Mar 1997 22:18:27 +0200 (EET) Organization: Helsinki University of Technology, TCM-laboratory X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Best ipsec mailing list members, The following text is from draft-ietf-ipsec-arch-sec-01.txt: > 1.4 Minimal Essential Support > ...... > > The following sequences of combinations of AH and ESP, each > represented by a separate security association, must be supported by an > IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport), > AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and > ESP(tunnel)-ESP(transport). > ...... >Atkinson [Page 5] > >Internet Draft Security Architecture for IP 10 November 1996 To me, this part of the text seems a bit unclear. I would interpret it so, that the word "each" would refer to the word "combinations". Then this text would in my opinion mean that e.g. the combination AH-ESP(transport) would have one SPI value, not one SPI value for AH and one SPI for ESP(transport). Am I misinterpreting the text? Will always all transforms have an SPI of their own? Kindly, Bengt Sahlin From owner-ipsec Thu Mar 6 17:20:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28204 for ipsec-outgoing; Thu, 6 Mar 1997 17:17:51 -0500 (EST) Date: 6 Mar 97 16:20:54 -0600 Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) From: "James Hughes" To: dharkins@cisco.com Cc: rmonsour@earthlink.net, ipsec@tis.com X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have been hesitant to reply to this. Network Systems presented compression as a feature for an ESP to the IETF IPSEc group in san jose in 1994. NSC has since productized the proprietary ESP that includes compression and pays royalties to IBM for this privilege. We also have numbers on the compression ratios in real world, long run time situations, and even clearing the dictionary on every packet, we average 2:1 compression of data. Even on most small packets, the overhead of the encapsulationis removed by what compression there is. (Sarcasm on) Frankly it is in our best interest that the status quo of the IPSEC group's inability to converge on a compression standard continue (Sarcasm off). After igniting this issue, I would also suggest that this is not very easy issue to resolve. Even if there is someone willing to claim that their compression is unencumbered by patent, are they willing to indemnify you if someone claims it is not? Our contract with IBM includes a statement that they would defend us if their code violates someone else's patent. NSC made a conscious decision to buy because our parent (StorageTek) has deep pockets and would be deeply vulnerable if a claimed public domain compression algorithm was not. I do not know how to handle this. jim On Thu, Feb 27, 1997 7:57 PM, Phil Karn wrote: > >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. > > I feel exactly the same way. I've seen nothing that can beat the > performance of gzip-style compress up above TCP, e.g., in SSH with the > -C option. The fact that gzip is widely distributed GNUware, free of > patent concerns, is just icing on the cake. > > Phil > > From owner-ipsec Thu Mar 6 17:56:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28487 for ipsec-outgoing; Thu, 6 Mar 1997 17:54:37 -0500 (EST) Message-ID: From: Raul Olaya To: "'ipsec@ex.tis.com'" Subject: IP packet fragmentation Date: Thu, 6 Mar 1997 18:07:08 -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 How are IP security transforms applied to fragmented packets (for example a 2000 byte PING which is fragmented into a 1500 byte fragment (header+data) and 548 byte fragment (header+data))?. Is the packet reassembled in the outbound direction and then the security transform applied to the entire reassembled packet?, or is the security transform applied to the first 1500 byte fragment, and 548 byte fragment independently? Raul Olaya From owner-ipsec Thu Mar 6 18:18:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28625 for ipsec-outgoing; Thu, 6 Mar 1997 18:16:37 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703062319.PAA08906@kebe.eng.sun.com> Subject: Re: IP packet fragmentation To: rolaya@ire.com (Raul Olaya) Date: Thu, 6 Mar 1997 15:19:33 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Raul Olaya" at Mar 6, 97 06:07:08 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 > How are IP security transforms applied to fragmented packets (for > example a 2000 byte PING which is fragmented into a 1500 byte fragment > (header+data) and 548 byte fragment (header+data))?. Is the packet > reassembled in the outbound direction and then the security transform > applied to the entire reassembled packet? IPsec _must_ be done before fragmentation. This is specified in RFC 1825, and why this is a good idea is documented in Bellovin's USENIX Security paper from last summer. Bump-in-the-stack encryptors are a nice short-term fix, but in the long term, IPsec NEEDS to dig its meathooks into the general IP code. Basically, outbound processing is: 1.) create IP headers 2.) Fill in headers 3.) Apply IPsec 4.) Do I fragment? If so, fragment. 5.) Send out the wire. On inbound packets... 1.) Get off the wire, check if for me. If not, forward. 2.) Reassemble 3.) Apply IPsec 4.) Determine HLP/endpoint/etc. > or is the security transform applied to the first 1500 byte fragment, and > 548 byte fragment independently? NO NO NO! This is bad. I'm sure lots of implementations currently do this, but it's bad because either: 1.) You have to keep security information per reassembly queue ** OR ** 2.) The bad guy can inject fragments of his choosing. IMPORTANT SAFETY TIP: IPsec, THEN fragment. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Thu Mar 6 19:13:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28901 for ipsec-outgoing; Thu, 6 Mar 1997 19:09:02 -0500 (EST) Date: Thu, 6 Mar 1997 16:13:30 -0800 Message-Id: <199703070013.QAA26923@gump.eng.ascend.com> From: Karl Fox To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: rolaya@ire.com (Raul Olaya), ipsec@tis.com Subject: Re: IP packet fragmentation In-Reply-To: <199703062319.PAA08906@kebe.eng.sun.com> References: <199703062319.PAA08906@kebe.eng.sun.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk > > How are IP security transforms applied to fragmented packets (for > > example a 2000 byte PING which is fragmented into a 1500 byte fragment > > (header+data) and 548 byte fragment (header+data))?. Is the packet > > reassembled in the outbound direction and then the security transform > > applied to the entire reassembled packet? > > IPsec _must_ be done before fragmentation. This is specified in RFC 1825, > and why this is a good idea is documented in Bellovin's USENIX Security paper > from last summer. If you're running on a host, yes. If you're running on an encrypting gateway, you wrap each fragment in a tunnel mode packet. Of course, you might fragment the resulting encrypted datagram if it's too big. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Thu Mar 6 19:15:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28952 for ipsec-outgoing; Thu, 6 Mar 1997 19:14:33 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703070019.QAA09101@kebe.eng.sun.com> Subject: Re: IP packet fragmentation To: karl@Ascend.COM Date: Thu, 6 Mar 1997 16:19:18 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199703070013.QAA26923@gump.eng.ascend.com> from "Karl Fox" at Mar 6, 97 04:13:30 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 > If you're running on a host, yes. If you're running on an encrypting > gateway, you wrap each fragment in a tunnel mode packet. Good point, but those aren't YOUR fragments. Before YOU fragment, you encrypt. And let's not forget IPv6, where you aren't supposed to have intermediate fragmentation, but it _technically_ happens when you encapsulate. The same analogy applies to IPv4 datagrams with the "don't fragment" bit set. You don't fragment the packet to be forwarded, but if you encapsulate in a tunnel, the tunnel source/dst addresses are of the tunnel endpoints. The end-to-end is tunnel-end to tunnel-end in this case. > Of course, you might fragment the resulting encrypted datagram if it's too > big. See above. Good call, Karl. Dan From owner-ipsec Fri Mar 7 03:07:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA01202 for ipsec-outgoing; Fri, 7 Mar 1997 03:03:31 -0500 (EST) Message-Id: <199703070756.JAA04190@morden.ssh.fi> To: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-reply-to: Your message of "Thu, 06 Mar 1997 15:17:05 EST." <97Mar6.151803est.11650@elgreco.rnd.border.com> Date: Fri, 07 Mar 1997 09:55:35 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Norman" == Norman Shulman writes: >> Is this perhaps a "Security Association Bundle"? Anyone got a >> better name? Norman> How about just "Security Bundle" or "Security Package"? Uh... "policy" ?? ] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Fri Mar 7 11:26:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03952 for ipsec-outgoing; Fri, 7 Mar 1997 11:21:23 -0500 (EST) Date: Fri, 7 Mar 1997 10:53:40 -0500 (EST) Message-Id: <199703071553.KAA03840@carp.morningstar.com> From: Ben Rogers To: "C. Harald Koch" Cc: ipsec@tis.com Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Which brings us back to an old question: what do you call the set of > Security Associations that describe the actual desired results, as in > > "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, > ------------------------------- ------------------------------------ > SA 1 SA 2 > > and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." > ----------- --------------------- > SA 3 SA 4 > > > Is this perhaps a "Security Association Bundle"? Anyone got a better name? We use the term "Security Scheme" which is nice because it is relatively simple, accurately portrays it's own contents, and doesn't sound like a stilted computer geek term. Of course, if the IETF needs to acronym-ize the term (as it seems to do with everything in the whole world), you might end up with a bit of a negative connotation. ben From owner-ipsec Fri Mar 7 13:33:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04720 for ipsec-outgoing; Fri, 7 Mar 1997 13:30:49 -0500 (EST) Message-Id: <199703071835.AA275259711@relay.hp.com> To: Michael Richardson Cc: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: mcr's message of Fri, 07 Mar 1997 09:55:35 +0200. <199703070756.JAA04190@morden.ssh.fi> Date: Fri, 07 Mar 1997 13:35:10 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Norman> How about just "Security Bundle" or "Security Package"? > > Uh... "policy" ?? Too high level; in my mind, "policy" would cover things like "I need to encrypt all packets sent outside the LAN and authenticated all packets inbound from outside the LAN..". 'SA bundle' sounds good to me since "security association" has been defined to be something more low level.. - Bill From owner-ipsec Fri Mar 7 14:00:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04915 for ipsec-outgoing; Fri, 7 Mar 1997 13:58:58 -0500 (EST) Date: Fri, 7 Mar 1997 13:59:58 -0500 From: John Lowry Message-Id: <199703071859.NAA06697@dave.bbn.com> To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Microsoft has frequently been using the word BLOB go cover an aggregation of "stuff" that mere mortals shouldn't play with. How about SA BLOB ? :-) > From owner-ipsec@portal.ex.tis.com Fri Mar 7 13:50:29 1997 > To: Michael Richardson > Cc: ipsec@tis.com > Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) > Date: Fri, 07 Mar 1997 13:35:10 -0500 > From: Bill Sommerfeld > > > Norman> How about just "Security Bundle" or "Security Package"? > > > > Uh... "policy" ?? > > Too high level; in my mind, "policy" would cover things like "I need > to encrypt all packets sent outside the LAN and authenticated all > packets inbound from outside the LAN..". > > 'SA bundle' sounds good to me since "security association" has been > defined to be something more low level.. > > - Bill > From owner-ipsec Fri Mar 7 15:00:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05298 for ipsec-outgoing; Fri, 7 Mar 1997 14:56:31 -0500 (EST) Date: Fri, 7 Mar 1997 21:02:30 +0100 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199703072002.AA04809@orfeo.gc.ssr.upm.es> To: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Fri Mar 7 20:51:56 1997 > Date: Fri, 7 Mar 1997 13:59:58 -0500 > From: John Lowry > To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com > Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) > Cc: ipsec@tis.com > X-Sun-Charset: US-ASCII > Sender: owner-ipsec@ex.tis.com > Content-Length: 881 > > Microsoft has frequently been using the word BLOB go cover an > aggregation of "stuff" that mere mortals shouldn't play with. > How about SA BLOB ? I'm not an english native but *BLOB* is used in crypto too, can this confuse people?? Luis Saiz From owner-ipsec Fri Mar 7 15:18:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05434 for ipsec-outgoing; Fri, 7 Mar 1997 15:15:09 -0500 (EST) From: bmanning@isi.edu Posted-Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST) Message-Id: <199703072019.AA08777@zed.isi.edu> Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) To: saiz@gc.ssr.upm.es (LUIS SAIZ GIMENO) Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199703072002.AA04809@orfeo.gc.ssr.upm.es> from "LUIS SAIZ GIMENO" at Mar 7, 97 09:02:30 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 > > Microsoft has frequently been using the word BLOB go cover an > > aggregation of "stuff" that mere mortals shouldn't play with. > > How about SA BLOB ? > > I'm not an english native but *BLOB* is used in crypto too, can this confuse people?? > > Luis Saiz Its also used in database work for very large, undifferentiated datasets. -- --bill From owner-ipsec Sat Mar 8 09:58:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10221 for ipsec-outgoing; Sat, 8 Mar 1997 09:51:14 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703062036.PAA27656@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Mar 1997 11:29:57 -0500 To: owner-ipsec@ex.tis.com From: Stephen Kent Subject: Re: question about draft semantics Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bengt, I'm sorry that the text is not clear. It was contributed by me and I'll make sure the ambiguity is removed in the next draft. The intent is that each AH or ESP use require a separate SA, as has been the case for some time. Each combination of AH and ESP applied to a class of traffic might be called an "SA bundle" as suggested in a recent message, but there is no codified nomenclature for such aggregates yet. Steve From owner-ipsec Sat Mar 8 12:28:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10905 for ipsec-outgoing; Sat, 8 Mar 1997 12:25:51 -0500 (EST) Date: Sat, 8 Mar 97 17:17:15 GMT Standard Time From: Ran Atkinson Subject: Re: transport vs network and ipsec syn To: Arthur Parkos , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <9701288571.AA857165346@smtppc.ct.pb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 28 Feb 97 13:15:23 EST Arthur Parkos wrote: > one question (multipart), i was not sure how ipsec addresses the syn attack: > > - it's not guaranteed that all connections will be attempted with ipsec > authentication instantiated. therefore a host will still need to respond to the > request for a connection. or will a host refuse all connect attempts from > non-ipsec host. The NRL IPsec code that I wrote actually permits the system administrator to configure the node such that connection requests arriving without IPsec are simply dropped and not passed up to TCP. In such a configuration, the node is fully protected against TCP session stealing attacks. The node is also protected from hosts that it has no IPSEC Security Association with. Since the IPSEC Security Association creation requires at least one new round-trip, the current form of TCP SYN flooding attacks (which use a bogus source IP address in the SYN packets) are precluded. If the attacker uses a real source IP address to attack another node, then the attacker's identity is known and provable -- in which case one can add packet filters to one's router/node and/or call the Police. > - if ipsec is implemented, the host will still need to perform an > authentication on the potential partner which would eat cpu cycles. Experience with the cisco ISAKMP/Oakley daemon and NRL IPsec code on a BSD Pentium/90 box with 16 MB of RAM indicates this is not a significant operational issue. > - if ipsec is there, the host receives the connect attempt and retrieves the > address, so what if it was signed. couldn't a bad entity sign fake ip addresses > and then send them on to a potential host to be attacked? I can't parse the above. > - when will the infrastructure be in place so that a host can authenticate > a connection attempt from the myriad potential connectees where > certificates may have been issued by different certificate authorities Not clear how you are defining "infrastructure". If one considers the potential use of DNSSEC to distribute signed public key values, deployment could happen fairly quickly after the next version of BIND (which reportedly will include DNSSEC extensions) is released. TIS has already obtained US Export Licensing for BIND with DNSSEC, so that shouldn't be an obstacle. Ran rja@Inet.org From owner-ipsec Sat Mar 8 12:38:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10967 for ipsec-outgoing; Sat, 8 Mar 1997 12:37:22 -0500 (EST) Date: Sat, 8 Mar 97 17:32:11 GMT Standard Time From: Ran Atkinson Subject: Re: How many algorithms per SA/Transform? To: Ben Rogers , Naganand Doraswamy Cc: Dan McDonald , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703061758.MAA09960@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 6 Mar 1997 12:58:25 -0500 (EST) Ben Rogers wrote: > >From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand > that that you should never have more than one transform per SA: > > 1.5 Security Association Management > > ... > > A single IPsec Security Association is a simplex (unidirectional) > connection with which either AH or ESP (but not both) is employed. If both > AH and ESP protection is to be applied to a traffic stream, then two (or > more) security associations are created to control processing of the > traffic stream. > > To me, this seems to be a clarifcation of RFC1825, and not a change in > intent. Is this not the case? What you say makes sense to me, as the editor of RFC-1825. I will note, however, that with the Combined ESP transform one somewhat obviates the need for end-to-end AH+ESP that existed when RFC-1828/RFC-1829 were the only standards-track transforms. There might be legitimate situations where ESP were used from H1 to H2 and a tunnel-mode AH were in use from R1 to R2, where H1,H2 are IPsec- capable hosts and R1,R2 are IPsec-capable encrypting routers (aka security gateways), and the topology were loosely described as: H1----R1---[IP cloud]---R2---H2 This situation would cause the packets on the wire between R1 and R2 to look something like this: [IP, R1->R2][AH][IP, H1->H2][ESP[user data]] Ran rja@inet.org From owner-ipsec Sat Mar 8 12:47:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11024 for ipsec-outgoing; Sat, 8 Mar 1997 12:45:53 -0500 (EST) Date: Sat, 8 Mar 97 17:41:51 GMT Standard Time From: Ran Atkinson Subject: Re: question about draft semantics To: ipsec@tis.com, owner-ipsec@ex.tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703062036.PAA27656@portal.ex.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 6 Mar 1997 22:18:27 +0200 (EET) owner-ipsec@ex.tis.com wrote: > To me, this part of the text seems a bit unclear. Mea culpa. I'm sure it will become more clear after Steve Kent edits the text. :-) The correct interpretation is thus: AH and ESP have separate and distinct SPI spaces. When processing a packet, one always knows whether the header being processed is AH or ESP -- hence one knows whether it is an AH SPI or an ESP SPI. Correspondingly, a single Security Association includes only either ESP or AH. No single Security Association contains both ESP and AH. If ESP and AH are used together, there are two distinct SAs -- one for ESP and another for AH. If I'm still not being clear, please post a followup question and I'll try again. :-) Ran rja@inet.org From owner-ipsec Sun Mar 9 20:24:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18157 for ipsec-outgoing; Sun, 9 Mar 1997 20:16:33 -0500 (EST) Date: Sun, 9 Mar 1997 20:19:15 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703100119.UAA10857@earth.hpc.org> To: rrglenn@erols.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703062049.NAA10706@baskerville.CS.Arizona.EDU> Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the > "new" AH-HMAC drafts out sometime next week. I can't speak for > Jim Hughes draft. > Rob G. > Rob Adams wrote: > > > > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? > > I think we did but I just want to be clear. > > > > Also, how does this apply to the Hughes Combined transform? Do we truncate > > the MD5 hash there also? I hope so for uniformity's sake. > > > > -Rob The MD5 truncation is not recommended. Hilarie From owner-ipsec Sun Mar 9 23:39:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19111 for ipsec-outgoing; Sun, 9 Mar 1997 23:37:46 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703100442.XAA33606@mailhub1.watson.ibm.com> Date: Sun, 9 Mar 97 23:42:06 EST To: ho@earth.hpc.org, rrglenn@erols.com cc: ipsec@tis.com Subject: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Sun, 9 Mar 1997 20:19:15 -0500 Hilarie, you say: > The MD5 truncation is not recommended. we are talking here about truncating HMAC-MD5. Is there any reason why is that "not recommended"? we're finally close to settling this issue so any recommendation against needs to be clearly justified. Hugo From owner-ipsec Mon Mar 10 08:01:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21527 for ipsec-outgoing; Mon, 10 Mar 1997 07:57:51 -0500 (EST) Message-Id: <3.0.16.19970310075404.1e477788@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Mon, 10 Mar 1997 08:02:58 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: truncation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Could someone remind us where the justification is for truncation? I remember in San Jose, Hugo stood up and said it was a good idea. I don't remember where it got discussed or what papers were referenced/etc. I realize this probably went by sometime in the past two months but I don't recall when. At 08:19 PM 3/9/97 -0500, you wrote: >> Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the >> "new" AH-HMAC drafts out sometime next week. I can't speak for >> Jim Hughes draft. > >> Rob G. > >> Rob Adams wrote: >> > >> > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? >> > I think we did but I just want to be clear. >> > >> > Also, how does this apply to the Hughes Combined transform? Do we truncate >> > the MD5 hash there also? I hope so for uniformity's sake. >> > >> > -Rob > >The MD5 truncation is not recommended. > >Hilarie > > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Mon Mar 10 10:12:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22220 for ipsec-outgoing; Mon, 10 Mar 1997 10:07:58 -0500 (EST) Date: Mon, 10 Mar 1997 10:10:07 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703101510.KAA05281@earth.hpc.org> To: HUGO@watson.ibm.com Cc: rrglenn@erols.com, ipsec@tis.com In-reply-to: Yourmessage <199703100442.XAA33606@mailhub1.watson.ibm.com> Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk MD5 is already borderline, and the removal of that much of the output seems way too risky, an invitation to doom. If you only have to match 96 bits, the possibility of taking one message+HMAC and turning it into a legal message'+HMAC, even without knowing the key, seems not impossible, given that only 96 bits have to match. In fact, it seems to me that you might be able to use such a technique to test for individual key bits, using the receiver as a verifier. Hilarie From owner-ipsec Mon Mar 10 12:41:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23491 for ipsec-outgoing; Mon, 10 Mar 1997 12:37:28 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Date: Mon, 10 Mar 1997 18:41:37 +0100 (MET) From: Bart Preneel To: Hilarie Orman cc: HUGO@watson.ibm.com, rrglenn@erols.com, ipsec@tis.com Subject: Re: truncation In-Reply-To: <199703101510.KAA05281@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I repeat briefly the main points of my post of February 16th: - MD5 is probably not a strong cryptographic primitive. - The most dangerous attacks on HMAC constructions based on MD5 seem to be the _key recovery_ attacks. These attacks become more difficult if truncation is applied. (just as DES in 16-bit CFB is harder to break than DES). Forgery attacks seem to be less realistic, and also not as dangerous as key recovery attacks. Bart Preneel ------------------------------------------------------------------------------- On Mon, 10 Mar 1997, Hilarie Orman wrote: > MD5 is already borderline, and the removal of that much of the output > seems way too risky, an invitation to doom. If you only have to match > 96 bits, the possibility of taking one message+HMAC and turning it > into a legal message'+HMAC, even without knowing the key, seems not > impossible, given that only 96 bits have to match. In fact, it seems > to me that you might be able to use such a technique to test for > individual key bits, using the receiver as a verifier. > > Hilarie > From owner-ipsec Mon Mar 10 13:37:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23884 for ipsec-outgoing; Mon, 10 Mar 1997 13:35:58 -0500 (EST) Date: Mon, 10 Mar 1997 13:38:19 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703101838.NAA11494@earth.hpc.org> To: Bart.Preneel@esat.kuleuven.ac.be Cc: ipsec@tis.com, rrglenn@erols.com, HUGO@watson.ibm.com In-reply-to: Yourmessage Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk Oh, OK, make it 96 bits. Sorry for the diversion. Hilarie From owner-ipsec Tue Mar 11 03:22:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA27928 for ipsec-outgoing; Tue, 11 Mar 1997 03:16:38 -0500 (EST) Message-Id: <9703110820.AA03690@elgamal.radguard.com> Comments: Authenticated sender is From: "Yael Dayan" To: rgm3@chrysler.com Date: Tue, 11 Mar 1997 10:23:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: IPSec Interoperability Cc: ipsec@tis.com X-Mailer: Pegasus Mail for Windows (v2.23) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Mr. Moskowitz, Our company (Radguard) would like to join the IPSec + ISAKMP/Oakley interoperability effort. If this is possible, we would like some information about the testing schedule and the implementation requirements. Thank You, Yael Dayan Radguard From owner-ipsec Wed Mar 12 13:21:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11398 for ipsec-outgoing; Wed, 12 Mar 1997 13:10:07 -0500 (EST) Date: Wed, 12 Mar 1997 13:12:43 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703121812.NAA05496@earth.hpc.org> To: ipsec@tis.com Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 Sender: owner-ipsec@ex.tis.com Precedence: bulk The following workshop might be of interest to some of you; it's a chance to tell the formalists what the real problems in crypto protocol correctness are, or to find out what tools are available for determining correctness. Hilarie ===================================================================== From: Barbara Quigley Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 -------------------------------------------------------------------------- | DIMACS: Center for Discrete Mathematics & Theoretical Computer Science | | A National Science Foundation Science and Technology Center | -------------------------------------------------------------------------- DIMACS Special Year on Networks Workshop on Cryptographic Protocol Design and Verification September 3-5, 1997 DIMACS Center, CoRE Building, Rutgers University ORGANIZERS: Hilarie Orman, orman@darpa.mil Catherine Meadows, meadows@itd.nrl.navy.mil The purpose of the workshop is to bring together those who design and implement cryptographic protocols with those who formally analyze them, in order to develop a community that can routinely produce secure protocols for use in protecting organizational data and facilitating commerce. The two groups will have opportunities to share ideas about the current state of the art, directions to pursue, and the motivation for their work. Participants will be encouraged to bring demonstration software with them, and part of the workshop organization will involve determining the needs for Internetwork access and local networking. The demonstrations will be of secure protocols in action and of interactive specification and verification techniques. In addition to examining the current state, participants will attempt to quantify the factors that they expect to be significant contributors to scaling the current techniques for future problems. For example, the ability to perform proofs new protocols within a day might be significant. What are the prospects for doing this for a mobile internetwork protocol, for example. Ideally the conclusion of the workshop would be a set of published guidelines for how to design and verify secure cryptographic protocols in reasonable time. --------------------------------------------------------------------- The Special Year program is made possible by long term funding from the National Science Foundation, the New Jersey Commission on Science and Technology and DIMACS university and industry partners. DIMACS Center; Rutgers University; P.O. Box 1179; Piscataway, NJ 08855-1179 TEL: 908-445-5928 FAX: 908-445-5932 ** EMAIL: center@dimacs.rutgers.edu WWW: http://dimacs.rutgers.edu ** TELNET: telnet info.rutgers.edu DIMACS is a partnership of Rutgers University, Princeton University, AT&T Labs, Bellcore, and Bell Laboratories. From owner-ipsec Wed Mar 12 14:08:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11967 for ipsec-outgoing; Wed, 12 Mar 1997 14:04:44 -0500 (EST) Message-Id: <3.0.1.32.19970312140629.00a14470@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 12 Mar 1997 14:06:29 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Round 2, IPsec - Oakley/ISAKMP interop testing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The AIAG (Automotive Industry Action Group) will again be hosting an interop test session. Thanks to the kind offer of FTP/Software for a facility, we will be in Andover MA March 24-27th. I am finishing roughing out a interop check list based on the Glenn AH, Hughes Combined, Oakley v6, ISAKMP v2, and X.509v3 documents. I will be posting some details by tomorrow evening. We are interested in both gateway and workstation implementations. Vendors that are ready to test in this time frame, please contact me directly. We are also planning for activities at Interop in May. The AIAG's Automotive Network eXchange (ANX) will be in pilot this summer with controled rollout in the fall. IPsec technology will be required for ANX subscribers. We will give a status report at the wg session, and are working with the IPsec chairs for an implementors session at Memphis. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 12 14:12:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11986 for ipsec-outgoing; Wed, 12 Mar 1997 14:08:48 -0500 (EST) Date: Wed, 12 Mar 1997 14:11:04 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703121911.OAA07282@earth.hpc.org> To: ipsec@tis.com Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's a more complete announcement for the workshop. Hilarie ============================================================================= DIMACS Workshop on Formal Verification of Security Protocols Sept. 3-5, 1997 Organizers: Hilarie Orman, DARPA and Catherine Meadows, Naval Research Laboratory As we come to rely more and more upon computer networks to perform vital functions, the need for cryptographic protocols that can enforce a variety of security properties has become more and more important. Thus it is no surprise that in recent years a number of new protocols have been proposed for such applications as electronic credit card transactions, Web browsing, and so forth. Since it is notoriously difficult to design cryptographic protocols correctly, this increased reliance on them to provide security has become cause for some concern. This is especially the case since many of the new protocols are extremely complex. In answer to these needs, research has been intensifying in the application of formal methods to cryptographic protocol verification. Recently this work has matured enough so that it is starting to see application to real-life protocols. The goal of this workshop is to facilitate this process by bringing together those were are involved in the design and standardization of cryptographic protocols, and those who are developing and using formal methods techniques for the verification of such protocols. To this end we plan to alternate papers with panels soliciting new paths for research. We are particularly interested in paper and panel proposals addressing new protocols with respect to their formal and informal analysis. Other topics of interest include, but are not limited to - Progress in belief logics - Use of theorem provers and model checkers in verifying crypto protocols - Interaction between protocols and cryptographic modes of operation - Methods for unifying documentation and formal, verifiable specification - Methods for incorporating formal methods into crypto protocol design - Verification of cryptographic API systems - Formal definition of correctness of a cryptographic protocol - Arithmetic capability required for proofs of security for number theoretic systems - Formal definitions of cryptographic protocol requirements - Design methodologies - Emerging needs and new uses for cryptographic protocols - Multiparty protocols, in particular design and verification methods We encourage attendees to bring tools for demonstration. Information about availability of facilities for demonstration will be posted later. To submit a paper to the workshop, submit a one or two page abstract, in Postscript or ASCII to both organizers at the email addresses given below by June 16, 1997. Authors will be notified of acceptance or rejection of abstracts by July 1. Full papers will be due by August 1. Copies of papers will be distributed at the workshop. We also plan to publish a proceedings. Participation in the workshop is *not* limited to those giving presentations. If you would like to attend the workshop, a registration form is available at http://dimacs.rutgers.edu/Workshops/Cryptographic/reg_form.html. Information on accommodations and travel arrangements is available at http://dimacs.rutgers.edu/Workshops/general/accommodations.html and http://dimacs.rutgers.edu/Workshops/general/travel.html. Information on the workshop in general is at http://dimacs.rutgers.edu/Workshops/Cryptographic. Organizers Hilarie Orman Catherine Meadows DARPA ITO Naval Research Laboratory 3701 N. Fairfax Drive Code 5543 Arlington VA 22203-1714 Washington, DC 20375 phone: (703)696-2234 phone: (202)-767-3490 email: horman@darpa.mil email:meadows@itd.nrl.navy.mil From owner-ipsec Wed Mar 12 21:21:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14775 for ipsec-outgoing; Wed, 12 Mar 1997 21:16:36 -0500 (EST) Message-Id: <199703130221.SAA14356@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Cc: anx-sec@dot.netrex.net, isakmp-oakley@cisco.com, rlfs@cisco.com Subject: free ISAKMP reference implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 18:21:05 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Cisco Systems is pleased to announce the availability of their free ISAKMP+Oakley reference implementation. This is based on ISAKMP version 6 and the ISAKMP+Oakley Resolution document version 2. New features from the previous release include all mandatory and optional authentication methods. Authentication with RSA signatures and RSA encryption is accomplished by compiling the ISAKMP distribution with RSAREF. (Note: RSAREF is *not* included in the distribution). This ISAKMP+Oakley implementation has successfully interoperated with other independent implementations at the ANX IPsec bake-off and in independent testing. And it is fully compliant with the relevant drafts. This distribution uses the PF_KEY Key Management API to register security associations with a PF_KEY aware kernel. The NRL IPsec software distribution contains an implementation of PF_KEY for 4.4-BSD systems. As with all cryptographic utilites this code is export controlled and all applicable (U.S) laws will be obeyed in its distribution. Apologies to all who cannot obtain it. To obtain a copy of the ISAKMP+Oakley distribution (and also a copy of the NRL IPsec distribution) point your favorite browser to: http://www.cisco.com/public/library/isakmp scroll down to "Cisco Systems Implementation" and follow the hot links. Please send all comments, opinions, bug reports and suggestions to the isakmp-oakley mailing list (isakmp-oakley@cisco.com). To join this list send a message to majordomo@cisco.com with "subscribe isakmp-oakley" in the *body* of the message. regards, Dan Harkins From owner-ipsec Thu Mar 13 11:06:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21122 for ipsec-outgoing; Thu, 13 Mar 1997 11:00:47 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Thu, 13 Mar 1997 10:00:42 -0600 Message-ID: <32823C30.3000@usr.com> Subject: Questions on the Security Arch. draft To: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. I had a question on section 1.4 of the Security Architecture draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft says : "A security gateway which receives a datagram containing a recognised sensitivity label, for example IPSO [Ken91], from a trusted host MUST take that label's value into consideration when creating/selecting an Security Association for use with AH between the gateway and the external destination. In such an environment, a gateway which receives a IP packet containing the IP Encapsulating Security Payload (ESP) should add appropriate authentication, including implicit (i.e. contained in the Security Association used) or explicit label information (e.g. IPSO), for the decrypted packet that it forwards to the trusted host that is the ultimate destination." I don't get the last part about the gateway adding authentication information for the decrypted packet. Does this mean that the gateway uses the SA that it used to decrypt the packet, to generate the authentication info? That really doesn't make sense to me since AH and ESP have separate SAs and also since any given security association is for use with one peer only. Or, is it that the gateway has a security association with the trusted host and tunnels all the packets for that host using this SA? Thanks, Sumit A. Vakil Software Engineer US Robotics, Access Corp. From owner-ipsec Thu Mar 13 14:23:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22761 for ipsec-outgoing; Thu, 13 Mar 1997 14:14:43 -0500 (EST) Message-Id: <3.0.16.19970313141636.297f94d8@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 13 Mar 1997 14:19:43 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: PKI Signature format in ISAKMP -- proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In preparing for the ANX bakeoff there has been some discussion of exactly what a "signature" should look like for ISAKMP. Some people have interpreted this to mean the signature output was in PKCS#1 format. Others have not. In this message I have described what I interpreted this to mean. Note this DOES NOT use PKCS#1. At the end I have listed my reasons for not using PKCS#1 and what I think would have to change to use it. The Oakley resolution draft, in section 5.1, describes the use of "signatures" for authentication. The signature consists of data formed by applying the signature algorithm to a hash and transmitting the signature. In the case of RSA signatures, this means you create a hash and encrypt the hash with the RSA private key. At the receiving end, the process is reversed -- the encrypted data is decrypted using the RSA public key, then the result is compared to the locally calculated hash. [someone else can augment this with proper prose for DSA...] In ISAKMP, this hash which is used in the signature process has specific meaning related to ISAKMP. The draft specifies it to be the HMAC form, and the hash algorithms that may be used are specified explicitly. The procedure used to produce the signature is described here for the RSA signature algorithm case. Note the terms are from draft-ietf-ipsec-isakmp-oakley-03.txt. - ISAKMP produces HASH_I/HASH_R however it wishes - the hash is used as input data for encryption with the RSA private key, with padding as required by the RSA algorithm (see PKCS#1 or the BSAFE documentation) - the (key bits) of encryption output is passed over the wire as the signature - the other side calculates the hash value HASH_I/HASH_R independantly - the other side decrypts the signature data using the public key retrieved from the cert we are sending over the wire - the other side compares the decrypted signature against it's locally calculated hash and if they match you're all set. Note that the 'signature' data passed over the wire is the of data as generated by the RSA algorithm. The normal ISAKMP payload processing allows the receiving side to determine how much data is present. The 'signature', that is, the encoded hash, must be padded as required by the RSA algorithm, so when the data is encrypted it consists of: one byte of zero hash bytes padding of zero bytes up to DIFFERENCE FROM PKCS#1. In PKCS#1 an ASN.1 structure encoded in BER would be transmitted over the wire. I don't think this can be used because: a. PKCS#1 can't be referenced in IETF documents b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger Note also this would add an implementation burden in that the ISAKMP code would be responsible for generating BER encoded information. In my opinion, we should use the 'raw' signature for now. If we could obtain an IETF-compliant defininition of an enhanced PKCS#1 format I would be willing to convert. The fact the PKCS#1 format contains the length and the algorithm is appealing. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMyhSfsKmlvJNktGxAQHJagP/WgKnRWF4IVX92kPlJU9juPacB0fwYNEO slRCKLQcUatueyuSTvar+I23X6tOO/aNGndGsZfwrAss0cPI271TkCwVd4cOkRnY EKRxZEVWS9ieAj9Oh7IwqDAeM2Lun9sDzuUUOJxGXZjuj+rVUaXqa9Gt9GljI2cW SPxfHdkakKI= =22vj -----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 Thu Mar 13 16:48:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24035 for ipsec-outgoing; Thu, 13 Mar 1997 16:42:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <32823C30.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 16:43:21 -0500 To: svakil@usr.com From: Stephen Kent Subject: Re: Questions on the Security Arch. draft Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Sumit, We are in the process of re-writing the architecture document and will address this question in the revised version. If one is using security labels and these labels are implicitly bound to an SA, then it might be appropriate for a gateway terminating a (tunnel mode) SA to introduce such labels into the decapsulated IP header. However, this could backfire if this header were covered by transport mode AH! So, we need to be careful in describing under what circumstances this intermediate system processing is appropriate. I'm not sure that there is other authentication data that ought to be addressed here, in a general fashion, and so we may tighen this part of the spec to focus only on security labels, to the extent appropriate. Ran, as the author of this version of the architecture document, is there anything else you'd like to add to this reply? Steve From owner-ipsec Thu Mar 13 20:21:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA25382 for ipsec-outgoing; Thu, 13 Mar 1997 20:18:39 -0500 (EST) Date: Fri, 14 Mar 97 01:11:19 GMT Standard Time From: Ran Atkinson Subject: Re: Questions on the Security Arch. draft To: ipsec@tis.com, svakil@usr.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <32823C30.3000@usr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 13 Mar 1997 10:00:42 -0600 svakil@usr.com wrote: > Hi. I had a question on section 1.4 of the Security Architecture > draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft > says : > > "A security gateway which receives a datagram containing a > recognised sensitivity label, for example IPSO [Ken91], from a trusted > host MUST take that label's value into consideration when > creating/selecting an Security Association for use with AH between the > gateway and the external destination. In such an environment, a > gateway which receives a IP packet containing the IP Encapsulating > Security Payload (ESP) should add appropriate authentication, > including implicit (i.e. contained in the Security Association used) > or explicit label information (e.g. IPSO), for the decrypted packet > that it forwards to the trusted host that is the ultimate > destination." > > I don't get the last part about the gateway adding authentication > information for the decrypted packet. Does this mean that the gateway > uses the SA that it used to decrypt the packet, to generate the > authentication info? That really doesn't make sense to me since AH > and ESP have separate SAs and also since any given security > association is for use with one peer only. Or, is it that the gateway > has a security association with the trusted host and tunnels all the > packets for that host using this SA? If your system does not implement CIPSO and does not implement RFC-1038 or RFC-1108, then the above doesn't apply since those are just about the only known sensitivity labels used with IPv4. If your gateway implements one of those label systems (or is B1 or higher), then the gateway SHOULD use AH (or ESP) when transmitting the packet along to its final destination. The IPsec SA used for transmitting the packet along to its final destination MUST have a sensitivity label value consistent with the sensitivity label associated with that packet when it was received. The goal here is to accurately maintain end-to-end integrity on the sensitivity label of the data. If this is still confusing, send private email. This is not a general interest topic... Ran rja@inet.org From owner-ipsec Fri Mar 14 02:37:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA27133 for ipsec-outgoing; Fri, 14 Mar 1997 02:33:45 -0500 (EST) Message-Id: <199703140707.XAA15976@dharkins-ss20> 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: PKI Signature format in ISAKMP -- proposal In-Reply-To: Your message of "Thu, 13 Mar 1997 14:19:43 EST." <3.0.16.19970313141636.297f94d8@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 23:07:08 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In preparing for the ANX bakeoff there has been some discussion > of exactly what a "signature" should look like for ISAKMP. Some > people have interpreted this to mean the signature output was in > PKCS#1 format. Others have not. The fact that it is open to interpretation means it needs clarification. But, regardless of people's interpretation, the intent of the draft is to not do "PKCS#1 Signatures" for RSA-SIG authentication. The intent was to do "PKCS#1 Encryption" of the result of the hmac. > The procedure used to produce the signature is described here for the > RSA signature algorithm case. Note the terms are from > draft-ietf-ipsec-isakmp-oakley-03.txt. > > - ISAKMP produces HASH_I/HASH_R however it wishes > > - the hash is used as input data for encryption with the RSA private > key, with > padding as required by the RSA algorithm (see PKCS#1 or the BSAFE > documentation) > > - the (key bits) of encryption output is passed over the wire as the > signature > > - the other side calculates the hash value HASH_I/HASH_R independantly > > - the other side decrypts the signature data using the public key > retrieved > from the cert we are sending over the wire This is fine for the bake-off but there is no requirement to pass certs over the wire and signature verification should not be dependent upon it. > - the other side compares the decrypted signature against it's locally > calculated hash and if they match you're all set. > > Note that the 'signature' data passed over the wire is the > of data as generated by the RSA algorithm. The > normal ISAKMP payload processing allows the receiving side to > determine how much data is present. The 'signature', that is, > the encoded hash, must be padded as required by the RSA > algorithm, so when the data is encrypted it consists of: > > one byte of zero > hash bytes > padding of zero bytes up to Actually, it should be (from PKCS#1): 00 | BT | PS | 00 | hmac where BT in this case would be a 1 (because it's encrypting with the private key), PS is a string of 0xff which is modulus-length minus 3 minus hmac length in length. > DIFFERENCE FROM PKCS#1. > > In PKCS#1 an ASN.1 structure encoded in BER would be transmitted > over the wire. I don't think this can be used because: > > a. PKCS#1 can't be referenced in IETF documents > b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger > > Note also this would add an implementation burden in that the > ISAKMP code would be responsible for generating BER encoded > information. But is is PKCS#1, it's just "PKCS#1 encryption". To do an RSA signatures you do a PKCS#1-defined RSA private key encryption of the output from the hmac function instead of a PKCS#1-defined "RSA signature" (which includes encoding a magic number that is outside the control of the IETF). > In my opinion, we should use the 'raw' signature for now. > > If we could obtain an IETF-compliant defininition of an enhanced > PKCS#1 format I would be willing to convert. The fact the > PKCS#1 format contains the length and the algorithm is > appealing. The fact that it contains the length is extremely important. Given a key modulus length payload how do you know the true length of the hash is without the above-mentioned encoding? The fact that it contains an algorithm identifier is problematic. The intent of the draft was to do authentication with RSA signatures by encrypting the hmac with a private key and verifying it with the corresponding public key. I've failed quite spectacularly in conveying this. I'm open to suggested text on how to properly convey the intent. regards, 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 Mar 14 15:29:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02650 for ipsec-outgoing; Fri, 14 Mar 1997 15:21:34 -0500 (EST) Message-Id: <2.2.32.19970314203324.00b4a220@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, 14 Mar 1997 15:33:24 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: Clarification on 3des draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there any need to support optional IV for the 3des transform. I would remove it is there is not going to be any hardware that implements 3des and needs to generate its own IV. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Mar 14 15:37:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02751 for ipsec-outgoing; Fri, 14 Mar 1997 15:35:47 -0500 (EST) Message-ID: From: Greg Carter To: "'rodney@sabletech.com'" , "'dharkins@cisco.com'" Cc: "'ipsec@tis.com'" Subject: RE: PKI Signature format in ISAKMP - DSS Date: Fri, 14 Mar 1997 15:15:27 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk This refers to DSS signatures... Could we clarify the format of DSS signatures, all that's in the isakmp-oakley draft is 'encoded', to us that means the DSS signature defined in ANSI X9.30 part 3: "Certificate management for DSA". That is the ASN.1 encoding of r followed by s. ie DER encoding of type: SEQUENCE { r INTEGER, s INTEGER } Bye. From owner-ipsec Fri Mar 14 16:45:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03239 for ipsec-outgoing; Fri, 14 Mar 1997 16:41:53 -0500 (EST) To: IETF-Announce: cc: ipsec@tis.com From: The IESG Subject: Last Call: The resolution of ISAKMP with Oakley to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 14 Mar 1997 16:17:42 -0500 Message-ID: <9703141617.aa22907@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider the following Internet-Drafts for the status of Proposed Standard: o The resolution of ISAKMP with Oakley o Internet Security Association and Key Management Protocol (ISAKMP) o The Internet IP Security Domain of Interpretation for ISAKMP 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 March 28, 1997 Files can be obtained via ftp://ds.internic.net/internet-drafts/ From owner-ipsec Fri Mar 14 17:03:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03360 for ipsec-outgoing; Fri, 14 Mar 1997 17:03:00 -0500 (EST) Message-Id: <3.0.16.19970314170013.2e9fff5e@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 14 Mar 1997 17:07:46 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec in Memphis - when? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see any IPsec sessions on the agenda at . When is it? -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Mon Mar 17 00:44:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16889 for ipsec-outgoing; Mon, 17 Mar 1997 00:34:00 -0500 (EST) Message-Id: <3.0.32.19970316213807.00930100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 16 Mar 1997 21:38:10 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Closing out the COMPRESSION discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk All, First, thanks to all who participated in the compression discussion. The debate has been lively and useful. I wanted to make sure that the straw ballot results were available to the list prior to the 3/26 cutoff for drafts to be released in time for Memphis. The results of the straw poll indicated: (1) a significant majority of those who participated in the discussion (there were around 30 total participants) believe that adding compression as an optional feature to ESP is a good idea, and (2) of those in that majority, most felt that using the most-significant bit of the pad length byte as a compressed/not-compressed indicator was an appropriate technique. There were a number of concerns raised on the list and I would like to close out the discussion with some additional insights on these points. 1. Compression belongs at a higher layer than IP There are a handful of people who feel this way. Some responded to this (as I did) by stating that there was no universally appropriate higher layer in which to do the compression. This is indeed true. However, it is certainly true that if compression was added to a higher layer protocol, say TCP, one would have the potential advantage of reducing the number of IP packets as well maintaining compression state across segments. The result would be a higher compression ratio for the same type of data. While adding compression to such a higher layer protocol has its advatnages for some environments, there is *NO* need for it to preclude the OPTIONAL use of compression in IPSec, where there *IS* gain to be had (leading to the next point). 2. There's not enough to gain when compressing packet-by-packet As most of you know (hopefully all of you), the amount of compression you get depends on the type of data being compressed. I first responded to this by providing some compression results based on using the LZS algorithm on some publically available test data. The response to this was "that's not *real* network data". Since that time, I have had a number of discussions with people in the networking industry regarding what *real* network data is. The reality is that one person's *real* network data is another person's meaningless data. You cannot simply sniff someone's T1 connection to the internet to get *real* network data. In the context of IPSec, I would imagine that network data that will be encrypted will look more like today's LAN traffic (currently privately held data that will now, under IPSec, be exposed to the internet). Also, as pointed out by Terry Davis from Boeing, "CAD, GIFs, or other barely compressable objects" will not compress well, but "email or a few thousand pages of maintenance manual" can achieve significant gains by compressing. A second response on this point came from Jim Hughes, who recently stated that "We also have numbers on the compression ratios in real world, long run time situations, and even clearing the dictionary on every packet, we average 2:1 compression of data. Even on most small packets, the overhead of the encapsulationis removed by what compression there is." Similarly, a Q&A doc from VPNet states "VPNet's data compression technology is oriented around a per-packet compensation for security-induced packet expansion. In current network tests, the performance improvement for very small packets is small, but for larger packets, network performance gains are substantial. Improvements between 10 and 40 percent are typical, though for packets containing highly compressible data, improvements of up to 70 percent are possible." 3. Using the most significant bit (msb) of the pad length will cause compatibility problems The proposal involves using the msb of the pad length field to indicate whether or not a packet is compressed. Note that the use of compression is intended to be negotiated on a per SA basis at by the key management protocol. Any current implementation of ESP that does not wish to support the OPTIONAL compression feature is free not to and will suffer no compatibility problems when interoperating with those implementations that support the compression feature. Current implementations will NEVER negotiate to turn on the compression feature. As a result, compressed data will NEVER be sent to them. As such, the msb can continue to be interpreted to mean that there are 128 additional bytes of padding. Implementations that DO support the compression feature will use a maximum of 127 bytes of padding, leaving the msb to indicate compressed/not-compressed. With that said, the working group should expect the next draft of the ESP specification to include compression as an optional feature of ESP (negotiated by the KMP) with the msb of the pad length field used as the packet compressed/not-compressed indicator. -Bob From owner-ipsec Mon Mar 17 11:29:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21108 for ipsec-outgoing; Mon, 17 Mar 1997 11:25:50 -0500 (EST) Message-Id: <199703171625.LAA21108@portal.ex.tis.com> Date: Mon, 17 Mar 1997 11:21:47 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: iesg@ietf.org, smamros@newoak.com Subject: Comment on the ISAKMP/Oakley resolution draft X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a concern regarding the latest version of the ISAKMP/Oakley resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt). The previous version of the draft (-02) allowed a mode of operation which is no longer possible under the new draft. When using pre- shared keys for authentication (in section 5.3), one can now use Oakley Main Mode only if the pre-shared keys are identified by the IP addresses of the peers. One cannot use keys associated with some other identifier supplied by the initiator (denoted as IDii in the draft), because that payload is encrypted with SKEYID_e, which is derived in part from the pre-shared key in question (as described at the beginning of section 5 - the pre-shared key is used to derive SKEYID, which in turn is used to derive SKEYID_e). The -02 version of the draft did allow Main Mode to be used for any initiator identifier, because SKEYID was derived in a different manner which did not include the pre-shared key. While the -03 draft does state that one can use Oakley Aggressive Mode instead for pre-shared keys, Agressive Mode does not provide identity protection (i.e., encryption of IDii) as Main Mode does. The root cause of the problem seems to be that the -03 draft introduces a new common algorithm for deriving HASH_I and HASH_R which uses SKEYID (beginning of section 5). In the -02 draft, HASH_I and HASH_R were derived differently, depending on which authentication method (signatures, public keys, or pre-shared keys) was used. When using pre-shared keys, the key clearly must be used to derive the hash in order to authenticate the peers to one another. In order to allow for this, the use of the pre-shared key was moved into the derivation for SKEYID. However, doing so introduces a dependency on the pre-shared key for SKEYID_a and SKEYID_e, which did not exist in the -02 draft. While I certainly believe that having common algorithms across different authentication methods wherever possible is a Good Thing in terms of reducing complexity, I do not feel that that justifies eliminating a useful mode of operation which was previously allowed. That being said, I do believe there exists a method by which the new common HASH_I and HASH_R derivation can remain. Just as HASH_I and HASH_R require additional processing to derive SIG_I and SIG_R when using signatures for authentication (section 5.1), one could require an additional step which combines HASH_I and the key into a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow the pre-shared key to be removed from the derivation of SKEYID without losing authentication capability. Of course, I am open to other possible solutions to this problem. My goal here is to allow for a useful mode of operation (pre-shared keys identified by IDii with identity protection provided by Oakley Main Mode) to continue as it did in the prior version of the draft. -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Mon Mar 17 11:55:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21385 for ipsec-outgoing; Mon, 17 Mar 1997 11:54:33 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 17 Mar 1997 12:04:34 -0500 Message-Id: <9703171704.AA24466@secpwr.watson.ibm.com> To: smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft Cc: ipsec@tis.com, hugo@watson.ibm.com, pau@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: eZpwI3MlSYwhgkfKKoBwKg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA21382 Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, Hugo and I discovered this too. One solution Hugo has is to give the shared key an ID (like an SPI). This ID could be sent in ID payload together with KE and NONCE. Another possibility I could see is to augment the DOI a little bit and send the key ID in "situation". Pau-Chen > > I have a concern regarding the latest version of the ISAKMP/Oakley > resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt). > > The previous version of the draft (-02) allowed a mode of operation > which is no longer possible under the new draft. When using pre- > shared keys for authentication (in section 5.3), one can now use > Oakley Main Mode only if the pre-shared keys are identified by the > IP addresses of the peers. One cannot use keys associated with > some other identifier supplied by the initiator (denoted as IDii > in the draft), because that payload is encrypted with SKEYID_e, > which is derived in part from the pre-shared key in question (as > described at the beginning of section 5 - the pre-shared key is > used to derive SKEYID, which in turn is used to derive SKEYID_e). > The -02 version of the draft did allow Main Mode to be used for > any initiator identifier, because SKEYID was derived in a different > manner which did not include the pre-shared key. > > While the -03 draft does state that one can use Oakley Aggressive > Mode instead for pre-shared keys, Agressive Mode does not provide > identity protection (i.e., encryption of IDii) as Main Mode does. > > The root cause of the problem seems to be that the -03 draft > introduces a new common algorithm for deriving HASH_I and HASH_R > which uses SKEYID (beginning of section 5). In the -02 draft, > HASH_I and HASH_R were derived differently, depending on which > authentication method (signatures, public keys, or pre-shared keys) > was used. When using pre-shared keys, the key clearly must be used > to derive the hash in order to authenticate the peers to one another. > In order to allow for this, the use of the pre-shared key was moved > into the derivation for SKEYID. However, doing so introduces a > dependency on the pre-shared key for SKEYID_a and SKEYID_e, which > did not exist in the -02 draft. > > While I certainly believe that having common algorithms across > different authentication methods wherever possible is a Good Thing > in terms of reducing complexity, I do not feel that that justifies > eliminating a useful mode of operation which was previously allowed. > That being said, I do believe there exists a method by which the > new common HASH_I and HASH_R derivation can remain. Just as HASH_I > and HASH_R require additional processing to derive SIG_I and SIG_R > when using signatures for authentication (section 5.1), one could > require an additional step which combines HASH_I and the key into > a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow > the pre-shared key to be removed from the derivation of SKEYID > without losing authentication capability. > > Of course, I am open to other possible solutions to this problem. > My goal here is to allow for a useful mode of operation (pre-shared > keys identified by IDii with identity protection provided by Oakley > Main Mode) to continue as it did in the prior version of the draft. > > -Shawn Mamros > E-mail to: smamros@newoak.com > > > From owner-ipsec Mon Mar 17 14:18:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22336 for ipsec-outgoing; Mon, 17 Mar 1997 14:17:25 -0500 (EST) Message-Id: <3.0.16.19970317141440.357f70a0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Mon, 17 Mar 1997 14:22:27 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec Implementation Survey Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_858644547==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" Attached is a revision of the IPsec Implementation Survey form. If you have an IPsec implementation and you would like to be listed in the survey, please fill this out and send it back to me, Rodney Thayer, at . I will collect this and publish them to the list before the meeting in Memphis. --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="SURVEY2.TXT" Name of Implementation : (name of your implementation/product) Version Described : Organization : (name of your organization) Which IP versions are supported : (IPv4, IPv6, or IPv4 and IPv6) Implements RFC-1828 AH MD5 : (YES, NO, In Progress, Planned, Partial) Implements RFC-1829 ESP DES-CBC : (YES, NO, In Progress, Planned, Partial) Implements AH HMAC MD5 : (YES, NO, In Progress, Planned, Partial; draft rev.) Implements AH HMAC SHA-1: (YES, NO, In Progress, Planned, Partial; draft rev.) Implements Combined ESP (DES+MD5+Replay, etc) : Please list combinations you support, and for each combination indicate (YES, NO, In Progress, Planned, Partial; draft rev.) Examples include MD5+DES+Replay, SHA-1+3DES, etc. Other AH Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Other ESP Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Transport mode : (YES, NO, In Progress, Planned, Partial) Tunnel mode : (YES, NO, In Progress, Planned, Partial) Key Management : (Manual, ISAKMP+Oakley, SKIP, Photuris, other, proprietary) Platforms : (4.4-Lite BSD, Solaris, IRIX, , STREAMS, LINUX, etc) Lineage of IPsec Code : (, ETHZ, JI, KA9Q, NIST, NRL, SUN, not applicable) Lineage of Key Mgmt Code: (, SUN, ETHZ, JI, cisco, not applicable) Location of Source Code : (provide URL if freely available, use the word "proprietary" if isn't freely available) POINTS of Contact : (email address, optionally also phone/fax/name) Claimed Interoperability: (list of systems that your implementation fully interoperates with) --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" 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" --=====================_858644547==_-- From owner-ipsec Mon Mar 17 15:09:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22787 for ipsec-outgoing; Mon, 17 Mar 1997 15:09:12 -0500 (EST) Message-Id: <199703172013.MAA17906@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: smamros@newoak.com, ipsec@tis.com, hugo@watson.ibm.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft In-Reply-To: Your message of "Mon, 17 Mar 1997 12:04:34 EST." <9703171704.AA24466@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 12:13:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, Pau-Chen, > Shawn, Hugo and I discovered this too. One solution Hugo has > is to give the shared key an ID (like an SPI). This ID could > be sent in ID payload together with KE and NONCE. Another > possibility I could see is to augment the DOI a little bit > and send the key ID in "situation". If you pass an ID payload with the KE and NONCE payloads then why do Main Mode? That sounds like an Aggressive Mode to me. And if the ID payload is only some opaque blob of data that has meaning only to the parties involved then there's no loss of "ID protection" in Aggressive Mode. An ID of dharkins@cisco.com means something to a passive evesdropper; an ID of 7a8927c5478 (like a SPI) means nothing so why not just pass it in the clear and do an Aggressive Mode? The problem is that IDs of type FQDN or user@FQDN (the only two that convey any real meaning that the two parties might want to hide) cannot be used to identifiy pre-shared keys to be used with Main Mode. I'm not sure how big a problem this is. The two parties must somehow agree to a pre-shared key in some out-of-band manner, and presumably they'll also agree to some identifier for that key (which right now can't be FQDN or user@FQDN). The IPSec DOI reserves 6 ID types for private use. The two parties could agree that the identifier will be some opaque blob (like a SPI) and it's ID type will be from the private use range. Then you do Aggressive Mode with out conveying your identities to any evesdroppers; you retain "ID protection". Why isn't this acceptable? The pre-shared key was put into SKEYID, and SKEYID is used as the key to the HMAC (as opposed to part of the data to hash) on the recommendation of a cryptographer (it's a security issue). I'm hesitant to remove it to allow a case that I don't see as overwhelmingly compelling. Comments? Dan. From owner-ipsec Mon Mar 17 18:22:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23983 for ipsec-outgoing; Mon, 17 Mar 1997 18:19:16 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703172324.SAA50747@mailhub1.watson.ibm.com> Date: Mon, 17 Mar 97 17:48:17 EST To: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com cc: smamros@newoak.com, ipsec@tis.com Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared) Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn and other intersted parties: Having the pre-shared key in SKEYID and the derived keys increases security. It was my recommendation to do so. As just one example consider two parties that use DH with a public prime p. If at some point enough cryptanalysis and pre-computation is done on p then every exchange using that prime may be compromised. This is a not-impossible scenario where you lose (in a hard way) all the advantages of perfect forward secrecy (your traffic of the last few years may be compromised!). If, however, you derived your key depending on both g^xy and your pre-shared key the attacker will need to find the value of that pre-shared key (which will probably not exist at that point of time) to find the actual keys used to protect the session traffic. I agree with you that having to tie the pre-shared key only to IP addresses is too much of a loss of flexibility and functionality of the protocol. However, there is the simple solution suggested in Pau-Chen and Dan's messages. That is, use a key identifier for the pre-shared key: such a key identifier would be meaningful only to the specific parties sharing that key. As Dan pointed out you can then dispense of non-aggressive mode and just do aggressive, thus saving communication. (You may still want non-aggressive mode for the sake of negotiation). Bottom line: we achieved more security, a more modular protocol, less communication and full functionality. In order to accomodate this key identifier one needs an "Identifiction Type Value" as defined in the Ipsec DOI (draft-ietf-ipsec-ipsec-doi-02.txt). This can be one of the "private" values to be agrred upon by the communicating parties, or we could have a type value (say 7) added in that draft for "ID_KEY". If there is no opposition to do so I would suggest this mininal editorial change to the DOI draft. Hugo From owner-ipsec Mon Mar 17 19:05:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24219 for ipsec-outgoing; Mon, 17 Mar 1997 19:04:13 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703180009.TAA29672@mailhub1.watson.ibm.com> Date: Mon, 17 Mar 97 18:53:17 EST To: smamros@newoak.com cc: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared) Sender: owner-ipsec@ex.tis.com Precedence: bulk See response below. > HUGO@watson.ibm.com wrote: > > Having the pre-shared key in SKEYID and the derived keys increases security. > > It was my recommendation to do so. As just one example consider two > > parties that use DH with a public prime p. If at some point enough > > cryptanalysis and pre-computation is done on p then every exchange using that > > prime may be compromised. This is a not-impossible scenario where you > > lose (in a hard way) all the advantages of perfect forward secrecy > > (your traffic of the last few years may be compromised!). > > If, however, you derived your key depending > > on both g^xy and your pre-shared key the attacker will need to find the > > value of that pre-shared key (which will probably not exist at that point > > of time) to find the actual keys used to protect the session traffic. > > OK, but if that's the case, is there then a problem with the > derivation of SKEYID in the case where signatures are used for > authentication, where only the nonces (passeed across the wire in > plaintext) and g^xy are used? You are right. In this sense the signature mode is the weakest of all three modes. In particular, in the case the public key encryption mode of authentication the attacker needs to break the TWO private keys of the parties AND the DH prime to find the keys (i.e. you get the MAXIMAL security of both DH and RSA). This is one of the important reasons why I have been "promoting" this mode for long time. BTW, this not only protects against a broken DH, but also against a partner to the communciation that implements poorly the DH exchange, e.g. by choosing short exponents or by not destroying the exponents immediately after use. In addition, the signature mode has several privacy weaknesses: it provides proofs of communication between the communicating parties, does not protects identities against active attacker (on the other hand it protects idenities with PFS), and does not provide identity-protection at all in aggressive mode. > > Regarding the other comments and suggestions that have been made, > I may have more to say in the next day or two - need to do some > more thinking on the subject... Hope it will be ok with you and others. Using pre-shared key in this way (with a key identifier) seems to be the best solution in many cases, e.g. for mobile users and dynamic IP addrsses. Hugo > > -Shawn Mamros > E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 07:42:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28129 for ipsec-outgoing; Tue, 18 Mar 1997 07:36:43 -0500 (EST) Message-Id: <199703181236.HAA28129@portal.ex.tis.com> Date: Mon, 17 Mar 1997 18:45:51 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: HUGO@watson.ibm.com CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) X-Priority: 3 (Normal) References: <199703172324.SAA50747@mailhub1.watson.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk HUGO@watson.ibm.com wrote: > Having the pre-shared key in SKEYID and the derived keys increases security. > It was my recommendation to do so. As just one example consider two > parties that use DH with a public prime p. If at some point enough > cryptanalysis and pre-computation is done on p then every exchange using that > prime may be compromised. This is a not-impossible scenario where you > lose (in a hard way) all the advantages of perfect forward secrecy > (your traffic of the last few years may be compromised!). > If, however, you derived your key depending > on both g^xy and your pre-shared key the attacker will need to find the > value of that pre-shared key (which will probably not exist at that point > of time) to find the actual keys used to protect the session traffic. OK, but if that's the case, is there then a problem with the derivation of SKEYID in the case where signatures are used for authentication, where only the nonces (passeed across the wire in plaintext) and g^xy are used? Regarding the other comments and suggestions that have been made, I may have more to say in the next day or two - need to do some more thinking on the subject... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 08:53:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28821 for ipsec-outgoing; Tue, 18 Mar 1997 08:53:01 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-vpn-00.txt Date: Tue, 18 Mar 1997 08:49:48 -0500 Message-ID: <9703180849.aa18842@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 Security Protocol Working Group of the IETF. Title : Implementation of Virtual Private Network (VPNs) with IP Security Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-vpn-00.txt Pages : 5 Date : 03/14/1997 This document discusses methods for implementing Virtural Private Networks (VPN) with IP Security (IPSec). We discuss different scenarios in which VPN is implemented and the security implications for each of these scenarios. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-vpn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-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-ipsec-vpn-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: <19970317162735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-vpn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970317162735.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Mar 18 11:19:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00056 for ipsec-outgoing; Tue, 18 Mar 1997 11:17:46 -0500 (EST) Date: Tue, 18 Mar 97 16:15:01 GMT Standard Time From: Ran Atkinson Subject: Re: Closing out the COMPRESSION discussion To: Bob Monsour , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970316213807.00930100@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The WG chairs do not see any clear consensus on compression within the IPsec WG at this time. As such, the discussion on compression is NOT "closed". In fact additional discussion on this topic is encouraged. We hope to have further discussions in Memphis on the topic of compression. People desiring to make technical presentations on this (or other IPsec) topic(s) should send email to me and Paul Lambert with the topic and time requested. Ran rja@inet.org From owner-ipsec Tue Mar 18 11:41:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00239 for ipsec-outgoing; Tue, 18 Mar 1997 11:40:04 -0500 (EST) Date: Tue, 18 Mar 97 16:37:36 GMT Standard Time From: Ran Atkinson Subject: [Admin] 38th IETF: IPSEC slots To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970318162210.0070912c@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk There are two sessions for IPSEC in Memphis as follows: Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, run, ids, rps, ftpext, qosr, otsv) Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) One of these meetings will be focused on implementation discussions, including reports from the AIAG interoperability testing, etc. The other will focus more on standards issues. Ran rja@inet.org From owner-ipsec Tue Mar 18 12:18:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00506 for ipsec-outgoing; Tue, 18 Mar 1997 12:06:00 -0500 (EST) Message-Id: <3.0.16.19970318120243.2957b404@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 18 Mar 1997 12:10:55 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: survey results Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk If you have previously responded to a survey and you don't have any changes, you don't have to respond again. I will post the existing survey results along with the new ones I'm receiving. Sorry about the confusion. 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 Mar 18 15:04:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00939 for ipsec-outgoing; Tue, 18 Mar 1997 15:01:06 -0500 (EST) Message-ID: <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 15:09:15 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: HUGO@watson.ibm.com CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) X-Priority: 3 (Normal) References: <199703172324.SAA50747@mailhub1.watson.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk After thinking about the issue some more and discussing it with my coworkers, we're willing to go with the workaround proposed by Pau-Chen, Dan and Hugo (i.e., using an opaque identifier in Oakley Aggressive Mode to find the correct pre-shared key). Thanks for the suggestion, guys... One possibility that Hugo mentioned in one of his messages: > In order to accomodate this key identifier one needs an > "Identifiction Type Value" as defined in the Ipsec DOI > (draft-ietf-ipsec-ipsec-doi-02.txt). > This can be one of the "private" values to be agrred upon by the > communicating parties, or we could have a type value (say 7) added in > that draft for "ID_KEY". > If there is no opposition to do so I would suggest this mininal editorial > change to the DOI draft. Ideally, I too would like to see an "official" value designated in the DOI draft, if it's possible. But I'm willing to live with a private value if we have to... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 15:06:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00987 for ipsec-outgoing; Tue, 18 Mar 1997 15:06:03 -0500 (EST) Message-Id: <199703182009.MAA03622@mailsun3-fddi.us.oracle.com> Date: 18 Mar 97 11:09:43 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda Cc: rodney@sabletech.com, rja@inet.org 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 There will be two IPSEC sessions in Memphis: Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, run, ids, rps, ftpext, qosr, otsv) Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) The first session will cover the IPSEC specifications in progress and ongoing or new IPSEC work items. The second session will be an implementation session that only covers implementation issues, interoperability testing, interoperability profiles, etc. Please send requests for agenda slots asap to the co-chairs (rja@inet.org, palamber@us.oracle.com). Please be sure to have "IPSEC Agenda" in your subject line or your message may be ignored. Preference is always given to editors of IPSEC I-Ds. If you are interested in presenting during the implementation session please also copy to Rodney Thayer (rodney@sabletech.com). Rodney is helping coordinate the IPSEC implementation session in Memphis (thanks Rodney!). Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Secure jobs for software developers 6+ years experience. Send resumes to palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Tue Mar 18 15:57:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01310 for ipsec-outgoing; Tue, 18 Mar 1997 15:56:57 -0500 (EST) Message-Id: <199703182022.MAA09677@fluffy.cisco.com> To: smamros@newoak.com (Shawn Mamros) cc: HUGO@watson.ibm.com, dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) In-reply-to: Your message of "Tue, 18 Mar 1997 15:09:15 EST." <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 12:22:16 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk This seems like a worthwhile addition. I'll post an updated IPSEC DOI before the Memphis deadline. I have one other attribute that needs to be added ("Key Length" for variable length ciphers like RC5). Derrell From owner-ipsec Tue Mar 18 17:32:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01887 for ipsec-outgoing; Tue, 18 Mar 1997 17:27:56 -0500 (EST) Date: 18 Mar 97 16:32:27 -0600 Subject: Re: [Admin] 38th IETF: IPSEC slots From: "James Hughes" To: ipsec@tis.com, "Ran Atkinson" X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00034EB0" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk --Cyberdog-MixedBoundary-00034EB0 X-Fontfamily: Palatino X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Should I plan on presenting? jim On Tue, Mar 18, 1997 10:37 AM, --Cyberdog-MixedBoundary-00034EB0 Content-Type: application/X-url Content-Transfer-Encoding: base64 Content-Description: Ran Atkinson bWFpbHRvOnJqYUBpbmV0Lm9yZw== --Cyberdog-MixedBoundary-00034EB0 X-Fontfamily: Palatino X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable wrote: > > > There are two sessions for IPSEC in Memphis as follows: > > Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, > run, ids, rps, ftpext, qosr, otsv) > Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) > > One of these meetings will be focused on implementation discussions, > including reports from the AIAG interoperability testing, etc. > > The other will focus more on standards issues. > > Ran > rja@inet.org --Cyberdog-MixedBoundary-00034EB0-- From owner-ipsec Tue Mar 18 18:41:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02261 for ipsec-outgoing; Tue, 18 Mar 1997 18:39:58 -0500 (EST) Message-Id: <2.2.32.19970318235202.00b0e704@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 Mar 1997 18:52:02 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: Issues with generating IV's in combined transforms Sender: owner-ipsec@ex.tis.com Precedence: bulk Both DES and 3DES combined transform specify the way to generate IV's. However, we dont maintain a running IV. In this case, isint it better to just send an IV in the packet always and not make it optional? --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Mar 18 20:38:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02940 for ipsec-outgoing; Tue, 18 Mar 1997 20:36:58 -0500 (EST) Message-Id: <199703190141.RAA19484@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Cc: anx-sec@dot.netrex.net Subject: cisco's free ISAKMP reference implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 17:41:27 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk A bug has been found in the latest ISAKMP release from cisco. If any of you obtained a copy (and want to do signature authentication) please get a fresh copy. Sorry for the inconvienence. Dan. From owner-ipsec Wed Mar 19 09:59:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07232 for ipsec-outgoing; Wed, 19 Mar 1997 09:56:36 -0500 (EST) Message-Id: <3.0.32.19970319065713.00949100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 06:57:20 -0800 To: Ran Atkinson From: Bob Monsour Subject: Re: Closing out the COMPRESSION discussion 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 Would someone like to suggest where to take the discussion from here? -Bob At 04:15 PM 3/18/97 Time, Ran Atkinson wrote: >All, > >The WG chairs do not see any clear consensus on compression within the IPsec >WG at this time. As such, the discussion on compression is NOT "closed". >In fact additional discussion on this topic is encouraged. > >We hope to have further discussions in Memphis on the topic of compression. > >People desiring to make technical presentations on this (or other IPsec) >topic(s) should send email to me and Paul Lambert >with the topic and time requested. > >Ran >rja@inet.org > > > From owner-ipsec Wed Mar 19 11:02:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07734 for ipsec-outgoing; Wed, 19 Mar 1997 11:00:03 -0500 (EST) Message-Id: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 11:03:15 -0500 To: Bob Monsour , Ran Atkinson From: Robert Moskowitz Subject: Re: Closing out the COMPRESSION discussion Cc: Bob Monsour , ipsec@tis.com In-Reply-To: <3.0.32.19970319065713.00949100@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:57 AM 3/19/97 -0800, Bob Monsour wrote: >Would someone like to suggest where to take the discussion from here? > Unfortunately, this straw vote occured over a time where my mail was hosed from multiple sources (maybe someone was out to get me ;). Compression is a must deliver for remote, dialup users. These will number in their thousands in the corporate arena. In fact, until IPsec is deployed internally in corporations, remote systems will represent the lion share of the market and the dollar volume (even with gateways costing more than ws code). If this group does not address compression head-on, someone(s) will do it and publish, at best, an informational RFC of how they did it and vendors will move down that road to compete in the market. ie the market decides. Get off the dime, people. Chrysler alone currently fields 6000 notebooks with another 1000 on order. We plan on putting IPsec into all of them 4Q97. The vendor that delivers compression will get our attention. Ford, GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We will work as a consolidated group (to an extent of course :) to get product that meets our needs. I welcome Bob's efforts. It is a careful balance of functionality and interoperability. I invite him to bring his approach to round 3 or 4 of our testing/piloting of IPsec. I'd rather it be an IPsec wg methodology. I can dance around no compression for a little while, but I've been chartered by the AIAG to deliver the goods, securely..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 11:48:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08121 for ipsec-outgoing; Wed, 19 Mar 1997 11:48:25 -0500 (EST) Date: Wed, 19 Mar 1997 11:50:40 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703191650.LAA28195@earth.hpc.org> To: rgm3@chrysler.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703191615.JAA20358@baskerville.CS.Arizona.EDU> Subject: Re: Closing out the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk > Compression is a must deliver for remote, dialup users. Wonderful, just have the compression WG publish their RFC describing the protocol; I assume they'll define one for TCP streams and another that can sit over any datagram protocol. The dime that this group should rise from is inline rekeying using DH medium-term secrets. Hilarie From owner-ipsec Wed Mar 19 12:22:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08339 for ipsec-outgoing; Wed, 19 Mar 1997 12:20:41 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703191725.JAA00587@kebe.eng.sun.com> Subject: All this tweaking is nice, but... To: ipsec@tis.com Date: Wed, 19 Mar 1997 09:25:39 -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 Hello folks in IPsec-land! I've been seeing a lot of last-minute tweaks lately on the list. As someone who Writes Code (TM), and as someone who's helped build some of the earliest versions of IPsec, I just have one question: WHY? Most of the ones I've seen recently seem extraneous (we can argue until we're blue in the face about if truncation is stronger, but the critical question is if non-truncated is BROKEN?), and others are made for reasons that don't take into account the big picture (code needed to parse variable-sized replay counters is lost in the noise compared with the HMAC calculations, so don't go whining about performance). I'll bet small sums that some of what's been popping up on IPsec is the result of some of the AIAG stuff. It's good that stuff like AIAG happens, but you guys can't forget that some of us aren't doing (or can't do) AIAG yet for _varying_ reasons. A few things to remember folks: 1.) The IP Security Architecture is EXTENSIBLE. This means if something's really broke, you can obsolete the current draft with a new one. Apart from changes derived from Bellovin's summer USENIX paper (some of which, mind you, merely involved following the spec), I haven't seen anything after those changes (Combined ESP, replay) that fixes honest-to-God BREAKAGE. Let's go with what's there, and create NEW drafts for some of these new approaches. 2.) The KISS principle. Yes, we can't leave gaping holes, but if there are no gaping holes, let's not go changing for change's sake! I'd suggest to everyone on this list a re-reading of _The Mythical Man-Month_ by Fred Brooks. And if you've never read this seminal work, for crying out loud find a copy. 3.) Let's not create a separate implementors list the way IPng did. I don't get AIAG-type mail, because I'm unable to show up for now. I'm sure I'm not the only one, though. Spec writers need to hear about implementation experience, and implementors need to hear the writers' rationale(s). 4.) We're in the risk reduction business. The only perfect security is the good ole-fashioned airgap firewall, or something else that keeps you from moving bits. (If anyone calls your network "truly secure" be afraid, be very afraid.) If we reduce the vulnerability, we're doing well. Alright alright, I'll climb down off my soapbox now. ObPlug: My updated internet drafts are in the I-D queue currently. Watch for them. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Wed Mar 19 13:01:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08737 for ipsec-outgoing; Wed, 19 Mar 1997 13:00:55 -0500 (EST) Message-Id: <3.0.1.32.19970319130501.00a79450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 13:05:01 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Purpose of AIAG discussion list.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk For those of you not interested in what is going on the AIAG list, but want to know why it exists, here is a note that I posted on it a week ago to clear this up, I hope. >Reply-To: rgm3@is.chrysler.com >X-Sender: rgm3@dilbert.is.chrysler.com >Date: Wed, 12 Mar 1997 16:57:22 -0500 >To: anx-sec@dot.netrex.net, anx-sec@dot.netrex.net, > Naganand Doraswamy >From: Robert Moskowitz >Subject: Re: developers list >Sender: owner-anx-sec@dot.netrex.net >Reply-To: anx-sec@dot.netrex.net > >At 05:02 PM 3/8/97 Time, Ran Atkinson wrote: >> >>Paul Lambert and I would like to suggest that the implementer discussions >>occur on the main IPsec list rather than on some sidebar list. This >>helps keep everyone in sync. Also, the IPsec list is not so noisy these >>days that it is an issue to have implementer discussions on the main >>list. > >The purpose of this list is to allow vendors and AIAG members to move IPsec >forward to implementation in step with the ANX schedule. To this extent, >defining what will be needed in terms of the protocols, and what is not >clear can definitely be handled on this list. > >However, when things are unclear in understanding the specs, or when >particular insights are learned here, these really have to go to the main >IPsec list. > >I also plan on keeping the main IPsec list abreast of what our requirements >- expectations - experiences are. > >As an ADMIN note, Ran has been on this list since I started it. I was very >appreciative of Steve Kent to be willing to add this list to his traffic to >gain his insights. But to all non-coders or non-auto-implementors, I ask >you to understand our purpose (get product out that interoperates) and our >schedule. > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 13:18:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08842 for ipsec-outgoing; Wed, 19 Mar 1997 13:18:01 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: rgm3@chrysler.com, Bob Monsour , Ran Atkinson Cc: ipsec@tis.com Subject: RE: Closing out the COMPRESSION discussion Date: Wed, 19 Mar 1997 10:03:23 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure I understand your point, Bob. Surely most (if not all) dial-up users will be using PPP, which already offers compression. What am I missing? -----Original Message----- From: Robert Moskowitz [SMTP:rgm3@chrysler.com] Sent: Wednesday, March 19, 1997 8:03 AM To: Bob Monsour; Ran Atkinson Cc: Bob Monsour; ipsec@tis.com Subject: Re: Closing out the COMPRESSION discussion At 06:57 AM 3/19/97 -0800, Bob Monsour wrote: >Would someone like to suggest where to take the discussion from here? > Unfortunately, this straw vote occured over a time where my mail was hosed from multiple sources (maybe someone was out to get me ;). Compression is a must deliver for remote, dialup users. These will number in their thousands in the corporate arena. In fact, until IPsec is deployed internally in corporations, remote systems will represent the lion share of the market and the dollar volume (even with gateways costing more than ws code). If this group does not address compression head-on, someone(s) will do it and publish, at best, an informational RFC of how they did it and vendors will move down that road to compete in the market. ie the market decides. Get off the dime, people. Chrysler alone currently fields 6000 notebooks with another 1000 on order. We plan on putting IPsec into all of them 4Q97. The vendor that delivers compression will get our attention. Ford, GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We will work as a consolidated group (to an extent of course :) to get product that meets our needs. I welcome Bob's efforts. It is a careful balance of functionality and interoperability. I invite him to bring his approach to round 3 or 4 of our testing/piloting of IPsec. I'd rather it be an IPsec wg methodology. I can dance around no compression for a little while, but I've been chartered by the AIAG to deliver the goods, securely..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 14:05:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09269 for ipsec-outgoing; Wed, 19 Mar 1997 14:02:17 -0500 (EST) Message-Id: <3.0.1.32.19970319140514.00ab68f0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 14:05:14 -0500 To: Glen Zorn , Bob Monsour , Ran Atkinson From: Robert Moskowitz Subject: RE: Closing out the COMPRESSION discussion Cc: ipsec@tis.com In-Reply-To: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 3/19/97 -0800, Glen Zorn wrote: >I'm not sure I understand your point, Bob. Surely most (if not all) >dial-up users will be using PPP, which already offers compression. What >am I missing? Once you encrypt you cannot compress, or else there is something wrong with your crypto, as I understand it. Thus PPP compression would only act on the PPP and IP header stuff. No offense, Glen, but this question tends to indicate that you have missed a big part of the compression discussion. Another reason given for IPsec compression is to get a packet to fit into an IP tunnel payload. The argument against this is that MTU discovery should handle this problem. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 17:13:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10541 for ipsec-outgoing; Wed, 19 Mar 1997 17:11:06 -0500 (EST) Message-ID: <01BC3470.1AC91AE0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: RE: All this tweaking is nice, but... Date: Wed, 19 Mar 1997 14:16:02 -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 don't know but I think we wouldn't be doing all this tweeking if the original drafts had been well thought out and the NRL "reference" pile of... code... made sense for more than just the base transforms which, lets face it, made no sense. You must agree that less than six months ago when we had a base transform that depended on changing the behaviour of MD5 and sets of documents that said "oh and key management will handle that" when key management didn't exist really, and we had drafts with material changes being introduced AFTER last call and etc. etc. etc. we were in pretty bad shape. I would argue that this process is broken and that the tweaks are necessary to produce something that is secure and that does make sense and is extensible. The drafts/RFC we have now are not really any of the above. 64 bit replay? great for alignment, bad for security/stupid to implement. key hashing by transforms based on ISAKMP attributes? what? secure maybe, extensible? what? documents to resolve documents? When is that ever right? variable length optional fields in the middle of fixed headers?? WHAT! -10. I can hear my compsci 120 prof laughing now.. I would call all of the above "honest to God BREAKAGE." A lot of us "Write Code (TM)". A lot of us write for a market that cares about quality and security. A lot of us write code that has to be maintained and costs money if it is broken. A lot of us will have to live with this pile of .. code .. for a long time in the future. We want this to work, to be secure, to be really extensible and we don't want to support broken, ill-conceived trash that we'll have to maintain forever because some customer will not upgrade. That's the difference between the NRL hack ah oh sorry, code and what we are doing. I don't think we require perfection, we just require that it makes sense and will actually achieve the goals we have for our products and our customers. Rob Adams Cisco Systems ---------- From: Dan McDonald[SMTP:Dan.McDonald@Eng.sun.com] Sent: Wednesday, March 19, 1997 9:25 AM To: ipsec@tis.com Subject: All this tweaking is nice, but... Hello folks in IPsec-land! I've been seeing a lot of last-minute tweaks lately on the list. As someone who Writes Code (TM), and as someone who's helped build some of the earliest versions of IPsec, I just have one question: WHY? Most of the ones I've seen recently seem extraneous (we can argue until we're blue in the face about if truncation is stronger, but the critical question is if non-truncated is BROKEN?), and others are made for reasons that don't take into account the big picture (code needed to parse variable-sized replay counters is lost in the noise compared with the HMAC calculations, so don't go whining about performance). I'll bet small sums that some of what's been popping up on IPsec is the result of some of the AIAG stuff. It's good that stuff like AIAG happens, but you guys can't forget that some of us aren't doing (or can't do) AIAG yet for _varying_ reasons. A few things to remember folks: 1.) The IP Security Architecture is EXTENSIBLE. This means if something's really broke, you can obsolete the current draft with a new one. Apart from changes derived from Bellovin's summer USENIX paper (some of which, mind you, merely involved following the spec), I haven't seen anything after those changes (Combined ESP, replay) that fixes honest-to-God BREAKAGE. Let's go with what's there, and create NEW drafts for some of these new approaches. 2.) The KISS principle. Yes, we can't leave gaping holes, but if there are no gaping holes, let's not go changing for change's sake! I'd suggest to everyone on this list a re-reading of _The Mythical Man-Month_ by Fred Brooks. And if you've never read this seminal work, for crying out loud find a copy. 3.) Let's not create a separate implementors list the way IPng did. I don't get AIAG-type mail, because I'm unable to show up for now. I'm sure I'm not the only one, though. Spec writers need to hear about implementation experience, and implementors need to hear the writers' rationale(s). 4.) We're in the risk reduction business. The only perfect security is the good ole-fashioned airgap firewall, or something else that keeps you from moving bits. (If anyone calls your network "truly secure" be afraid, be very afraid.) If we reduce the vulnerability, we're doing well. Alright alright, I'll climb down off my soapbox now. ObPlug: My updated internet drafts are in the I-D queue currently. Watch for them. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Wed Mar 19 18:28:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11248 for ipsec-outgoing; Wed, 19 Mar 1997 18:26:34 -0500 (EST) Message-Id: <61CDD2C9A961CF11B6A000805FD40AA9031DB71B@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: rgm3@chrysler.com, Bob Monsour Cc: ipsec@tis.com Subject: RE: Closing out the COMPRESSION discussion Date: Wed, 19 Mar 1997 15:29:57 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 3/19/97 -0800, Glen Zorn wrote: >I'm not sure I understand your point, Bob. Surely most (if not all) >dial-up users will be using PPP, which already offers compression. What >am I missing? Once you encrypt you cannot compress, or else there is something wrong with your crypto, as I understand it. Thus PPP compression would only act on the PPP and IP header stuff. Yes, you wouldn't get a very good compression factor at least. No offense, Glen, None taken! but this question tends to indicate that you have missed a big part of the compression discussion. That answers one question; I'll shut up an d listen for awhile. Perhaps it was just that I dropped in on the middle of the conversation, but I was puzzled as to what compression had to do w/security. Another reason given for IPsec compression is to get a packet to fit into an IP tunnel payload. The argument against this is that MTU discovery should handle this problem. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 21:04:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12032 for ipsec-outgoing; Wed, 19 Mar 1997 21:03:30 -0500 (EST) Date: Thu, 20 Mar 97 01:57:18 GMT Standard Time From: Ran Atkinson Subject: Re: the COMPRESSION discussion To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Just to be clear, I _personally_ am indifferent about compression. As co-chair, I'm very religious about following the standards process. Before we can move forward there MUST be rough consensus within the WG on how to proceed. Right now this just is not present. Sigh. The items that the IPsec WG needs to sort out are: 1) Is compression "must implement" or "optional to implement" or "outside our scope" ? If its inside our scope, then these next items also need to be sorted out: 2) What compression mechanism (not algorithm, but how to implement and at what processing layer) should be used ? 3) How to ensure that the compression mechanism can support arbitrary compression algorithms so that a new gee-whiz compression algorithm can be added modularly without changing everything. Reasonable steps towards progress might include: - Various people writing up various approaches as I-Ds and presenting these in Memphis (warning: time is short) - Discussing specifics on the IPsec list, noting which items are most important. - A clear agreement on the scope of the problem that should be addressed. - Deciding whether compression is just an ESP issue or whether it might be good to have a more generalised scheme for IP-layer compression of any IP packet (not just those packets with IPsec) Ran rja@inet.org From owner-ipsec Wed Mar 19 21:05:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12076 for ipsec-outgoing; Wed, 19 Mar 1997 21:05:33 -0500 (EST) Date: Thu, 20 Mar 97 02:04:42 GMT Standard Time From: Ran Atkinson Subject: Re: Closing out the COMPRESSION discussion To: Hilarie Orman , rgm3@chrysler.com Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703191650.LAA28195@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 19 Mar 1997 11:50:40 -0500 Hilarie Orman wrote: > The dime that this group should rise from is inline rekeying using DH > medium-term secrets. > > Hilarie ---------------End of Original Message----------------- Hilarie, I expect that Bill Sommerfeld will be publishing a revised version of inline keying with ISAKMP in the near future and I hope it will be discussed in Memphis. Bill is the document editor for that work item. Best wishes, Ran rja@inet.org From owner-ipsec Thu Mar 20 02:42:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA13657 for ipsec-outgoing; Thu, 20 Mar 1997 02:41:13 -0500 (EST) Message-Id: <3.0.32.19970319234159.009c34e0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 23:42:06 -0800 To: Ran Atkinson From: Bob Monsour Subject: Re: the COMPRESSION discussion Cc: PALAMBER@us.oracle.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:57 AM 3/20/97 Time, Ran Atkinson wrote: > >Just to be clear, I _personally_ am indifferent about compression. >As co-chair, I'm very religious about following the standards process. >Before we can move forward there MUST be rough consensus within the WG >on how to proceed. Right now this just is not present. Sigh. >The items that the IPsec WG needs to sort out are: > >1) Is compression "must implement" or "optional to implement" or > "outside our scope" ? > Ran, please forgive my frustration here (and perhaps I'm miss-reading the process) but I distinctly recall Paul Lambert getting up to summarize the activity of the WG meeting (in San Jose) and saying that there appeared to be consensus that the WG should take up compression as a work item. What I find frustrating is that the recently issued minutes (I understand that they "have not been edited") state "A straw pole indicated there is no current consensus on how to proceed". Am I the only one with this recollection? I read Paul's comment as calling compression within the scope of the WG. >If its inside our scope, then these next items also need to >be sorted out: > > >2) What compression mechanism (not algorithm, but how to implement > and at what processing layer) should be used ? >3) How to ensure that the compression mechanism can support arbitrary > compression algorithms so that a new gee-whiz compression > algorithm can be added modularly without changing everything. I appreciate your desire to be "very religious about following the standards process", but what I also find frustrating is the lack of presence of the co-chairs, in a moderating role, during the lengthy discussions that have been conducted on the list; items 2 and 3 that you list above are topics that have been discussed somewhat vigorously over the last few months. Where were you? The working group guidelines call for the co-chairs to "attempt to ensure that the discussions on the list are relevant and that they converge to consensus agreements". If there was an issue of whether or not compression was "inside our scope", then I would've expected to have the question of relevance raised early in the discussion for us to carry out that debate prior to spending an awful lot of WG time and energy on the topic. Specifically, in an email I wrote on Jan 23, I said: At the December IETF meeting, the IPSEC working group consensus was to undertake compression as a work item. In the rest of that email, I recapped the San Jose discussion, reviewed the proposals made in San Jose, and requested input on some of the issues raised at the WG meeting. I understand that the decisions in the meeting are not final (nothing is), but again, I would've expected some co-chair moderation to raise the question to the WG to avoid wasting everyone's valuable time. >Reasonable steps towards progress might include: > - Various people writing up various approaches as I-Ds and > presenting these in Memphis (warning: time is short) > - Discussing specifics on the IPsec list, noting which items > are most important. > - A clear agreement on the scope of the problem that should > be addressed. > - Deciding whether compression is just an ESP issue or > whether it might be good to have a more generalised scheme > for IP-layer compression of any IP packet (not just those > packets with IPsec) In an earlier email I made a formal request for agenda time in Memphis. There will be a draft submitted by the 3/26 cutoff date. As promised earlier, I will not refer to any consensus or straw poll info during my presentation. I will defer to you to make the necessary process calls at the meeting. In closing, the reality I am seeing in the vendor community is that there WILL be a number of companies in the market with compressing IPSec implementations. In the interest of the user community, it is important that the WG strive for the goal of interoperable implementations of this capability. I hope you understand my concerns. Regards (really), -Bob From owner-ipsec Thu Mar 20 09:44:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16496 for ipsec-outgoing; Thu, 20 Mar 1997 09:42:34 -0500 (EST) Date: Thu, 20 Mar 1997 09:45:10 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703201445.JAA06780@earth.hpc.org> To: rja@inet.org Cc: rgm3@chrysler.com, ipsec@tis.com In-reply-to: Yourmessage Subject: Re: Closing out the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk As I mentioned in San Jose, Bill Sommerfeld's version of inline keying is not at all what I mean. What I mean is carrying an identifier in the ESP header that can be hashed with a pre-established secret to produce the unique key for the packet payload. This can be done many times to achieve uni-directional rekeying before security would demand that the pre-established secret be changed. I think the distinction is inline keys vs. inline key exchanges. Hilarie From owner-ipsec Thu Mar 20 10:44:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17060 for ipsec-outgoing; Thu, 20 Mar 1997 10:43:23 -0500 (EST) Date: Thu, 20 Mar 97 15:30:53 GMT Standard Time From: Ran Atkinson Subject: Re: the COMPRESSION discussion To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970319234159.009c34e0@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 19 Mar 1997 23:42:06 -0800 Bob Monsour wrote: > At 01:57 AM 3/20/97 Time, Ran Atkinson wrote: > > > >Just to be clear, I _personally_ am indifferent about compression. > >As co-chair, I'm very religious about following the standards process. > >Before we can move forward there MUST be rough consensus within the WG > >on how to proceed. Right now this just is not present. Sigh. > >The items that the IPsec WG needs to sort out are: > > > >1) Is compression "must implement" or "optional to implement" or > > "outside our scope" ? > > > > Ran, please forgive my frustration here (and perhaps I'm miss-reading the > process) but I distinctly recall Paul Lambert getting up to summarize the > activity of the WG meeting (in San Jose) and saying that there appeared to > be consensus that the WG should take up compression as a work item. > ... the recently issued minutes (I understand that > they "have not been edited") state "A straw pole indicated there is no > current consensus on how to proceed". Am I the only one with this > recollection? I read Paul's comment as calling compression within the scope > of the WG. Those statements are not mutually exclusive. The fact that we are discussing compression is consistent with it being a Work Item. Not all work items lead to specifications, though most do. "How to proceed" is a broader question that encompasses the items I mentioned in my email note: mandatory or optional to implement what mechanism to use etc. (see original note) Further, frustrating though it might be, the consensus of this WG seems to be fairly fluid on several topics, including compression. I have received recent email from several different people asserting that they now believe compression to be important but out of scope for IPsec in that they believe it should be done at a higher protocol processing layer. I might or might not personally agree, but its not my personal call -- its up to the group as a whole to reach some conclusions. Those who really want to make progress on this should write up some concrete protocol specifications in the form of an I-D, put it online, present it to the WG in Memphis, and see whether the WG as a whole is comfortable with that approach. Such an I-D should try to answer the questions I've posed. Its entirely possible for this WG to reach consensus on this in Memphis if people will write some concrete things up and present them in a way that convinces most people in the WG... Ran rja@inet.org From owner-ipsec Thu Mar 20 10:53:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17135 for ipsec-outgoing; Thu, 20 Mar 1997 10:53:29 -0500 (EST) Message-Id: <97Mar20.105913est.11651@elgreco.rnd.border.com> To: Ran Atkinson cc: ipsec@tis.com Subject: Re: the COMPRESSION discussion References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> In-reply-to: Your message of "Wed, 19 Mar 1997 20:57:18 -0500". From: "C. Harald Koch" 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19029.858873477.1@rafael.rnd.border.com> Date: Thu, 20 Mar 1997 10:57:58 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Ran Atkinson writes: > > Just to be clear, I _personally_ am indifferent about compression. > As co-chair, I'm very religious about following the standards process. > Before we can move forward there MUST be rough consensus within the WG > on how to proceed. Right now this just is not present. Sigh. And this is where I'm wary of compression as part of the IPsec WG. Compression is extremely difficult to standardize, due to the number of patents on compression algorithms. Witness the PPP WG, which ran around and around on the discussion of compression for years, and where there is *still* no useful interoperable compression. It's already taken us far too long to get standards out; adding compression will only make this worse. -- Harald Koch From owner-ipsec Thu Mar 20 11:02:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17189 for ipsec-outgoing; Thu, 20 Mar 1997 11:02:02 -0500 (EST) Date: Thu, 20 Mar 1997 10:59:15 -0500 From: "Ferdinand N. Ahlberg" Message-Id: <199703201559.KAA19229@olympus.ctron.com> To: rgm3@chrysler.com, rmonsour@earthlink.net, rja@inet.org, glennz@microsoft.com Subject: RE: Closing out the COMPRESSION discussion Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hey now! > > I'm not sure I understand your point, Bob. Surely most (if not all) > dial-up users will be using PPP, which already offers compression. What > am I missing? > IPSec, among other things, defines encrypting packets at the network layer. PPP compression is performed at the data link layer. Compression algorithms search the data stream for patterns and then replace those patterns with smaller representations. Encryption algorithms generate outputs which are free of repetitive patterns. Therefore, compression of encryted data will have no effect. So, use of compression deserves to be defined in IPSec, because, if you encrypt at the network layer, your PPP compression will not compress the packets. In order to harmonize the two technologies, you must compress before encrypting. Ferd /////////////////////////////////////// // // // Ferdinand N. Ahlberg // // WAN Development // // Cabletron Systems, Inc. // // // // ahlberg@ctron.com // // // /////////////////////////////////////// From owner-ipsec Thu Mar 20 11:23:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17288 for ipsec-outgoing; Thu, 20 Mar 1997 11:23:39 -0500 (EST) Date: Thu, 20 Mar 1997 08:28:44 -0800 Message-Id: <199703201628.IAA25182@gump.eng.ascend.com> From: Karl Fox To: "C. Harald Koch" Cc: Ran Atkinson , ipsec@tis.com Subject: Re: the COMPRESSION discussion In-Reply-To: <97Mar20.105913est.11651@elgreco.rnd.border.com> References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> <97Mar20.105913est.11651@elgreco.rnd.border.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Compression is extremely difficult to standardize, due to the number of > patents on compression algorithms. Witness the PPP WG, which ran around and > around on the discussion of compression for years, This is true. > and where there is *still* no useful interoperable compression. This is not true. CCP is standardized, and at least two compression methods are in widespread use, being available on the majority of all PPP-speaking devices. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Thu Mar 20 12:12:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17580 for ipsec-outgoing; Thu, 20 Mar 1997 12:11:27 -0500 (EST) Message-Id: <199703201715.MAA00500@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: rja@inet.org, rgm3@chrysler.com, ipsec@tis.com Subject: Re: inline keying In-Reply-To: ho's message of Thu, 20 Mar 1997 09:45:10 -0500. <199703201445.JAA06780@earth.hpc.org> Date: Thu, 20 Mar 1997 12:15:14 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I've received relatively little feedback on the inline keying proposal; as i'm in the process of revising it (hopefully in time for the deadline next Wednesday), I'd very much like to hear what you, or anyone else, has to say. > As I mentioned in San Jose, Bill Sommerfeld's version of inline keying > is not at all what I mean. What I mean is carrying an identifier in > the ESP header that can be hashed with a pre-established secret to > produce the unique key for the packet payload. This can be done many > times to achieve uni-directional rekeying before security would demand > that the pre-established secret be changed. What you're suggesting is rekeying every packet. Putting my efficiency hat on, this could get quite expensive (potentially doubling the crypto overhead vs. fixed keys for short packets..). My proposal was (essentially) rekeying every "connection" or "flow", so that the second and subsequent packets in each direction can run at the same speed as a vanilla fixed-key SA. > I think the distinction is inline keys vs. inline key exchanges. Fair enough.. Anyone else have any comments? - Bill From owner-ipsec Thu Mar 20 12:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17855 for ipsec-outgoing; Thu, 20 Mar 1997 12:54:36 -0500 (EST) Message-Id: <3.0.32.19970320095113.009c6680@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 09:51:27 -0800 To: "C. Harald Koch" From: Bob Monsour Subject: Re: the COMPRESSION discussion Cc: Ran Atkinson , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:57 AM 3/20/97 -0500, C. Harald Koch wrote: >Compression is extremely difficult to standardize, due to the number of >patents on compression algorithms. Witness the PPP WG, which ran around and >around on the discussion of compression for years, and where there is >*still* no useful interoperable compression. The issue that surrounded and delayed the PPP WG had to do with 2 Motorola patents, neither of which involved compression algorithms per se. One has to do with the idea of maintaining multiple compression contexts/histories over a communication link and the second had to do with a way to handle out-of-order packets and resetting the compression contexts/histores appropriately. Neither of these come into play in the proposed IPSec method for compressing. This is because no context/history is maintained from one packet to the next (unlike PPP). Perhaps someone else from the PPP world could respond with their knowledge on the subject as well. -Bob Disclaimer: I'm not a lawyer. From owner-ipsec Thu Mar 20 12:58:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17887 for ipsec-outgoing; Thu, 20 Mar 1997 12:58:08 -0500 (EST) Message-Id: <199703201803.KAA00704@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 20 Mar 97 10:03:08 -0800 To: Ran Atkinson Subject: Re: the COMPRESSION discussion cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <3.0.32.19970319234159.009c34e0@earthlink.net> Sender: owner-ipsec@ex.tis.com Precedence: bulk > Those who really want to make progress on this should write up > some concrete protocol specifications in the form of an I-D, > put it online, present it to the WG in Memphis, and see whether > the WG as a whole is comfortable with that approach. Such an I-D > should try to answer the questions I've posed. > I'm confused, don't we already have such documents? (draft-sabin-esp-des3-lzs-md5-00.txt and draft-sabin-lzs-payload-00.txt) -dpg From owner-ipsec Thu Mar 20 13:09:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA18000 for ipsec-outgoing; Thu, 20 Mar 1997 13:09:10 -0500 (EST) Message-Id: <199703201813.KAA00712@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 20 Mar 97 10:13:58 -0800 To: ipsec@tis.com Subject: How about a DESX transform? Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there interest for a DESX transform? Would the introduction of such a transform be counter productive at this time? -dpg From owner-ipsec Thu Mar 20 15:59:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19234 for ipsec-outgoing; Thu, 20 Mar 1997 15:55:24 -0500 (EST) Date: Thu, 20 Mar 1997 16:00:17 -0500 (EST) From: Robert Glenn Message-Id: <199703202100.QAA26863@snad.ncsl.nist.gov> To: ipsec@tis.com Subject: New AH Transform Drafts submitted Cc: rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk I've submitted the new AH transform drafts today. They should show up at your favorite I-D place in a few days. Until then, I've made them available at: ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-md5-96-00.txt and ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt. These are to replace RFC2085 and draft-ietf-ipsec-ah-hmac-sha-04.txt. Here are some quick diffs & potential open issues. Before commenting on this message, please first read the drafts. 1. The HMAC digest is truncated to 96 bits. 2. The Replay Prevention field is a fixed 32-bits. 3. Replay Prevention is still optional BUT, if not implemented or not in use (as specified by the SA) the field remains in the packet header but is zeroed and ignored - read the spec for more details. 4. The Replay Prevention field is an up counter that starts at 1. Actually this is kept from the previous specs. The reason I mention it, is that it differs from the ESP-DES-MD5 spec. I avoided using a negotiated counter because of the complexity it adds and I'm not convinced that starting at a fixed number weakens security. I'm open to be convinced. 5. There is a pointer to a HMAC test vectors draft (forth coming with in the next day or so) that will hopefully eliminate some of the interoperability problems seen recently. There are additional changes where we tried to make things a bit more clear. Please read the drafts and provide comments. I'll re-iterate the above in Memphis and bring up additional issues that may arise between now and then. Rob G. rob.glenn@nist.gov From owner-ipsec Thu Mar 20 16:47:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00284 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:09 -0500 (EST) Message-Id: <199703202130.QAA17141@raptor.research.att.com> To: Robert Glenn cc: ipsec@tis.com, rob.glenn@nist.gov Subject: Re: New AH Transform Drafts submitted Date: Thu, 20 Mar 1997 16:30:38 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk 4. The Replay Prevention field is an up counter that starts at 1. Act ually this is kept from the previous specs. The reason I mention it, is that it differs from the ESP-DES-MD5 spec. I avoided using a negotiated counter because of the complexity it adds and I'm not convinced that starting at a fixed number weakens security. I'm open to be convinced. My issue with the replay counter applies to ESP, not AH. I know of no weaknesses here. The only possible issue is whether or not MD5 or SHA are weaker if handed large numbers of 0-bits; I suspect not with this few. From owner-ipsec Thu Mar 20 16:47:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00275 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:01 -0500 (EST) Date: Thu, 20 Mar 97 21:15:26 GMT Standard Time From: Ran Atkinson Subject: RE: the COMPRESSION discussion To: "Ferdinand N. Ahlberg" Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703201559.KAA19229@olympus.ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 20 Mar 1997 10:59:15 -0500 "Ferdinand N. Ahlberg" wrote: > So, use of compression deserves to be defined in IPSec, because, if you > encrypt at the network layer, your PPP compression will not compress the > packets. Some have argued that it is better to define a separate per-packet compression method that can be used by IPsec but is not tied directly inside the ESP packet format. Others argue that compression should be within ESP. Either approach eliminates the issue that link-layer compression is ineffective on encrypted data. > In order to harmonize the two technologies, you must compress before > encrypting. That is an argument for optional compression but it doesn't argue for or against either of the approaches that have been proposed on this list. Ran rja@inet.org From owner-ipsec Fri Mar 21 06:59:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04382 for ipsec-outgoing; Fri, 21 Mar 1997 06:57:41 -0500 (EST) Message-Id: <2.2.32.19970321013202.006df08c@trix.cisco.com> X-Sender: sned@trix.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 17:32:02 -0800 To: rmonsour@earthlink.net From: Steve Sneddon Subject: "Pillage first, then burn" - Attila the Hun Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk "Compress first, then encrypt" - Bob Monsure Bob, I have watched the IPSec mailing list debates pretty much from the sidelines so far. I am heartened by the lively debate, but disappointed by closure on key aspects of the standards effort (no slam intended against anyone). I agree with Ran - there isn't a consensus at this point. Email to the IPSec list has its place, and formal presentations have their place, but I believe you (HiFn) and I (Cisco) need to host an informal BOF-like discussion in Memphis around this topic in the hope that it can help move opinion forward. Maybe Tuesday evening would work. At that session, I propose that we discuss Cisco's results with compression in an IPSec-type environment. We have tied LZS into our client stack and are now accumulating data on what it can do for you. We should present that data to the community, even if it's in pretty raw form (which it will be!) at that time. Who knows, we may even be ready to demo a compression-enabled IPSec implementation by then (watch as five Cisco engineers slaughter me in Email for saying this...). I will also be prepared to discuss ways that Cisco can assist others with their implementations. One final point. Some people worry that working on compression now will slow down IPSec standards work. While I understand that concern, it is more than outweighed in my mind by how seriously a lack of compression would impede actual customer adoption of this technology. In fact, Cisco does not plan to release an IPSec implementation until there is a plan, which we can communicate clearly to customers, about how and when we will be doing compression in that environment. This is the result of significant customer backlash to lack of compression in our now-shipping but non-standard encryption offering. In closing, let me emphatically state my support for proper process in the IETF, and my strong desire for a standard in this important area. Thanks, Bob, for your help with this. Anybody on the IPSec list who wants to discuss this more in private is encouraged to send me private Email. \|||/ (. .) ------ooO-(_)-Ooo------------------------------------------------------------ ^^ ^^ Cisco Systems, Inc. STEVE SNEDDON .||. .||. IOS Development Director, IOS Client Tech .||||. .||||. 170 West Tasman Drive Phone: 408-527-1035 ..:||||||||:..:|||||||:.. SJ-F2 Pager: 800-365-4578 Cisco Systems Inc. San Jose, CA 95134-1706 EMAIL: sned@cisco.com ----------------------------------------------------------------------------- From owner-ipsec Fri Mar 21 07:48:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04803 for ipsec-outgoing; Fri, 21 Mar 1997 07:48:22 -0500 (EST) Message-Id: <3.0.1.32.19970321075102.0093ee10@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Mar 1997 07:51:02 -0500 To: Steve Sneddon , rmonsour@earthlink.net From: Robert Moskowitz Subject: Re: "Pillage first, then burn" - Attila the Hun Cc: ipsec@tis.com In-Reply-To: <2.2.32.19970321013202.006df08c@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:32 PM 3/20/97 -0800, Steve Sneddon wrote: >Email to the IPSec list has its place, and formal presentations have their >place, but I believe you (HiFn) and I (Cisco) need to host an informal >BOF-like discussion in Memphis around this topic in the hope that it can >help move opinion forward. Maybe Tuesday evening would work. I hope we can fit this into the main IPsec session. I seem to think I have some IAB meeting tues night. >At that session, I propose that we discuss Cisco's results with compression >in an IPSec-type environment. We have tied LZS into our client stack and are >now accumulating data on what it can do for you. We should present that data >to the community, even if it's in pretty raw form (which it will be!) at >that time. Who knows, we may even be ready to demo a compression-enabled >IPSec implementation by then (watch as five Cisco engineers slaughter me in >Email for saying this...). I will also be prepared to discuss ways that >Cisco can assist others with their implementations. Gee do I know those 5 engineers? Aren't they already very busy next week? >One final point. Some people worry that working on compression now will slow >down IPSec standards work. While I understand that concern, it is more than >outweighed in my mind by how seriously a lack of compression would impede >actual customer adoption of this technology. In fact, Cisco does not plan to >release an IPSec implementation until there is a plan, which we can >communicate clearly to customers, about how and when we will be doing >compression in that environment. This is the result of significant customer >backlash to lack of compression in our now-shipping but non-standard >encryption offering. I can do my boarder to boarder without compression, but workstation to boarder I need it or I will get slaughtered by the whole auto community. And they use heavy wheeled methods over here... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Mar 21 13:51:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07322 for ipsec-outgoing; Fri, 21 Mar 1997 13:48:28 -0500 (EST) Date: 21 Mar 97 12:50:52 -0600 Subject: Re: "Pillage first, then burn" - Attila the Hun From: "James Hughes" To: rmonsour@earthlink.net, "Steve Sneddon" Cc: ipsec@tis.com, ken@anubis.network.com, varnis@winternet.com X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Press release first, then develop" - (Name withheld by request) Again, I hesitate to answer this. I seem to see that there are people that again claim that their intentions and experiments are more valuable than product experience in a compression with encryption product. The NSC product won the Best of Show at INTEROP '95. It had compression then, and it has it now. On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon wrote: > Email to the IPSec list has its place, and formal presentations have their > place, but I believe you (HiFn) and I (Cisco) need to host an informal > BOF-like discussion in Memphis around this topic in the hope that it can > help move opinion forward. Maybe Tuesday evening would work. In my heart, I know that cisco -is- the pre-eminent vendor of eveything important and we are not. NSC does have 2+ years of experience with implementing, deploying and real traffic with products that have packet level compression and encryption. This is actual experience, not conjecture. This is also true from the legal, commercial as well as the technical areas. I find that Cisco claiming the right to lead the discussions and host such a BOF to be incredulous. > This is the result of significant customer > backlash to lack of compression in our now-shipping but non-standard > encryption offering. > In fact, Cisco does not plan to > release an IPSec implementation until there is a plan I personally find this kind of grandstanding abhorrent. To claim the high ground in the compression discussion because their customers see this as cisco problem is (in my mind) the same kind of paper tiger announcements that their encryption program did 2 years ago when several vendors were trying to make a living with existing products built on forethough, cisco was trying to freeze the market with press releases so they could play catch up. I will (again) be happy to supply real results in providing a combined compressed, replay prevented, authentic, integrity and privacy transform (as I did to the IPSEC working group in 1994 in San Jose). jim http://www.network.com/~hughes From owner-ipsec Fri Mar 21 14:04:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07444 for ipsec-outgoing; Fri, 21 Mar 1997 14:03:32 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 14:10:11 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Proposed changes to ESP (andf a little AH too) Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In working on revisions to the AH and ESP specs, we've noticed that there is an opportunity to make a change to the ESP format and processing that would simplify implementations, introduce greater consistency between AH and ESP, and offer greater protection against denial of servioce attacks. However, in setting out to revise the ESP spec, the intent was NOT to make any changes to the format (for backward compatability) and hence I am somewhat reluctant to prose such changes at this point in time. Nonetheless, I ask the WG to consider these proposed changes relative to the benefits noted above, and balance them against the cost to implementors. ESP transforms that include an anti-replay counter place this counter at the begining of the encrypted portion of the ESP payload. This motivates negotiating a random starting value for the counter (to minimize known plaintext attacks) and it creates the requirement for the AR window mechanism to deal with modular arithmetic, since the counter may wrap around the 32 bit space legitimately. Note that for AH, recent I-Ds defin ethe counter value to begin at 1, which makes life much easier. I propose to move the counter value out of the encrypted portion of the payload (it would appear immediately after the SPI), and to define it to begin at 1. This would simplify counter and counter window management and make it uniform with AH in this regard. It also allows for very fast rejection of replays by a receiver. After matching an inbound packet to an SA (using the SPI) the counter value can be checked, prior to any crypto processing. Moving the counter to this location causes the IV (if present) to appear immediately before the encrypted portion of the payload, and to be aligned on an 8-byte boundary. This offers potential (though probably minor) performance improvements for receivers, since crypto that uses explicit IVs tend to view it as an immdeiate prefix for the ciphertext. Now for a bigger change! I suggest that we reverse the order of encryption and authentication processing, when both are employed. Now, authentication processing occurs first, then encryption. This means that a receiver must decrypt then autehnticate. While most systems I have seen in the past have adopted this strategy, we are now more concerned with denial of service attacks. A likely common use of ESP is to create VPNs thorugh IPSEC implementations in security gateways. If we reverse the order of processing, then a secruity gateway can validate the integrity and authenticity of a packet befor edecrypting it, thus rejecting bogus packets faster (about twice as fast, in many instances), than if we had to decrypt then authenticate. Combined with the psoposed positional change for the counter (suggested above), we now have an ability to reject duplicate or spurious packets very quickly, providing better defense against DoS attacks. One final note re ESP formats and processing: I-Ds discussing anti-replay require support of a window size of 1, which implies strict sequencing of packets. I'd like to remove this requirement. In fact, I'd like to suggest that supporting a window size of 1 is inappropriate. The IP layer does NOT guarantee ordered delivery and by imposing strict sequencing via IPSEC we are violating a fundamental characteristic of the IP layer. Note that such sequencing could have adverse affects on TCP connections (ofrcing unnecessary retransmission), merely because of packets arrived at a security gateway out of order, due to no malicious actions. The motivation for the counter and window mechanaims was to protect against replays, not to enforce strict sequencing at the IP layer. Please respond to these proposed changes. We're submitting revised versions of AH and ESP, designed to reduce the proliferation of distinct transform documents, to meet the 3/36 cutoff. We'll put the changes I noted above in these I-Ds, but if the WG does not endorse some or all of these changes, we will quickly revise the documents and re-issue them. Presentations on these changes, and on other issues that we've encountered in the course of revising the architecture document, will be made in Memphis. I also will be sending out a message on the architecture issues next week, providing fodder for discussion prior to Memphis. The revised architecture I-D will not be ready for Memphis, because of the many issues that we want to get Wg feedback on, and because we are re-writing the document from scratch to better articulate these and other issues. Thanks in advance for your carefuyl reading and feedback, Steve From owner-ipsec Fri Mar 21 15:20:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08035 for ipsec-outgoing; Fri, 21 Mar 1997 15:17:56 -0500 (EST) Message-Id: <3.0.32.19970321122157.00919680@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Mar 1997 12:21:59 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:10 PM 3/21/97 -0500, Stephen Kent wrote: > Now for a bigger change! I suggest that we reverse the order of >encryption and authentication processing, when both are employed. Now, >authentication processing occurs first, then encryption. This means that a >receiver must decrypt then autehnticate. Steve, I understand the rationale, but want to make sure I understand exactly what you are proposing. Are you saying that in ESP, the sender would encrypt the payload and then calculate the MAC over the encrypted payload? -Bob From owner-ipsec Fri Mar 21 16:05:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08304 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970321122157.00919680@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 16:08:36 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, Yes, that is exactly what I am saying. If both encryption and authentication/integrity are selected as services, apply the encryption algorithm first, then the auth/integrity algorithm (to the ciphertext). Steve From owner-ipsec Fri Mar 21 16:05:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08303 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST) Message-Id: <199703212108.QAA01317@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Bob Monsour Cc: Stephen Kent , ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: rmonsour's message of Fri, 21 Mar 1997 12:21:59 -0800. <3.0.32.19970321122157.00919680@earthlink.net> Date: Fri, 21 Mar 1997 16:08:22 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I understand the rationale, but want to make sure I understand exactly what > you are proposing. Are you saying that in ESP, the sender would encrypt the > payload and then calculate the MAC over the encrypted payload? Normally I tend to like things which improve performance, but I don't really like this proposal, for robustness reasons; it allows errors in encryption or decryption to go undetected, while doing the MAC over the plaintext provides better assurance that the data was decrypted correctly. Consider the case where the encryption key gets smashed but the authentication key is intact .. you get authentic gibberish out of the transform instead of a hard indication that something's out of synch between the endpoints. - Bill From owner-ipsec Fri Mar 21 16:09:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08339 for ipsec-outgoing; Fri, 21 Mar 1997 16:07:50 -0500 (EST) Date: Fri, 21 Mar 1997 16:12:11 -0500 Message-Id: <9703212112.AA20804@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: ipsec@tis.com In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500, Subject: Re: Proposed changes to ESP (andf a little AH too) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 21 Mar 1997 14:10:11 -0500 From: Stephen Kent Now for a bigger change! I suggest that we reverse the order of encryption and authentication processing, when both are employed. Now, authentication processing occurs first, then encryption. This means that a receiver must decrypt then autehnticate. While most systems I have seen in the past have adopted this strategy, we are now more concerned with denial of service attacks. Hmm... there's a definite tradeoff here between the trying to prevent denial of service attacks, versus the potential traffic analysis that this allows, at least in some cases. In the case of using ESP to create VPN's through security gateways, the threat of traffic analysis doesn't really apply, since the authenticated destination will always be the other security gateway. Indeed, the traffic analysis threat isn't important if we're doing host keying for the same reason --- the low level, unauthenticated address allows for traffic analysis anyway. The only place where traffic analysis would matter would be if we did user-based keying, and we have multiple users using the same host, in a time-sharing fashion. I believe this is not going to be a likely use of IPSEC, and so I agree with Steve's recommendation. If there is any disagreement on this point, it's likely going to be because people believe that there will be a large amount of usage of both (a) user-based keying, and (b) time-sharing machines. While I could believe (a), I have trouble believing (b). - Ted From owner-ipsec Fri Mar 21 16:34:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08518 for ipsec-outgoing; Fri, 21 Mar 1997 16:30:58 -0500 (EST) Date: Fri, 21 Mar 1997 16:33:15 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703212133.QAA01890@earth.hpc.org> To: sommerfeld@apollo.hp.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703201733.KAA02818@baskerville.CS.Arizona.EDU> Subject: Re: inline keying Sender: owner-ipsec@ex.tis.com Precedence: bulk > What you're suggesting is rekeying every packet. Not at all. If the "key hash index" doesn't change, then the key doesn't change. You can keep a small (2 or 3) table of most recently used derived keys to avoid having to recompute. Hilarie From owner-ipsec Fri Mar 21 16:55:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08646 for ipsec-outgoing; Fri, 21 Mar 1997 16:50:07 -0500 (EST) Message-Id: <199703212154.QAA01422@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Theodore Y. Ts'o" Cc: Stephen Kent , ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: tytso's message of Fri, 21 Mar 1997 16:12:11 -0500. <9703212112.AA20804@dcl.MIT.EDU> Date: Fri, 21 Mar 1997 16:54:09 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > If there is any disagreement on this point, it's likely going to be > because people believe that there will be a large amount of usage of > both (a) user-based keying, and (b) time-sharing machines. While I > could believe (a), I have trouble believing (b). traditional time-sharing is indeed fading, but I think there are a number of important services with similar characteristics: - "virtual web hosting" (many web sites from different companies on one server). - application gateways/proxies (going outbound through a firewall). - multiple-layer applications (with a client, a frontend server, and a backend database). - Bill From owner-ipsec Fri Mar 21 16:56:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08629 for ipsec-outgoing; Fri, 21 Mar 1997 16:48:34 -0500 (EST) Hops: 0 Host: tis.com. Posted-Date: Fri, 21 Mar 1997 23:49:47 -0200 (GMT) Message-Id: <199703212153.XAA26081@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 23:52:56 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm all in favour of doing the encryption first and the authentication after, so that on receipt we can authenticate before we receive, but wasn't there some cryptographic argument against that sort of thing? Or was it decided back when we only had the RFC 182* transforms that in the case of cascaded transforms, we should encapsulate first with AH-MD5 and then with DES-ESP, and that carried over into the combined ESP transform? Or could it even be a carry-over back from the swIPe days (which also encrypted the authenticated packet)? /ji From owner-ipsec Fri Mar 21 17:12:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08785 for ipsec-outgoing; Fri, 21 Mar 1997 17:10:13 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703212215.OAA22300@kebe.eng.sun.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Fri, 21 Mar 1997 14:15:23 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 21, 97 02:10:11 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 > In working on revisions to the AH and ESP specs, we've noticed that Ummm, I've a quick question. Who are, "we"? I thought you (singular) were rewhacking these drafts. Are there others we (the good folks in IPsec-land) do not currently know? > there is an opportunity to make a change to the ESP format and processing > that would simplify implementations, introduce greater consistency between > AH and ESP, and offer greater protection against denial of servioce > attacks. However, in setting out to revise the ESP spec, the intent was > NOT to make any changes to the format (for backward compatability) and > hence I am somewhat reluctant to prose such changes at this point in time. Good points on the cleanup, the backward compatibility, and the implication that there is a tradeoff between the two. > Nonetheless, I ask the WG to consider these proposed changes relative to > the benefits noted above, and balance them against the cost to > implementors. My first and foremost concern is that we don't hold up this IPsec specification train any longer. We need to stop the target from moving as much as it is. Some of us have enough implementation headaches w/o changing specs. After that urgent concern, the question becomes: Is improvement worth the time and pain

that it'll take to implement said improvement? Is: >> X

It seems we have quite a few working systems already. So while time might be relatively small, pain might be high because things might be deployed already. Enough philosophy, I got shredded for that once already. ;) > I propose to move the counter value out of the encrypted portion of the > payload (it would appear immediately after the SPI), and to define it to > begin at 1. This would simplify counter and counter window management and > make it uniform with AH in this regard. It also allows for very fast > rejection of replays by a receiver. After matching an inbound packet to an > SA (using the SPI) the counter value can be checked, prior to any crypto > processing. It _seems_ very rational. How much replay-enabled code do we have out there? I personally haven't approached replay protection yet, and this seems easy enough to build. OTOH, I can't speak for my fellow implementors. Also, consider this potential attack when taking your "It also allows for very fast rejection..." sentence into account: I'm receiving ESP packets. I get packets #1, #2, and #3 from the actual source. Now assume active attacker Mallory injects an ESP packet with #4 into the flow. My "quick reject" algorithm accepts Mallory's #4, while rejecting the geniune #4 that arrives while I'm attempting to decrypt Mallory's #4. (Remember folks, some of us live in a multi-threaded, multi-processing world.) Granted, this is a denial-of-service attack, and as your paper with Voidoc (sp.?) points out, you can't shut down all denial-of-service attacks. My question is, does this attack exist with the previous method of implementing replay counters? > Now for a bigger change! I suggest that we reverse the order of > encryption and authentication processing, when both are employed. This > means that a receiver must decrypt then autehnticate. While most systems I > have seen in the past have adopted this strategy, we are now more concerned > with denial of service attacks. A likely common use of ESP is to create > VPNs thorugh IPSEC implementations in security gateways. If we reverse the > order of processing, then a secruity gateway can validate the integrity and > authenticity of a packet befor edecrypting it, thus rejecting bogus packets > faster (about twice as fast, in many instances), than if we had to decrypt > then authenticate. Combined with the psoposed positional change for the > counter (suggested above), we now have an ability to reject duplicate or > spurious packets very quickly, providing better defense against DoS > attacks. Ahhhhh, so _THAT's_ how you solve my problem mentioned above. My "quick reject" algorithm doesn't reject until auth passes/fails. Let me reiterate that this seems rational, and that as a fresh-from-scratch implementor I can build this. Let me also reiterate that there is running code out there now (I'd like to know how widely deployed, actually. It could be useful data.), and it may be not operationally painless. > One final note re ESP formats and processing: I-Ds discussing > anti-replay require support of a window size of 1, which implies strict > sequencing of packets. I'd like to remove this requirement. At the risk of sounding like a parrot, it's a nice idea, but will it break anyone's back too much? In this case, however, it really seems like it's not difficult to achieve. Replay window size is negotiated in Key mgmt., so you can just have key mgmt. reject such window replay window sizes. > We're submitting revised versions of AH and ESP, designed to reduce > the proliferation of distinct transform documents, to meet the 3/36 cutoff. That's 3/26, and while it may reduce the number of transform documents, will it reduce the number of transforms? > Presentations on these changes, and on other issues that we've encountered > in the course of revising the architecture document, will be made in > Memphis. I also will be sending out a message on the architecture issues > next week, providing fodder for discussion prior to Memphis. The revised > architecture I-D will not be ready for Memphis, because of the many issues > that we want to get Wg feedback on, and because we are re-writing the > document from scratch to better articulate these and other issues. Again, the issue of transforms vs. algorithm vectors is foremost in my head. I've envisioned an IPsec module (AH or ESP) doing as much common work as possible and only farming out the algorithm-specific stuff. With "transforms" it's not clear to me that you can farm out as little. Hard to say, and I do live in a different kernel-internals world than other implementors. I'd like resolution on that issue. Is my unit of difference a transform, or (algorithm + option) combinations? > Thanks in advance for your carefuyl reading and feedback, Hope this helps! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Fri Mar 21 17:19:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08847 for ipsec-outgoing; Fri, 21 Mar 1997 17:18:19 -0500 (EST) Message-Id: <199703212221.RAA03006@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: ji@hol.gr cc: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 23:52:56 +0200." <199703212153.XAA26081@del.tla.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 21 Mar 1997 17:21:52 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk John Ioannidis writes: > I'm all in favour of doing the encryption first and the > authentication after, so that on receipt we can authenticate before > we receive, but wasn't there some cryptographic argument against > that sort of thing? Or was it decided back when we only had the RFC > 182* transforms that in the case of cascaded transforms, we should > encapsulate first with AH-MD5 and then with DES-ESP, and that > carried over into the combined ESP transform? Back when I was still involved in the drafting of these things (long ago) I kept asking for input on the cryptographic and other desiderata for picking one or the other. I got very little feedback. I don't think the decisions was made consciously. The topic deserves a full scale discussion... Perry From owner-ipsec Fri Mar 21 18:31:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09367 for ipsec-outgoing; Fri, 21 Mar 1997 18:29:36 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9703212112.AA20804@dcl.MIT.EDU> References: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 18:23:44 -0500 To: "Theodore Y. Ts'o" From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, Even for transport mode ESP, the proposed swap of fields only exposes the packet counters, nothing else that was not expose before. The SPIs are equally visible in both cases, as are the soure and destination addresses and the IP packet IDs. Together, these pieces of data provide me with enough info to do a good job of TA, exclusive of the counter info. So, I'm not sure that I understand why you feel that the exposure of the packet counters represents much of an aid to traffic analysis. Steve From owner-ipsec Fri Mar 21 18:32:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09387 for ipsec-outgoing; Fri, 21 Mar 1997 18:31:06 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 18:26:41 -0500 To: Bill Sommerfeld From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You are right that an error that occurs during decryption will not be detected by this reversed ordering of the operations. However, the purpose of the authentication/integrity service in IPSEC is to detect malicious modification of the data, not to protect against errors that might occur during protocol processing within IPSEC. Such errors copuld also occur after both operations were completed, irrespective of the order of processing, and thus would be undetected by the IPSEC module. Yes, an encryption key mismatch would not be detected under the proposed processing order, but I expect the encryption and authentication keys for ESP will be derrived algorithmically from a common source, e.g., as described in Jim Hughes I-D. In such cases, it would be unlikely for the sort of error you describe to occur. I admit there is a greater chance of this for manually configured keys, but since this would trash all incoming traffic over the Sa in question, this should be an easy error to track down. Steve From owner-ipsec Fri Mar 21 18:51:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09476 for ipsec-outgoing; Fri, 21 Mar 1997 18:49:43 -0500 (EST) Message-ID: <33331FCD.2781@cs.umass.edu> Date: Fri, 21 Mar 1997 18:54:53 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: Proposed changes to ESP (andf a little AH too) References: <199703212108.QAA01317@thunk.ch.apollo.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: [re: ciphertext = MAC(encrypt(plaintext))] > Normally I tend to like things which improve performance, but I don't > really like this proposal, for robustness reasons; it allows errors in > encryption or decryption to go undetected, while doing the MAC over > the plaintext provides better assurance that the data was decrypted > correctly. The optional preliminary "sanity check" of the decrypted replay counter value (in e.g. draft-...-esp-3des-md5-00) still could be used to detect most encryption/decryption errors, provided the counter remains inside the encrypted portion and randomly initialized. This would represent an intermediate approach between the current method and the revised one proposed by Steve K. (et al. ?). Fake packets could be detected relatively quickly, as per Steve, but replays would still take longer to notice, as per the status quo. Presumably the sanity check would change from optional to required or recommended. -Lewis From owner-ipsec Fri Mar 21 18:55:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09521 for ipsec-outgoing; Fri, 21 Mar 1997 18:53:44 -0500 (EST) Date: Fri, 21 Mar 1997 18:58:55 -0500 Message-Id: <9703212358.AA20912@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 18:23:44 -0500, Subject: Re: Proposed changes to ESP (andf a little AH too) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, My mistake. I had assumed that the AH SPI was encrypted, and was therefore not visible. It sounds like I was mistaken. - Ted From owner-ipsec Fri Mar 21 19:12:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09598 for ipsec-outgoing; Fri, 21 Mar 1997 19:10:48 -0500 (EST) Message-ID: <333324BE.794B@cs.umass.edu> Date: Fri, 21 Mar 1997 19:15:58 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little AH too)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > One final note re ESP formats and processing: I-Ds discussing > anti-replay require support of a window size of 1, which implies strict > sequencing of packets. I'd like to remove this requirement. In fact, I'd > like to suggest that supporting a window size of 1 is inappropriate. Do you have a recommendation for the replacement mandatory-to-implement window size, instead of 1? To minimize disruption, we might upgrade size=32 from recommended to mandatory-to-implement. -Lewis From owner-ipsec Fri Mar 21 21:44:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA10289 for ipsec-outgoing; Fri, 21 Mar 1997 21:42:09 -0500 (EST) Date: Sat, 22 Mar 97 02:38:59 GMT Standard Time From: Ran Atkinson Subject: Re: "Pillage first, then burn" - Attila the Hun To: Steve Sneddon Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970321013202.006df08c@trix.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, If you are interested in working within the process, constructive steps towards consensus would include: -- NOT holding a separate meeting. -- writing up cisco's proposal for compression with IPsec as an I-D and submitting it before the I-D cutoff before Memphis. -- presenting that specific proposal to the IPsec WG in the usual IPsec meeting so that everyone can consider it openly (I also anticipate other compression proposals to be presented in the IPsec WG meetings). For item 3, you'd need to send email to Paul Lambert (copy to me) asking for agenda time, providing a topic, and giving a presentation estimate so Paul can schedule accordingly (Paul mostly takes care of the meetings :-). Best wishes, Ran rja@inet.org From owner-ipsec Sat Mar 22 10:17:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13406 for ipsec-outgoing; Sat, 22 Mar 1997 10:13:22 -0500 (EST) Message-Id: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Date: Sat, 22 Mar 1997 10:17:41 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> ESP transforms that include an anti-replay counter Stephen> place this counter at the begining of the encrypted Stephen> portion of the ESP payload. This motivates negotiating a Stephen> random starting value for the counter (to minimize known Stephen> plaintext attacks) and it creates the requirement for the Stephen> AR window mechanism to deal with modular arithmetic, Stephen> since the counter may wrap around the 32 bit space Stephen> legitimately. Note that for AH, recent I-Ds defin ethe Stephen> counter value to begin at 1, which makes life much Stephen> easier. I propose to move the counter value out of the Stephen> encrypted portion of the payload (it would appear Stephen> immediately after the SPI), and to define it to begin at Forgive me for not being a cryptographer: but isn't the SHA+AH+reply draft flawed in not including the replay counter in the authenticated data? It seems that the ESP anti-reply counter is properly placed to me. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMzP4DqZpLyXYhL+BAQGyzQL/XLrmjbQWECxOeIeA0E81zfr3qYXLPPhF A78qwqBgXeX69huwMqmYnGQORe1riuP1sw6X5mVhzjf3qMxKNDeZtLXboB+R+jj3 SBcnVWMQpXVCaEKzbcZ15nG2+7WDEyI5 =WS+q -----END PGP SIGNATURE----- From owner-ipsec Sat Mar 22 11:40:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13740 for ipsec-outgoing; Sat, 22 Mar 1997 11:38:23 -0500 (EST) Message-Id: <2.2.32.19970322165101.00b92a24@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: Sat, 22 Mar 1997 11:51:01 -0500 To: Stephen Kent From: Naganand Doraswamy Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I like your idea of starting the replay counter with 1. I think we should adopt it. With respect to doing authentication first and then encryption, in terms of implementation it is not a very big change. I am not a cryptographer but it looks like the processing involed with bad packets is lesser in the scheme you are proposing. I dont know of vendor who has a product out in the market supporting the combined transform. So if we decide to do this, this HAS to be decided at Memphis. Many of us are almost ready to release products in the next 3-4 months timeframe and once we have products out there, it becomes a real pain if there is a fundamental change in the transform. I will support this provided we can reach a decision in Memphis. Regarding the window size, I think it is upto the implementation. I have always seen window size as something that should not be negoatiated and is entirely upto the receiver to decide the size. If the receiver chooses a window size of 1, they in all probability they may drop quite a few packets. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Sat Mar 22 14:44:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14480 for ipsec-outgoing; Sat, 22 Mar 1997 14:41:28 -0500 (EST) Message-Id: <3.0.16.19970322144254.1d1721aa@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sat, 22 Mar 1997 14:46:55 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Who is ELVIS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is not a joke. Sorry but I couldn't resist that subject line, as I stare at my Memphis IETF Hotel reservation, where the price goes UP for Saturday night (to $219) apparently due to tourists who come into town to see Graceland. On the IPsec survey I see two implementations I don't have new or old entries for. These are listed in the section where people report what other implementations they have interoperated with. One is "Elvis" and one is "SOS". What are these? -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sat Mar 22 14:53:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14507 for ipsec-outgoing; Sat, 22 Mar 1997 14:50:59 -0500 (EST) Message-Id: <1.5.4.16.19970322195558.0bf7ea44@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 14:55:58 -0500 To: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com From: "David P. Jablon" Subject: Re: Last Call: The resolution of ISAKMP with Oakley to Proposed Standard Cc: ipsec@tis.com, iesg@ietf.org Sender: owner-ipsec@ex.tis.com Precedence: bulk Douglas, Mark, Jeff, and Mark, In draft-ietf-ipsec-isakmp-07.txt, there is some some seriously misleading information in the initial discussion of strong and weak authentication. I've included a reworded paragraph that corrects this problem. Here's the offending paragraph: | 1.5 Authentication | | A very important step in establishing secure network communications is au- | thentication of the entity at the other end of the communication. Many | authentication mechanisms are available. Authentication mechanisms fall | into two catagories of strength - weak and strong. | [So far so good, except for "categories"] Passwords are an ex- | ample of a mechanism that provides weak authentication. ... This is wrong. Passwords are not a mechanism. They're just a factor in establishing identity, like stored secret keys, private keys, fingerprints, or faces. Strong password protocols exist, and passwords are important for strong network authentication. Yes, many bad ways to use passwords have been implemented and deployed. Yes, there's a lot of misinformation about passwords out there. But let's not propagate more of it. | ... The reason pass- | words are considered weak is the fact that most users pick passwords that | are easy to guess and when used over an unprotected network are easily | read by network sniffers. ... This is poorly worded. If you're talking about off-line dictionary attack on the sniffed messages, strong password methods are immune to this. There are also good ways to generate large-enough (for strong methods) passwords with deterministic entropy that are easily memorized, and for preventing on-line guessing attacks. Sending clear-text passwords or keys is a weak mechanism. Sending passwords or keys in easily decrypted form is weak. Sending small passwords in a one-way hashed form that permits eavesdropper dictionary attack is weak. Password-authenticated key exchange is strong, and there are at least three ways to do this. They are all as strong as the more commonly known digital signature approaches, when properly used, and can provide added benefits in many applications, due to decreased need for stored keys or certificates. As I understand ISAKMP, passwords aren't suitable here mainly because users are not actively involved in the authentication process. So the keys have to be stored anyway, and thus there is no good reason not to use *large* keys. This makes your condemnation of password-based mechanisms even more inappropriate. Here's a suggested rewording of the paragraph: | 1.5 Authentication | | A very important step in establishing secure network communications is au- | thentication of the entity at the other end of the communication. Many | authentication mechanisms are available. Authentication mechanisms fall | into two categories of strength - weak and strong. | Sending clear-text keys over a network is weak, | due to the threat of reading them with a network sniffer. | Sending one-way hashed poorly-chosen keys with low-entropy is | also weak, due to the added threat of brute-force guessing | attack on the sniffed messages. Digital signatures [... etc.] Thanks. -- David > The IESG has received a request from the IP Security Protocol Working > Group to consider the following Internet-Drafts for the status of > Proposed Standard: > > o The resolution of ISAKMP with Oakley > > o Internet Security Association and Key Management Protocol (ISAKMP) > > o The Internet IP Security Domain of Interpretation for ISAKMP > > > 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 March 28, 1997 > >Files can be obtained via ftp://ds.internic.net/internet-drafts/ ------------------------------------ David P. Jablon Integrity Sciences, Inc. Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Sat Mar 22 15:12:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14609 for ipsec-outgoing; Sat, 22 Mar 1997 15:10:00 -0500 (EST) Message-Id: <199703222014.MAA24591@dharkins-ss20> 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: Who is ELVIS? In-Reply-To: Your message of "Sat, 22 Mar 1997 14:46:55 EST." <3.0.16.19970322144254.1d1721aa@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 12:14:52 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Elvis not only left the building, he left the country. You can visit him at http://www.elvis.ru (it helps if you have KOI-8). > On the IPsec survey I see two implementations I don't have new or old > entries for. These are listed in the section where people report what > other implementations they have interoperated with. One is "Elvis" and one > is "SOS". > > What are these? Elvis is a SKIP implementation from Russia. Dan. From owner-ipsec Sat Mar 22 15:24:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14661 for ipsec-outgoing; Sat, 22 Mar 1997 15:20:02 -0500 (EST) Message-Id: <3.0.16.19970322152445.2a07148e@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sat, 22 Mar 1997 15:25:16 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec Survey Results, March 1997 [rev 1] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I have gathered the survey results at this URL: . Thanks to FTP Software for hosting this. Please check for errors. There are 28 implementations listed. I'll update this periodically as I get more responses. -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sat Mar 22 18:11:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15417 for ipsec-outgoing; Sat, 22 Mar 1997 18:02:44 -0500 (EST) Message-Id: <199703222307.PAA24653@dharkins-ss20> 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: IPsec Survey Results, March 1997 [rev 1] In-Reply-To: Your message of "Sat, 22 Mar 1997 15:25:16 EST." <3.0.16.19970322152445.2a07148e@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 15:07:54 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, Please update ftp://research.ftp.com/pub/ipsec/results.htm for the cisco IOS entry to the following: Name of Implementation: cisco IOS (TM) Organisation: cisco Systems Which IP versions are supported: IPv4 & IPv6 in progress Implemented Features: AH (RFC-1825,1826): yes ESP (RFC-1825,1827): yes AH MD5 (RFC-1828): yes ESP DES (RFC-1829): yes Other implemented AH transforms: AH-HMAC-MD5 & AH-HMAC-SHA Other implemented ESP transforms: ESP-DES-MD5-Replay Key Management: ISAKMP+Oakley (v6 and v2, v7 and v3 in progress) Platforms: cisco Lineage of IPsec Code: cisco Systems Lineage of Key Mgmt Code: cisco Systems Location of Source Code: proprietary Point of Contact: Cheryl Madson > Thanks to FTP Software for hosting this. Yes, thanks! Dan. From owner-ipsec Sat Mar 22 19:08:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15660 for ipsec-outgoing; Sat, 22 Mar 1997 19:03:52 -0500 (EST) Hops: 0 Host: sabletech.com. Posted-Date: Sun, 23 Mar 1997 02:05:13 -0200 (GMT) Message-Id: <199703230008.CAA08137@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: Who is ELVIS? In-reply-to: Your message of "Sat, 22 Mar 1997 14:46:55 EST." <3.0.16.19970322144254.1d1721aa@pop3.pn.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Mar 1997 02:08:20 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk [[ intentionally Cc'ed to the whole list ]] > On the IPsec survey I see two implementations I don't have new or old > entries for. These are listed in the section where people report what > other implementations they have interoperated with. One is "Elvis" and one > is "SOS". > > What are these? > I don't know about Elvis, but SOS refers to my (JI) implementation for BSDI, presented at the December '95 IETF in Dallas. /ji From owner-ipsec Sun Mar 23 13:24:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19988 for ipsec-outgoing; Sun, 23 Mar 1997 13:16:59 -0500 (EST) From: Uri Blumenthal Message-Id: <9703231820.AA24783@hawpub.watson.ibm.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: ji@hol.gr Date: Sun, 23 Mar 1997 13:20:53 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at Mar 21, 97 11:52:56 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 John Ioannidis says: > I'm all in favour of doing the encryption first and the authentication > after, so that on receipt we can authenticate before we receive, but > wasn't there some cryptographic argument against that sort of thing? The main argument against doing encryption first and auth second would be - generally speaking there is no guarantee even if you verified the CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same as was sent. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Sun Mar 23 15:04:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20357 for ipsec-outgoing; Sun, 23 Mar 1997 14:59:37 -0500 (EST) Message-Id: <3.0.16.19970323150234.2987aab4@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sun, 23 Mar 1997 15:04:42 -0500 To: uri@watson.ibm.com From: Rodney Thayer Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Would that mean that a transform combination of (outer AH, ESP, and inner AH) be useful? Or, of course, AH and ESP-with-authentication. At 01:20 PM 3/23/97 -0500, you wrote: >John Ioannidis says: >> I'm all in favour of doing the encryption first and the authentication >> after, so that on receipt we can authenticate before we receive, but >> wasn't there some cryptographic argument against that sort of thing? > >The main argument against doing encryption first and auth second would >be - generally speaking there is no guarantee even if you verified the >CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same >as was sent. >-- >Regards, >Uri uri@watson.ibm.com >-=-=-=-=-=-=- > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sun Mar 23 16:59:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20848 for ipsec-outgoing; Sun, 23 Mar 1997 16:53:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca> References: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 14:56:05 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, Both AH and ESP encompass the anti-replay counter within the scope of the authentication/integrity calculation. Steve From owner-ipsec Sun Mar 23 18:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21175 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9703231820.AA24783@hawpub.watson.ibm.com> References: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at Mar 21, 97 11:52:56 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 18:02:25 -0500 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, Just an observation about the encrypt-then-authentication (outbound) approach. When AH and ESP were initially defined, ESP provided only encryption. To achieve the combined authentication and encrypt function that was later added to ESP transforms, one would have to employ both AH and ESP. The architecture document does not recommend against applying ESP first and then adding AH, and I have seen many examples based on this ordering of these transforms. Thus, in reversing the order of the algorithm processing as I have suggested, one has a function analogous (though not exactly equivalent) to what has been proposed and advertized as a reasonable application of AH and ESP in the IPSEC context. You are right, of course, that the "outer" authentication computation verifies the ciphertext, not the underlying plaintext. However, the recipient has negotiated both the key and the encryption algorithm used to transform the ciphertext into plaintext, and we are requiring PFS for the key management algorithms. So, a number of tricks that one might attempt to undermine the binding between the ciphertext and plaintext should be thwarted. Also, we are talking about authentication and integrity, not non-repudiation, here, so some other forms of attacks that might be of concern in the NR context don't apply either. Given these caveats, do you feel that the proposed re-ordering of the processing steps (and associated syntax changes) poses a concern? If so, could you provide an example of the sort of attack that we would be subject to under this proposed re-ordering? Thanks, Steve From owner-ipsec Sun Mar 23 18:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21176 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:21 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703212215.OAA22300@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 21, 97 02:10:11 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 17:36:13 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, The "we" working on the revisions include two folks from my network security departement at BBN (Karen Seo and Nina Yuan), plus Charlie Lynn, a protocol expert who has been involved in Nimrod, IPv6, host requirements and many other TCP/IP activities at BBN for over 15 years. Nina will be at Memphis (I have a prior engagement in Singapore) to brief the AH and ESP I-Ds, plus to go over some of the architecture document open issues. I agree with your observation that we have to look at every proposed change to AH and ESP with an eye toward the percieved benefit and to the cost (including time to market) for vendors. However, in working on the architecture document, we have uncovered a lot of issues that have not been well addressed to date, and I suspect that resolving these issues will actually cause more potential delays than the format changes we're looking at for AH and ESP. For example, the list had a brief discussion of PMTU and DF bit conventions, but our analysis has come up with a pretty good rationale for what various implementations should do, and when. Also, the currently posted architectuire I-D calls for being able to use a variety of IP header fields (and TCP/UDP port fields) as selectors for defining SAs or nested sets of SAs (I like the term "SA bundle" as suggested earlier). Yet, I have not seen any implementations that support these features, so far, even though the I-D has been out for over 6 months. As for the window size issue, I agree that one can simply decline to negotiate a size of 1, as a means of addressing this issue. However, I really believe that a size of 1 is so awful that it ought not be allowed. Moreover, only a size of 1 is proposed as required so far, and if we say dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) instead. So, that's why I'd like to change to make 32 a MUST support, and multiples of 32 be recommemded optional window sizes. Your question about tranform document vs. transforms deserves a thoughtful reply. The revised specs (its more of an issue for ESP, but it applies to AH as well) will contain the details for (optional) anti-replay counter management. They also will describe how to do (optional) HMAC computation, with appropriate references to base spec by Hugo. There will be a definition of the required padding technique for ESP. Default algorithms will be cited and referred to via base algorithm specs. The goal is to no longer have "transform" documents, but only these specs and algorithm documents. In that sense, the number of transforms will diminish, since we will have made the combinations of algorithms and processing morr modular. However, one will still need to negotiate "transforms" as part of SA management, and it's up to the Wg to decide how many of these MUST be supported, vs. ones that MAY be supported, etc. So, I do think my goal is consistent with yours, in that I hope to have algorithms plus options within each protocol. One selects the combinations of algorithms and options via SA management, and we have chosen to label the bundled combinations "transforms." Steve P.S. I hope this explanation lays to rest any rumors about the demise of AH. I do see a diminished role for AH once we have ESP implementations that support encryptionless SAs, but there will still be uses for AH. From owner-ipsec Sun Mar 23 18:26:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21241 for ipsec-outgoing; Sun, 23 Mar 1997 18:21:51 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 18:22:09 -0500 To: Ran Atkinson From: Stephen Kent Subject: Re: the COMPRESSION discussion Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, I think that we can make provision for compression in ESP, while deferring some of the issues you raised. For example, we already allow the definition of additional encryption and authentication algorithms, in addition to having define defaults that must be implemented. For compression, we could hold off on defining a MUST implement default, and thus rely on specific choices that are defined later. I admit that this is not the preferred approach, and it certainly does not promote interoperability as well as the tack we have taken with encryption and authentication algorithms so far, but it is a start. We have debated the question of at what processing layer to implement compression and there is agreement that one cabn do it at various layers, with differing benefits. But, the issue for us is not that more general one, but rather do we wish to provide for optional compression in the context of ESP. I agree with Bob and others that the responses on the list suggest that there is asubstantial support for this as an optional feature, to be negotiated on a per-SA basis. Support for arbitrary algorithms is a good goal, but operating in the IP layer, we have to limit ourselves to algorithms that do not rely on ordered delivery. I think that we understand the limitations on the methods that will work in our context, and those become constraints on applicable algorithms. It does not seem appropriate to require than any compression algortihm be a candiadte for IPSEC ESP use. Only ones that are fairly stateless should be candidates, given the out-of-order arrival and packet loss that are characteristics of IP layer traffic. I agree with most of your proposed process for dealing with this issue, and hope that we will receive submissions on specific, detailed proposals. However, I also believe that Bob has provided the necessary details that are sufficient for mods to the ESP spec, to accommodate a range of compression options and that we can add this to a later version of the ESP I-D with little or no effort. I do not agree with the suggestion to explore whether this is a generic IP layer issue vs. just an ESP issue. If we really want to make progerss on this, and meet the well-articulated needs of folks like Bob Moskowitz, I think we must plan on putting compression into IPSEC, since it is the use of ESP that especially motivates the need for compression as a compensating factor. So, I'd like to see us proceed as follows to add compression to our specs, if the WG agrees: - have the architecture document describe the optional use of compression within ESP, to be negotiated on a per-SA basis - define in the relevant ISAKMP documents how to negotiate compression - set aside the high order bit from the ESP padding field to indicate if compression has been applied to an individual packet - define in ESP the scope of compression and any alignment considerations applicable to the use of compression - define compression algorithms for ESP use in separate base documents, which can have backpointers to the architecture, ESP, and ISAKMP docs Steve From owner-ipsec Sun Mar 23 22:15:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22243 for ipsec-outgoing; Sun, 23 Mar 1997 22:10:10 -0500 (EST) From: Uri Blumenthal Message-Id: <9703240315.AA280941@hawpub.watson.ibm.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Sun, 23 Mar 1997 22:15:13 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 23, 97 06:02:25 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 Stephen Kent says: > You are right, of course, that the "outer" authentication > computation verifies the ciphertext, not the underlying plaintext. Of course. (:-) > However, the recipient has negotiated both the key and the encryption > algorithm used to transform the ciphertext into plaintext, and we are > requiring PFS for the key management algorithms....Also, we are talking > about authentication and integrity, not non-repudiation, here....... Yes, I understand that. > Given these caveats, do you feel that the proposed re-ordering of > the processing steps (and associated syntax changes) poses a concern? If > so, could you provide an example of the sort of attack that we would be > subject to under this proposed re-ordering? 1. I'm not sure. As you might have noticed, that same approach is adopted by SNMP Security (encrypt the body first, then authenticate the whole package), and similar arguments were made (wrt. who cares about non- repudiation etc.). Of course it's a reasonable assumption, that if both sides have the same encryption algorithm/key and the ciphertext is authentic, then the plaintext will also match. And *if* you can guarantee that the keys are indeed intact on both ends, *probably* the approach will work OK. 2. I don't have [at this moment] an example of how to break this encrypt-first-auth-second scheme. But I haven't really thought about it, and there are others more clever than me wrt. crypto attacks on the algorithms and protocols. 3. I basically tried to simply answer the question posted: what's the difference wrt. the order of the operations. Crypto people, am I the only one who is not 100% comfortable with this order of the operations? Can *you* think of an attack? What would be the assumptions for such an attack to succeed? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Sun Mar 23 22:46:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22414 for ipsec-outgoing; Sun, 23 Mar 1997 22:42:43 -0500 (EST) Message-Id: <199703240346.WAA15658@raptor.research.att.com> To: uri@watson.ibm.com cc: kent@bbn.com (Stephen Kent), ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) Date: Sun, 23 Mar 1997 22:46:32 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Crypto people, am I the only one who is not 100% comfortable with this order of the operations? Can *you* think of an attack? What would be the assumptions for such an attack to succeed? Kent's approach defeats Wagner's short-block guessing attack (described in my paper ftp://ftp.research.att.com/dist/smb/badesp.ps). This is precisely because it does protect the ciphertext. My discomfort is due solely to the fact that I want these transforms standardized *now*. Anything that delays them is no good. From owner-ipsec Mon Mar 24 01:03:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23092 for ipsec-outgoing; Mon, 24 Mar 1997 00:57:27 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703240602.WAA06987@kebe.eng.sun.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Sun, 23 Mar 1997 22:02:36 -0800 (PST) Cc: Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 23, 97 05:36:13 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 > For example, the list had a brief discussion of PMTU and DF bit > conventions, but our analysis has come up with a pretty good rationale for > what various implementations should do, and when. I remember this discussion. I'm looking forward to seeing what you have to say on this topic. (IMHO, the only big issue I see on this front is that transport sessions (i.e. TCP) should be informed to ratchet down their MSS when/if using IPsec. This passing of information can be difficult in certain circumstances.) > Also, the currently posted architectuire I-D calls for being able to use a > variety of IP header fields (and TCP/UDP port fields) as selectors for > defining SAs or nested sets of SAs (I like the term "SA bundle" as > suggested earlier). Yet, I have not seen any implementations that support > these features, so far, even though the I-D has been out for over 6 months. Previous work has suggested that for outbound packets and their SAs, the "per-endpoint" abstraction works well. This same previous work, however, does not cover tying inbound SAs to an endpoint. I have some ideas, but I look forward to learning other approaches to the problem. > So, that's why I'd like to change to make 32 a MUST support, and multiples > of 32 be recommemded optional window sizes. My current experience with replay is limited, hence I do not feel qualified to comment on this just now. I look at it as something new to learn. :) > Your question about tranform document vs. transforms deserves a > thoughtful reply. It's a tricky question that affects: 1.) Key management * What do I negotiate? * What allows better policy definitions? 2.) AH and ESP code * What abstraction to my kernel-loadable modules implement? * What allows better policy definitions? 3.) APIs for both key management and endpoint security * What do I offer to the user or key management programs? * How do I manually administer such things? > However, one will still need to negotiate "transforms" as part of SA > management, and it's up to the Wg to decide how many of these MUST be > supported, vs. ones that MAY be supported, etc. > One selects the combinations of algorithms and options via SA management, > and we have chosen to label the bundled combinations "transforms." Okay. > I hope this explanation lays to rest any rumors about the demise of AH. I > do see a diminished role for AH once we have ESP implementations that > support encryptionless SAs, but there will still be uses for AH. There are plenty of uses for AH, even with encryptionless ESP. These include (in order of importance): 1.) Use of certain IP/IPv6 options w/o having to encapsulate them. Source routing is the foremost example that comes to my mind. These options, while used hop-by-hop, only need to be really authenticated end-to-end. 2.) AH has been sucessfully exported. I'm under the impression that ESP is "encryption-enabling" as per dain-bramaged U.S. export control law. 3.) Given the way IPv6 handles its payloads and options in discrete next-header units, AH fits in better (IMHO) with IPv6 processing. Thanks for the reply, and see you in Memphis! Dan From owner-ipsec Mon Mar 24 01:04:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23103 for ipsec-outgoing; Mon, 24 Mar 1997 00:59:26 -0500 (EST) Message-ID: <3336197C.2847@cs.umass.edu> Date: Mon, 24 Mar 1997 01:04:44 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: Proposed changes to ESP (andf a little AH too) References: <9703240315.AA280941@hawpub.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > 2. I don't have [at this moment] an example of how to break this > encrypt-first-auth-second scheme. Let me just toss in another observation on this operation ordering. Compared to auth-then-encrypt, I think this order technically makes it easier to compile a set of plaintext/ciphertext pairs, because it moves a potential entropy source outside the encryption. Suppose the replay counter is shifted outside the encryption as suggested. If an attacker can choose payload data & type values that require no padding, then all the plaintext input to the encryption transform is known, and of course the resulting ciphertext can be observed. On the other hand, with the auth-then-encrypt ordering, the HMAC digest forms part of the plaintext input to the encryption transform. The attacker presumably can't choose the HMAC digest value, and _may_ be unable to verify it at the receiver. Thus the complete plaintext corresponding to an observed ciphertext may not be as readily available to the attacker. (It also may be easier under some circumstances for the attacker to verify unpadded payload data & type values than HMAC digest values, at the receiver, even when nothing is chosen. The HMAC digest is much less interesting to higher protocol layers than is the payload, after the receiver performs its authentication check.) -Lewis From owner-ipsec Mon Mar 24 08:26:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25427 for ipsec-outgoing; Mon, 24 Mar 1997 08:23:32 -0500 (EST) Date: Mon, 24 Mar 1997 08:23:32 -0500 (EST) Message-Id: <199703241323.IAA25427@portal.ex.tis.com> To: "James Hughes" From: Steve Sneddon Subject: Re: "Pillage first, then burn" - Attila the Hun Cc: rmonsour@earthlink.net, ipsec@tis.com, ken@anubis.network.com, varnis@winternet.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:50 PM 3/21/97 -0600, James Hughes wrote: >"Press release first, then develop" - (Name withheld by request) OK, I admit, you made me :=). > >Again, I hesitate to answer this. > >I seem to see that there are people that again claim that their intentions >and experiments are more valuable than product experience in a compression >with encryption product. The NSC product won the Best of Show at INTEROP >'95. It had compression then, and it has it now. Then I hope we can figure out a way to work together toward the goal of getting standards in this area. Let's discuss any commercial issues outside of the IETF list. > >On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon wrote: >> Email to the IPSec list has its place, and formal presentations have >their >> place, but I believe you (HiFn) and I (Cisco) need to host an informal >> BOF-like discussion in Memphis around this topic in the hope that it can >> help move opinion forward. Maybe Tuesday evening would work. > >In my heart, I know that cisco -is- the pre-eminent vendor of eveything >important and we are not. NSC does have 2+ years of experience with >implementing, deploying and real traffic with products that have packet >level compression and encryption. This is actual experience, not >conjecture. This is also true from the legal, commercial as well as the >technical areas. > >I find that Cisco claiming the right to lead the discussions and host such >a BOF to be incredulous. I said an "informal BOF-like discussion". I have something very informal and totally unofficial and off the record in mind. We'll have plenty of occasion for real sessions at the official meeting. If you want to help lead it, great. I'll find the hall, and you can bring the pizza. :=) [The rest of this message is best answered off the mailing list. I'll send you private mail.] From owner-ipsec Mon Mar 24 08:30:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25497 for ipsec-outgoing; Mon, 24 Mar 1997 08:29:34 -0500 (EST) Date: Mon, 24 Mar 1997 08:29:34 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199703241329.IAA25497@portal.ex.tis.com> To: lmccarth@cs.umass.edu (Lewis McCarthy) cc: ipsec@tis.com (IPsec Mailing List) Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little AH too)) Date: Sun, 23 Mar 1997 11:14:46 -0800 From: Derrell Piper Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk The size of the replay window should be implementation defined. There's nothing you can do in the protocol to force the other end to honor any particular window size, so you might as well let him choose one that's efficient for his particular kernel/architecture. On 32-bit systems, this will probably be 32, and on Alpha, 64. Steve Kent suggested in Montreal that the size might want to be negotiated so that the initiator has some way to indicate to the receiver the anti-replay size that he believes might be most appropriate. I think this adds unnecessary complexity, but I could support this if it's worded appropriately. In the past, it has been worded as if increasing the size of the replay detection window somehow weakens the anti-replay protection. Derrell > Do you have a recommendation for the replacement mandatory-to-implement > window size, instead of 1? To minimize disruption, we might upgrade > size=32 from recommended to mandatory-to-implement. > >-Lewis From owner-ipsec Mon Mar 24 10:16:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27000 for ipsec-outgoing; Mon, 24 Mar 1997 10:16:00 -0500 (EST) Message-Id: <97Mar24.102209est.11650@elgreco.rnd.border.com> To: "James Hughes" cc: "Steve Sneddon" , ipsec@tis.com Subject: Vendor Interests (was Re: "Pillage first, then burn" - Attila the Hun) References: In-reply-to: hughes's message of "Fri, 21 Mar 1997 13:50:52 -0500". From: "C. Harald Koch" Date: Mon, 24 Mar 1997 10:20:45 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "James Hughes" writes: > > I find that Cisco claiming the right to lead the discussions and host such > a BOF to be incredulous. I assume that everyone participating in this discussion is an individual, and not a mindless slave to their employer's desires. It's certainly the case that at each IETF meeting, the participants remain the same while the "company names" on people's badges keep changing; this would support my assumption. -- Harald Koch From owner-ipsec Mon Mar 24 10:45:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3336197C.2847@cs.umass.edu> References: <9703240315.AA280941@hawpub.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:46:42 -0500 To: Lewis McCarthy From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: IPsec Mailing List Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis, It is true that moving the counter and the HMAC outside of the encryption boundary does remove a source of unpredictable plaintext from the message. However, the HMAC is at the end of the message, and the use of an IV in feedback modes is designed to provide an unpredictable starting point for the encryption process. If the contents of the message are predictable, as suggested, then there typically will be enough plaintext to support a known plaintext attack irresepctive of the posotioning of the counter value. See Steve Bellovin's recent paper (in the Proceedings of the Symposium on Network and Distributed System Security, Feb 97) analyzing such attacks in a typical IP/TCP context. Steve From owner-ipsec Mon Mar 24 11:16:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3336197C.2847@cs.umass.edu> References: <9703240315.AA280941@hawpub.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:46:42 -0500 To: Lewis McCarthy From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: IPsec Mailing List Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis, It is true that moving the counter and the HMAC outside of the encryption boundary does remove a source of unpredictable plaintext from the message. However, the HMAC is at the end of the message, and the use of an IV in feedback modes is designed to provide an unpredictable starting point for the encryption process. If the contents of the message are predictable, as suggested, then there typically will be enough plaintext to support a known plaintext attack irresepctive of the posotioning of the counter value. See Steve Bellovin's recent paper (in the Proceedings of the Symposium on Network and Distributed System Security, Feb 97) analyzing such attacks in a typical IP/TCP context. Steve From owner-ipsec Mon Mar 24 11:22:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00405 for ipsec-outgoing; Mon, 24 Mar 1997 11:20:44 -0500 (EST) From: Hsin Fang Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST) Message-Id: <199703241623.LAA06124@emu.ncsl.nist.gov> To: kent@bbn.com Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, In your 23 Mar 1997 note, you wrote: > As for the window size issue, I agree that one can simply decline > to negotiate a size of 1, as a means of addressing this issue. However, I > really believe that a size of 1 is so awful that it ought not be allowed. > Moreover, only a size of 1 is proposed as required so far, and if we say > dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) > instead. So, that's why I'd like to change to make 32 a MUST support, and > multiples of 32 be recommemded optional window sizes. I can understand that mandatory window size of 1 is not a good idea: it force to drop every single out-of-order packet. But I don't see any good reason to force the window size to be 32*X (X >= 1). Shouldn't people be allowed to pick up any smaller number, let us say 8 or 16, as best fit their application? Window size of 32*X when X>=2 is quite big to me considering that it is a per destination/per security association figure. Regards, Hsin From owner-ipsec Mon Mar 24 11:22:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00391 for ipsec-outgoing; Mon, 24 Mar 1997 11:19:14 -0500 (EST) To: IETF-Announce:; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-96-00.txt Date: Mon, 24 Mar 1997 09:58:17 -0500 Message-ID: <9703240958.aa24177@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 Security Protocol Working Group of the IETF. Title : HMAC-MD5-96 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-96-00.txt Pages : 8 Date : 03/21/1997 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [RFC-2104]. A replay prevention field is also specified. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-md5-96-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-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-ipsec-ah-hmac-md5-96-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: <19970321095813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-96-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970321095813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 24 11:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00283 for ipsec-outgoing; Mon, 24 Mar 1997 11:13:51 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703241329.IAA25497@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:59:48 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Re: replay window size Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, The revised specs will make sure that there is no confusion re the relative secruity afforded by different replay windo sizes. As you observe, a large window, if proparly implemented, does just as good a job of preventing replays as a smaller window. The difference is that larger windows have a greater tolerance for out of order packet arrival than smaller windows, but IP assumes out of order arrival, and is silent on the extent to which such behavior may be benign (vs. malicious). I'm concvrened about having the window size be solely implementation defined, since that can lead to unopredictable behavior that may be hard to track down. Also, there seems to be general agreement that a wiondow size of 32, or multiples thereof, is relatively easy to implement. I don't want to have implementors feel that they must implement arbitrary size windows, since that is potentially hard (or inefficient), yet some have sent me private mail expressing concerns abotu exactly that. So, we need to clarify this. Also, I don't want to see a window size of 1 since that conflcits with the IP layer model for delivery. I like to think in terms of "consumer protection" when writing a spec. If certain requirements are levied, then the purchasers of IPSEC-compliant devices will be assured of a certain level of functionality (though not assurance), and interoperability will be fostered. If we are silent on important issues, such as what size window is supported for anti-replay, then I worry about what the products will do. Hence my desire to stipulate reasonable requirements for window sizes. However, I am sensitive to your concern re negotiation and if we could settle on a window size of 32 as a mandatory to implement default, and have negotiation of larger sizes optional, that might address both concerns. Steve From owner-ipsec Mon Mar 24 13:59:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01739 for ipsec-outgoing; Mon, 24 Mar 1997 13:56:11 -0500 (EST) From: Robert Glenn Date: Mon, 24 Mar 1997 14:00:37 -0500 (EST) Message-Id: <199703241900.OAA12874@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: HMAC Test case draft submitted Cc: pau@watson.ibm.com, rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk In hopes of helping eliminate some of the more basic algorithm-specific interoperability problems, Pau-Chen Cheng and I have put together and submitted a HMAC Test Cases I-D that covers HMAC-MD5 and HMAC-SHA. I've put an advanced copy at: ftp://ftp.antd.nist.gov/pub/ipsec/draft-cheng-hmac-test-cases-00.txt. Rob G. rob.glenn@nist.gov From owner-ipsec Mon Mar 24 16:40:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02892 for ipsec-outgoing; Mon, 24 Mar 1997 16:36:52 -0500 (EST) Message-Id: <199703242141.QAA01968@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: Open issues for inline keying. Date: Mon, 24 Mar 1997 16:41:25 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I've gotten several bits of feedback on my inline keying proposal; unfortunately, there doesn't seem to be any particular consensus in the comments I've received. Please read draft-ietf-ipsec-inline-isakmp-00.txt; it's not very long; a quick summary is that it involves "spawning" new security associations from old ones by using "reply-SPI-creation" messages piggybacked on normal network traffic. I see three major open isues: Issue 1: How do we frame the reply-SPI creation message within the packet? [There are some similarities between this issue and the compression issue. It would be good to resolve them in a similar way..] option 1a: Steal a bit out of the ESP encoding to indicate the presence of a reply-SPI-creation message. Perhaps the next-to-the-high-order bit of the pad length? :-)) This bit would only be used if the endpoints had configured/negotiated inline keying in the parent SA. option 1b: use a new IP-level protocol with a "next-protocol" field, and set the next-protocol field of the containing ESP header to this new protocol, and the inline-keying protocol's next-protocol to the payload's protocol. One implementor was significantly opposed to this idea; another was significantly in favor of it and I haven't heard any other opinions. option 1c: Use the ipv6 "destination options" IP-layer protocol (IP protocol 60) to contain the reply-SPI-creation message. For those unfamiliar with ipv6 (which includes myself): ipv6 doesn't include any space for option information in the base IP header; instead, it uses a nested protocol approach akin to AH (ip protocol 60 is the "ipv6 destination options" protocol). It appears to me that there is fundamentally no reason why this protocol could not also be used inside an ipv4 header, though it may be a little more work in ipv4-only implementations and it may complicate mixed ipv4/ipv6 implementations. option 1d: anyone have any better ideas? Issue 2: What goes inside the reply-SPI creation message? option 2a: An a message from an ISAKMP quick-mode exchange (which requires three messages before both new SA's can be brought up). option 2b: A simplified quick-mode-like message which creates a reply-SPI in a single message, allowing both child-SA's to be brought up in a single message exchange, probably piggybacked on the SYN and SYN-ACK of a connection establishment. This is lower overhead, probably higher efficiency, but more work to implement and analyze since we can't just encapsulate the isakmp message and send it in line. Issue 3: Keying the payload which is along for the ride with the reply-SPI-creation message. option 3a: Just use the SPI's encryption as-is [which seems like it might be cryptographically weaker than options 3b and 3c ] option 3b: Include a nonce in the reply-spi-creation message to hash with the shared secret to generate the key for this packet. [this is effective, but non-modular] option 3c: define a new class of ESP transforms which include a nonce in each packet (Hilarie Orman called this a "key hash index") which is combined with the SA's shared secret to generate the key used to encrypt the packet. This may be easier to do given the new mix-and-match ESP architecture which Steve Kent has proposed, and I think this, without the additional reply-SPI-creation protocol, is what Hilarie is looking for. --- Does anyone have any commentary? If you have a preference, please explain why (since I'm easier to convince if there's a rationale behind it). I am currently leaning towards 1c, 2b, and 3c, but could be convinced one way or the other. The -01 draft will likely continue to waffle about the issues unless I receive *convincing* arguments in favor of particular options by late tomorrow. - Bill From owner-ipsec Mon Mar 24 23:44:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05211 for ipsec-outgoing; Mon, 24 Mar 1997 23:41:45 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703250446.XAA49412@mailhub1.watson.ibm.com> Date: Mon, 24 Mar 97 23:38:20 EST To: iesg@ietf.org, IPSEC@tis.com cc: DHARKINS@cisco.com, carrel@ipsec.org, RJA@inet.org, PALAMBER@us.oracle.com, CANETTI@watson.ibm.com Subject: oakley-03: last call comments Sender: owner-ipsec@ex.tis.com Precedence: bulk In the last months I have been collaborating with Dan Harkins on several design issues for the isakmp/oakley protocol. Dan has been very open and receptive of the changes and design guidelines that I suggested. There are two issues, however, that were not resolved in oakley-03. They are significant for security and functionality reasons so I insist they need to be done. I am also adding a third simple change that I failed to communicate to the editors in time before the appearance of oakley-03. The changes are simple from editorial point of view (full text change is suggested below). They do impact implementations but do not require any extensive work to adjust to them. Therefore, now is the right time to do them before fielded implementations are available. Notice that I am careful not to suggest any change that could lead to delays in the standard definition and deployment. Change No. 1: Quick Mode ************************ The draft says: > Quick Mode is defined as follows: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui, IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui, IDur ] > HDR*, HASH(3) --> > > Where: > HASH(1) and HASH(2) are the prf over the message id (M-ID) from > the ISAKMP header concatenated with the entire message that follows > the hash including payload headers, but excluding any padding added > for encryption. HASH(3)-- for liveliness-- is the prf over the value > zero represented as a single octet, followed by a concatenation of > the message id and the two nonces-- the initiator's followed by the > responder's. In other words, the hashes for the above exchange are: > > HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) > HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ]) > HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) > Problem: A basic practice in authentication protocols is to use nonces to guarantee the freshness of the authentication messages. In this case there is a nonce Ni sent for I to R in the first message. That nonce Ni needs to be incorporated into the hash computation of HASH(2) for such a freshness purpose (to prevent re-play attacks). This is also consistent with design of HASH_I and HASH_R in all the other modes of the protocol. Recommendation: Change > HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ]) to HASH(2) = prf(SKEYID_a, M-ID | SA | Nr | Ni [ | KE ] [ | IDui | IDur ]) ^^ Discussion: Currently, freshness in HASH(2) IS provided via the field M-ID which ISAKMP specifies to be "randomly chosen by the Initiator". The problem is that M-ID (message identifier) has no cryptographic motivation by itself in ISAKMP. It is used by a system to differentiate parallel (phase 2) exchanges belonging to the same tunnel. In particular, in many cases implementations could dispense of the randomness (e.g. when no parallel sessions are run). Actually, we cannot even guarantee that this definition of M-ID as a random number will not be changed in the future in arevised ISAKMP version. Who will then remember that there is a cryptographic use of this number in Oakley? Since Ni is there anyway in Oakley let's use it as freshness guarantee, thus making Oakley more self-contained, more secure, and easier for analysts and implementers to understand its cryptographic rationale and design. Change No. 2: Authentication through public key encryption *********************************************************** Problem: The draft currently provides identity protection in this mode (page 11) by encrypting the identities under a public key encryption. As specified now this public key encryption is separated from that of the nonces Ni and Nr. This means that the protocol requires TWO encryption and decryption operation for each party. This is unnecessarily expensive (depending on your processor the extra exponentiation may have negligible up to significant effect in performance). Indeed it is enough to encrypt the nonce under the public key and to derive from it a key for a symmetric encryption (e.g. under DES) of the identity. This solution adds no significant complexity to the implementation and saves a costly long (RSA or other) exponentiation. (It also allows to easily encrypt long certificates if sent from Inititiator to Responder; currently such an encryption is not specified/possible.) Recommendation: Change the following text (page 11) > > In addition to the nonce, the identities of the parties (IDii and > IDir) are also encrypted with the other parties public key. If the > authentication method is public key encryption, the nonce and > identity payloads MUST be encrypted with the public key of the other > party. Only the body of the payloads are encrypted, the payload > headers are left in the clear. > > When using encrytion for authentication with Oakley, Main Mode is > defined as follows. > > Initiator Responder > ----------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, [ HASH(1), ] > PubKey_r, > PubKey_r --> > HDR, KE, PubKey_i, > <-- PubKey_i > HDR*, HASH_I --> > <-- HDR*, HASH_R > > Oakley Aggressive Mode authenticated with encryption is described as > follows: > > Initiator Responder > ----------- ----------- > HDR, SA, [ HASH(1),] KE, > Pubkey_r, > Pubkey_r --> > HDR, SA, KE, PubKey_i, > <-- PubKey_r, HASH_R > HDR, HASH_I --> > > > > Harkins, Carrel [Page 11] TO: The nonce is encrypted with the other parties public key. The identities of the parties (IDii and IDir) are encrypted with a symmetric cipher (as negotiated by the ISAKMP Security Association, e.g. DES) using a key derived from the nonce (if a certificate is passed from Initiator to Responder it is encrypted under the same key as the identities). If the authentication method is public key encryption, the nonce payload MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear. When using encryption for authentication with Oakley, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r --> Ne_i [Ne_i] <-- HDR, KE, PubKey_i Ne_r HDR*, HASH_I --> <-- HDR*, HASH_R The keys Ne_i and Ne_r are defined as: Ne_i = prf(Ni, CKY-I) Ne_r = prf(Nr, CKY-R) The notation <...>PubKey refers to public key encryption (e.g. using the RSA algorithm) while the notation <...>Ne refers to encryption under a symmetric cipher (e.g DES) as negotiated for payload encryption by the ISAKMP SA. The key used for symmetric encryption to protect the third (resp. fourth) message payloads is derived (and possibly expanded) from Ne_i (resp. Ne_r) in an algorithm-specific manner (see appendix B). If CBC mode is used for the encryption then the initialization vector (IV) is set to 0 (notice that the value Ne_i is ephemeral). Encrypted payloads are padded up to the nearest block size using bytes containing 0x00. Oakley Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Pubkey_r, Ne_i --> [Ne_i] HDR, SA, KE, PubKey_i, <-- Ne_r, HASH_R HDR, HASH_I --> (end of proposed change) Discussion: A further security measure that can be taken here is to use Ne_i and Ne_r to encrypt the KE payload. This adds more security to the DH exchange (against broken modulus p, against short exponents, etc.). I leave the decision to the editors whether to add this encryption as part of the specification or not. Also, notice that I left the HDR* notation in non-aggressive mode although this encryption (under SKEYID_e) it is not really necessary since the identities are not there. Whether to remove that encryption is up to the editors. Leaving it adds to the processing time but may simplify implementation as it is consistent with other non-aggressive modes. Change No. 3: Derivation of SKEYID ********************************** SKEYID derivation is defined as: > > For signatures: SKEYID = prf(Ni | Nr, g^xy) > For public key encryption: SKEYID = hash(Ni | Nr) > For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr) In the case of public key encryption I suggest to change the definition to For public key encryption: SKEYID = prf(Ni | Nr, CKY-I | CKY-R) This is better compatible with the definition of prf (rather than just hash) and uniform with all other key derivations in this protocol. Note: The suggestion SKEYID = hash(Ni | Nr) is my own fault. Pau-Chen Cheng suggested the above improved prf derivation. Hugo From owner-ipsec Tue Mar 25 01:34:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05854 for ipsec-outgoing; Tue, 25 Mar 1997 01:32:17 -0500 (EST) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Proposed changes to ESP (andf a little AH too) Date: 24 Mar 1997 22:33:06 -0800 Organization: ISAAC Group, UC Berkeley Lines: 39 Message-ID: <5h7rj2$ng6@joseph.cs.berkeley.edu> References: <199703212153.XAA26081@del.tla.org> <9703231820.AA24783@hawpub.watson.ibm.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <9703231820.AA24783@hawpub.watson.ibm.com>, Uri Blumenthal wrote: > The main argument against doing encryption first and auth second would > be - generally speaking there is no guarantee even if you verified the > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > as was sent. That's a robustness argument against authenticating the ciphertext, and a pretty good one if the decryption routine is complicated. However, if the decryption is simple & easy to analyze, we can (mostly) put to rest those fears about authenticating ciphertext. Suppose the decryption routine depends only on the authenticated ciphertext (and a key). We assume the two endpoints both see the same view of the key. Furthermore, we assume the MAC is secure, so that the two endpoints both share the same view of the ciphertext. Because decryption is a function that depends on no other parameters (by assumption), then the result of decryption will be the same at both endpoints. Therefore, you can be sure that the plaintext finally obtained is the same as was sent. Some examples where this informal "proof" goes wrong will probably make the argument clearer. If decryption depended on an IV which wasn't authenticated (more specifically, wasn't included in the MAC input for this packet), then the arguments fails -- and indeed, if an adversary with control over the IV can fake the first block of plaintext at will without breaking the MAC. If decryption included a decompression stage which depended on some context (a LZH dictionary, say), and that context was implicit and un-authenticated, the argument fails. So-- how simple is the decryption routine? What parameters does it depend on? If the decryption routine is simple enough that we can (with pretty high assurance) isolate all the parameters it depends on and ensure that they are authenticated, then we have a good argument saying that authenticating the ciphertext is safe. Otherwise, we should start to worry that authenticating the ciphertext is not robust enough. From owner-ipsec Tue Mar 25 09:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09120 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:04 -0500 (EST) Message-Id: <3.0.1.32.19970325072815.009d8350@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:28:15 -0500 To: Stephen Kent , "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com In-Reply-To: References: <9703212112.AA20804@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:23 PM 3/21/97 -0500, Stephen Kent wrote: > > Even for transport mode ESP, the proposed swap of fields only >exposes the packet counters, nothing else that was not expose before. The >SPIs are equally visible in both cases, as are the soure and destination >addresses and the IP packet IDs. Together, these pieces of data provide me >with enough info to do a good job of TA, exclusive of the counter info. >So, I'm not sure that I understand why you feel that the exposure of the >packet counters represents much of an aid to traffic analysis. Silly rabbit, when you are behind on mail, good thing to read through whole thread before interjecting :) This answers my question Steve.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 09:12:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09125 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:06 -0500 (EST) Message-Id: <3.0.1.32.19970325071745.009d7450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:17:45 -0500 To: Stephen Kent , ipsec@tis.com From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:10 PM 3/21/97 -0500, Stephen Kent wrote: > > Now for a bigger change! I suggest that we reverse the order of >encryption and authentication processing, when both are employed. Now, >authentication processing occurs first, then encryption. This means that a >receiver must decrypt then autehnticate. While most systems I have seen in >the past have adopted this strategy, we are now more concerned with denial >of service attacks. A likely common use of ESP is to create VPNs thorugh >IPSEC implementations in security gateways. If we reverse the order of >processing, then a secruity gateway can validate the integrity and >authenticity of a packet befor edecrypting it, thus rejecting bogus packets >faster (about twice as fast, in many instances), than if we had to decrypt >then authenticate. Combined with the psoposed positional change for the >counter (suggested above), we now have an ability to reject duplicate or >spurious packets very quickly, providing better defense against DoS attacks. Steve, I will admit my limited experience in this matter, but in secure mail, it makes sense to auth then encrypt to hide identities for traffic analysis and for gaining identities of protected individuals (like CEOs). Now does the same argument apply to IPsec? Would exposing the auth information reveal more than some would want? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 09:12:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09135 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:30 -0500 (EST) Message-Id: <3.0.1.32.19970325072021.009d7450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:20:21 -0500 To: "Theodore Y. Ts'o" , Stephen Kent From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com In-Reply-To: <9703212112.AA20804@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:12 PM 3/21/97 -0500, Theodore Y. Ts'o wrote: > >In the case of using ESP to create VPN's through security gateways, the >threat of traffic analysis doesn't really apply, since the authenticated >destination will always be the other security gateway. Indeed, the >traffic analysis threat isn't important if we're doing host keying for >the same reason --- the low level, unauthenticated address allows for >traffic analysis anyway. > >The only place where traffic analysis would matter would be if we did >user-based keying, and we have multiple users using the same host, in a >time-sharing fashion. Ah, but you missed the case where the SA was built from the identity of the system behind the gateway. This is not user-based keying, but key proxing. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 10:27:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09753 for ipsec-outgoing; Tue, 25 Mar 1997 10:24:32 -0500 (EST) Message-Id: <3.0.16.19970325102428.1b17eeca@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 25 Mar 1997 10:29:50 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: replay mandatory? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Replay is mandatory? As in, replay size of 1 (no replay checking) is forbidden? >From: Hsin Fang >Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST) >To: kent@bbn.com >Subject: Re: Proposed changes to ESP (andf a little AH too) >Cc: ipsec@tis.com >Sender: owner-ipsec@ex.tis.com > > >Steve, > >In your 23 Mar 1997 note, you wrote: > >> As for the window size issue, I agree that one can simply decline >> to negotiate a size of 1, as a means of addressing this issue. However, I >> really believe that a size of 1 is so awful that it ought not be allowed. >> Moreover, only a size of 1 is proposed as required so far, and if we say >> dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) >> instead. So, that's why I'd like to change to make 32 a MUST support, and >> multiples of 32 be recommemded optional window sizes. > >I can understand that mandatory window size of 1 is not a good idea: it force >to drop every single out-of-order packet. But I don't see any good reason to >force the window size to be 32*X (X >= 1). Shouldn't people be allowed to pick >up any smaller number, let us say 8 or 16, as best fit their application? >Window size of 32*X when X>=2 is quite big to me considering that it is a per >destination/per security association figure. > >Regards, >Hsin > > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Tue Mar 25 10:28:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09759 for ipsec-outgoing; Tue, 25 Mar 1997 10:25:52 -0500 (EST) Date: Tue, 25 Mar 1997 10:30:15 -0500 Message-Id: <199703251530.KAA00625@road-warrior.mit.edu> From: "Jeffrey I. Schiller" To: kent@bbn.com CC: rja@inet.org, ipsec@tis.com In-reply-to: (message from Stephen Kent on Sun, 23 Mar 1997 18:22:09 -0500) Subject: Re: the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk I have tried to keep my nose out of this debate, but Memphis is approaching rapidly (must have put it on one of the Fedex jets) and we need to come to cloture real soon. From: Stephen Kent ... So, I'd like to see us proceed as follows to add compression to our specs, if the WG agrees: - have the architecture document describe the optional use of compression within ESP, to be negotiated on a per-SA basis - define in the relevant ISAKMP documents how to negotiate compression - set aside the high order bit from the ESP padding field to indicate if compression has been applied to an individual packet - define in ESP the scope of compression and any alignment considerations applicable to the use of compression - define compression algorithms for ESP use in separate base documents, which can have backpointers to the architecture, ESP, and ISAKMP docs This looks like a good plan to me. -Jeff From owner-ipsec Tue Mar 25 11:00:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10042 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:47 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703241623.LAA06124@emu.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 10:54:58 -0500 To: Hsin Fang From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hsin, Arbitrary size windows are potentially expensive to implement, though conceptually simple. We chose 32 (and multiples thereof) for the ease with which one can implement the window on a 32 bit (or 64 bit) machine. This sort of pragmatic recognition of commonly deployed machine word sizes also shows up in the IPv6 packet alignment requirements, so it is not out of pace here. Note that there is no security risk associated with a larger window size, i.e., in all cases all replays are rejected. The larger window size just provides a greater tolerance for out-of-order arrival, which is itsefl a feature of IP. Steve From owner-ipsec Tue Mar 25 11:00:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10041 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:46 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.16.19970325102428.1b17eeca@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 10:59:50 -0500 To: Rodney Thayer From: Stephen Kent Subject: Re: replay mandatory? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The window size of 1 does prevent replay, but it also prevents legitimate, out-of-order arrival of packets at the IP layer. A larger window size does not allow ANY replays; it just allows packets to arrive at the IPsec implementation out of order and still be checked and accepted. Steve From owner-ipsec Tue Mar 25 11:56:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56 -0500 (EST) Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: daw@cs.berkeley.edu (David Wagner) Cc: ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800. <5h7rj2$ng6@joseph.cs.berkeley.edu> Date: Tue, 25 Mar 1997 11:56:26 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The main argument against doing encryption first and auth second would > > be - generally speaking there is no guarantee even if you verified the > > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > > as was sent. > > That's a robustness argument against authenticating the ciphertext, > and a pretty good one if the decryption routine is complicated. > > However, if the decryption is simple & easy to analyze, we can (mostly) > put to rest those fears about authenticating ciphertext. It's also the case that the bulk of the protocols which will likely be used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum, which will cause most garbled traffic to be dropped. If we assume that errors where the ciphertext is authenticated but the decryption is garbled will most likely occur during debugging of new code or manual keying, then that would seem to be an acceptable risk; the operator(s) will interpret 99.998% packet loss as 100% packet loss and start debugging.. We merely need to specify that the IP checksum MUST be supplied on transmission and verified on receipt for packets nested inside ESP. - Bill From owner-ipsec Tue Mar 25 13:43:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11500 for ipsec-outgoing; Tue, 25 Mar 1997 13:40:40 -0500 (EST) Message-Id: <3.0.16.19970325133743.373f1152@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 25 Mar 1997 13:45:32 -0500 To: Stephen Kent From: Rodney Thayer Subject: Re: replay mandatory? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I wonder if I am missing something. Today, in an IPsec-less environment, if I get IP packets for 1000 different TCP circuits, I have to have some pool of local copies of packets to deal with out-of-order IP packets. If I implement IPsec, with NO replay, things are the same. I decrypt, I send it to the next step in the process, and presumably the same pool could be used. If I require a replay window of 32 for 1000 different Security Associations, that means I need to keep 32*1000 copies of IP packets around. I can't spread the pool cost among the 1000 like I could in the non-IPsec case. At 10:59 AM 3/25/97 -0500, you wrote: >Rodney, > > The window size of 1 does prevent replay, but it also prevents >legitimate, out-of-order arrival of packets at the IP layer. A larger >window size does not allow ANY replays; it just allows packets to arrive at >the IPsec implementation out of order and still be checked and accepted. > >Steve > > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Tue Mar 25 14:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11864 for ipsec-outgoing; Tue, 25 Mar 1997 14:20:05 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703251925.LAA07271@kebe.eng.sun.com> Subject: Re: replay mandatory? To: rodney@sabletech.com (Rodney Thayer) Date: Tue, 25 Mar 1997 11:25:06 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com> from "Rodney Thayer" at Mar 25, 97 01:45:32 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 > I wonder if I am missing something. I think the only thing you're missing is that you CAN have no replay protection on your SA(s). (There is no window size when you have no replay.) I see people saying, "If you use replay, the minimum window size MUST be 32 packets." And let's look at your concerns. > Today, in an IPsec-less environment, if I get IP packets for 1000 different > TCP circuits, I have to have some pool of local copies of packets to deal > with out-of-order IP packets. Basically, each TCP connection has state which will queue up the packets that arrive out of order, rather than deliver them to the appropriate application. If a segment arrives out-of-order, it gets queued at the TCP control block (or whatever you call yours), and that memory is held until such time as the data is delivered and consumed. > If I implement IPsec, with NO replay, things are the same. I decrypt, I > send it to the next step in the process, and presumably the same pool could > be used. If the same memory block (mbuf, mblk, whatever you use) ISN'T being used after you've decrypted (OR AUTHENTICATED, DON'T FORGET AH, FOLKS), I question your design. :) You're right, you just deliver as before w/o replay. > If I require a replay window of 32 for 1000 different Security > Associations, that means I need to keep 32*1000 copies of IP packets > around. Not necessarily. It's POSSIBLE that you'll have 31*1000 copies of IP packets queued up, assuming a Byzantine failure. Besides, at some point in time, you just assume that packet didn't arrive, drop it, then deliver the .. etc packets. Delivery will free up the resources. Keep in mind that with larger replay windows, system resources CAN be consumed at a faster rate. It doesn't, however, mean that they WILL be consumed at a faster rate. > I can't spread the pool cost among the 1000 like I could in the non-IPsec > case. I understand that you're concerned about system resources. It sounds like, in your system, you allocate a fixed number of buffers allocated to network traffic. Yes, a large replay window will perhaps exhaust your finite supply of buffers quicker than no replay. If packets are behaving themselves and arrive mostly in-order, even with a replay window of 256, you won't be burning your buffers very quickly. I suspect that's the common case. Finally, if I understand, if you're that concerned about system resources, you can have a policy of no-replay-protection in your KMd. Dan From owner-ipsec Tue Mar 25 14:32:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12015 for ipsec-outgoing; Tue, 25 Mar 1997 14:31:18 -0500 (EST) Message-Id: <199703251935.OAA02413@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Rodney Thayer Cc: Stephen Kent , ipsec@tis.com Subject: Re: replay mandatory? In-Reply-To: rodney's message of Tue, 25 Mar 1997 13:45:32 -0500. <3.0.16.19970325133743.373f1152@pop3.pn.com> Date: Tue, 25 Mar 1997 14:35:12 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > If I require a replay window of 32 for 1000 different Security > Associations, that means I need to keep 32*1000 copies of IP packets > around. I can't spread the pool cost among the 1000 like I could in the > non-IPsec case. No, you process non-replayed packets out-of-order as they arrive (and toss replayed or stale packets as they arrive), so, at the ipsec layer, for 1000 SA's, you need room for 1000 * 64 bits of storage (32 bits of sequence number plus 32 bits of replay-window bitmap); this is most likely smaller than the encryption state. You still need buffering in tcp and in ip fragment reassembly. - Bill From owner-ipsec Tue Mar 25 14:39:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12156 for ipsec-outgoing; Tue, 25 Mar 1997 14:37:56 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703251942.OAA28141@mailhub1.watson.ibm.com> Date: Tue, 25 Mar 97 14:12:31 EST To: sommerfeld@apollo.hp.com, daw@cs.berkeley.edu cc: ipsec@ex.tis.com Subject: Proposed changes to ESP (andf a little AH too) Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Tue, 25 Mar 1997 11:56:26 -0500 (attached) I agree with both Bill's note attached here, and Dave Wagner's comments in a recent note. If the choice would be pure cryptographic I might be inclined for the current authenticate-the-plaintext (and encrypt the MAC) approach. It better captures the real objective which is to authenticate the plaintext rather than the ciphertext. However, the other approach is not bad enough as to be immediately disqualified. If authenticate-the-ciphertext is chosen, it will be important to have some remarks in the draft in the lines of Dave's note. The real question to decide in this WG is whether the advantage against denial of service attacks provided by the authenticate-the-ciphertext approach is important enough to risk even further delay of ipsec deployment (which is also a form of denial-of-service attack :) In other words, if any of these discussion cannot be resolved by Memphis leave it the way it is now and go forward. Hugo ----------------------------- Note follows ------------------------------ Received: from mailhub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R4) with TCP; Tue, 25 Mar 97 12:19:36 EST Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [9.2.250.12]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with ESMTP id MAA43726; Tue, 25 Mar 1997 12:19:35 -0500 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by igw2.watson.ibm.com (8.7.6/8.7.1) with ESMTP id MAA24364; Tue, 25 Mar 1997 12:18:56 -0500 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56 -0500 (EST) Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: daw@cs.berkeley.edu (David Wagner) Cc: ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800. <5h7rj2$ng6@joseph.cs.berkeley.edu> Date: Tue, 25 Mar 1997 11:56:26 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The main argument against doing encryption first and auth second would > > be - generally speaking there is no guarantee even if you verified the > > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > > as was sent. > > That's a robustness argument against authenticating the ciphertext, > and a pretty good one if the decryption routine is complicated. > > However, if the decryption is simple & easy to analyze, we can (mostly) > put to rest those fears about authenticating ciphertext. It's also the case that the bulk of the protocols which will likely be used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum, which will cause most garbled traffic to be dropped. If we assume that errors where the ciphertext is authenticated but the decryption is garbled will most likely occur during debugging of new code or manual keying, then that would seem to be an acceptable risk; the operator(s) will interpret 99.998% packet loss as 100% packet loss and start debugging.. We merely need to specify that the IP checksum MUST be supplied on transmission and verified on receipt for packets nested inside ESP. - Bill From owner-ipsec Tue Mar 25 14:39:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12164 for ipsec-outgoing; Tue, 25 Mar 1997 14:38:26 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 14:44:50 -0500 To: Rodney Thayer From: Stephen Kent Subject: Re: replay mandatory? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, I think I see the source of your confusion. Anti-replay is not designed to ensure that TCP receives packets in order. The ordering of packets for delivery to an application is a TCP function and we should not try to usurp that function at the IP layer. Our only goal for anti-replay in AH and ESP is to detect and reject (authentic) packets that we have already received. We use an integrity-protected, monotonically increasing sequence number in AH or ESP for anti-replay purposes. Thus an IPSEC implementation can reject a duplacate packet merely by examining the sequence number and comparing it to the window maintained for the SA via which the packet arrived. By choosing windows that are 32-bit multiples, one can mainatin a bit map to easily track pacets that arrive outr of order, but within the (trailing, sliding) window. See Jim Hughes code in one of his I-Ds for details. Thus we can achieve the anti-replay goal without buffering ANY packets in IPSEC. TCP still needs to buffer packets, to allow for out-of-order arrival, but the buffer pool arrangemetts should be the same as before. That's a TCP, not an IP, function, and anti-replay will not change this buffering and re-oredering task for TCP. However, TCP already does this just fine and IPsec anti-replay will protect TCP implementations from having to buffer bogus packets. Steve From owner-ipsec Thu Mar 27 15:16:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00687 for ipsec-outgoing; Thu, 27 Mar 1997 15:07:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 15:12:55 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new I-Ds, etc. Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Extensively revised versions of the AH and ESP specs have been submitted as I-Ds. I'll send out the formatted versions to the list as well, to help speed up the distribution process. Please forgive the receipt of moderately large documents later today. The changes to the documents represent an attempt to unify the document structure for IPsec (to do away with the proliferation of "transform" documents), and to make some substantive changes that promise better efficiency and effectiveness, and simplier impelmentations. For example, the new AH spec should suffice, with its reference to HMAC and the indirect references to MD5 and SHA-1, to encopmass all of the previously described AH transforms. Any new algorithms that might be added for AH use can be described in very brief documents that need not reproduce packet syntax, etc. Similarly, the new ESP spec attempts to capture all of the essential features of all of the proposed ESP transforms. (No inclusion of compression for now, but it will be easy to add the necessary placeholders if the WG elects to do so.) We do need a revised spec for DES CBC, with explicit and implicit IVs but without reference to all the other fields, and then the transition to the revised spec format shold be complete (for the default algorithm sets). New algorithms should be described in short, focused documents that need not describe the rest of the packet, other security services, etc. Combinations of services and algorithms are definbed through the ISAKMP negotiations, thus doing away with the need for additional documents to describe all the precommended combinations of services and algorithms. If nothing else, we will save lots of trees (and electrons?) through this consolidation strategy. Implementors will have fewer documents to read and there will be fewer opportunities for inconsistency. All of the sunstantive changes to the AH and ESP specs have been discussed on the list, and most were briefed at the last WG meeting, in San Jose. Although I will not be in Memphis, Nina Yuan has worked with me on these specs and will be there to provide briefings on the I-Ds and on the architecture document (see below). We look forward to receiving any feedback that will further improve the quality of these important specs. We hope for speed approval by the WG, so that we can move to last call and issue new RFCs that reflect the nature of the current, evolved AH and ESP designs and implementations. I am sorry to say that the architecture document is not among the newly released I-Ds. I have decided to re-write this document from scratch: (zero-based budgeting?). This decision was motivated by several observations: - the extensive changes in the AH and ESP documents - descovery of a number of architectural issues that need to be addressed but were not included in previous versions of the document (and some of which have not received extensive discussion on the mailing list) In this latter category are several important issues that we will be raising on the list (after Memphis). The plan is to propose language for the architecture document for each major issue, with supporting analysis for the proposal, and to reach concensus before incorporating the text (or a revised verison of the text) into the new document. The list of issues to be addressed in this fashion include: - proper handling of the DF bit and processing of ICMP PMTU messages - requirements for selectors (filters) for SA bundles, in integrated host, bump-in-the-stack, bump-in-the-wire and security gateway implementations - header and option copying in tunnel mode, for both inbound and outbound traffic, in hosts and gateways - a uniform mechanism for extracting autehntication and/or encryption keys for use with AH and ESP, based on ISAKMP exchanges - a mechanism for discovering and verifying the authorization of security gateways As you can see, we have a few things to discuss and resolve before we can calim to have a complete architecture for IPsec, even though we have made a lot of progress so far and we have nailed down a number of architectural issues. As noted above, we will begin sedning out messages (one per topic) for each of these issues, after Memphis, with the intent to having resolution of the issues and a new architecture I-D well before Munich. Steve From owner-ipsec Thu Mar 27 15:22:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00796 for ipsec-outgoing; Thu, 27 Mar 1997 15:21:58 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1352627887==_============" Date: Thu, 27 Mar 1997 15:22:08 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new AH spec (big message) Sender: owner-ipsec@ex.tis.com Precedence: bulk --============_-1352627887==_============ Content-Type: text/plain; charset="us-ascii" --============_-1352627887==_============ Content-Type: text/plain; name="AH_Final_(formatted)"; charset="us-ascii" Content-Disposition: attachment; filename="AH_Final_(formatted)" Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-04.txt 26 March 1997 IP Authentication Header Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng and IPsec Working Groups. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header 26 March 1997 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................4 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................5 3. Authentication Header Processing..................................5 3.1 Authentication Header Location...............................5 3.2 Outbound Packet Processing...................................8 3.2.1 Security Association Lookup.............................8 3.2.2 Sequence Number Field...................................8 3.2.3 Integrity Check Value Calculation.......................8 3.2.3.1 Handling Mutable Fields............................8 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.2 ICV Computation for IPv6......................9 3.2.3.2 Padding...........................................10 3.2.3.2.1 Authentication Data Padding..................10 3.2.3.2.2 Implicit Packet Padding......................10 3.2.3.3 Authentication Algorithms.........................10 3.2.4 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Reassembly.............................................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................11 3.3.4 Integrity Check Value Verification.....................12 4. Conformance Requirements.........................................13 5. Security Considerations..........................................13 Acknowledgements....................................................13 References..........................................................14 Disclaimer..........................................................15 Author Information..................................................15 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 26 March 1997 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides an optional confidentiality (encryption) service. The primary difference between ESP and AH, when used for authentication, is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP. For more details on how to use AH and ESP in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by AH (and by ESP), the concept of Security Associations, the different key management options available for AH (and ESP), and the ways in which AH can be used in conjunction with ESP. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 26 March 1997 2. Authentication Header Format +---------------+---------------+---------------+---------------+ | Next Header(8)| Payload Len(8)| RESERVED (16) | +---------------+---------------+---------------+---------------+ | Security Parameters Index (32) | +---------------+---------------+---------------+---------------+ | Sequence Number Field (32) | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields that comprise the AH format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of the Integrity Check Value (ICV). Whether or not an option is selected is defined as part of the Security Association. In contrast, "mandatory" fields are always present in the AH format. 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.2 Payload Length This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion of AH is not counted. The minimum value is 0, which is used only in the degenerate case of a "null" authentication algorithm. The Payload Length field is mandatory. *** Do we want to retain a null authentication algorithm as part of the *** spec at this point? What purpose does it serve? 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) The Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 26 March 1997 Reserved field is mandatory. 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value identifying the Security Association for this datagram (relative to the destination IP address contained in the IP header with which this security header is associated). The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. A value of zero indicates that no Security Association exists. The SPI field is mandatory. It is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" [KA97a] for more details). *** Under what circumstances will a zero SPI be employed? Is this *** still relevant or is it vestigial? 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The sequence number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. The Sequence Number field is optional. It is included only if the anti- replay service (a form of loose sequence integrity) is selected as a security service for the SA. 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.2.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided in Section 3.2.3.2.1 below. The Authentication Data field is mandatory. 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 26 March 1997 provides protection for upper layer protocols, in addition to selected IP header fields. In this mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------ authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 26 March 1997 BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<-------------------- authenticated --------------------->| except for mutable fields * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode AH may be employed in either hosts or security gateways. When AH is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<---------------- authenticated ------------->| except for mutable fields -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<---------------------- authenticated --------------------->| except for mutable fields * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 26 March 1997 3.2 Outbound Packet Processing In transport mode, the transmitter inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". 3.2.2 Sequence Number Field If the anti-replay service has been selected for this SA, the transmitter increments the sequence number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number Field. A transmitter MUST not send a packet on an SA if doing so would cause the sequence number to cycle. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. (Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation.) DISCUSSION: For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed here and classified as either mutable or immutable. For IPv4, the entire option is viewed as a unit; so even though the Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 26 March 1997 type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The mutable IPv4 header fields also are enumerated below. The ICV calculation is restricted to the immutable options and (base) header fields. 3.2.3.1.1 ICV Computation for IPv4 The IPv4 base header fields "Time to Live", "Header Checksum", "Offset", "Flags", and "Type of Service" are zeroed prior to the computation of the ICV. (The TOS field is included here because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field.) *** What about OFFSET and FLAGS. Since reassembly takes place before *** AH processing why are these fields omitted from the ICV *** computation? The following IPv4 options are mutable: record route, timestamp, loose source routing, and strict source routing. These options are treated as zero-filled for purposes of the ICV computation. The IP Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO (option number 134) option are included in the ICV calculation and are not zeroed. 3.2.3.1.2 ICV Computation for IPv6 In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed prior to performing the ICV calculation. IPv6 options contain a bit that indicates whether the option might change during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All other options are also included in the ICV calculation. See the IPv6 specification [DH95] for more information. Note that the IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as an immutable option. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. *** Do we want to make any recommendation for what an AH implementation *** should do if it encounters an unfamiliar IPv6 extension header, Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 26 March 1997 *** e.g., Routing Header "Type 1" (aka Nimrod)? 3.2.3.2 Padding 3.2.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by three factors: - the presence or absence of the Sequence Number field - the length of the ICV - the IP protocol context (v4 or v6) For example, if the Sequence Number field is present and a default, 96-bit truncated HMAC algorithm is selected, no padding is required for either IPv4 nor IPv6. In contrast, if the anti-replay service is not selected, and a default 96-bit truncated HMAC algorithm is selected, no padding is required for IPv4, but 4 bytes of padding are required for IPv6. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.2.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.3.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are suitable. As of this writing, the mandatory-to-implement authentication algorithms are based on the Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 26 March 1997 former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. However, an IP packet to which AH has been applied may itself be fragmented by routers en route, including security gateways that may apply AH or ESP (tunnel mode) to the already-protected packet or fragments. 3.3 Inbound Packet Processing 3.3.1 Reassembly If required, reassembly is performed prior to AH processing. 3.3.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA will indicate whether the Sequence Number field should be present, will specify the algorithm(s) employed for ICV computation, and will indicate the key(s) required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet and the failure MUST be recorded in an audit log. The log entry SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. The log entry MAY also include other identifying data. There is no requirement for the receiver to transmit any message to the purported transmitter in response to receipt of such packets (because of the potential to induce denial of service via such actions). 3.3.3 Sequence Number Verification If the anti-replay service has been selected for this SA, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 26 March 1997 Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Number values lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. If such a failure occurs, the log entry MUST include the SPI value, date/time received, Sending Address, Destination Address, and (in IPv6) Flow ID. The log data MAY also include other information about the failed packet. The window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number field before updating the bit mask (either turning on a bit or updating the "right" side of the window). 3.3.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. The log data MUST include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. The log data also MAY include other information about the failed packet. Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 26 March 1997 DISCUSSION: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.2.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 4. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." Note that support for manual key distribution is required, but its use is inconsistent with the anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97]): - HMAC with MD5 - HMAC with SHA-1 5. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". Acknowledgements For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 26 March 1997 Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC- 1636, 9 June 1994, pp. 21-34. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, April 1993. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, November 1991. [KA96a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA96b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, March 1997. [KA96c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1997. [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 26 March 1997 March 1996. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA Kent, Atkinson [Page 15] --============_-1352627887==_============-- From owner-ipsec Thu Mar 27 15:26:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00835 for ipsec-outgoing; Thu, 27 Mar 1997 15:26:33 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Date: Thu, 27 Mar 1997 15:22:38 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new ESP spec (bigger message) Sender: owner-ipsec@ex.tis.com Precedence: bulk --============_-1352627881==_============ Content-Type: text/plain; charset="us-ascii" --============_-1352627881==_============ Content-Type: text/plain; name="ESP_final_(formatted)"; charset="us-ascii" Content-Disposition: attachment; filename="ESP_final_(formatted)" Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-03.txt 26 March 1997 IP Encapsulating Security Payload (ESP) Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft is a product of the IETF's IPng and IPsec working groups. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................4 2.2 Sequence Number .............................................5 2.3 Initialization Vector........................................5 2.4 Payload Data.................................................5 2.5 Padding (for encryption).....................................6 2.6 Pad Length...................................................6 2.7 Next Header..................................................6 2.8 Authentication Data..........................................6 3. Encapsulating Security Protocol Processing........................7 3.1 ESP Header Location..........................................7 3.2 Outbound Packet Processing...................................9 3.2.1 Security Association Lookup.............................9 3.2.2 Anti-replay Service.....................................9 3.2.3 Packet Encryption.......................................9 3.2.3.1 Scope of Encryption.................................9 3.2.3.2 Encryption Algorithms..............................10 3.2.4 Integrity Check Value Calculation......................10 3.2.4.1 Scope of Authentication Protection................10 3.2.4.2 Authentication Padding............................10 3.2.4.3 Authentication Algorithms.........................11 3.2.5 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Pre-ESP Processing Overview............................11 3.3.2 Security Association Lookup............................11 3.3.3 Anti-replay Service....................................12 3.3.4 Integrity Check Value Verification.....................13 3.3.5 Packet Decryption......................................13 4. Conformance Requirements.........................................14 5. Security Considerations..........................................14 Acknowledgements....................................................14 References..........................................................15 Disclaimer..........................................................17 Author Information..................................................17 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of optional security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or the encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, anti-replay service (a form of sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and the implementation placement. Confidentiality may be selected independent of all other services. Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication), independent of confidentiality. An anti-replay service may be selected only if data origin authentication is selected, but it is independent of confidentiality. Traffic flow confidentiality depends on confidentiality, and requires selection of tunnel mode. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by ESP (and by AH), the concept of Security Associations, the different key management options available for ESP (and AH), and the ways in which ESP can be used in conjunction with the Authentication Header (AH). Kent, Atkinson [Page 3] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 2. Encapsulating Security Payload Packet Format +---------------+---------------+---------------+---------------+ ---- | Security Parameters Index (SPI), (32 bits) | ^ +---------------+---------------+---------------+---------------+ | | Sequence Number (32 bits) | | +---------------+---------------+---------------+---------------+ Auth/ | Initialization Vector (variable) | Integrity + + Coverage | | | +---------------+---------------+---------------+---------------+ | ----- | Payload Data (variable) | | ^ - - | | | | | | + +---------------+---------------+---------------+ | Confid. | | Padding (0-255 bytes) | | Coverage +---------------+ +---------------+---------------+ | | | | Pad Length(8) | Next Header(8)| v v +---------------+---------------+---------------+---------------+ -------- | Authentication Data (variable) | - - | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV. Whether or not an option is selected is defined as part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs. 2.1 Security Parameters Index The SPI is an arbitrary 32-bit value identifying the Security Association for this datagram (relative to the destination IP address contained in the IP header with which this security header is associated). The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. A value of zero indicates that no Security Association exists. (Note that the SPI is similar to the SAID used in other security protocols. The name has been changed because the semantics used here are not exactly the same as those used in other security protocols.) Kent, Atkinson [Page 4] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) ***Under what circumstances will a zero SPI be employed? Is this ***vestigial, or is there still a use for a zero SPI? Is it a SKIP ***support feature of some sort? The SPI field is mandatory, and its value is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" for more details.) 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The Sequence Number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. The Sequence Number is optional. It is only included if the anti- replay service is selected as a security service for the SA. Since the anti-replay service requires selection of the authentication service as well, the Sequence Number MUST not be present in the absence of the Authentication Data field (described below.) 2.3 Initialization Vector This is a variable-length field used only when an explicit IV is required by the selected encryption algorithm, mode or device. The length of the IV is dependent upon the choice of encryption algorithm, and is established during SA negotiation. The IV field is optional, but all implementations must be capable of generating and processing this field if they support algorithms or devices that require an explicit IV. 2.4 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. This field is an integral number of bytes in length. The Payload Data field is mandatory. ***We have a potential IPv6 alignment problem here, that may have ***been present for some time. Ignoring the presence or absence of an ***iv, the payload data will not be aligned on an 8-byte boundary if ***the Sequence Number is omitted. This may cause a problem for ***efficient crypto data transfer. If the IV is present, and the ***Sequence Number is omitted, the same problem arises, starting with ***the IV, unless the IV is of a compensating size. The decryption ***process can fix the problem for higher layer protocols, because the ***output buffer from decryption is usually distinct from the input Kent, Atkinson [Page 5] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) ***buffer, but that still causes potential problems for transfer of ***data to the crypto module. Also, if encryption is not employed, ***this becomes a potential problem for authentication data being ***passed up. We could solve this by adding an optional alignment ***field to the ESP header, when required for IPv6. What do people think? 2.5 Padding (for Encryption) If the confidentiality service has been selected, the Padding field is used to fill the Payload Data to a multiple of the blocksize required by the encryption algorithm. This blocksize requirement is a parameter of the algorithm negotiated during SA establishment. If encryption has not been selected, the Padding field is used to align the Next Header field so that the last bit of that field ends on a 32-bit boundary. The Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Padding beyond that required for encryption algorithm blocksize alignment may be used to conceal the actual length of the payload, in support of traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. 2.6 Pad Length The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. The Pad Length field is mandatory. 2.7 Next Header The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.8 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Kent, Atkinson [Page 6] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Authentication Data. The length of the field depends upon the authentication function selected. The mandatory-to-implement authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit ICVs because of the truncation convention adopted for use in IPsec. The Authentication Data field is optional. 3. Encapsulating Security Protocol Processing 3.1 ESP Header Location Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, but not the IP header. In this mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | | | | ESP | ESP| |(any options)| ESP | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hxh,rtg,frag|dest| |dest| | | ESP | ESP| |IP hdr|if present**|opt*|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. ----------------------------------------------------------- IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| ----------------------------------------------------------- |<--------- encrypted ---------->| |<----------- authenticated ---------->| --------------------------------------------------------------- IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP| |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth| --------------------------------------------------------------- |<---------- encrypted ----------->| |<----------- authenticated ---------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 8] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 3.2 Outbound Packet Processing In transport mode, the transmitter encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". 3.2.2 Anti-replay Service If the anti-replay service has been selected for this SA, the transmitter increments the Sequence Number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number field. A transmitter MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. As mentioned in section 2.2, the anti-replay service requires the selection of the authentication services thus the Sequence Number field MUST NOT be present in the absence of the Authentication Data field (described below.) 3.2.3 Packet Encryption 3.2.3.1 Scope of Encryption In transport mode, if encryption has been selected, the transmitter encapsulates the original upper layer protocol information into the ESP payload field, adds any necessary padding, and encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, and algorithm mode indicated by the SA. In tunnel mode, the transmitter encapsulates and encrypts the the entire original IP datagram (plus the Padding, Pad Length, and Next Header). If both encryption and authentication have been selected, encryption is performed first, before the authentication and the encryption does Kent, Atkinson [Page 9] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV. 3.2.3.2 Encryption Algorithms If confidentiality is selected, the encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry either an explicit Initialization Vector (IV) that allows the receiver to establish cryptographic synchronization for decryption, or data derived from the packet header must suffice to generate an IV at the receiver. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. 3.2.4 Integrity Check Value Calculation 3.2.4.1 Scope of Authentication Protection If authentication is selected for the SA, the transmitter computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number (if present), Initialization Vector (if present), Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. If encryption has been selected, the last 4 fields will be in ciphertext form. 3.2.4.2 Authentication Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, prior to ICV Kent, Atkinson [Page 10] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.4.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are suitable. As of this writing, the mandatory-to-implement authentication algorithms are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. However, an IP packet to which ESP has been applied may itself be fragmented by routers en route, including security gateways that may apply AH or ESP (tunnel mode) to the already-protected packet or fragments. 3.3 Inbound Packet Processing 3.3.1 Pre-ESP Processing Overview If required, reassembly is performed prior to ESP processing. 3.3.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA indicates whether the Sequence Number, Initialization Vector, and Authentication Data fields should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable). If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the Kent, Atkinson [Page 11] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) packet and the failure MUST be recorded in an audit log. The log entry MUST include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. The log entry MAY also include other identifying data. There is no requirement for the receiver to transmit any message to the purported transmitter in response to receipt of such packets (because of the potential to induce denial of service via such actions). 3.3.3 Anti-replay Service If the anti-replay service has been selected for this SA, the receiver MUST verify that the packet contains a Sequence Number value that does not duplicate the Sequence Number of any other packet received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Reply Protection value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. If such a failure occurs, the log entry MUST include the SPI value, date/time received, Sending Address, Destination Address, and (in IPv6) Flow ID. The log data MAY also include other information about the failed packet. The window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number before updating the Sequence Kent, Atkinson [Page 12] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Number window data. 3.3.4 Integrity Check Value Verification If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. The log data MUST include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the clear-text Flow ID. The log data MAY also include other information about the failed packet. DISCUSSION: Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 3.3.5 Packet Decryption If data confidentiality was selected, the receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the session key that has been established for this traffic. If an explicit IV is present, it is input to the decryption algorithm as per the algorithm specification. If an implicit IV is employed, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. (Decryption may take place in parallel with authentication, but care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet.) After decryption, the original IP datagram is reconstructed and processed per the normal IP protocol specification. The exact steps for reconstructing the original datagram depend on the mode (tunnel Kent, Atkinson [Page 13] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) vs transport) and are described in the document, "Security Architecture for the Internet Protocol." Note that there are two ways in which the decryption can "fail". The selected SA may not be correct or the encrypted ESP packet could be corrupted. (The latter case would be detected if authentication is selected for the SA, as would tampering with the SPI. However, an SA mismatch might still occur due to tampering with the IP Destination Address.) In either case, the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." Note that support for manual key distribution is required, but its use is inconsistent with anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97] and in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. - DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 5. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92 IB93]. For over 2 years, this document has evolved through multiple versions Kent, Atkinson [Page 14] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPSEC and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org. [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6 (Ipv6) Specification, RFC 1883, December 1995. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol (IPSO)", RFC-1108, November 1991. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1997. [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", RFC-1829, August 1995. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) [NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA Kent, Atkinson [Page 17] --============_-1352627881==_============-- From owner-ipsec Thu Mar 27 17:43:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01775 for ipsec-outgoing; Thu, 27 Mar 1997 17:41:49 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272247.OAA00326@kebe.eng.sun.com> Subject: Re: new AH spec To: kent@bbn.com (Stephen Kent) Date: Thu, 27 Mar 1997 14:47:11 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 27, 97 03:22:08 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 I guess someone has to toss out the first feedback. > IP Authentication Header > 1. Introduction Looks good so far. The bit about "piecemeal" might be a bit strong, but that's really hairsplitting. > 2. Authentication Header Format > *** Do we want to retain a null authentication algorithm as part of the > *** spec at this point? What purpose does it serve? Mostly, the NULL authentication algorithm is used for testing of protocol plumbing. I don't expect any shipping product to have a null authentication algorithm. I do expect AH implementations that are in their nascent stages to have a null authentication algorithm. Interpret this data as you will w.r.t. how the spec should read. > 2.4 Security Parameters Index (SPI) > A value of zero indicates that no Security Association exists. The SPI > field is mandatory. It is ordinarily selected by the destination > system upon establishment of an SA (see "Security Architecture for > the Internet Protocol" [KA97a] for more details). > > *** Under what circumstances will a zero SPI be employed? Is this > *** still relevant or is it vestigial? A zero SPI is useful for any number of implementation-specific aids. An example I can think of off the top of my head is that if my getassocybyendpoint() call for an outgoing datagram returns an association with a zero SPI, I can interpret this as any number of results (including, "I just kicked key management in the rear, I'll get back to you.") > 2.5 Sequence Number > > This unsigned 32-bit field contains a monotonically increasing > counter value (sequence number). The counter is initialized to 1 > when an SA is established. The sequence number must never be allowed > to cycle; thus, it MUST be reset (by establishing a new SA and thus a > new key) prior to the transmission of 2^32-1 packets on an SA. The > Sequence Number field is optional. It is included only if the anti- > replay service (a form of loose sequence integrity) is selected as a > security service for the SA. I know certain people who have issues about having this field NOT being present. I don't have a problem with this, but I suspect the people who have these issues will speak up. See the newly issued HMAC-96 drafts for details. > 3. Authentication Header Processing > > 3.1 Authentication Header Location > > Like ESP, AH may be employed in two ways: transport mode or tunnel > mode. The former mode is applicable only to host implementations and > provides protection for upper layer protocols, in addition to > selected IP header fields. In this mode, AH is inserted after the IP > header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return to this upper-layer protocol idea in a bit. > In the IPv6 context, AH is viewed as an end-to-end payload, and thus > should appear after hop-by-hop, routing, and fragmentation extension > headers. The destination options extension header(s) could appear > either before or after the AH header depending on the semantics > desired. The following diagram illustrates AH transport mode > positioning for a typical IPv6 packet. > > BEFORE APPLYING AH > --------------------------------------- > IPv6 | | ext hdrs | | | > | orig IP hdr |if present| TCP | Data | > --------------------------------------- > > AFTER APPLYING AH > ------------------------------------------------------------ > IPv6 | |hxh,rtg,frag| dest | | dest | | | > |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | > ------------------------------------------------------------ > |<-------------------- authenticated --------------------->| > except for mutable fields > > * = if present, could be before AH, after AH, or both > ** = hop by hop, routing, fragmentation headers This isn't _quite_ accurate. Destination options CAN appear before or after AH. But the semantic of destination options is very precise. From RFC 1883... IPv6 | Hop-by-Hop | Destination | Routing | Fragment.... If Destination options appear before AH, they appear before the routing header. The semantics being that the destination options are parsed on each hop specified in the routing header. This might be hairsplitting, but others who are IPv6/IPsec implementors might get confused. > The position of AH in tunnel mode, relative to the outer IP > header, is the same as for AH in transport mode. This sentence is more important than is apparent at first. An implementation can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps reduce some of the special-casing for IP as the inner payload. It doesn't _ELIMINATE_ it, but it can reduce it. (For example, if you have A->B with the inner IP saying A->B, you can make stronger assertions than if the inner packet says something else.) > 3.2 Outbound Packet Processing > > In transport mode, the transmitter inserts the AH header after the IP > header and before an upper layer protocol header, as described above. > In tunnel mode, the outer and inner IP header/extensions can be > inter-related in a variety of ways. The construction of the outer IP > header/extensions during the encapsulation process is described in > the document, "Security Architecture for the Internet Protocol". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmmm. I'm looking forward to this. > 3.2.1 Security Association Lookup > > AH is applied to an outbound packet only after an IPsec > implementation determines that the packet is associated with an SA > that calls for AH processing. The process of determining what, if > any, IPsec processing is applied to outbound traffic is described in > the document, "Security Architecture for the Internet Protocol". Once again, I'm looking forward to this. As an aside, I'd strongly encourage to look at the current implementations out there, as well as some of the analysis literature. I suspect you've already done your homework on this front and will be drawing on their experience when you finish rewhacking the architecture document. > 3.2.2 Sequence Number Field > > If the anti-replay service has been selected for this SA, the > transmitter increments the sequence number for this SA, checks to > ensure that the counter has not cycled, and inserts the new value > into the Sequence Number Field. A transmitter MUST not send a packet > on an SA if doing so would cause the sequence number to cycle. Do you have any recommendations for when the sequence number cycles? (Kick key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.) > 3.2.3 Integrity Check Value Calculation > > 3.2.3.1 Handling Mutable Fields > 3.2.3.1.1 ICV Computation for IPv4 > *** What about OFFSET and FLAGS. Since reassembly takes place before > *** AH processing why are these fields omitted from the ICV > *** computation? Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after reassembly! The question of DF is perhaps why the decision was made to just zero out that bit too. > 3.2.3.1.2 ICV Computation for IPv6 > *** Do we want to make any recommendation for what an AH implementation > *** should do if it encounters an unfamiliar IPv6 extension header, > *** e.g., Routing Header "Type 1" (aka Nimrod)? IMHO, new IPv6 extensions should document their own AH properties. Keep in mind this is IMHO only. > 3.2.3.2 Padding > > 3.2.3.2.1 Authentication Data Padding > > As mentioned in section 2.6, the Authentication Data field explicitly > includes padding to ensure that the AH header is a multiple of 32 > bits (IPv4) or 64 bits (IPv6). If padding is required, its length is > determined by three factors: > - the presence or absence of the Sequence Number field > - the length of the ICV > - the IP protocol context (v4 or v6) > > For example, if the Sequence Number field is present and a default, > 96-bit truncated HMAC algorithm is selected, no padding is required > for either IPv4 nor IPv6. In contrast, if the anti-replay service is > not selected, and a default 96-bit truncated HMAC algorithm is > selected, no padding is required for IPv4, but 4 bytes of padding are > required for IPv6. The content of the padding field is arbitrarily > selected by the sender. (The padding is arbitrary, but need not be > random to achieve security.) These bytes are included in the > Authentication Data calculation, counted as part of the Payload > Length, and transmitted at the end of the Authentication Data field > to enable the receiver to perform the ICV calculation. Thank you! We in IPv6-land appreciate this. > 3.2.3.3 Authentication Algorithms > > The authentication algorithm employed for the ICV computation is > specified by the SA. For point-to-point communication, suitable > authentication algorithms include keyed Message Authentication Codes > (MACs) based on symmetric encryption algorithms (e.g., DES) or on > one-way hash functions (e.g., MD5 or SHA-1). For multicast > communication, one-way hash algorithms combined with asymmetric > signature algorithms are suitable. As an aside, has anyone tackled this? A lightweight digital signature algorithm would be perfect in a multicast environment with a small number of senders compared with an arbitrary number of receivers. LARGE number of senders, however, requires Real Work (TM). > As of this writing, the mandatory-to-implement authentication algorithms > are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or > HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated > to (the leftmost) 96 bits. Other algorithms, possibly with different > ICV lengths, MAY be supported. Like I mentioned before, as currently written, these I-Ds _always_ include the replay counter. The replay counter is set to 0 for associations that don't use replay. > 3.3 Inbound Packet Processing > 3.3.3 Sequence Number Verification > > If the anti-replay service has been selected for this SA, the > receiver MUST verify that the packet contains a Sequence Number that > does not duplicate the Sequence Number of any other packets received > during the life of this SA. This SHOULD be the first AH check > applied to a packet after it has been matched to an SA, to speed > rejection of duplicate packets. Ummm, what if I live in a multithreaded world? I can theoretically get two packets near-concurrently with the same sequence number. If the bogus one arrives first, do I trash the good one just because one with the same replay number arrived first? Or do I not count a sequence number as "good" until I've authenticated? Or is this just an implementation detail? Or is this why it says SHOULD rather than MUST? > DISCUSSION: > > Note that if the packet is either inside the window and new, or > outside the window on the "right" side, the receiver MUST > authenticate the Sequence Number field before updating the bit > mask (either turning on a bit or updating the "right" side of the > window). Ahhhh, I get it now. I left the questions in because this is how some might think as they read it. I guess that's it for pass one. As I see more things, I'll report them. Dan From owner-ipsec Thu Mar 27 17:52:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01881 for ipsec-outgoing; Thu, 27 Mar 1997 17:52:23 -0500 (EST) From: touch@isi.edu Date: Thu, 27 Mar 1997 14:57:40 -0800 Posted-Date: Thu, 27 Mar 1997 14:57:40 -0800 Message-Id: <199703272257.AA18146@ash.isi.edu> To: kent@bbn.com, Dan.McDonald@Eng.sun.com Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Dan.McDonald@eng.sun.com (Dan McDonald) > > 2.4 Security Parameters Index (SPI) > > > A value of zero indicates that no Security Association exists. The SPI > > field is mandatory. It is ordinarily selected by the destination > > system upon establishment of an SA (see "Security Architecture for > > the Internet Protocol" [KA97a] for more details). > > > > *** Under what circumstances will a zero SPI be employed? Is this > > *** still relevant or is it vestigial? > > A zero SPI is useful for any number of implementation-specific aids. An > example I can think of off the top of my head is that if my > getassocybyendpoint() call for an outgoing datagram returns an association > with a zero SPI, I can interpret this as any number of results (including, "I > just kicked key management in the rear, I'll get back to you.") But under what circumstances would you set the SPI in the outgoing datagram to zero - wouldn't you wait?? (I can't send it and hope to resolve it later - what if I have several pending key mgt requests, then I can't distinguish which packets use which associations later) Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Thu Mar 27 17:54:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01896 for ipsec-outgoing; Thu, 27 Mar 1997 17:53:54 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272259.OAA00476@kebe.eng.sun.com> Subject: Re: new AH spec To: touch@isi.edu Date: Thu, 27 Mar 1997 14:59:11 -0800 (PST) Cc: kent@bbn.com, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: <199703272257.AA18146@ash.isi.edu> from "touch@ISI.EDU" at Mar 27, 97 02:57:40 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 > But under what circumstances would you set the SPI in the outgoing datagram > to zero - wouldn't you wait?? Oops, my bad. On the WIRE you'll NEVER see a zero SPI. I was arguing that the value 0 should continue to be reserved. Pardon the confusion, folks! Dan From owner-ipsec Thu Mar 27 18:29:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02041 for ipsec-outgoing; Thu, 27 Mar 1997 18:29:07 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272334.PAA00564@kebe.eng.sun.com> Subject: Re: new ESP spec (bigger message) To: kent@bbn.com (Stephen Kent) Date: Thu, 27 Mar 1997 15:34:28 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 27, 97 03:22:38 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 Note that many of my questions were covered in AH already. > IP Encapsulating Security Payload (ESP) > 2. Encapsulating Security Payload Packet Format > 2.1 Security Parameters Index > 2.4 Payload Data > > Payload Data is a variable-length field containing data described by > the Next Header field. This field is an integral number of bytes in > length. The Payload Data field is mandatory. > > ***We have a potential IPv6 alignment problem here, that may have > ***been present for some time. Ignoring the presence or absence of an > ***iv, the payload data will not be aligned on an 8-byte boundary if > ***the Sequence Number is omitted. This may cause a problem for > ***efficient crypto data transfer. If the IV is present, and the > ***Sequence Number is omitted, the same problem arises, starting with > ***the IV, unless the IV is of a compensating size. The decryption > ***process can fix the problem for higher layer protocols, because the > ***output buffer from decryption is usually distinct from the input > ***buffer, but that still causes potential problems for transfer of > ***data to the crypto module. Also, if encryption is not employed, > ***this becomes a potential problem for authentication data being > ***passed up. We could solve this by adding an optional alignment > ***field to the ESP header, when required for IPv6. What do people think? This isn't a real problem for IPv6. The reason for the 8-byte alignment drive in IPv6 was to make fast-path processing faster. (Those of us with UltraSPARC appreciate this.) Since ESP is already beating down the slow path, this isn't as huge of a deal as one might think at first. Also, a properly formed IPv6 datagram will be 8-byte aligned once you strip out the ESP cruft after decryption. There's always crypto-algorithm alignment issues, but I leave those to the crypto wizards. > 3. Encapsulating Security Protocol Processing See my previous note about IPv6 destination option semantics, tunnel-mode not being all that different, and outbound SA selection. > 3.2.3 Packet Encryption > > 3.2.3.1 Scope of Encryption > > In transport mode, if encryption has been selected, the transmitter > encapsulates the original upper layer protocol information into the > ESP payload field, adds any necessary padding, and encrypts the > result (Payload Data, Padding, Pad Length, and Next Header) using the > key, encryption algorithm, and algorithm mode indicated by the SA. > In tunnel mode, the transmitter encapsulates and encrypts the the > entire original IP datagram (plus the Padding, Pad Length, and Next > Header). > > If both encryption and authentication have been selected, encryption > is performed first, before the authentication and the encryption does > not encompass the Authentication Data field. This order of > processing facilitates rapid detection and rejection of replayed or > bogus packets by the receiver, prior to decrypting the packet, hence > potentially reducing the impact of denial of service attacks. It > also allows for the possibility of parallel processing of packets at > the receiver, i.e., decryption can take place in parallel with > authentication. Note that since the Authentication Data is not > protected by encryption, a keyed authentication algorithm must be > employed to compute the ICV. You've seen my comments on this (reversing the order of authentication and encryption) already. > 3.2.4.3 Authentication Algorithms > > The authentication algorithm employed for the ICV computation is > specified by the SA. For point-to-point communication, suitable > authentication algorithms include keyed Message Authentication Codes > (MACs) based on symmetric encryption algorithms (e.g., DES) or on > one-way hash functions (e.g., MD5 or SHA-1). For multicast > communication, one-way hash algorithms combined with asymmetric > signature algorithms are suitable. As of this writing, the > mandatory-to-implement authentication algorithms are based on the > former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 > [Riv92]. The output of the HMAC computation is truncated to (the > leftmost) 96 bits. Other algorithms, possibly with different ICV > lengths, MAY be supported. Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do so, but I sometimes miss these things. > 3.3 Inbound Packet Processing You've seen some comments about things in here in the AH comments. > 3.3.5 Packet Decryption > > If data confidentiality was selected, the receiver decrypts the ESP > Payload Data, Padding, Pad Length, and Next Header using the session > key that has been established for this traffic. If an explicit IV is > present, it is input to the decryption algorithm as per the algorithm > specification. If an implicit IV is employed, a local version of the > IV is constructed and input to the decryption algorithm as per the > algorithm specification. (Decryption may take place in parallel with > authentication, but care must be taken to avoid possible race > conditions with regard to packet access and reconstruction of the > decrypted packet.) > > After decryption, the original IP datagram is reconstructed and > processed per the normal IP protocol specification. The exact steps > for reconstructing the original datagram depend on the mode (tunnel > vs transport) and are described in the document, "Security > Architecture for the Internet Protocol." Ahh, the stripping of the ESP cruft I was talking about before... :) That's it for this one, Dan From owner-ipsec Thu Mar 27 22:19:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03208 for ipsec-outgoing; Thu, 27 Mar 1997 22:18:12 -0500 (EST) Message-Id: <199703280320.WAA04052@relay.hq.tis.com> Date: Thu, 27 Mar 97 22:21:16 EST From: Charles Lynn To: ipsec@tis.com cc: Dan McDonald Subject: Re: new AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > This isn't _quite_ accurate. > > Destination options CAN appear before or after AH. But the semantic of > destination options is very precise. From RFC 1883... > > IPv6 | Hop-by-Hop | Destination | Routing | Fragment.... > > If Destination options appear before AH, they appear before the routing > header. The semantics being that the destination options are parsed on each > hop specified in the routing header. This might be hairsplitting, but others > who are IPv6/IPsec implementors might get confused. >From RFC 1883: < IPv6|Hop-by-Hop|Destination|Routing|Fragment|AH|ESP|Destination|ULP When Destination options appear before the Routing Header, they are processed at each cluster contained in the Routing Header (including the final destination), as described. When they appear after any AH or ESP, they are only processed by the final destination after the AH and/or ESP processing. The text in the draft is pointing out an extensibility issue. It is often hard to foresee what evolution may happen in the future. Some option, which may be defined in the future, may have an effect that alters how the AH or ESP is to be processed by the final destination. Such an option could not appear before the Routing Header (as it should not be processed at each cluster), and could not appear after the AH and/or ESP as that would be too late to have the intended effect. For example, there is a Destination option that effectively alters the "source" and "destination" "addresses" which are to be use further up the protocol stack, e.g., as used in TCP or UDP "pseudo headers". As currently defined, the SPI is relative to the "destination address". There is no restriction on how an implementor must manage the SPI number space. I.e., an implementor may have a single SPI space per box, or may have one per interface, or even separate spaces for link addresses and global addresses, etc., and then there is multihoming, and the idea of having border routers rewriting addresses of packets that pass through them. There are many issues to be worked out (hopefully we can get the spec out before they are all resolved :-). Lets not write extra code to eliminate flexibility that we might find we want further down the road. Charlie From owner-ipsec Thu Mar 27 22:58:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03379 for ipsec-outgoing; Thu, 27 Mar 1997 22:58:18 -0500 (EST) Message-Id: <199703280400.XAA04513@relay.hq.tis.com> Date: Thu, 27 Mar 97 23:01:11 EST From: Charles Lynn To: ipsec@tis.com cc: Dan McDonald Subject: Re: new ESP spec (bigger message) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, +=========+ > > ***We have a potential IPv6 alignment problem | ver ... | > > here, that may have | ESP | ... | src ... | > | | > This isn't a real problem for IPv6. The reason | | > for the 8-byte alignment drive in IPv6 was to make | | > fast-path processing faster. (Those of us with | dst ... | > UltraSPARC appreciate this.) Since ESP is already | | > beating down the slow path, this isn't as huge of | | > a deal as one might think at first. Also, a | | > properly formed IPv6 datagram will be 8-byte +=========+ > aligned once you strip out the ESP cruft after | SPI | > decryption. | IV ... | | | I was under the impression that the 8-byte alignment +---------+ drive was to make processing not incur a lot of | ver ... | address alignment faults when processing IPv6 | TCP | packets. I also heard a desire that IPsec be | src ... | "friendly" to both hardware and software based | | algorithms. If one uses a software algorithm that | | decrypts in place, and have an IPv6 packet that | | begins as shown to the left, then the tunneled IPv6 | dst ... | header, etc., is not aligned, relative to the outer | | one. | | | | One argument for not needing alignment is that +---------+ decryption in place won't be common, as a hardware | TCP Hdr | decryption will "copy" the packet and can be made to | Data | do realignment in the process. | +----+ | |n|IP| Another is that IPv6 header alignment on 64-bit +----+----+ boundaries is not a "requirement", just a "guide line". I do not see any justification why AH and ESP should differ in their requirements to preserve alignment across their headers. Comments anyone? Charlie From owner-ipsec Fri Mar 28 13:03:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07923 for ipsec-outgoing; Fri, 28 Mar 1997 13:00:35 -0500 (EST) Message-Id: <3.0.32.19970328100436.00925300@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 10:04:37 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Internet Draft on compression Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The attached draft was submitted on Wednesday. Since there is a delay between draft submission and draft annoucement, I wanted to get this in front of the group so you would have enough time to review it. Please feel free to provide comments prior to Memphis. Regards, -Bob Internet Draft March 1997 (Expires September 1997) R. Monsour, Hi/fn Inc. M. Sabin, Consultant A. Shacham, Cisco Systems S. Anand, Microsoft Corporation R. Thayer, Sable Technology Compression in IP Security Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft is intended provide input to the IP Security working group as it sorts through the debate regarding the incorporation of lossless data compression into the IP Security architecture. Comments about this draft should be submitted to the authors or to the IPSEC mailing list (ipsec@tis.com). Abstract This memo discusses the application of lossless compression technology to the IP Security Architecture [IPSecArch]. Over the last few several months, a number of lively debates on this topic have been held on IPSec mailing list. This memo discusses the issues raised, the alternatives available to resolve them and provides a set of recommendations to bring resolution to the issue. The goals of the draft are to: (1) define the problem solved by the use of compression in the context of IPSec, (2) review the use of compression and security technologies as they have been applied in other layers of the protocol stack, (3) outline a set of Monsour, et al [Page 1] INTERNET DRAFT Compression in IP Security March 1996 requirements for applying compression to IPSec, (4) discuss alternative methods which can be implemented to meet the requirements, and (4) propose a set of recommendations for consideration by the working group. Acknowledgments The authors wish to acknowledge the many contributors to the compression debate on the IPSec mailing list. In addition, the concept of compressing prior to encrypting data is drawn from several prior sources, including Rodney Thayer's draft [Thayer], the ECP/CCP protocols under PPP and the TLS protocol (better known as SSL). Table of Contents 1. Introduction 2. Compression in IPSec - Problem Definition 3. Review of Other Protocols Using Compression and/or Security 3.1 Overview 3.2 The Encryption Control Protocol (ECP) 3.3 Transport Layer Security (TLS) 3.4 Application Layer Security 4. Does Compression Fall Within the Scope of the Working Group? 5. Requirements for Applying Compression to IPSec 5.1 Negotiated Algorithm 5.2 Stateless AND Stateful Compression 5.3 Compressed Packet Indicator 5.4 Compatibility with Existing and Emerging Implementations 5.5 Optional Use of Compression 5.6 Ability to Optimize Compression Across Protocol Layers 5.7 Anti-Expansion of Payload Data 6. Alternative Approaches to the Use of Compression in IPSec 6.1 Layered Architecture Using a Separate Compression Header 6.2 Optional Feature of ESP 6.3 Comparison of the Two Approaches 7. Which Approach Meets the Proposed Requirements? 7.1 Negotiated Algorithm 7.2 Stateless AND Stateful Compression 7.3 Compressed Packet Indicator 7.4 Compatibility with Existing and Emerging Implementations 7.5 Optional Use of Compression 7.6 Ability to Optimize Compression Across Protocol Layers 7.7 Anti-Expansion of Payload Data 8. Conclusions 9. Recommendations 10. Security Considerations 11. References 12. Authors' Addresses Monsour, et al [Page 2] INTERNET DRAFT Compression in IP Security March 1996 1. Introduction Encrypted data is random in nature and not compressible. When an IP datagram is encrypted, compression methods used at lower protocol layers -- e.g., the PPP Compression Control Protocol [RFC1962] -- no longer work. If both compression and encryption are desired, compression must be performed first. The IPSec working group of the IETF has been debating the topic of incorporating lossless data compression into the IPSec architecture for the past several months. In fact, the initial introduction of the topic goes as far back as 1994, when Jim Hughes of Network Systems presented the idea at the San Jose meeting of the IPSec working group [Dec96WG]. Following that initial presentation, Network Systems, as well as a handful of other companies have implemented proprietary methods for compressing IP datagrams prior to encrypting them. This memo takes that work, and analyzes similar work done in other security protocols, and proposes a negotiable, interoperable method for applying lossless data compression to the IPSec protocol. The first compression-related drafts were developed in 1996 and three of those drafts were discussed at the December 1996 IPSec working group meeting in San Jose [Thayer][Sabin1][Sabin2]. 2. Compression in IPSec - Problem Definition The widespread use of the internet has resulted in equally widespread use of point-to-point (PPP) connections between hosts as well as between routers. Lossless compression technology has been deployed in the PPP environment in the form of a sub-protocol known as the Compression Control Protocol (CCP). PPP is a connection-oriented protocol. Many lossless compression technologies have the capability to retain state across each "packet" of data that is compressed. Hence, in a connection-oriented protocol such as PPP, compression can be applied to the continuing stream of "packets". The principal advantage to such a stateful mechanism is a higher compression ratio. Another important aspect of the CCP is the negotiability of the compression algorithm for each PPP connection. Today, PPP is the predominant method for end-user hosts to connect to the internet. Compression in CCP provides end users with significant improvements in bandwidth utilization. In a different environment, today's routers that support connections in the T1 range AND use lossless compression technology, provide great economic value to their users. For example, a corporate user Monsour, et al [Page 3] INTERNET DRAFT Compression in IP Security March 1996 employing a leased T1 line can save thousands of dollars per month in line charges through the use of compression technology. The use of encryption technologies at protocol layers higher than the data-link/PPP layer, renders PPP compression ineffective. With the strong demand for secure communications, encryption is actively being deployed at various layers in the protocol stack to meet the security requirements of various environments. The is the core problem which has driven the compression debate in the IPSec working group. 3. Review of Other Protocols Using Compression and/or Security This section provides an overview of several examples of other protocols and applications involving the use of lossless compression technology. Some of the protocols described use compression in conjunction with encryption. 3.1 Overview The diagram below depicts the OSI reference model for data communications protocol layers along with various internet protocols and/or products which incorporate the use of compression and/or security capabilities. These are just a few examples of the technologies being deployed to meet the security and bandwidth requirements of various classes of users and systems. Protocols and/or Protocol Layers Products Compression Security ------------------ ----------- ------------- ------------ +----------------+ | Application | PGPmail yes yes |----------------| | Presentation | HTTPv1.1* yes no |----------------| | Session | TLS/SSL yes yes |----------------| | Transport | TCP** no no |----------------| | Network | IPSec no yes |----------------| | Data Link | PPP/CCP/ECP yes yes |----------------| | Physical | link encryptors no yes +----------------+ link compressors yes no *[RFC2068] Monsour, et al [Page 4] INTERNET DRAFT Compression in IP Security March 1996 **Note: There is discussion within the IETF of taking up work in this area. 3.2 The Encryption Control Protocol (ECP) At the same time that the Compression Control Protocol was defined, a sister protocol, the Encryption Control Protocol (ECP) [RFC1968], was defined. In the ECP protocol, it is clearly noted that if compression has been negotiated for a connection, compression must be performed prior to encryption. As far as the authors can tell at this time, the ECP has not been widely deployed. However, it should also be noted that the PPP Extensions working group [PPPEXT] is currently working on additional security protocols in the areas of authentication and public key technologies. 3.3 Transport Layer Security (TLS) TLS [TLS] (formerly/better known as SSL, the Secure Socket Layer) is a security protocol originally defined and implemented by Netscape Communications Corporation. In the initial draft of TLS 1.0, the use of compression is defined as an optional data transformation which can be used prior to encryption for each packet. In TLS, the selection of compression algorithm is a negotiated property of the session. Since TLS is a connection-oriented protocol, compression state can be maintained from one packet to the next, thereby improving compression ratio. 3.4 Application Layer Security There are several examples of application layer security. Clearly, any application which has requirements for confidentiality in its data flow can implement encryption technology to meet such a security requirement. One example of this is an email application. A secure email client is capable of encrypting messages sent from one host to another. PGPmail [PGPMan], a security add-on to many popular email client products, is one such example. PGPmail provides the capability to compress mail prior to encrypting it. No doubt, this is due to the realization of its developers that subsequent attempts to compress the data at lower layers in the protocol stack will be rendered ineffective. 4. Does Compression Fall Within the Scope of the Working Group? There are several issues which surround the question of whether the IPSec working group should directly consider the issue of applying compression to the IPSec protocols. The IPSec working group charter specifically states: Monsour, et al [Page 5] INTERNET DRAFT Compression in IP Security March 1996 A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to- subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol. The problem definition in section 2 describes the "problem" in terms of the affect of IPSec on a lower-layer protocol. While this is indeed true, it is unclear whether the obligation to provide the detailed protocol "fix" to correct the problem lies within the scope of the IPSec working group. While progress is being made, it is also true that the IPSec specifications have been not been stable and available in a manner to support widespread interoperable implementations (as has been noted by various members of the working group). The user community has indicated their requirement that compression capabilities be "supported" by IPSec implementations. The specific methods used to provide such support are clearly in the scope of the working group to decide. There is currently discussion underway (within the IETF) to explore the application of compression in TCP. This raises a question regarding the potential to provide a consistent mechanism for supporting compression across these two closely- related protocols (TCP & IP). 5. Requirements for Applying Compression to IPSec As noted earlier, the use of encryption at any protocol layer above the data link layer renders PPP compression ineffective. This leads to the need to support the use of compression in the context of IPSec. The question then becomes one of how to provide this support. An understanding of the problem, the approaches taken in other protocol environments, the emerging discussion of compression support in TCP, and the discussions on the mailing list lead to the definition of the following requirements for the technical Monsour, et al [Page 6] INTERNET DRAFT Compression in IP Security March 1996 approaches to support compression in IPSec. 5.1 Negotiated Algorithm Regardless of the protocol for which compression support is provided, a method is required for the two communicating parties to negotiate both the use and the type of compression to be applied to the packets. 5.2 Stateless AND Stateful Compression Since IP is a connectionless/stateless protocol, it is important that each compressed packet be capable of being decompressed independently of any other packet; i.e., the successful decompression of a packet must not depend on the contents of any other packet(s), nor should it depend on order of receipt of any other packet(s). The development of a consistent approach to providing compression capabilities to both IPSec and TCP should support the use of stateful compression in the TCP context. TCP's connection orientation can guarantee packet ordering and thus achieve higher compression ratios. 5.3 Compressed Packet Indicator Once the use of compression is negotiated between two communicating parties, the sender must have the flexibility to determine whether or not to compress each packet. Such flexibility requires a per-packet indication of whether or not the packet is compressed. 5.4 Compatibility with Existing and Emerging Implementations Changes to the IPSec protocol definitions to support compression must not not break any existing implementation. This means that for an implementation to be compression-capable, it will have to be modified, but it will remain compliant with the IPSec protocols without the addition of compression support. This requirement becomes more desirable with the passage of time, as more and more implementations are developed and deployed. 5.5 Optional Use of Compression This requirement derives from the previous requirement. If an existing implementation is to be considered compliant with the IPSec protocol, then it MUST NOT be required to provide support for compression. Monsour, et al [Page 7] INTERNET DRAFT Compression in IP Security March 1996 5.6 Ability to Optimize Compression Across Protocol Layers The use of compression at several layers in the protocol stack can cause inefficiencies in the processing by sending systems. For example, in an environment where application layer compression is in use, it is desirable to communicate to the lower layer protocols that the data is already compressed and that the lower layers need not attempt to compress (read as "waste cycles"). Thus, support for compression in IPSec shall be provide the capability for "turning compression on or off" through some mechanism of inter-layer communication. 5.7 Anti-Expansion of Payload Data It is not possible in all instances to pre-determine if a payload has already been compressed at a higher layer. Future protocol changes could support such a pre-determination. Until then, a mechanism for detecting the expansion of data and optionally sending the original uncompressed payload is required. 6. Alternative Approaches to the Use of Compression in IPSec Two general technical approaches to meet the requirements outlined in previous section have been presented to the working group and subsequently debated on the mailing list. These two approaches are described below along with their relative advantages and disadvantages. 6.1 Layered Architecture Using a Separate Compression Header This approach involves the use of a separate compression header which would follow the IP header and precede the AH and/or ESP header(s). The header would provide all the fields necessary to support compression of either AH and/or ESP payloads as well as support for compression in TCP. 6.2 Optional Feature of ESP This approach is based on the fact that it is the encryption of ESP payloads which renders downstream compression techniques ineffective. This approach is limited to only compressing ESP payloads and does not extend naturally to any upper layer protocols. 6.3 Comparison of the Two Approaches Below is a comparison of the advantages and disadvantages of the two approaches. Monsour, et al [Page 8] INTERNET DRAFT Compression in IP Security March 1996 Advantages Disadvantages ----------------------------------------------------------------- Layered not tied to use some delay in getting Architecture of encryption; i.e., to a standard works with AH payloads as well can be applied to upper layer protocols such as TCP in addition to IPSec routers can more easily determine if a packet is compressed without knowledge of IPSec protocol details Optional Easily defined due to doesn't map well for Feature its limited scope use in upper layer protocols of ESP tied to use of security protocols requires routers to know IPSec to avoid compression processing overhead 7. Which Approach Meets the Proposed Requirements? This section describes how the two approaches described in the previous section meet each of the requirements defined in section 5. 7.1 Negotiated Algorithm Both approaches meet this requirement. ISAKMP provides a method for algorithm negotiation which can easily be extended to support the negotiation of the use and type of compression. In the TCP context, TCP negotiation would be extended to negotiate the use and type of compression. 7.2 Stateless AND Stateful Compression IPSec compression MUST be stateless. Both approaches support this concept. TCP, as a connection-oriented protocol, can support stateful compression and achieve higher compression ratios as a result. The use of the layered architecture approach makes stateful TCP compression possible. Monsour, et al [Page 9] INTERNET DRAFT Compression in IP Security March 1996 7.3 Compressed Packet Indicator In the layered architecture approach, the compression header would contain a field to indicate whether or not the packet is compressed. In the ESP option approach, the most-significant bit of the pad length field has been proposed to serve this function. 7.4 Compatibility with Existing and Emerging Implementations Since compression is a negotiated option in both approaches, they both meet this requirement. Existing implementations will not negotiate to use compression and will continue to interoperate with new and existing IPSec compliant implementations. 7.6 Ability to Optimize Compression Across Protocol Layers The layered architecture approach meets this requirement. The ESP option approach sacrifices the opportunity to develop a single method for compressing across IP and TCP layer protocol. 7.7 Anti-Expansion of Payload Data Both approaches can meet this requirement. 8. Conclusions The authors have drawn the following conclusions based on discussions with user community members, analysis of the proposed technical approaches, and the emerging need to broaden the use of compression beyond the IPSec context. - The need for compression in the IPSec context exists. The effect of IPSec encryption on downstream compression and the demands by members of the user community demonstrate a clear need for supporting compression in an IPSec context. - The compression topic does not distinctly fall in the charter of the IPSec working group. - A layered architecture approach is a superior approach when compared to the ESP option approach to problem of providing compression capabilities in the IPSec context. 9. Recommendations The authors recommend the following course of action. Monsour, et al [Page 10] INTERNET DRAFT Compression in IP Security March 1996 - Document the IPSec Architecture to Support Optional Compression It is important that the IPSec architecture specification include the notion that payload data of IPSec payloads may optionally be compressed. The draft should note that the specification for providing such compression capabilities will be developed outside of the IPSec working group. - Develop a Layered Architecture Approach to Compression A layered architecture approach, when considered against the ESP option approach has significant advantages which outweigh any potential delays in specification development and subsequent deployment. - Establish a compression working group This group would take on the responsibility for defining a the layered architecture and the separate compression header for use in IPSec as well as other candidate upper layer protocols. The rationale for this recommendation is based on several factors, including (1) the user community as well as the vendor community are under pressure to finalize the IPSec specifications, complete development and begin deployment of IPSec-compliant products. As Hugo put in a recent post to the list, "...further delay of ipsec deployment (which is also a form of denial-of-service attack :)", (2) the desire to support compression in a context broader than IPSec alone (i.e., TCP or other candidate protocols), and 10. Security Considerations This memo discusses the use of lossless compression technology in a security protocol, specifically IPSec. The proposed use of compression within this protocol is not believed to have an effect on the underlying security functionality provide by the protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it. The use of compression does change the length of ESP payloads, in a manner that depends on the data prior to encryption. Thus, the use of compression may have an effect on the ability of an eavesdropper to glean information by analyzing the length of transmitted packets. 11. References [IPSecArch] Atkinson, R., "Security Architecture for the Internet Protocol," November 1996. Monsour, et al [Page 11] INTERNET DRAFT Compression in IP Security March 1996 [Dec96WG] Lambert, P., Minutes of the IPSec Working Group, San Jose December 1994. [Thayer] Thayer, R., "Compression Header for IPSec", draft-thayer-seccomp-00.txt, May, 1996. [Sabin1] Sabin, M., Monsour R., " [Sabin2] Sabin, M., Monsour R., " [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)," RFC-1962, June 1996. [RFC2068] ????, "Hypertext Transport Protocol version 1.1", January, 1997. [RFC1968] ????, "The PPP Encryption Control Protocol (ECP)", June 1996. [PPPEXT] Point-to-Point Protocol Extensions Working Group Charter. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-01.txt, March 1997. [PGPMan] ????, "PGPmail Reference Manual" [AH] Atkinson, R., "IP Authentication Header" [ESP] Atkinson, R., "IP Encapsulating Security Payload," June 1996. [DOI] Piper, D., "IPSec Domain of Interpretation", March 1997. [Calgary] Text Compression Corpus, University of Calgary, available at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. 8. Authors' Addresses Robert Monsour Hi/fn Inc. 12636 High Bluff Drive San Diego, CA 92130 Email: rmonsour@hifn.com Michael Sabin 883 Mango Avenue Sunnyvale, CA 94087 Email: mike.sabin@worldnet.att.net Monsour, et al [Page 12] INTERNET DRAFT Compression in IP Security March 1996 Abraham Shacham Cisco Systems 101 Cooper Street Santa Cruz, CA 95060 Email: shacham@cisco.com Sanjay Anand Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: sanjayan@microsoft.com Rodney Thayer Sable Technology 246 Walnut Street Newton, MA 02160 Email: rodney@sabletech.com Monsour, et al [Page 13] From owner-ipsec Fri Mar 28 13:42:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08361 for ipsec-outgoing; Fri, 28 Mar 1997 13:42:19 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703272334.PAA00564@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 27, 97 03:22:38 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 13:47:06 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: new ESP spec (bigger message) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >> 2.4 Payload Data >This isn't a real problem for IPv6. The reason for the 8-byte alignment >drive in IPv6 was to make fast-path processing faster. (Those of us with >UltraSPARC appreciate this.) Since ESP is already beating down the slow >path, this isn't as huge of a deal as one might think at first. Also, a >properly formed IPv6 datagram will be 8-byte aligned once you strip out the >ESP cruft after decryption. > >There's always crypto-algorithm alignment issues, but I leave those to the >crypto wizards. Good to hear that view from an IPv6 perspective, but we are crypto people too! >> 3.2.4.3 Authentication Algorithms >Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do >so, but I sometimes miss these things. We were going for consistency here. There's no reason to believe that if 96 bits is good enough for authentication/integrity in AH that it isn't good enough for the same services in ESP. Steve From owner-ipsec Fri Mar 28 13:44:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08381 for ipsec-outgoing; Fri, 28 Mar 1997 13:44:50 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703272247.OAA00326@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 27, 97 03:22:08 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 13:47:45 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: new AH spec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >Looks good so far. The bit about "piecemeal" might be a bit strong, but >that's really hairsplitting. I'm not trying to be negative, just accurate in my description of the way in which Ah is computed over portions of the IP header, zero-filling others, etc. >Mostly, the NULL authentication algorithm is used for testing of protocol >plumbing. I don't expect any shipping product to have a null authentication >algorithm. I do expect AH implementations that are in their nascent stages >to have a null authentication algorithm. Interpret this data as you will >w.r.t. how the spec should read. I think if NULL is used only for testing, it would be better not to have it as a cited transform/algorithm. >A zero SPI is useful for any number of implementation-specific aids. An >example I can think of off the top of my head is that if my >getassocybyendpoint() call for an outgoing datagram returns an association >with a zero SPI, I can interpret this as any number of results (including, "I >just kicked key management in the rear, I'll get back to you.") As above, if a zero SPI will never appear on the wire (fiber?), I'd rather not specify it here. What you describe is a local interface matter. >I know certain people who have issues about having this field NOT being >present. I don't have a problem with this, but I suspect the people who have >these issues will speak up. Yes, documents have clearly diverged re the presence or absence of this field and I'm going with the interpretation we adopted for ESP, i.e., if the servuce is not negotiated, the field is absent. >BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return >to this upper-layer protocol idea in a bit. Yep! We'll add ESP as an obvious additional example. I'll leave the resolution of IPv6 header element ordering to those more knowledgable in the intricacies of that protocol. >This sentence is more important than is apparent at first. An implementation >can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps >reduce some of the special-casing for IP as the inner payload. It doesn't >_ELIMINATE_ it, but it can reduce it. > >(For example, if you have A->B with the inner IP saying A->B, you can make >stronger assertions than if the inner packet says something else.) We can emphasize this point if you think it's important and does not receive enough attention here. >As an aside, I'd strongly encourage to look at the current implementations >out there, as well as some of the analysis literature. I suspect you've >already done your homework on this front and will be drawing on their >experience when you finish rewhacking the architecture document. The implementations I have seen so far do not seem to provide the sort of granularity that Ran's previous architecture I-D called for, and that I called for in my talk at the last IETF WG, etc. But I am going on what I've seen at the trade shows, not the bakeoffs, so I hope we are closer than I fear. >Do you have any recommendations for when the sequence number cycles? (Kick >key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.) I'm tempted to say that cycling is an error, and that key managememtn should have been kicked sooner. The architecture document can address this in more detail, or we can say something more definite here is there is concensus. >Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after >reassembly! The question of DF is perhaps why the decision was made to just >zero out that bit too. I think we agree on the basic premise. Note that if a security gateway fragments a packet with AH applied already, it will be using tunnel mode, so the DF bit covered by the inner AH is not an issue here. We will be sending out a message iscussion DF and PMTU after Memphis. >IMHO, new IPv6 extensions should document their own AH properties. Keep in >mind this is IMHO only. I like this as an answer; it allows it to reach closure on this document. >Thank you! We in IPv6-land appreciate this. You're welcome. >As an aside, has anyone tackled this? A lightweight digital signature >algorithm would be perfect in a multicast environment with a small number of >senders compared with an arbitrary number of receivers. This is a hard problem is we look for digital signature solutions, but maybe we'll get lucky. ECC signatures are faster and smaller, but ... Are you suggesting solutions that are not digital signature based? I ask only because of your comment re the number of possible senders, which would seem not to be an issue if we use a real signature algorithm. >Like I mentioned before, as currently written, these I-Ds _always_ include >the replay counter. The replay counter is set to 0 for associations that >don't use replay. The I-Ds cited are not ones that inlude references to counters, AH, etc. They are raw algorithms I-Ds, which is just what we want for this style of specification. The issue of the presence or absence of the replay counter should be with separately, in this document. >Ummm, what if I live in a multithreaded world? I can theoretically get two >packets near-concurrently with the same sequence number. If the bogus one >arrives first, do I trash the good one just because one with the same replay >number arrived first? Or do I not count a sequence number as "good" until >I've authenticated? Or is this just an implementation detail? Or is this >why it says SHOULD rather than MUST? We can make mention earlier of the need to authentciate prior to accepting a packet, as you observed later. Steve From owner-ipsec Fri Mar 28 18:51:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10293 for ipsec-outgoing; Fri, 28 Mar 1997 18:47:09 -0500 (EST) Message-ID: <01BC3B90.23A3D480@nomad16.nomadix.com> From: Andrew Everett To: "'ipsec@tis.com'" Subject: Call for Presentations - SIP & Security for Mobile Users Date: Fri, 28 Mar 1997 15:53:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Speakers are sought for a half-day tutorial on Security for Mobile Users and and a conference session on Secure IP at the upcoming Nomadic 97 conference. The theme of the conference is Enabling Mobility on the Internet and Intranets and will take place August 25-28, 1997 in Santa Clara, California. Interested parties may inquire about speaking opportunities by sending an e-mail to Andrew Everett at aeverett@tticom.com. From owner-ipsec Sun Mar 30 15:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20789 for ipsec-outgoing; Sun, 30 Mar 1997 15:18:35 -0500 (EST) Date: Sun, 30 Mar 97 20:16:52 GMT Daylight Time From: Ran Atkinson Subject: Re: new ESP spec (bigger message) To: Charles Lynn , ipsec@tis.com Cc: Dan McDonald X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703280400.XAA04513@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, Since the alignment question is one driven by the IPng community, it seems to me that the right approach to this question includes at least: (1) posting a note to both IPsec and IPng lists announcing the new drafts and raising the alignment question (2) asking that all followup notes be cross-posted to both lists so that both communities see all the discussion (3) understanding that consensus in BOTH WGs on this question is a prerequisite for considering this matter resolved. Ran rja@inet.org From owner-ipsec Sun Mar 30 15:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20782 for ipsec-outgoing; Sun, 30 Mar 1997 15:13:36 -0500 (EST) Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time From: Ran Atkinson Subject: Re: new AH spec To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703272257.AA18146@ash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe, "An SPI value of zero indicates no Security Association exists." is a very useful part of the IPsec specificationS. By definition, this SPI value is NEVER used in a packet sent on the wire. It is extremely useful, however, to have a single reserved SPI value that can be optionally used for implementation-specific purposes inside some implementation. In practice, changing or removing this sentence will cause existing fully conforming implementations to become non-conforming (which is something that the IETF does NOT generally do unless the prior statement has some fatal operational flaw, which this reserved value does not). Ran rja@inet.org From owner-ipsec Mon Mar 31 09:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26068 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:01 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-new-esp-00.txt Date: Mon, 31 Mar 1997 09:35:18 -0500 Message-ID: <9703310935.aa04772@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 Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-new-esp-00.txt Pages : 17 Date : 03/28/1997 The Encapsulating Security Payload (ESP) header is designed to provide a mix of optional security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-new-esp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-esp-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-ipsec-new-esp-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: <19970328110738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-new-esp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-new-esp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970328110738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 31 09:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26074 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:31 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-new-auth-00.txt Date: Mon, 31 Mar 1997 09:35:20 -0500 Message-ID: <9703310935.aa04792@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 Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-new-auth-00.txt Pages : 15 Date : 03/28/1997 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-new-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-auth-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-ipsec-new-auth-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: <19970328111608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-new-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-new-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970328111608.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 31 12:36:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26978 for ipsec-outgoing; Mon, 31 Mar 1997 12:35:51 -0500 (EST) From: touch@isi.edu Date: Mon, 31 Mar 1997 09:41:01 -0800 Posted-Date: Mon, 31 Mar 1997 09:41:01 -0800 Message-Id: <199703311741.AA01725@ash.isi.edu> To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu, rja@inet.org Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From rja@inet.org Sun Mar 30 12:19:08 1997 > Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time > From: Ran Atkinson > Subject: Re: new AH spec > To: Dan.McDonald@eng.sun.com, kent@bbn.com, touch@isi.edu > Cc: ipsec@tis.com > X-Priority: 3 (Normal) > References: <199703272257.AA18146@ash.isi.edu> > > > Joe, > > "An SPI value of zero indicates no Security Association exists." is a > very useful part of the IPsec specificationS. By definition, this SPI > value is NEVER used in a packet sent on the wire. It is extremely useful, > however, to have a single reserved SPI value that can be optionally > used for implementation-specific purposes inside some implementation. Sure - that part is clear. The SPI value of 0 is to the API, but there is never a case when the value needs to be stored in the field. This should be made clear in section 2.4 of the draft. > In practice, changing or removing this sentence will cause existing fully > conforming implementations to become non-conforming (which is something > that the IETF does NOT generally do unless the prior statement has > some fatal operational flaw, which this reserved value does not). Given that there's already a revision of the RFC in progress, this statement is of little significance. Fully conforming to WHICH - the new or old spec? PS - in that vein, why does the new draft have no references to RFC 1826, even though it has the same title? Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Mon Mar 31 15:51:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28370 for ipsec-outgoing; Mon, 31 Mar 1997 15:50:32 -0500 (EST) Message-Id: <2.2.32.19970331210326.00bddb34@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: Mon, 31 Mar 1997 16:03:26 -0500 To: Bill Sommerfeld From: Naganand Doraswamy Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >We merely need to specify that the IP checksum MUST be supplied on >transmission and verified on receipt for packets nested inside ESP. > I think IPv6 does not do any checksum. It depends on the upper layer protocols to perform checksums. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Mon Mar 31 15:51:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28349 for ipsec-outgoing; Mon, 31 Mar 1997 15:45:54 -0500 (EST) Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time From: Ran Atkinson Subject: Re: new AH spec To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703311741.AA01725@ash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe, The notion is that the _revised_ AH/ESP specifications should be written such that existing implementations that conform fully to RFC-1825 through RFC-1827 are NOT made non-conforming except for very very good reason (e.g. a specific known cryptographic attack). My understanding from Steve Kent during and since Montreal has always been that his revisions would have the above property -- except as required to fix specific publicly-known attacks on the existing RFCs. Ran rja@inet.org From owner-ipsec Mon Mar 31 17:21:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28888 for ipsec-outgoing; Mon, 31 Mar 1997 17:20:54 -0500 (EST) From: touch@isi.edu Date: Mon, 31 Mar 1997 14:26:10 -0800 Posted-Date: Mon, 31 Mar 1997 14:26:10 -0800 Message-Id: <199703312226.AA08928@ash.isi.edu> To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu, rja@inet.org Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From rja@inet.org Mon Mar 31 12:51:22 1997 > Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time > From: Ran Atkinson > Subject: Re: new AH spec > To: Dan.McDonald@eng.sun.com, kent@bbn.com, rja@inner.net, touch@ISI.EDU > Cc: ipsec@tis.com > X-Priority: 3 (Normal) > References: <199703311741.AA01725@ash.isi.edu> > > > Joe, > > The notion is that the _revised_ AH/ESP specifications should be > written such that existing implementations that conform fully to > RFC-1825 through RFC-1827 are NOT made non-conforming except for > very very good reason (e.g. a specific known cryptographic attack). maybe a paragraph indicating this goal would be appropriate, and certainly the revised specs should refer directly to the original specs Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Mon Mar 31 19:11:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29445 for ipsec-outgoing; Mon, 31 Mar 1997 19:06:16 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703312226.AA08928@ash.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 1997 19:11:26 -0500 To: touch@isi.edu, rja@inet.org From: Stephen Kent Subject: Re: new AH spec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe + Ran, It was an oversight on my part that we did not reference the original AH and ESP specs, and that will be remedied in our next round of revisions. We also can add a section to provide a brief overview of format/processing differences between the old and new verisons, to make reading easier for those already familiar with the current RFCs. As per Ran's clarifying comments, we will re-wrod the specs to make clear that an SPI of 0 is for internal use, not for transmission on the wire. Steve From owner-ipsec Mon Mar 31 22:03:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00507 for ipsec-outgoing; Mon, 31 Mar 1997 22:02:45 -0500 (EST) Message-Id: <199704010307.WAA06277@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Naganand Doraswamy Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: naganand's message of Mon, 31 Mar 1997 16:03:26 -0500. <2.2.32.19970331210326.00bddb34@mailserv-H.ftp.com> Date: Mon, 31 Mar 1997 22:07:13 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I think IPv6 does not do any checksum. It depends on the upper layer > protocols to perform checksums. Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the ones-complement checksum, right? - Bill From owner-ipsec Mon Mar 31 22:34:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00700 for ipsec-outgoing; Mon, 31 Mar 1997 22:34:05 -0500 (EST) Message-Id: <199704010338.WAA04898@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Bill Sommerfeld cc: Naganand Doraswamy , daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Mon, 31 Mar 1997 22:07:13 EST." <199704010307.WAA06277@thunk.ch.apollo.hp.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 31 Mar 1997 22:38:24 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > I think IPv6 does not do any checksum. It depends on the upper layer > > protocols to perform checksums. > > Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the > ones-complement checksum, right? Yes. From owner-ipsec Tue Apr 1 14:46:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06195 for ipsec-outgoing; Tue, 1 Apr 1997 14:26:38 -0500 (EST) Message-Id: <199704011932.LAA28570@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: MUST vs. SHOULD audit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Apr 1997 11:32:10 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, This is taken from draft-ietf-ipsec-auth-04.txt but there is similar wording in the esp draft as well so my comments apply there too. From section 3.3.2 Security Association Lookup: > If no valid Security Association exists for this session (e.g., the > receiver has no key), the receiver MUST discard the packet and the > failure MUST be recorded in an audit log. I don't want to discount the wisdom of auditing (and am, in fact, all in favor of it) but I don't want to see an otherwise conforming implementation be rendered non-conforming simply because it didn't audit. Some devices which provide IPsec have no harddisk and a limited amount of memory (e.g. a router) and auditing of packets that arrive for which no valid SA exists opens one up to a denial-of-service attack. I propose that "the failure MUST be recorded" be changed to "the failure SHOULD be recorded". Also, section 3.3.3 Sequence Number Verification states: > If the received packet falls within the window, then the receiver > proceeds to ICV verification. If the ICV validation fails, the > receiver MUST discard the received IP datagram as invalid and MUST > record the authentication failure in an audit log. I believe the 2nd sentence should begin, "If the sequence number check fails...." since the next section, 3.3.4 Integrity Check Value Verification states: > If the computed and received ICV's match, then the datagram is valid, > and it is accepted. If the test fails, then the receiver MUST > discard the received IP datagram as invalid and MUST record the > authentication failure in an audit log. Of course, I would also like those two references to "MUST audit" be changed to "SHOULD audit". regards, Dan. From owner-ipsec Tue Apr 1 16:00:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06752 for ipsec-outgoing; Tue, 1 Apr 1997 15:52:40 -0500 (EST) Date: Tue, 1 Apr 1997 15:55:36 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704012055.PAA15379@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704012006.NAA23247@baskerville.CS.Arizona.EDU> Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk An implementation that is not capable of auditing these events wouldn't conform to the expectations of the community. What I'd think would be reasonable would be to say that if the platform has an audit facility, these events must be logged. This leaves open the possibility of tailoring the logging rate for this event type to the system administrator. After all, IPSEC is unlikely to be the only way to introduce denial of service through excessive logging, so the audit system must already be capable of dealing with such things. If there is no audit facility, should one say that IPSEC cannot be implemented on that platform? Seems drastic, but less drastic than requiring that IPSEC implementations carry a full audit log capability along with them. Hilarie From owner-ipsec Tue Apr 1 16:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06964 for ipsec-outgoing; Tue, 1 Apr 1997 16:19:58 -0500 (EST) Date: Tue, 1 Apr 1997 16:22:07 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704012122.QAA16158@earth.hpc.org> To: HUGO@watson.ibm.com Cc: iesg@ietf.org, IPSEC@tis.com, DHARKINS@cisco.com, carrel@ipsec.org, RJA@inet.org, PALAMBER@us.oracle.com, CANETTI@watson.ibm.com In-reply-to: Yourmessage <199703250456.VAA15742@baskerville.CS.Arizona.EDU> Subject: Re: oakley-03: last call comments Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree that the first recommendation in its entirety is very important and must be implemented. Hilarie From owner-ipsec Tue Apr 1 16:50:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07275 for ipsec-outgoing; Tue, 1 Apr 1997 16:39:40 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704011932.LAA28570@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 1997 16:44:10 -0500 To: Daniel Harkins From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I was worried about the MUSTs in both documents re auditing and potential denial of service implications, but chose to copy them and hope for feedback from the WG. I'd be comfortable with a spec that required logging if the platform already supported audit, but I'm up in the air re the right requirement if the platform does not perform audit. If marking this case as SHOULD would make folks happy, I'm certainly comfortable with that sort of change, though I'm not sure what the bottom line effect would be. Thanks for catching the "ICV" vs. "sequence number" check typo. Steve From owner-ipsec Tue Apr 1 16:50:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07283 for ipsec-outgoing; Tue, 1 Apr 1997 16:40:36 -0500 (EST) Message-Id: <199704012145.NAA28713@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Tue, 01 Apr 1997 15:55:36 EST." <199704012055.PAA15379@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Apr 1997 13:45:42 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, My feeling is that auditing is a local matter and not part of the protocol. > An implementation that is not capable of auditing these events > wouldn't conform to the expectations of the community. What I'd think > would be reasonable would be to say that if the platform has an audit > facility, these events must be logged. This leaves open the > possibility of tailoring the logging rate for this event type to the > system administrator. After all, IPSEC is unlikely to be the only way > to introduce denial of service through excessive logging, so the audit > system must already be capable of dealing with such things. I think the market will decide what the expectations of the community are. > If there is no audit facility, should one say that IPSEC cannot be > implemented on that platform? Seems drastic, but less drastic than > requiring that IPSEC implementations carry a full audit log capability > along with them. That's really drastic. If an implementation does all the mandatory transforms and the mandatory key management and interoperates with every other implement- ation are you saying that it's not IPsec because it doesn't audit? It's a wise thing to audit (and an even wiser thing to be able to tailor a logging rate) and there should be mention of it as a security recommendation in the drafts, but I don't feel such a local matter which does not affect the bits-on-the-wire should be part of the definition of what makes you IPsec-compliant. Dan. From owner-ipsec Tue Apr 1 17:16:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07628 for ipsec-outgoing; Tue, 1 Apr 1997 17:15:24 -0500 (EST) From: Uri Blumenthal Message-Id: <9704012220.AA31931@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: dharkins@cisco.com (Daniel Harkins) Date: Tue, 1 Apr 1997 17:20:32 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199704012145.NAA28713@dharkins-ss20> from "Daniel Harkins" at Apr 1, 97 01:45:42 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 Daniel Harkins says: > My feeling is that auditing is a local matter and not part of the > protocol. I support this. > > would be reasonable would be to say that if the platform has an audit > > facility, these events must be logged....... I think that IPSEC defines the protocol. How much of the exchange should be logged (if at all) is personal business of the implementor. Different buyers may have different req's wrt. this and make their purchasing choice accordingly. Still, it's not IPSEC's business. > > If there is no audit facility, should one say that IPSEC cannot be > > implemented on that platform? Of course not. One should not say anything, except: "THIS IS AN IMPLEMENTATION-SPECIFIC ISSUE". If you want it to be REMOTELY controlled, then it's a remote management issue, which again, isn't really part of IPSEC. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Tue Apr 1 18:03:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07862 for ipsec-outgoing; Tue, 1 Apr 1997 18:00:13 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704012305.PAA03949@kebe.eng.sun.com> Subject: Re: MUST vs. SHOULD audit To: ipsec@tis.com Date: Tue, 1 Apr 1997 15:05:30 -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 > My feeling is that auditing is a local matter and not part of the > protocol. I have to agree with Dan on this one. *I* have logging facilities and will do my best to log where I can. OTOH, a small system, like a router or perhaps a Javastation, won't necessarily have all of these capabilities. > there should be mention of it as a security recommendation in the drafts, Great idea! This is the sort of issue the _Security Recommendations_ are for. Dan McD. (disambiguating token added) From owner-ipsec Tue Apr 1 19:09:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08205 for ipsec-outgoing; Tue, 1 Apr 1997 19:08:05 -0500 (EST) Message-ID: <3341A51E.4EFC@htc.sj.nec.com> Date: Tue, 01 Apr 1997 16:15:26 -0800 From: Bill Pabst Reply-To: bpabst@holontech.com Organization: Holontech X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Hilarie Orman CC: dharkins@cisco.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704012055.PAA15379@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Would this be something that could be enabled/disabled through a Radius Server with its audit and accounting capibilities? New to the Group. Bill From owner-ipsec Tue Apr 1 19:33:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08347 for ipsec-outgoing; Tue, 1 Apr 1997 19:33:37 -0500 (EST) Message-Id: <199704020037.QAA00806@fluffy.cisco.com> To: ipsec@tis.com Subject: auditing Date: Tue, 01 Apr 1997 16:37:41 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Auditing is obviously a host-system issue and outside of the scope of the network protocol or IPSEC architecture document(s). However, there's nothing wrong with pointing out where a host should perform auditing, if it's capable of doing so. In this spirit, it would seem more appropriate for the specs to read SHOULD instead of MUST. Derrell From owner-ipsec Wed Apr 2 10:20:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13719 for ipsec-outgoing; Wed, 2 Apr 1997 10:17:44 -0500 (EST) Date: Wed, 2 Apr 1997 10:20:18 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021520.KAA18004@earth.hpc.org> To: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk Of course interoperability is the main point of the spec, but is the discussion so far well-founded? I'm a little confused by the responses --- most seem comfortable having the audit requirement mentioned, as long as it's "should", but a "must" is declared out of scope for a protocol specification. That doesn't seem logical; if you're in for a "should", then you're in for a "must". If there is an important security-related protocol event, it seems to me on technical grounds that it "must" be logged, if at all possible. If that can't be said in the protocol specification, then it "must" go somewhere else. If the logging is deemed crucial, then we can discuss where to put the requirement, I suppose. I'd thought the group would have interest in whether or not receipt of an invalid SA identifier (or any similar event) is significant enough to require logging. I'd thought the reason in favor would be that anything that seemed to indicate an attempt to explore the valid security states of the host would probably indicate an attack attempt, and it would be critically important to notify the administrator, if at all possible. And I'd thought the argument against would be that the built-in safeguards are strong enough to render such attempts feeble and useless. I can appreciate the reasons for the "should" preference on grounds of scope, but maybe the requirements for security protocol implementations "should" be more stringent. Not so stringent as to constitute denial of solution, but something more than an SEP* nod to security technology that is not evident on-the-wire. Hilarie * Somebody Else's Problem, cit. Douglas Adams From owner-ipsec Wed Apr 2 10:27:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13783 for ipsec-outgoing; Wed, 2 Apr 1997 10:27:19 -0500 (EST) Message-Id: <3.0.1.32.19970402101620.0072de94@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 02 Apr 1997 10:16:20 -0500 To: Derrell Piper From: Rodney Thayer Subject: Re: auditing Cc: ipsec@tis.com In-Reply-To: <199704020037.QAA00806@fluffy.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I think auditing is WITHIN scope since as an IETF WG we've been told we need to address all those real-world issues a draft is supposed to cover, including network management. Auditing is one form of network management. In fact, we should have our own SNMP MIB and be generating (in my opinion optional) traps at theses points where the docs reference auditing. [Refer to Bradner's talk at the San Jose IETF meeting for my thinking we've been told we should consider network management.] At 04:37 PM 4/1/97 -0800, you wrote: >Auditing is obviously a host-system issue and outside of the scope of the >network protocol or IPSEC architecture document(s). However, there's >nothing wrong with pointing out where a host should perform auditing, if >it's capable of doing so. In this spirit, it would seem more appropriate >for the specs to read SHOULD instead of MUST. > >Derrell > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Wed Apr 2 12:29:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14681 for ipsec-outgoing; Wed, 2 Apr 1997 12:26:28 -0500 (EST) Date: Wed, 2 Apr 97 17:18:56 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Daniel Harkins Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704011932.LAA28570@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk [co-chair hat off; IPsec implementer and former cisco coder hat on :-] Dan, Ciscos do have the ability to record events to logging hosts that are outside the router which do have non-volatile storage (an SNMP trap is an example of such a mechanism[1], though cisco IOS has other possibilities in addition). This would fully meet the requirement of "MUST audit" as currently written in the draft. Note also that, this is not a new requirement as it exists also in the current RFCs which were previously agreed to by this WG. Past experience in security-related IETF documents is that anything not made "MUST implement" is generally not implemented. As you note, auditing is an important property of an IPsec implementation because it is a good way of detecting important security-relevant events (e.g. a denial of service attack on the cisco that causes the router to spend cycles computing MD5 over forgeries instead of forwarding packets). If the language is changed at all (which I don't believe is best), I'd propose changing it to something like "IPsec implementations having access to non-volatile storage MUST audit... and all other implementations SHOULD audit...". Ran rja@inet.org [1] In the absence of SNMP security, an SNMP trap is not the best choice for security-related logging, IMHO. From owner-ipsec Wed Apr 2 12:36:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14736 for ipsec-outgoing; Wed, 2 Apr 1997 12:35:33 -0500 (EST) Message-Id: <199704021740.JAA00327@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 10:20:18 EST." <199704021520.KAA18004@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 09:40:08 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Of course interoperability is the main point of the spec, but is the > discussion so far well-founded? I'm a little confused by the > responses --- most seem comfortable having the audit requirement > mentioned, as long as it's "should", but a "must" is declared out of > scope for a protocol specification. That doesn't seem logical; if > you're in for a "should", then you're in for a "must". Well, no. There's language in the drafts for "MUST", "SHOULD", and "MAY" for a reason. They're not all the same and being in for "SHOULD" does not make you in for "MUST". [snip] > I can appreciate the reasons for the "should" preference on grounds of > scope, but maybe the requirements for security protocol > implementations "should" be more stringent. Not so stringent as to > constitute denial of solution, but something more than an SEP* nod to > security technology that is not evident on-the-wire. I'm confused now. Are you saying that an implementation that implements all the mandatory transforms and the mandatory key management and interoperates with every other "IPsec compliant" implementation is itself not "IPsec compliant" because it doesn't do auditing? Dan. From owner-ipsec Wed Apr 2 12:46:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14797 for ipsec-outgoing; Wed, 2 Apr 1997 12:45:06 -0500 (EST) Date: Wed, 2 Apr 1997 12:47:57 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021747.MAA22459@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704021740.JAA00327@dharkins-ss20> Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not taking much of a stand on the issue of whether or not auditing should be required, it's more the form of the debate that is at issue. > > Of course interoperability is the main point of the spec, but is the > > discussion so far well-founded? I'm a little confused by the > > responses --- most seem comfortable having the audit requirement > > mentioned, as long as it's "should", but a "must" is declared out of > > scope for a protocol specification. That doesn't seem logical; if > > you're in for a "should", then you're in for a "must". > Well, no. There's language in the drafts for "MUST", "SHOULD", and "MAY" > for a reason. They're not all the same and being in for "SHOULD" does not > make you in for "MUST". No, I'm just saying that if a sentence containing "should" is in scope then "must" also would be in scope. > > I can appreciate the reasons for the "should" preference on grounds of > > scope, but maybe the requirements for security protocol > > implementations "should" be more stringent. Not so stringent as to > > constitute denial of solution, but something more than an SEP* nod to > > security technology that is not evident on-the-wire. > I'm confused now. Are you saying that an implementation that implements > all the mandatory transforms and the mandatory key management and > interoperates with every other "IPsec compliant" implementation is itself > not "IPsec compliant" because it doesn't do auditing? I'm saying that it is an allowable outcome of group discussion. Hilarie From owner-ipsec Wed Apr 2 12:48:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14869 for ipsec-outgoing; Wed, 2 Apr 1997 12:47:38 -0500 (EST) Message-Id: <97Apr2.125416est.11649@elgreco.rnd.border.com> To: ho@earth.hpc.org (Hilarie Orman) cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021520.KAA18004@earth.hpc.org> In-reply-to: Your message of "Wed, 02 Apr 1997 10:20:18 -0500". <199704021520.KAA18004@earth.hpc.org> From: "C. Harald Koch" 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: Wed, 2 Apr 1997 12:52:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704021520.KAA18004@earth.hpc.org>, Hilarie Orman writes: > Of course interoperability is the main point of the spec, but is the > discussion so far well-founded? I'm a little confused by the > responses --- most seem comfortable having the audit requirement > mentioned, as long as it's "should", but a "must" is declared out of > scope for a protocol specification. That doesn't seem logical; if > you're in for a "should", then you're in for a "must". >From RFC 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I'd postulate that "must if possible" is the same as "should", given these definitions of the words. -- Harald Koch From owner-ipsec Wed Apr 2 12:53:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14954 for ipsec-outgoing; Wed, 2 Apr 1997 12:52:10 -0500 (EST) Date: Wed, 2 Apr 97 17:33:59 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Bill Pabst , Hilarie Orman Cc: dharkins@cisco.com, ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3341A51E.4EFC@htc.sj.nec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Tue, 01 Apr 1997 16:15:26 -0800 Bill Pabst wrote: > Would this be something that could be enabled/disabled through a Radius > Server with its audit and accounting capibilities? > > New to the Group. > > Bill A fine idea. RADIUS has some transmission security built-in, hence might be a better choice than an insecure SNMP Trap. cisco routers support RADIUS Accounting as of (at least) IOS 11.2, as I've been learning lately. Another observation is that cisco implemented full DNSIX (a US DoD networking security protocol suite to support MLS with IP networks) a long while back (IOS 10.0 ? 9.21 ?) -- including full support for the DNSIX Audit Protocol (if you have a cisco router, you can see this by browsing at the top level of "config term" using the string "dnsix ?"... So there ought to be several ways that cisco can comply with the current I-Ds without having to write gobs of new code. I'd suggest that other router vendors can use similar methods for addressing the same issue. Ran rja@inet.org From owner-ipsec Wed Apr 2 12:56:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14967 for ipsec-outgoing; Wed, 2 Apr 1997 12:55:12 -0500 (EST) To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021520.KAA18004@earth.hpc.org> From: Marc Horowitz Date: 02 Apr 1997 13:00:02 -0500 In-Reply-To: ho@earth.hpc.org's message of Wed, 2 Apr 1997 10:20:18 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk ho@earth.hpc.org (Hilarie Orman) writes: >> I'd thought the group would have interest in whether or not receipt of >> an invalid SA identifier (or any similar event) is significant enough >> to require logging. I'd thought the reason in favor would be that >> anything that seemed to indicate an attempt to explore the valid >> security states of the host would probably indicate an attack attempt, >> and it would be critically important to notify the administrator, if >> at all possible. And I'd thought the argument against would be that >> the built-in safeguards are strong enough to render such attempts >> feeble and useless. I think this issue explains why people are against making auditing a must. Some sites will want to know about every conceivable event. Some sites will run high-profile services which will get probed so often that logging such probes would be a waste of cheap disk space. Having the protocol spec flag certain events as candidates for auditing seems like a fine idea. However, stating what should or must be logged it seems like it would be more appropriate in a Best Current Practices (BCP) document, rather than a protocol RFC. You could even have more than one, from the billion-dollar paranoid financial industry logging BCP to the toaster oven logging BCP. Marc From owner-ipsec Wed Apr 2 12:59:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14983 for ipsec-outgoing; Wed, 2 Apr 1997 12:58:14 -0500 (EST) Message-Id: <199704021803.KAA00360@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 17:18:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 10:03:32 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, While my motivation for starting this may be obvious, I would feel the same way if I had a 5GB disk at my disposal. Auditing is not germane to the protocol itself. Its a security feature that is very valuable but I don't think it should be part of the definition of what makes an implementation be "IPsec compliant". The suggestion that implementors don't do the "SHOULD implement" is not really true as the recent ANX IPsec bake-off demonstrated. "SHOULD" is very important and things like auditing capability will weigh heavily in the minds of customers when they start to buy this stuff. > If the language is changed at all (which I don't believe is best), > I'd propose changing it to something like "IPsec implementations having > access to non-volatile storage MUST audit... and all other implementations > SHOULD audit...". This is even worse. NVRAM is a precious resource. I'm not saying that a cisco router cannot audit. There are ways it can satisfy this requirement but I just think the requirement is bull. I actually didn't think it was all that controversial either. Dan. From owner-ipsec Wed Apr 2 13:02:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15030 for ipsec-outgoing; Wed, 2 Apr 1997 13:01:16 -0500 (EST) Date: Wed, 2 Apr 1997 13:03:48 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021803.NAA23032@earth.hpc.org> To: marc@cygnus.com Cc: ipsec@tis.com In-reply-to: Yourmessage Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Some sites will want to know about every conceivable event. > Some sites will run high-profile services which will get probed so > often that logging such probes would be a waste of cheap disk space. I'm not familiar with state-of-the-art in audit, but I'd assumed that all auditing systems allowed administrator control over such things. Hilarie From owner-ipsec Wed Apr 2 13:05:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15079 for ipsec-outgoing; Wed, 2 Apr 1997 13:04:19 -0500 (EST) Date: Wed, 2 Apr 97 17:50:09 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Derrell Piper , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704020037.QAA00806@fluffy.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk [co-chair hat off] --- On Tue, 01 Apr 1997 16:37:41 -0800 Derrell Piper wrote: > Auditing is obviously a host-system issue and outside of the scope of the > network protocol or IPSEC architecture document(s). I hear your opinion. This is not what the IPsec WG has concluded in the past. It is also not what other IETF WGs have concluded in the past. The requirement for implementing audit support is entirely consistent with past and current IETF standards-track specifications and practices. [co-chair hat on; a general comment not specific to Derrell] There is not a standards process issue with having an IETF specification require logging or auditing or such like. The group might decide to abandon auditing, but it would not be legitimate to claim a standards process violation as the rationale for doing so. [co-chair hat off] > However, there's > nothing wrong with pointing out where a host should perform auditing, if > it's capable of doing so. In this spirit, it would seem more appropriate > for the specs to read SHOULD instead of MUST. The current RFCs and drafts require that some form of auditing be implemented. They do not, however, specify any _particular_ form of auditing. One form might be syslog(), another might be SNMP, a third might be appending text strings to an ASCII file [the approach Windows95 takes with respect to PPP connections]. So the current requirement is quite minimal really and gives implementers LOTS of manuevering room to pick an implementation approach that is most sensible for their platforms. Hilarie is quite right that auditing is really an essential component. It needs to continue to be a mandatory-to-implement part of the specifications. One could argue that it would be useful to have a standards-track SNMP IPsec MIB for diagnostic and auditing information. If anyone wants to volunteer to write up such a MIB for this WG to consider, please send an email to me and Paul Lambert. I would suggest that things like the crypto keys be kept outside such an SNMP MIB because it would be unfortunate if a SNMP security breach caused an IPsec security breach. Regards, Ran rja@inet.org From owner-ipsec Wed Apr 2 13:07:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15096 for ipsec-outgoing; Wed, 2 Apr 1997 13:05:50 -0500 (EST) Message-Id: <199704021811.KAA00372@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: Bill Pabst , Hilarie Orman , ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 17:33:59 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 10:11:28 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, > So there ought to be several ways that cisco can comply with the current > I-Ds without having to write gobs of new code. I'd suggest that other > router vendors can use similar methods for addressing the same issue. That there are ways to comply do not make the requirement valid. Is there a reason for this to be a MUST (please don't say that SHOULDs aren't implemented or that the old RFCs had this because the fact that we have these I-Ds renders that void)? We're getting away from the protocol specification and dealing with mandating how it is implemented. Bad, bad, bad. Dan. From owner-ipsec Wed Apr 2 14:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15684 for ipsec-outgoing; Wed, 2 Apr 1997 14:09:50 -0500 (EST) To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021803.NAA23032@earth.hpc.org> From: Marc Horowitz Date: 02 Apr 1997 14:13:50 -0500 In-Reply-To: ho@earth.hpc.org's message of Wed, 2 Apr 1997 13:03:48 -0500 Message-ID: Lines: 15 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk ho@earth.hpc.org (Hilarie Orman) writes: >> > Some sites will want to know about every conceivable event. >> > Some sites will run high-profile services which will get probed so >> > often that logging such probes would be a waste of cheap disk space. >> >> I'm not familiar with state-of-the-art in audit, but I'd assumed that all >> auditing systems allowed administrator control over such things. I assume most would, too. But what does "MUST log" mean? Must end up in the audit log? Must be given to the audit system as input? I think this is outside the scope of the IPsec protocol document, and should be discussed in a different document. Marc From owner-ipsec Wed Apr 2 14:21:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15739 for ipsec-outgoing; Wed, 2 Apr 1997 14:20:22 -0500 (EST) Message-Id: <199704021925.OAA00299@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Stephen Kent Cc: ipsec@tis.com Subject: Re: auditing Date: Wed, 02 Apr 1997 14:25:03 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmm. Let's look at the text which started this thread.. > If no valid Security Association exists for this session (e.g., the > receiver has no key), the receiver MUST discard the packet and the > failure MUST be recorded in an audit log. This is pretty unambiguous, and goes pretty far. I read it as saying: a) you must have auditing. b) you must not be able to turn auditing off. ("the failure MUST be recorded in an audit log") Most of the responses I've seen so far in this thread appear to assume that (b) is not the case. I'd like to make a modest suggestion: change the text to: ... discard the packet. This failure MUST be auditable. and add some common text defining what "auditable" means. This document defines several events as being "auditable". At a minimum, "auditable" means that an implementation MUST provide a mechanism which securely records the fact that the event occurred one or more times in the recent past. Other relevant information about the event (time, source address, destination address, SPI, etc.,) SHOULD also be recorded. Auditing MUST be enabled by default, but it MUST be possible for an administrator to disable auditing. [This can easily be tweaked if the consensus is that the default should be to disable auditing unless explicitly requested.] --- One cautionary note on circular dependancies: We ran into some serious problems with circular dependancies when auditing was added to DCE security and was secured by DCE security; in particular, certain facilities within DCE security which were used by the audit system could also generate audit records. A number of people have suggested using various forms of networked auditing (RADIUS, syslog, etc.) to record events noticed by ipsec. If you're in a position where the communication with the audit server may be secured using ipsec, you need to be careful, lest you wind up in a recursive spiral of death when the SA with your audit server goes bad.. - Bill From owner-ipsec Wed Apr 2 15:38:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16321 for ipsec-outgoing; Wed, 2 Apr 1997 15:34:27 -0500 (EST) Date: Wed, 02 Apr 1997 14:34:40 -0500 From: "Freedman, Jerome" Subject: RE: MUST vs. SHOULD audit To: "'ipsec@tis.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > >> If the language is changed at all (which I don't believe is best), >>I'd propose changing it to something like "IPsec implementations having >>access to non-volatile storage MUST audit... and all other implementations >>SHOULD audit...". > >> Ran >> rja@inet.org > As an implementor for an embedded sytem would be happier with this change. A straight "MUST" is a bit strong. Jerry Freedman Jerome.Freedman@gsc.gte.co >m From owner-ipsec Wed Apr 2 15:47:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16449 for ipsec-outgoing; Wed, 2 Apr 1997 15:46:05 -0500 (EST) Message-Id: <2.2.32.19970402205305.014b03f8@fh.us.bosch.com> X-Sender: cwerner@fh.us.bosch.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 15:53:05 -0500 To: ipsec@tis.com From: "Christopher L. Werner" Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 4/2/97 -0800, Dan Harkins wrote: > Ran, [snip] > The suggestion that implementors don't do the "SHOULD implement" is not >really true as the recent ANX IPsec bake-off demonstrated. "SHOULD" is >very important and things like auditing capability will weigh heavily in >the minds of customers when they start to buy this stuff. > Actually there are a number of legal ramifications which are directly related to whether one has an audit trail or not. When things go wrong and law enforcement/lawyers are involved the evidence provided by a log file can be the difference between success and failure of litigation. This issue alone may have more influence on the 'market' decision to use products which log vs those which do not. Some businesses will rely on IPsec as their primary security mechanism and it's effectiveness will be very critical. [returning to listening mode...] ----------------------------------------------------------------------- Opinions expressed are mine and not necessarily those of my employer. ----------------------------------------------------------------------- Christopher L. Werner Robert Bosch Corporation System Engineer 38000 Hills Tech Dr. (810)553-1389 Farmington Hills, MI 48331-3417 From owner-ipsec Wed Apr 2 15:55:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16524 for ipsec-outgoing; Wed, 2 Apr 1997 15:53:44 -0500 (EST) Date: Wed, 2 Apr 1997 15:55:04 -0500 Message-Id: <9704022055.AA21260@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Ran Atkinson Cc: Derrell Piper , ipsec@tis.com In-Reply-To: Ran Atkinson's message of Wed, 2 Apr 97 17:50:09 GMT Daylight Time, Subject: Re: auditing Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have to agree with those who think that audit support should be a SHOULD, not a MUST, for the same reasons they cited; it's not protocol issue, it should be a host issue, there may be some host environments where logging isn't possible, etc. I have two other thoughts. What happens if the administrators decides not turn off auditing those types of events, or the other end of the SNMP trap receiver which the Cisco router has been forwarding the events is just ignoring all of the packets and sending the logs to /dev/null. Does the way the administrator configure a product make that product non-conformant with the RFC? Also, why is it so critical that we log packets with non-existent security associations? Is the security of IPSEC fundamentally compromised if system administrators don't review the logs daily looking for these events? I understand the desireability of influencing vendors to provide auditing capability for these sorts of events, but we're in pretty bad shape if the security of a protocol depends on someone poring over the audit logs! - Ted From owner-ipsec Wed Apr 2 16:22:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16703 for ipsec-outgoing; Wed, 2 Apr 1997 16:20:55 -0500 (EST) Date: Wed, 2 Apr 97 21:18:49 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Daniel Harkins Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021803.KAA00360@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, NVRAM was NOT one of the several proposals I made for router-originated auditing, if you read my notes in detail. I made several different proposals, NONE of which requires ANY non-volatile on-board storage within the router and several of which are already coded up inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). Regards, Ran rja@inet.org From owner-ipsec Wed Apr 2 16:27:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16746 for ipsec-outgoing; Wed, 2 Apr 1997 16:26:28 -0500 (EST) Date: Wed, 2 Apr 97 21:25:26 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, RADIUS has its own security and does not rely on IPsec, hence there is no circular dependency. The question is a good one. Your proposed editorial changes seem reasonable to me. It is the ability to audit that is essential, whether the sys admin turns it off is a separable issue. Ran rja@inet.org From owner-ipsec Wed Apr 2 16:48:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16823 for ipsec-outgoing; Wed, 2 Apr 1997 16:42:41 -0500 (EST) Message-Id: <199704022147.QAA00458@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: rja's message of Wed, 02 Apr 1997 21:25:26 -0500. Date: Wed, 02 Apr 1997 16:47:55 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > RADIUS has its own security and does not rely on IPsec, hence there > is no circular dependency. Of course, this means that outbound (and inbound) logging traffic needs to be treated the same way as key management traffic, bypassing any ipsec policy engine which might trigger the creation or use of a security association... - Bill From owner-ipsec Wed Apr 2 16:51:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16843 for ipsec-outgoing; Wed, 2 Apr 1997 16:46:37 -0500 (EST) Message-ID: <01BC3F6D.1B601C80@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: rja@inet.org (Ran Atkinson), tytso@MIT.EDU ('Theodore Y. Ts'o') cc: piper@cisco.com (Derrell Piper), ipsec@tis.com (ipsec@tis.com) Subject: RE: auditing Date: Wed, 2 Apr 1997 13:45:52 -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 Ted. I also agree with Mark.. The BCP idea is a good one. I agree for all the various reasons listed. The security of the base protocol doesn't depend on it. There are places were implementing auditing is at best difficult and leaves implementations open to denial of service attacks. Etc. etc. Auditing is not a protocol issue. If we choose to make it a protocol issue, we MUST spell out the details a lot more clearly than saying compliant implementations have to audit this or that. If we aren't willing to do that, and I for one, am not willing, we SHOULD leave it as a SHOULD. The implementors of the target implementation and finally the market place will determine what MUST be done for auditing. -Rob ---------- From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] Sent: Wednesday, April 02, 1997 12:55 PM To: Ran Atkinson Cc: Derrell Piper; ipsec@tis.com Subject: Re: auditing I have to agree with those who think that audit support should be a SHOULD, not a MUST, for the same reasons they cited; it's not protocol issue, it should be a host issue, there may be some host environments where logging isn't possible, etc. I have two other thoughts. What happens if the administrators decides not turn off auditing those types of events, or the other end of the SNMP trap receiver which the Cisco router has been forwarding the events is just ignoring all of the packets and sending the logs to /dev/null. Does the way the administrator configure a product make that product non-conformant with the RFC? Also, why is it so critical that we log packets with non-existent security associations? Is the security of IPSEC fundamentally compromised if system administrators don't review the logs daily looking for these events? I understand the desireability of influencing vendors to provide auditing capability for these sorts of events, but we're in pretty bad shape if the security of a protocol depends on someone poring over the audit logs! - Ted From owner-ipsec Wed Apr 2 17:23:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17055 for ipsec-outgoing; Wed, 2 Apr 1997 17:20:20 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704022225.OAA00456@kebe.eng.sun.com> Subject: Re: auditing To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 2 Apr 1997 14:25:35 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199704022147.QAA00458@thunk.ch.apollo.hp.com> from "Bill Sommerfeld" at Apr 2, 97 04:47:55 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 I have to say that after some further thought, if you HAVE logging facilities, you MUST audit. This, I guess, puts me in violent agreement with Bill. I keep having this sinking feeling that there might be some class of attack that can only get caught by auditing/logging. Anyone care to comment on this? And speaking of Bill, he mentions... > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... I'll insert a plug for draft-mcdonald-simple-ipsec-api-01.txt, which includes such a BYPASS setting for privileged applications. Dan From owner-ipsec Wed Apr 2 17:37:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17145 for ipsec-outgoing; Wed, 2 Apr 1997 17:34:55 -0500 (EST) Date: Wed, 2 Apr 97 22:30:56 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Ran Atkinson Cc: ipsec@tis.com, Stephen Kent X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022147.QAA00458@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 02 Apr 1997 16:47:55 -0500 Bill Sommerfeld wrote: > > RADIUS has its own security and does not rely on IPsec, hence there > > is no circular dependency. > > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... > > - Bill OR it means that the IPsec Policy Engine knows to bypass RADIUS traffic around IPsec -- as part of the Policy Engine's knowledge of the IPsec policy for that system. Bypassing might be quite reasonable for RADIUS since RADIUS has its own built-in security. I suspect that there are in fact N applications where one doesn't want to apply IPsec on top of some other higher-layer security mechanism (SSH, SSL, and PEM, provide potential examples of this). Ran rja@inet.org From owner-ipsec Wed Apr 2 17:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17159 for ipsec-outgoing; Wed, 2 Apr 1997 17:39:25 -0500 (EST) Date: Wed, 2 Apr 97 21:47:43 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 02 Apr 1997 14:25:03 -0500 Bill Sommerfeld wrote: > I'd like to make a modest suggestion: > > change the text to: > > ... discard the packet. This failure MUST be auditable. > > and add some common text defining what "auditable" means. > > This document defines several events as being "auditable". > > At a minimum, "auditable" means that an implementation MUST > provide a mechanism which securely records the fact that the ^^^^^^^ Dan Harkins suggests replacing "records" with "reports", which would permit network-based reporting to be substituted for local storage if appropriate in some implementation. > event occurred one or more times in the recent past. Other > relevant information about the event (time, source address, > destination address, SPI, etc.,) SHOULD also be recorded. ^^^^^^^^ Similarly, the word "recorded" above should be changed to "reported". > Auditing MUST be enabled by default, but it MUST be possible > for an administrator to disable auditing. > [This can easily be tweaked if the consensus is that the default > should be to disable auditing unless explicitly requested.] I personally don't care about which is the default. I have also heard a private suggestion that maybe some of the auditing material might be moved into the "Security Considerations" section. That wouldn't bother me, though I will observe that verbage anywhere in the RFC is equally binding on implementations. Would this be a reasonable compromise position on this topic, given that there are some seemingly deep philosophical differences amongst various parties on the question of whether the IETF is permitted to say anything beyond what 'goes on the wire' ?? Ran rja@inet.org From owner-ipsec Wed Apr 2 18:11:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17336 for ipsec-outgoing; Wed, 2 Apr 1997 18:07:35 -0500 (EST) Date: Wed, 2 Apr 97 23:05:05 GMT Daylight Time From: Ran Atkinson Subject: Apology To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022247.OAA00553@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 All, The note appended below was inappropriate and out of line in its personal tone. I wish to retract it. I apologise to Dan, Cheryl, and the list at large for my error. Ran rja@inet.org --- On Wed, 2 Apr 1997 14:47:01 -0800 (PST) Dan McDonald wrote: > Return-Path: > Dan, > > NVRAM was NOT one of the several proposals I made for router-originated > auditing, if you read my notes in detail. > > I made several different proposals, NONE of which requires ANY non-volatile > on-board storage within the router and several of which are already coded up > inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). > > Regards, > > Ran > rja@inet.org > ---------------End of Original Message----------------- From owner-ipsec Thu Apr 3 08:21:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17336 for ipsec-outgoing; Wed, 2 Apr 1997 18:07:35 -0500 (EST) Date: Wed, 2 Apr 97 23:05:05 GMT Daylight Time From: Ran Atkinson Subject: Apology To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022247.OAA00553@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 All, The note appended below was inappropriate and out of line in its personal tone. I wish to retract it. I apologise to Dan, Cheryl, and the list at large for my error. Ran rja@inet.org --- On Wed, 2 Apr 1997 14:47:01 -0800 (PST) Dan McDonald wrote: > Return-Path: > Dan, > > NVRAM was NOT one of the several proposals I made for router-originated > auditing, if you read my notes in detail. > > I made several different proposals, NONE of which requires ANY non-volatile > on-board storage within the router and several of which are already coded up > inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). > > Regards, > > Ran > rja@inet.org > ---------------End of Original Message----------------- From owner-ipsec Thu Apr 3 08:33:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00463 for ipsec-outgoing; Thu, 3 Apr 1997 08:32:39 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD416F@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Stephen Kent , Daniel Harkins Cc: ipsec@tis.com Subject: RE: MUST vs. SHOULD audit Date: Wed, 2 Apr 1997 19:07:35 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that auditing recommendations belong in the Security Considerations section. -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Tuesday, April 01, 1997 1:44 PM To: Daniel Harkins Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit Dan, I was worried about the MUSTs in both documents re auditing and potential denial of service implications, but chose to copy them and hope for feedback from the WG. I'd be comfortable with a spec that required logging if the platform already supported audit, but I'm up in the air re the right requirement if the platform does not perform audit. If marking this case as SHOULD would make folks happy, I'm certainly comfortable with that sort of change, though I'm not sure what the bottom line effect would be. Thanks for catching the "ICV" vs. "sequence number" check typo. Steve From owner-ipsec Thu Apr 3 08:37:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00621 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:15 -0500 (EST) Message-ID: <01BC3F81.69FF4780@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: sommerfeld@apollo.hp.com (Bill Sommerfeld), Dan.McDonald@Eng.sun.com ('Dan McDonald') cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: auditing Date: Wed, 2 Apr 1997 16:17:35 -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'll insert a plug for draft-mcdonald-simple-ipsec-api-01.txt, which includes >>such a BYPASS setting for privileged applications. Some platforms don't have the notion of privileged applications. ie. Windows 95. -Rob From owner-ipsec Thu Apr 3 08:37:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00633 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:20 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704030024.QAA01009@kebe.eng.sun.com> Subject: Re: auditing To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 2 Apr 1997 16:24:43 -0800 (PST) Cc: adams@cisco.com, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: <199704030021.TAA00664@thunk.ch.apollo.hp.com> from "Bill Sommerfeld" at Apr 2, 97 07:21:27 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 > > Some platforms don't have the notion of privileged > > applications. ie. Windows 95. Or MacOS for that matter. But Bill has beaten me to the punch when he says... > Actually, it was my impression that Win95 doesn't have a notion of > *un*priviledged applications. This is a subtle, but important, > distinction.. Yep. Win95/MacOS have all procs on the same playing field, for the most part, therefore you can't deny BYPASS to any app for that particular platform. Dan From owner-ipsec Thu Apr 3 08:37:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00641 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:22 -0500 (EST) Message-ID: <01BC3F81.68C986A0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: dharkins@cisco.com (Daniel Harkins), rja@inet.org ('Ran Atkinson') cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: MUST vs. SHOULD audit Date: Wed, 2 Apr 1997 16:14:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> (hence NOT a lot of work for you or Cheryl Madson). Okay... This doesn't have anything to do with this particular thread, BUT. Could people stop making judgements about how difficult it would be for other people to implement something??!?!? In reality, none of us know how difficult it is for someone to implement something. Simply because there are other things in IOS that already do something like this, doesn't mean that Cheryl or Dan can just use the prior art with no modification. It may be easy, then again, it may be nearly impossible. "Oh well, Windows 3.11 already has NETBUI, we can just shove the NRL code in there! No problem!!" Why don't we let them judge how hard it would be. Back to the thread... The ease of bolting the functionality into IOS is not relevant to the discussion. Should it be in the standard if it isn't appropriate in some instances? It certainly SHOULD NOT be in the standard because someone thinks it is easy to put the functionality in someone else's product. From owner-ipsec Thu Apr 3 08:37:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00634 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:20 -0500 (EST) Message-Id: <199704030021.TAA00664@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: adams@cisco.com (Rob Adams) Cc: Dan.McDonald@Eng.sun.com ('Dan McDonald'), ipsec@tis.com (ipsec@tis.com) Subject: Re: auditing In-Reply-To: adams's message of Wed, 02 Apr 1997 16:17:35 -0800. <01BC3F81.69FF4780@Tastid.cisco.com> Date: Wed, 02 Apr 1997 19:21:27 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >... a BYPASS setting for privileged applications. > > Some platforms don't have the notion of privileged > applications. ie. Windows 95. Actually, it was my impression that Win95 doesn't have a notion of *un*priviledged applications. This is a subtle, but important, distinction.. - Bill From owner-ipsec Thu Apr 3 08:37:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00655 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:25 -0500 (EST) Message-Id: <199704030004.QAA00961@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: Bill Sommerfeld , Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: Your message of "Wed, 02 Apr 1997 21:47:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 16:04:35 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 02 Apr 1997 21:47:43 EST (Ran, set your TZ correctly!), Ran modified Bill Sommerfeld's suggestion: >> change the text to: >> >> ... discard the packet. This failure MUST be auditable. >> >> and add some common text defining what "auditable" means. >> >> This document defines several events as being "auditable". >> >> At a minimum, "auditable" means that an implementation MUST >> provide a mechanism which securely reports the fact that the >> event occurred one or more times in the recent past. Other >> relevant information about the event (time, source address, >> destination address, SPI, etc.,) SHOULD also be reports. >> >> Auditing MUST be enabled by default, but it MUST be possible >> for an administrator to disable auditing. > > I personally don't care about which is the default. > Would this be a reasonable compromise position on this topic, >given that there are some seemingly deep philosophical differences >amongst various parties on the question of whether the IETF is >permitted to say anything beyond what 'goes on the wire' ?? This sound reasonable to me. Thanks Bill for sensible suggestion. Let me add that my philisophical differences (which BTW have nothing to do with what the IETF is permitted to say) do not reflect cisco's position vis-a-vis auditing. cisco will provide tunable auditing capability regardless of the wording in these I-Ds. It is regrettable that I must remind some people of this: I do not speak for cisco, ever. Dan. From owner-ipsec Thu Apr 3 08:37:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00659 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:28 -0500 (EST) Message-Id: <199704022344.SAA00612@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: rja's message of Wed, 02 Apr 1997 21:47:43 -0500. Date: Wed, 02 Apr 1997 18:44:38 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > At a minimum, "auditable" means that an implementation MUST > > provide a mechanism which securely records the fact that the > ^^^^^^^ > Dan Harkins suggests replacing "records" with "reports", > which would permit network-based reporting to be substituted > for local storage if appropriate in some implementation. I don't have a problem with this change to my amendment.. Note that as worded, a single counter per event (or perhaps a (counter,timestamp) pair) could conceivably be considered a minimal, but compliant, implementation of "auditing". I don't think this is an extreme burden, but it may be too minimalistic for some.. > I have also heard a private suggestion that maybe some of the > auditing material might be moved into the "Security Considerations" > section. That wouldn't bother me, though I will observe that verbage > anywhere in the RFC is equally binding on implementations. Hmm. I think that a statement that a given exceptional condition is an "auditable event" should be right next to the defintion of the exceptional condition. There could be a (redundant) complete list of auditable events in an appendix or in the security considerations section.. - Bill From owner-ipsec Thu Apr 3 09:11:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01089 for ipsec-outgoing; Thu, 3 Apr 1997 09:10:05 -0500 (EST) From: Uri Blumenthal Message-Id: <9704031414.AA175163@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: rja@inet.org (Ran Atkinson) Date: Thu, 3 Apr 1997 09:14:03 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Apr 2, 97 05:18:56 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 Ran Atkinson says: > As you note, auditing is an important property of an IPsec implementation It may be an important property of the IMPLEMENTATION, but why do people insist it should be STANDARDIZED?! You want it - implement it. Does it have to be exactly like mine? > [1] In the absence of SNMP security, an SNMP trap is not the best choice > for security-related logging, IMHO. I dislike this. It's absent in almost the same sense as IPSEC is absent. There were and are working models, some of them are deployed, the work is still going on. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 3 09:15:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01192 for ipsec-outgoing; Thu, 3 Apr 1997 09:15:09 -0500 (EST) From: Uri Blumenthal Message-Id: <9704031420.AA175280@hawpub.watson.ibm.com> Subject: Re: auditing To: rja@inet.org (Ran Atkinson) Date: Thu, 3 Apr 1997 09:20:17 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Apr 2, 97 05:50:09 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 Ran Atkinson says: > One could argue that it would be useful to have a standards-track SNMP > IPsec MIB for diagnostic and auditing information. If anyone wants to > volunteer to write up such a MIB for this WG to consider, please send > an email to me and Paul Lambert. OK, I volunteer. We'll talk about it in Memphis. > I would suggest that things like > the crypto keys be kept outside such an SNMP MIB because it would be > unfortunate if a SNMP security breach caused an IPsec security breach. I'm sorry but I have to disagree. 1. Without secure SNMP deployed, I find the wisdom of being manageable via non-secure SNMP questionble. 2. You either want IPSEC to be managed by SNMP or you don't. In the first case, several crypto-related variables will have to be not only "visible" but "modifiable"... That's life. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 3 09:43:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01373 for ipsec-outgoing; Thu, 3 Apr 1997 09:42:25 -0500 (EST) Message-ID: From: Andrew Robison To: "'ipsec@tis.com'" Subject: RE: MUST vs. SHOULD audit Date: Thu, 3 Apr 1997 09:46:34 -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 Here's my two cents worth from five years writing and working with IT security criteria: MUST AUDIT - the implementation must always audit the event in question, the feature cannot be turned off ever. MUST BE ABLE TO AUDIT - the implementation must include the configurable ability, at the request of the administrator, to audit the event. SHOULD AUDIT - the implementation may include the ability to audit the event in question and some justification may be required to explain why any given implementation does not. There is no requirement that the feature if present be configurable or able to be turned off. SHOULD BE ABLE TO AUDIT - as per SHOULD AUDIT except that the administrator must be able to turn on and off the auditing. MIGHT AUDIT - the implementers of the standard thought that if you were implementing an audit facility then this was an event which they considered worth auditing. Any details as to whether auditing can be turned on or off are outside of this requirement. I think that either SHOULD AUDIT or MIGHT AUDIT are the only reasonable terms to use. MUST is out because it means that all implementations must have auditing which may not always make sense given for instance an unmanaged IPSEC proxy. SHOULD BE ABLE TO AUDIT is out because it implies that the audit must be configurable to at least the granularity >of on/off. From owner-ipsec Thu Apr 3 10:25:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01653 for ipsec-outgoing; Thu, 3 Apr 1997 10:24:46 -0500 (EST) Message-ID: From: Greg Carter To: "'Bill Sommerfeld'" , "'Stephen Kent'" , "'Ran Atkinson'" Cc: "'ipsec@tis.com'" Subject: RE: auditing - RADIUS Date: Thu, 3 Apr 1997 10:14:12 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Ran Atkinson[SMTP:rja@inet.org] >Sent: Wednesday, April 02, 1997 4:25 PM >To: Bill Sommerfeld; Stephen Kent >Cc: ipsec@tis.com >Subject: Re: auditing > > >Bill, > > RADIUS has its own security and does not rely on IPsec, hence there >is no circular dependency. The question is a good one. Before anyone plans on using RADIUS, some things should be made clear: 1) All RADIUS communication is in the clear, with the only exception that user passwords (and the variations of them) are hidden. 2) The U in RADIUS is for USER. Good luck trying to get the RADIUS working group to add attributes to configure a router/NAS for auditing. It wont happen. You could argue for auditing on a per user basis, but is that what you want? and does that make sense? 3) RADIUS accounting is geared toward billable attributes. I don't know if you would get much support to add IPSec audit trails to the RADIUS account attributes. 4) RADIUS is shared secret based for all authentication between the RADIUS client and the RADIUS server. Wow, we just spent all this time implementing ISAKMP/Oakley with certificates, and now you want to tell your customers that in order to configure their router to do IPSec auditing that they'll have to configure a RADIUS server and manage shared secrets... (ok I could be biased) 5) The security of RADIUS is questionable when used in environments where proxying is necessary between RADIUS servers (i.e. roaming users). As long as all the RADIUS servers are run by the same organization things are fine. But as soon as it becomes necessary to proxy through a RADIUS server for which your organization has no control over things go down hill. A RADIUS server which proxies must decrypt the user password then re-encrypt it before sending it on to the RADIUS server which does the final authentication. This means that all passwords are exposed at the proxies. 6) If the user is setup to do CHAP authentication in RADIUS, there is NO authentication of the RADIUS client's request when received by the RADIUS server. This is due to the nature of how the shared secret is used in RADIUS. Basically when doing PAP the shared secret is used to encrypt the users password, proof that the RADIUS client holds the shared secret is shown when the RADIUS server decrypts the password correctly. When CHAP is done the CHAP response is not encrypted before being sent to the RADIUS server, therefore there is no proof that the RADIUS client is who they say they are since the shared secret is not used in the initial request. I'll admit that most of the security concerns wouldn't have much to do with auditing, but are you happy with recommending an IPSec solution based on a protocol with these characteristics (if you were successful at getting the RADIUS wg to add the necessary attributes)? As for the circular reference, if I was running a RADIUS environment with IPSec capable equipment I think the first thing I would do was configure IPSec between the clients and the server so I could at least get protection of the ids and possible authentication (if not proxying) when CHAP is in use (which I understand to be the majority). Bye ---- Greg Carter Entrust Technologies carterg@entrust.com > > From owner-ipsec Thu Apr 3 12:57:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02694 for ipsec-outgoing; Thu, 3 Apr 1997 12:56:20 -0500 (EST) Message-Id: <199704031800.KAA12965@mailsun3-fddi.us.oracle.com> Date: 03 Apr 97 09:55:34 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda - Preliminary Cc: PALAMBER@us.oracle.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 If you have not sent me a note with "IPSEC Agenda" in the subject line you are not on next weeks agenda. Last minute requests will be accepted. A very drafty agenda showing requested slots is attached below. Note order and times are preliminary and will change. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wednesday, April 9 at 0900-1115 Introduction 10 Grand Unified AH and ESP Specifications Nina Yuan 15 ISAKMP+Oakley draft, comments,requests, and burning issues Daniel Harkins 5 Issues for Closure Naganand Doraswamy 5 Cryptographic Aspects of the ISAKMP/Oakley Ran Canetti 10 New AH-HMAC transform drafts Robert Glenn Summary and Action Items ---------------- Thursday, April 10 at 1300-1500 IPSEC Implementation Survey Rodney Thayer Testing Results Robert Moskowitz Addressing/routing Issues Robert Moskowitz 10 "Test Cases for HMAC-MD5 and HMAC-SHA-1" Pau-Chen Cheng Summary and Action Items From owner-ipsec Thu Apr 3 13:42:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03003 for ipsec-outgoing; Thu, 3 Apr 1997 13:41:44 -0500 (EST) Message-ID: <01BC401C.6C9FB880@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: comments on draft-ietf-new-auth-00 Date: Thu, 3 Apr 1997 10:47:21 -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 read this again and had a few comments, but the major comment is.. wow.. good job! Thanks Steve, Ran and all other contributors... This makes a lot of things explicit and clear... My comments are mostly nits.. I'm an engineer, what do you want? Section 1: >> AH may be applied in combination with the IP Encapsulating >> Security Payload (ESP) [KA97b] I think I'm stupid. I don't really get the usefulness of this combination anymore other than it signs the IP header of an ESP'd packet. Is it really necessary to do this? And is there a situation where this would foil a realistic attack? I'm probably just being dumb, nothing new, but I'm at a loss. This made loads of sense before combined ESP transforms, but does it anymore? Section 2.2: Remove the null algorithm reference. I think this is only useful for debugging and probably doesn't belong in this document. Section 3.2.2: >> the transmitter increments the sequence number Earlier you said that the sequence starts at one, and here you say increment it first implying that the first on the wire is 2. Okay, Okay, I know this is a ridiculous comment and everyone knows what is meant, but I've actually had conversations with implementers where this particular point has caused confusion. Section 3.2.3.1.1: Offset and Flags. We actually had an interesting conversation about this at the anx bakeoff. Re-assembly is to take place underneath you but you can't be assured that the flags will be the same at the receiver as they are at the sender. You may not do MTU discovery on your host, but a gateway may. It could set the DF bit before forwarding. At the other end, the DF bit may still be set. In this case, fragmentation/reassembly may not even happen, but the bit will still be set in transit. Section 3.3.2: >>There is no requirement for the receiver to transmit any message >>to the purported transmitter in response I'd like to see a "MAY send an administratively prohibited ICMP" here... This could be very useful to some implementations, and probably ought to be a matter of policy. Say for example, in my LAN, I want this message so I can solve problems quickly, outside my LAN, let them stew... Not necessary, just an idea. Section 3.3.3: Could we update the example algorithm in the Hughes draft to do the window test/update in two separate operations? Now it does it in one, and the recommended path here is to test, authenticate then set. Any example algorithms published should fit the recommendation. That's it. Like I said.. mostly silly.. Again thanks to Steve, Ran and all who contributed, this feels like a real step forward. -Rob From owner-ipsec Thu Apr 3 14:13:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03192 for ipsec-outgoing; Thu, 3 Apr 1997 14:13:04 -0500 (EST) Message-ID: <01BC4020.D79923C0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: comments on draft-ietf-ipsec-new-esp-00 Date: Thu, 3 Apr 1997 11:18:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk %) good one.. Here we go again.. Section 2.3: The draft should probably state that the IV should always be a multiple of 32 bits. Or require multiples of 64 for IPv6. Section 2.4: To solve the alignment problem, could we always simply require the replay field. Don't use it if you don't have AH but leave it there with random trash otherwise to preserve alignment. I don't believe I'm saying this... %) -Rob From owner-ipsec Thu Apr 3 14:15:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03209 for ipsec-outgoing; Thu, 3 Apr 1997 14:15:34 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Thu, 3 Apr 1997 13:15:45 -0600 Message-ID: <34401680.3000@usr.com> Cc: ipsec@tis.com Subject: Re[2]: auditing - ISAKMP Content-Type: multipart/mixed; boundary="IMA.Boundary.428490068" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.428490068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >From section 5 of the ISAKMP draft: This section suggests the logging of events to a system au- dit file. This action is controlled by a system security policy and is, therefore, only a suggested action. Why is it that some IPSec protocols make auditing mandatory, whereas others make it optional? Shouldn't this be uniform for all IPSec protocols? Sumit A. Vakil Software Engineer, Routing Consulting Engineering US Robotics, Access Corp. --IMA.Boundary.428490068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 343EE530; Thu, 3 Apr 97 11:52:19 -0600 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id LAA05723; Thu, 3 Apr 1997 11:54:17 -0600 (CST) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17159 for ipsec-outgoing; Wed, 2 Apr 1997 17:39:25 -0500 (EST) Date: Wed, 2 Apr 97 21:47:43 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.428490068-- From owner-ipsec Thu Apr 3 16:59:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04408 for ipsec-outgoing; Thu, 3 Apr 1997 16:56:43 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD417A@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Bill Sommerfeld , Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: RE: auditing Date: Thu, 3 Apr 1997 10:25:29 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld [sommerfeld@apollo.hp.com] writes: > > At a minimum, "auditable" means that an implementation MUST > > provide a mechanism which securely records the fact that the > ^^^^^^^ > Dan Harkins suggests replacing "records" with "reports", > which would permit network-based reporting to be substituted * for local storage if appropriate in some implementation. I would second this suggestion. I am concerned with the word "securely" in the above, however. For example, neither of the popular suggestions I've heard for auditing (syslog, RADIUS) qualify as being particularly secure in my mind. I would be much more comfortable if we eithe a) removed or b) more closely defined the word "securely". Must the audit messages (if sent on the net) be tamper-proof? Encrypted? I don't have a problem with this change to my amendment.. Note that as worded, a single counter per event (or perhaps a (counter,timestamp) pair) could conceivably be considered a minimal, but compliant, implementation of "auditing". I don't think this is an extreme burden, but it may be too minimalistic for some.. > I have also heard a private suggestion that maybe some of the > auditing material might be moved into the "Security Considerations" > section. That wouldn't bother me, though I will observe that verbage > anywhere in the RFC is equally binding on implementations. Hmm. I think that a statement that a given exceptional condition is an "auditable event" should be right next to the defintion of the exceptional condition. There could be a (redundant) complete list of auditable events in an appendix or in the security considerations section.. - Bill From owner-ipsec Thu Apr 3 17:52:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04787 for ipsec-outgoing; Thu, 3 Apr 1997 17:50:48 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD4180@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Ran Atkinson , Bill Sommerfeld Cc: ipsec@tis.com, Stephen Kent Subject: RE: auditing Date: Thu, 3 Apr 1997 11:19:01 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Before we go too far down this "RADIUS for auditing" path, please note that 1. RADIUS is _not_ designed to carry this kind of information 2. RADIUS accounting provides only weak client authentication; RADIUS itself provides _no_ client authentication except that provided by checking the client IP address 3. RADIUS Accounting _only_ sends messages at the beginning and end of sessions (although this is under discussion) 4. RADIUS Accounting is not (according to Mike O'Dell, never will be) an IETF standard protocol 5. RADIUS does not scale due to its shared-secret form of security and there are no plans to incorporate either stronger or more scalable forms of encryption. In fact, RADIUS over IPSEC has been discussed at length recently on the RoamOps list as a possible means of solving this scalability problem 6. There is no provision in RADIUS for any data encryption Basically, this is _not_ a good idea (IMHO). As illustration (though anecdotal) of this: I was prohibited (by a non-competition agreement) from doing any security work from 1/96-1/97. My former employer was serious about enforcing this agreement, to the point of sending me a registered lawyer letter just because I published an Internet-Draft the title of which contained the word "authentication". In this period of time, I developed (with the blessing of said employer) two RADIUS servers. Tell you anything? -----Original Message----- From: Ran Atkinson [SMTP:rja@inet.org] Sent: Wednesday, April 02, 1997 2:31 PM To: Bill Sommerfeld; Ran Atkinson Cc: ipsec@tis.com; Stephen Kent Subject: Re: auditing --- On Wed, 02 Apr 1997 16:47:55 -0500 Bill Sommerfeld wrote: > > RADIUS has its own security and does not rely on IPsec, hence there > > is no circular dependency. > > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... > > - Bill OR it means that the IPsec Policy Engine knows to bypass RADIUS traffic around IPsec -- as part of the Policy Engine's knowledge of the IPsec policy for that system. Bypassing might be quite reasonable for RADIUS since RADIUS has its own built-in security. I suspect that there are in fact N applications where one doesn't want to apply IPsec on top of some other higher-layer security mechanism (SSH, SSL, and PEM, provide potential examples of this). Ran rja@inet.org From owner-ipsec Thu Apr 3 18:12:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04933 for ipsec-outgoing; Thu, 3 Apr 1997 18:11:52 -0500 (EST) Message-Id: <199704032316.SAA00991@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Glen Zorn Cc: Ran Atkinson , ipsec@tis.com, Stephen Kent Subject: Re: auditing In-Reply-To: glennz's message of Thu, 03 Apr 1997 11:19:01 -0800. <61CDD2C9A961CF11B6A000805FD40AA902BD4180@RED-84-MSG.dns.microsoft.com> Date: Thu, 03 Apr 1997 18:16:15 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the information about RADIUS; it sounds like that rules it out as a possible way to implement ipsec auditing.... - Bill From owner-ipsec Thu Apr 3 22:39:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06774 for ipsec-outgoing; Thu, 3 Apr 1997 22:38:05 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA9033E9E48@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Bill Sommerfeld Cc: Ran Atkinson , ipsec@tis.com, Stephen Kent Subject: RE: auditing Date: Thu, 3 Apr 1997 19:26:51 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld [sommerfeld@apollo.hp.com] writes: Thanks for the information about RADIUS; it sounds like that rules it out as a possible way to implement ipsec auditing.... I'd say so - almost anything (Kerberized syslog, anyone?) would be more appropriate, I think. - Bill From owner-ipsec Fri Apr 4 11:51:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11486 for ipsec-outgoing; Fri, 4 Apr 1997 11:43:15 -0500 (EST) Date: Fri, 4 Apr 1997 11:48:15 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: ipsec@tis.com Subject: Manual keying and replay prevention Message-Id: <97Apr4.115005est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The new auth and esp drafts contain the following identical wording: 4. Conformance Requirements Note that support for manual key distribution is required, but its use is inconsistent with the anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. Why not? Thanks. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 14:37:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12695 for ipsec-outgoing; Fri, 4 Apr 1997 14:36:49 -0500 (EST) Message-Id: <3.0.1.32.19970404143729.006e7d80@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 04 Apr 1997 14:37:29 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Manual keying and replay prevention and ISAKMP negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Does it make sense to talk about automatic negotiation of manual keying? The DOI has parameters for the manual case. Are people expecting that an ISAKMP implementation would potentially somehow decided to negotiate manual keying? Isn't the DOI only relevant to the ISAKMP (i.e. automatic key negotiation) schemes? >Date: Fri, 4 Apr 1997 11:48:15 -0500 >From: Norman Shulman >X-Sender: norm@rafael.rnd.border.com >To: ipsec@tis.com >Subject: Manual keying and replay prevention >Sender: owner-ipsec@ex.tis.com > >The new auth and esp drafts contain the following identical wording: > >4. Conformance Requirements > > Note that support for > manual key distribution is required, but its use is inconsistent with > the anti-replay service, and thus a compliant implementation must not > negotiate this service in conjunction with SAs that are manually > keyed. > >Why not? > >Thanks. > >Norm > > Norman Shulman Secure Computing Canada > Systems Developer Tel 1 416 813 2075 > norm@border.com Fax 1 416 813 2001 > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Fri Apr 4 15:05:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12976 for ipsec-outgoing; Fri, 4 Apr 1997 15:05:06 -0500 (EST) Date: Fri, 4 Apr 1997 15:06:56 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704042006.PAA21375@earth.hpc.org> To: rodney@sabletech.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704041955.MAA09374@baskerville.CS.Arizona.EDU> Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Sender: owner-ipsec@ex.tis.com Precedence: bulk There are two types of manual keying. The AH and ESP implementations must be able to work in the absence of any keying protocols at all. That's why the drafts mention manual keying: it's all you can count on without a key exchange protocol. The ISAKMP/Oakley manual keying is for a different case. If one party has a key generated by a method that he is especially fond of (e.g. hardware), he can securely transmit it to another party and assign it to an SA. Hilarie From owner-ipsec Fri Apr 4 15:18:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13048 for ipsec-outgoing; Fri, 4 Apr 1997 15:18:17 -0500 (EST) Message-Id: <199704042023.PAA01450@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Norman Shulman Cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: norm's message of Fri, 04 Apr 1997 11:48:15 -0500. <97Apr4.115005est.11649@elgreco.rnd.border.com> Date: Fri, 04 Apr 1997 15:23:11 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Note that support for manual key distribution is required, but > its use is inconsistent with the anti-replay service, and thus a > compliant implementation must not negotiate this service in > conjunction with SAs that are manually keyed. > > Why not? The wording seems convoluted; as my impression was that manual keying implies that no negotiation takes place. I think the issue with manual keying and replay is recovery from a reboot.. unless you store the receive-side replay state in stable storage as each packet is processed, you can't allow the SA to survive a crash without running the risk that you'll accept a replayed packet. (On the send side, you could checkpoint every N packets, and waste up to N packets of sequence space on a reboot. if you tried a similar hack on the receive side, you'd wind up needing to *ignore* up to N incoming in-sequence un-replayed packets..) Also, there's the issue of what to do when the replay counter maxes out.. - Bill From owner-ipsec Fri Apr 4 15:22:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13112 for ipsec-outgoing; Fri, 4 Apr 1997 15:22:20 -0500 (EST) Message-Id: <3.0.1.32.19970404152508.009d1e20@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 04 Apr 1997 15:25:08 -0500 To: Ran Atkinson , Bill Pabst , Hilarie Orman From: Robert Moskowitz Subject: Re: MUST vs. SHOULD audit Cc: dharkins@cisco.com, ipsec@tis.com In-Reply-To: References: <3341A51E.4EFC@htc.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:33 PM 4/2/97 Time, Ran Atkinson wrote: > >--- On Tue, 01 Apr 1997 16:15:26 -0800 Bill Pabst wrote: > >> Would this be something that could be enabled/disabled through a Radius >> Server with its audit and accounting capibilities? >> > >A fine idea. RADIUS has some transmission security built-in, hence >might be a better choice than an insecure SNMP Trap. cisco routers support >RADIUS Accounting as of (at least) IOS 11.2, as I've been learning lately. > There are many implementations that will have nothing to do with Radius. Particularly UNIX and MS OS implementations. Of course these systems have their own way to log audit information. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Apr 4 15:24:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13127 for ipsec-outgoing; Fri, 4 Apr 1997 15:23:50 -0500 (EST) Message-Id: <199704042023.PAA13127@portal.ex.tis.com> From: rob.glenn@nist.gov (Rob Glenn) To: norm@border.com Subject: Re: Manual keying and replay prevention Cc: ipsec@tis.com Date: Fri, 04 Apr 1997 20:30:03 GMT Sender: owner-ipsec@ex.tis.com Precedence: bulk I would guess that it would be difficult to "re-key" before the sequence number would wrap without having a KMP. In our own implementation (NIST), we're simply going to add a SA-Delete before the SN wraps in the case of manual key management. In this case, the manual key management system is no longer "completely" manual. Rob G. >The new auth and esp drafts contain the following identical wording: > >4. Conformance Requirements > > Note that support for > manual key distribution is required, but its use is inconsistent with > the anti-replay service, and thus a compliant implementation must not > negotiate this service in conjunction with SAs that are manually > keyed. > >Why not? > >Thanks. > >Norm > > Norman Shulman Secure Computing Canada > Systems Developer Tel 1 416 813 2075 > norm@border.com Fax 1 416 813 2001 > From owner-ipsec Fri Apr 4 15:35:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13211 for ipsec-outgoing; Fri, 4 Apr 1997 15:35:29 -0500 (EST) Date: Fri, 4 Apr 1997 15:40:44 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: <199704042023.PAA01450@thunk.ch.apollo.hp.com> Message-Id: <97Apr4.154235est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 4 Apr 1997, Bill Sommerfeld wrote: > > Note that support for manual key distribution is required, but > > its use is inconsistent with the anti-replay service, and thus a > > compliant implementation must not negotiate this service in > > conjunction with SAs that are manually keyed. > > > > Why not? > > The wording seems convoluted; as my impression was that manual keying > implies that no negotiation takes place. I assumed the negotiation takes place out of band (over the phone). > I think the issue with manual keying and replay is recovery from a > reboot.. unless you store the receive-side replay state in stable > storage as each packet is processed, you can't allow the SA to survive > a crash without running the risk that you'll accept a replayed packet. This issue is no different from the case of a stream cipher like RC4. You have to rekey after rebooting. > (On the send side, you could checkpoint every N packets, and waste up > to N packets of sequence space on a reboot. if you tried a similar > hack on the receive side, you'd wind up needing to *ignore* up to N > incoming in-sequence un-replayed packets..) > > Also, there's the issue of what to do when the replay counter maxes > out.. Again as in the case of a stream cipher, the connection breaks and must be rekeyed. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 15:42:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13227 for ipsec-outgoing; Fri, 4 Apr 1997 15:40:33 -0500 (EST) Date: Fri, 4 Apr 1997 15:46:04 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Rob Glenn cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: <199704042027.PAA19919@snad.ncsl.nist.gov> Message-Id: <97Apr4.154755est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 4 Apr 1997, Rob Glenn wrote: > I would guess that it would be difficult to "re-key" before the sequence > number would wrap without having a KMP. In our own implementation (NIST), > we're simply going to add a SA-Delete before the SN wraps in the case > of manual key management. In this case, the manual key management system > is no longer "completely" manual. Semi-automatic sounds good to me. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 15:57:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13404 for ipsec-outgoing; Fri, 4 Apr 1997 15:56:45 -0500 (EST) Date: Fri, 4 Apr 1997 15:59:33 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704042059.PAA23010@earth.hpc.org> To: rob.glenn@nist.gov Cc: ipsec@tis.com In-reply-to: Yourmessage <199704042038.NAA13597@baskerville.CS.Arizona.EDU> Subject: Re: Manual keying and replay prevention Sender: owner-ipsec@ex.tis.com Precedence: bulk > we're simply going to add a SA-Delete before the SN wraps > Semi-automatic sounds good to me. And after removing the bullet from your foot, what do you plan to do? :-) Seriously, this is a case where the inline-hashed-key idea makes sense. It's a simple way to continue operating when security is less-than-perfect but no good alternative is available. Of course, you'd be forced at gunpoint to log the event ... Hilarie From owner-ipsec Fri Apr 4 15:59:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13436 for ipsec-outgoing; Fri, 4 Apr 1997 15:59:18 -0500 (EST) Message-Id: <199704042104.NAA03097@fluffy.cisco.com> To: rodney@sabletech.com (Rodney Thayer) cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention and ISAKMP negotiation In-reply-to: Your message of "Fri, 04 Apr 1997 14:37:29 EST." <3.0.1.32.19970404143729.006e7d80@pop3.pn.com> Date: Fri, 04 Apr 1997 13:04:05 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The specific provision in the IPSEC DOI is for a manual key exchange algorithm, separate from Oakley. I actually feel that the manual keying requirement should be removed from the base architecture documents. Our security architecture should not mandate something that doesn't scale and is insecure. The ISAKMP/Oakley resolution document describes how to use "pre-shared" keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which provides the necessary attribute of manual authentication without digital certificates. I believe it's essential that ephemeral session keys be used for IPSEC, regardless of the associated authentication method. Derrell From owner-ipsec Fri Apr 4 16:13:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13580 for ipsec-outgoing; Fri, 4 Apr 1997 16:13:27 -0500 (EST) Message-Id: <3.0.1.32.19970404161127.006e7134@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 04 Apr 1997 16:11:27 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In this case may I suggest we call it "externally generated keys" rather than manual keys. I believe this case, where there is some sort of external mechanism (i.e. hardware, etc.) generating the keys is compatible with Cisco's views, as opposed to (old style humans-type-them-in) manual keying. >Date: Fri, 4 Apr 1997 15:06:56 -0500 >From: ho@earth.hpc.org (Hilarie Orman) >To: rodney@sabletech.com >Cc: ipsec@tis.com >Subject: Re: Manual keying and replay prevention and ISAKMP negotiation >Sender: owner-ipsec@ex.tis.com > >There are two types of manual keying. The AH and ESP implementations must >be able to work in the absence of any keying protocols at all. That's >why the drafts mention manual keying: it's all you can count on without >a key exchange protocol. > >The ISAKMP/Oakley manual keying is for a different case. If one party >has a key generated by a method that he is especially fond of >(e.g. hardware), he can securely transmit it to another party and >assign it to an SA. > >Hilarie > > > From owner-ipsec Fri Apr 4 18:49:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14161 for ipsec-outgoing; Fri, 4 Apr 1997 18:38:52 -0500 (EST) Message-Id: <1.5.4.16.19970404223038.423fdf8a@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 1997 17:30:38 -0500 To: Derrell Piper From: "David P. Jablon" Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Cc: ipsec@tis.com, rodney@sabletech.com (Rodney Thayer) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, I think you are wrong in suggesting that the ISAKMP/Oakley draft encourage the "pre-shared secrets" to be based on passwords. The word "password" is carefully (I suppose) omitted in the draft, and for good reason: Use of a too-small password exposes their protocol to dictionary attack. It *is* possible to do a password-authenticated DH exchange, immune to network dictionary attack. (e.g. SPEKE or DH-EKE) Such exchanges could be very convenient for secure re-connections, based on a temporary memorizable secret -- but these are not specified in Oakley. Forgive me if you think this is a nit, but I think wanton use of passwords as keys is a *bad thing*, especially in light of truly appropriate password alternatives. -- David At 01:04 PM 4/4/97 -0800, you wrote (to Rodney): > The specific provision in the IPSEC DOI is for a manual key exchange > algorithm, separate from Oakley. > ... > The ISAKMP/Oakley resolution document describes how to use "pre-shared" > keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which > provides the necessary attribute of manual authentication without digital > certificates. ------------------------------------ David Jablon Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Fri Apr 4 22:00:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA15099 for ipsec-outgoing; Fri, 4 Apr 1997 21:59:09 -0500 (EST) Message-Id: <199704050304.TAA02427@dharkins-ss20> 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: Manual keying and replay prevention and ISAKMP negotiation In-Reply-To: Your message of "Fri, 04 Apr 1997 16:11:27 EST." <3.0.1.32.19970404161127.006e7134@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 1997 19:04:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In this case may I suggest we call it "externally generated keys" rather > than manual keys. I believe this case, where there is some sort of > external mechanism (i.e. hardware, etc.) generating the keys is compatible > with Cisco's views, as opposed to (old style humans-type-them-in) manual > keying. cisco's views? I don't think that cisco has a view on what manual keying is. (Or if it does I haven't been let in on it). Lots of us have opinions but they don't necessarily have any relation to our employer's. Dan (speaking only for myself-- still). From owner-ipsec Sat Apr 5 02:46:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA16254 for ipsec-outgoing; Sat, 5 Apr 1997 02:45:24 -0500 (EST) Message-Id: <199704050749.XAA21207@mailsun3-fddi.us.oracle.com> Date: 04 Apr 97 17:01:29 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: Memphis IPSEC Cc: PALAMBER@us.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.5.1.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id CAA16251 Sender: owner-ipsec@ex.tis.com Precedence: bulk WEDNESDAY, April 9, 1997 0900-1115 Memphis C SEC ipsec IP Security Protocol WG ipsec I-Ds THURSDAY, April 10, 1997 0900-1130 Continental SEC ipsec IP Security Protocol WG Interoperability Discussions Paul From owner-ipsec Sat Apr 5 08:29:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17450 for ipsec-outgoing; Sat, 5 Apr 1997 08:26:32 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <97Apr4.115005est.11649@elgreco.rnd.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 04:27:24 -0500 To: Norman Shulman From: Stephen Kent Subject: Re: Manual keying and replay prevention Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I inserted the cited note re manually positioned keys was because I assumed that these keys would not be changed frequently (to assume otherwise would facilitate a management vulnerability) and because I assumed that saving state for the anti-replay sequence number would be problematic (across crashes, etc.). Under these assumptions, counter cycling becomes a problem. It does not seem to be realistic to assume that a manually positioned key would be changed in a timely fashion as the counter neared 2**32-1. These are conservative assumptions, but this is a security protocol, so such assumptions are not necessarily out of line. Later e-mail from others attempts to clarify the use of the phrase "manual keying," but I based this text on the prevous IPsec RFCs, where the intent (Ran can confirm this) was to refer to symmetric keys. Steve From owner-ipsec Sat Apr 5 08:29:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17456 for ipsec-outgoing; Sat, 5 Apr 1997 08:27:02 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <9704012220.AA31931@hawpub.watson.ibm.com> References: <199704012145.NAA28713@dharkins-ss20> from "Daniel Harkins" at Apr 1, 97 01:45:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 07:54:54 -0500 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, IPsec defines a protocol, and a protocol definition inlcludes the processing that takes place at the sender and receiver in response to the transmission and reception of packets, not just the format of the packet bits on the wire. On that basis, I'd argue that auditing is within the scope of the IPsec specs, especially since auditing is a security function and IPsec defines security protocols. I do agree with later contributors to this discussion, that we need to distinguish between "audited" and "auditable." Certainly we do not want to require that events be audited; that is a local policy matter. Thus, at a minimum, we need to chnage the wording to indicate that what is required (or recommended) is that an implementation allow a local security administrator to elect auditing for the specified events. I suspect that was Ran's intent when he first wrote this text (but which escaped noticed untile this round of revisions!). I like the general tone of Bill's and Andrew's proposed text; both are consistent with the notion of expressing what is to be audited if an event occurs and if auditing is turned on. I am a bit concerned about leaving the extent of what is logged be so general. A counter of events is not very helpful in identifying the source of a problem, characterizing an attack, etc. I'd be hapy with the notion that a certain set of data MUST be available for an audit log, but that the local security manager gets to select which of these data items is actually logged. I also believe that the IPsec architecture document is a good place to discuss when to audit, and what systems MUST/SHOULD provide an audit capability and what is meant by "secure audit." That audit records can be maintained locally, or transmitted to a remote location, is an appropriate elaboartion of the audit concept and I'm happy to include that as well. Auditing is a common concern for both AH and ESP, so I'd prefer not duplicating the text in each document, although I could be persuaded otherwise. Steve From owner-ipsec Sat Apr 5 08:29:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17474 for ipsec-outgoing; Sat, 5 Apr 1997 08:28:34 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <01BC401C.6C9FB880@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 08:06:06 -0500 To: adams@cisco.com (Rob Adams) From: Stephen Kent Subject: Re: comments on draft-ietf-new-auth-00 Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Thanks for the feedback; we worked on clarifying wherever possible, but the messages last week show that we still have some work ahead of us. Now onto your comments: Section 1 I agree that often one will not need to use AH and ESP together, now that we have integrity/authentication options within ESP, and assuming that we adopt the revised ESP, that makes encryption optional. However, if one makes use of security labels, AH is important in transport mode. Also, in IPv6, use of AH to protect the new style source routing header has been cited as a motivation for using AH. Section 2.2 I'm all in favor of removing the null algorithm, or rewording if this is just a debugging place holder. Section 3.2.2 You caught me! We'll reword to make it clear that the first packet packet on the wire should be number 1. We'll also add that the receive counter should be initialized to 0. Section 3.2.3.1.1 OK, that's a good explanation for the DF flag, but how about OFFSET? Section 3.3.2 If others do not object, I'm happy to add your proposed text. Section 3.3.3 The algorithm should be updated, as you note, to reflect the split processing. We get a brief reprieve on this, since we pushed it to an appendix in the architecture document. From owner-ipsec Sat Apr 5 08:30:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17475 for ipsec-outgoing; Sat, 5 Apr 1997 08:28:35 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <01BC4020.D79923C0@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 08:14:08 -0500 To: adams@cisco.com (Rob Adams) From: Stephen Kent Subject: Re: comments on draft-ietf-ipsec-new-esp-00 Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Some more responses to your additional comments: >Section 2.3: > >The draft should probably state that the IV should always be a multiple of >32 bits. >Or require multiples of 64 for IPv6. Well, this is really an algorithm independence issue. We don't get to pick IV lengths; they are defined by the algorithms. However, we can require this field to be a multiple of 32 bits and note that if the real IV does not conform to this requiremend, then the algorithm spec will describe how padding is performed. >Section 2.4: > >To solve the alignment problem, could we always simply require the replay >field. >Don't use it if you don't have AH but leave it there with random trash >otherwise >to preserve alignment. I don't believe I'm saying this... %) Yes, we could, but I hesitate to adopt that approach. It wastes space in an IPv4 context, and the presence/absence of an IV also affects the overall alignment problem, so always requiring the sequence number does not fix this in all cases anyway. For example, if one uses the 32-bit IV (for DES CBC) that is part of the original RFCs, and one allocates 32 bits for the anti-replay sequence counter, we have an IPv6 alignment problem anyway! Steve From owner-ipsec Sat Apr 5 09:51:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17783 for ipsec-outgoing; Sat, 5 Apr 1997 09:50:38 -0500 (EST) Message-Id: <199704051455.GAA03570@fluffy.cisco.com> To: dpj@world.std.com (David P. Jablon) Cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention and ISAKMP negotiation In-reply-to: Your message of "Fri, 04 Apr 1997 17:30:38 EST." <1.5.4.16.19970404223038.423fdf8a@world.std.com> Date: Sat, 05 Apr 1997 06:55:55 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk David, It was not the intent of my previous message to suggest that the resolution document encourages the definition of pre-shared secret to be based on a simple password. As you have observed, the resolution document does not currently specify how the pre-shared key is derived. If you have a suggestion as to what it should say about deriving the pre-shared secret, I suspect the authors of that document would be receptive to your comments. Derrell > Derrell, > > I think you are wrong in suggesting that the ISAKMP/Oakley > draft encourage the "pre-shared secrets" to be based on passwords. > The word "password" is carefully (I suppose) omitted in the draft, > and for good reason: Use of a too-small password exposes their > protocol to dictionary attack. > > It *is* possible to do a password-authenticated DH exchange, immune > to network dictionary attack. (e.g. SPEKE or DH-EKE) Such exchanges > could be very convenient for secure re-connections, based on a > temporary memorizable secret -- but these are not specified in Oakley. > > Forgive me if you think this is a nit, but I think > wanton use of passwords as keys is a *bad thing*, especially > in light of truly appropriate password alternatives. > > -- David > > > At 01:04 PM 4/4/97 -0800, you wrote (to Rodney): > > > The specific provision in the IPSEC DOI is for a manual key exchange > > algorithm, separate from Oakley. > > ... > > The ISAKMP/Oakley resolution document describes how to use "pre-shared" > > keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which > > provides the necessary attribute of manual authentication without digital > > certificates. > > ------------------------------------ > David Jablon > Tel: +1 508 898 9024 > http://world.std.com/~dpj/ > E-mail: dpj@world.std.com From owner-ipsec Sat Apr 5 15:09:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19032 for ipsec-outgoing; Sat, 5 Apr 1997 15:03:28 -0500 (EST) Message-Id: <199704052007.PAA03116@raptor.research.att.com> To: Stephen Kent cc: adams@cisco.com (Rob Adams), ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-new-esp-00 Date: Sat, 05 Apr 1997 15:07:09 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > >The draft should probably state that the IV should always be a multiple of > >32 bits. > >Or require multiples of 64 for IPv6. > > > Well, this is really an algorithm independence issue. We don't get to pick > IV lengths; they are defined by the algorithms. However, we can require > this field to be a multiple of 32 bits and note that if the real IV does > not conform to this requiremend, then the algorithm spec will describe how > padding is performed. No -- your first instinct is right. The pair is opaque to any level above the decryption routine; thus, higher-level routines can neither known nor care if one is present. At most, the existence of one is a parameter to be passed from the key negotiation layer straight through to the encryption/decryption layer. Let me give a concrete example. In, say, DES-CBC, the IV can be seen as the first block of ciphertext; it's decrypted with any IV whatsoever. The only difference is that the first block of the resulting plaintext -- that is, the plaintext that comes from the (conceptual) decryption of the IV -- is discarded. Seen this way, the difference between the IV and some other portion of the ciphertext is irrelevant. We can carry this further by assuming a block cipher with an 80-bit block size, and hence 80-bit IV. Why would we want to pad the IV? Again, it's just part of the input to the decryption engine. Decisions on the format of the field belong in the RFCs describing individual transforms. Those documents can and should consider block alignment and efficiency considerations for likely implementation techniques. From owner-ipsec Sun Apr 6 00:34:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA21291 for ipsec-outgoing; Sun, 6 Apr 1997 00:33:03 -0500 (EST) Date: Sun, 6 Apr 1997 00:38:30 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Stephen Kent cc: Rob Adams , ipsec@tis.com Subject: Re: comments on draft-ietf-new-auth-00 In-Reply-To: Message-Id: <97Apr6.003929est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Sat, 5 Apr 1997, Stephen Kent wrote: > Rob, > > Section 3.2.2 > You caught me! We'll reword to make it clear that the first packet > packet on the wire should be number 1. We'll also add that the receive > counter should be initialized to 0. In this case, Section 2.5 should be changed to state that the SA must be changed prior to transmitting 2^32 packets. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Sun Apr 6 10:26:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23291 for ipsec-outgoing; Sun, 6 Apr 1997 10:15:49 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704061421.AA285590@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: kent@bbn.com (Stephen Kent) Date: Sun, 6 Apr 1997 10:21:13 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Apr 5, 97 07:54:54 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent says: > IPsec defines a protocol, and a protocol definition inlcludes the > processing that takes place at the sender and receiver in response to the > transmission and reception of packets, not just the format of the packet > bits on the wire. Yes, but what to do with the INFORMATION AFTER it is processed clearly is beyond the scope. Verify auth - within. Enter a certain state when the auth failed - within. Define what the alert contains, who it is sent to etc. - questionably outside. Insisting that this alert really gets somewhere - clearly outside. > On that basis, I'd argue that auditing is within the > scope of the IPsec specs, especially since auditing is a security function > and IPsec defines security protocols. By this logic, since physical access to the computer room is a security function too - why don't you put it in the IPSEC paper? > I also believe that the IPsec architecture document is a good place > to discuss when to audit, and what systems MUST/SHOULD provide an audit > capability and what is meant by "secure audit." That audit records can be > maintained locally, or transmitted to a remote location, is an appropriate > elaboartion of the audit concept and I'm happy to include that as well. Let us not mix the two things! It is good and well to ADVISE the user and RECOMMEND the best spots to insert certain implementation-dependent features, like auditing. It is BAD to ENFORCE this 100% imlementation- dependent thing. > Auditing is a common concern for both AH and ESP, so I'd prefer not > duplicating the text in each document, although I could be persuaded > otherwise. No, you are correct here (I think). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Mon Apr 7 09:52:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00078 for ipsec-outgoing; Mon, 7 Apr 1997 09:43:03 -0400 (EDT) Message-Id: <3.0.1.32.19970406224934.006ca9d0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sun, 06 Apr 1997 22:49:34 -0500 To: Daniel Harkins From: Rodney Thayer Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Cc: ipsec@tis.com In-Reply-To: <199704050304.TAA02427@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Excuse me. I was trying to may attention to Derrell's comments and I chose my words poorly. At 07:04 PM 4/4/97 -0800, you wrote: >> In this case may I suggest we call it "externally generated keys" rather >> than manual keys. I believe this case, where there is some sort of >> external mechanism (i.e. hardware, etc.) generating the keys is compatible >> with Cisco's views, as opposed to (old style humans-type-them-in) manual >> keying. > >cisco's views? I don't think that cisco has a view on what manual keying is. >(Or if it does I haven't been let in on it). Lots of us have opinions but >they don't necessarily have any relation to our employer's. > > Dan (speaking only for myself-- still). > > > From owner-ipsec Tue Apr 8 13:01:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10666 for ipsec-outgoing; Tue, 8 Apr 1997 12:51:51 -0400 (EDT) Date: Tue, 8 Apr 1997 19:40:09 +0200 (IST) From: Sara Bitan To: Uri Blumenthal Cc: Ran Atkinson , ipsec@tis.com Subject: Re : keys visability (was : Re: auditing) In-Reply-To: <9704031420.AA175280@hawpub.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see any reason why secret and private keys should be "visible" let alone be "modifiable". If secret keys are automatically generated (using let's say ISAKMP/Oakley), there is certainly no sense in modifying them, and no need in viewing them. Even if secure SNMP is used, this certainly decreases the security of the system. I think that it is good practice that private/ secret keys will never leave the machine on which they were generated (except maybe for key recovery purposes, and then a secure way of transporting the keys parts should be deviced). The only case when you need to modify keys, is when you use manual keying. Even in this case, I think we should discuss if SNMP is the best way to enter these keys. I don't see any problem with having SNMP manage all but keys. Sara Bitan sarab@radguard.com RADGUARD http://www.radguard.com Tel-Aviv, Israel. -------------------------------------------- On Thu, 3 Apr 1997, Uri Blumenthal wrote: > Ran Atkinson says: > > One could argue that it would be useful to have a standards-track SNMP > > IPsec MIB for diagnostic and auditing information. If anyone wants to > > volunteer to write up such a MIB for this WG to consider, please send > > an email to me and Paul Lambert. > > OK, I volunteer. We'll talk about it in Memphis. > > > I would suggest that things like > > the crypto keys be kept outside such an SNMP MIB because it would be > > unfortunate if a SNMP security breach caused an IPsec security breach. > > I'm sorry but I have to disagree. > > 1. Without secure SNMP deployed, I find the wisdom of being > manageable via non-secure SNMP questionble. > > 2. You either want IPSEC to be managed by SNMP or you don't. > In the first case, several crypto-related variables will > have to be not only "visible" but "modifiable"... > That's life. > -- > Regards, > Uri uri@watson.ibm.com > -=-=-=-=-=-=- > > From owner-ipsec Wed Apr 9 00:14:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14217 for ipsec-outgoing; Wed, 9 Apr 1997 00:13:03 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704090413.AA35223@hawpub.watson.ibm.com> Subject: Re: Re : keys visability (was : Re: auditing) To: sarab@radguard.com (Sara Bitan) Date: Wed, 9 Apr 1997 00:13:32 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: from "Sara Bitan" at Apr 8, 97 07:40:09 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 Sara Bitan says: > I don't see any reason why secret and private keys should be "visible" let > alone be "modifiable". it is the other way around. The keys may need to be "modifiable", but of course by NO MEANS should they be "visible". When I said "sensitive information" I did not have the keys in mind! > The only case when you need to modify keys, is when you use manual > keying. Even in this case, I think we should discuss if SNMP is the best > way to enter these keys. Secure SNMP probably would be a "good enough" way, especially if integrated in the management framework. > I don't see any problem with having SNMP manage all but keys. (:-) > > 2. You either want IPSEC to be managed by SNMP or you don't. > > In the first case, several crypto-related variables will > > have to be not only "visible" but "modifiable"... > > That's life. Obviously this excludes the keys! -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed Apr 9 03:38:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA15400 for ipsec-outgoing; Wed, 9 Apr 1997 03:36:53 -0400 (EDT) From: pcn@teil.soft.net (P.C.Narasimha Reddy) Message-Id: <199704091836.NAA29914@teil.soft.net> Subject: isakmp doubts To: ipsec@tis.com Date: Wed, 9 Apr 1997 13:06:09 -0530 (IST) Cc: pcn@teil.soft.net (P.C.Narasimha Reddy), suren@teil.soft.net (S. Arockia Suren) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk hi I am having some doubts about the isakmp+oakley, can anyone please clarify them. 1) Is the SPI space used by the various protocols defined anywhere? In page 16 of the ISAKMP draft it says that "Each security protocol has its own SPI-space." 2) Is SPI unique on a host? Or is it unique for a particular destination IP address in the SA Data Base? 3) A "PROPOSAL" contains details of one "PROTECTION SUITE", and a "PROTECTION SUITE", may contain many "SECURITY PROTOCOLS". But SPI is part of the proposal payload, and one proposal payload is used to give the details of one "SECURITY PROTOCOL" only. To give details of more than one "SECURITY PROTOCOL" in a proposal we use multiple proposal payloads with the same proposal# (proposal number). So there can be different SPI values for the "SECURITY PROTOCOLS" within the same "PROPOSAL"(ie. multiple proposal payloads with the same proposal number)? So my doubt is whether it is mandatory to use different SPI values for different "SECURITY PROTOCOLS" within the same "PROPOSAL"? Or is it mandatory to use the same SPI value? In the case where different SPI values are mandatory, how is a SA identified, because an SA will then have more than one SPI values(one for each "SECURITY PROTOCOL")? 4) The different Exchanges defined in the ISAKMP have a defined set of messages to be exhanged to negotiate the ISAKMP SA and the IPSEC SA later. How do you handle the issue of "TIMEOUT" and "RE-TRANSMITION" of messages during these Exchanges? Is there an agreed upon way as to how we should handle this issue? I feel that this issue needs an agreed upon standard solution for interoperability reasons. 5) ISAKMP can be used to negotiate multiple SA's between two entities. So when there are multiple active SA's between any two nodes, how do I decide which of the active SA to use for the outgoing traffic? Because in IPSEC, the securing of the IP packets is done in the IP layer, And in the IP layer the information of which process had generated this IP packet is all lost, this information is only available in the socket layer. When we have a very dynamic situation where we have each user on the system, using his own ID_USER_FQDN (example piper@foo.bar.com) and each user negotiates an SA for his use. So we will ultimately have a situation where there are more than one active SA between two nodes(nodes that are identified by IP addresses). Here when the IP layer is securing outgoing traffic, it has to use the SA corresponding to the perticular user, so it has to know which process has generated this traffic, and who is the owner of that process. How can this situation be supported using IPSEC? 6) In a "Video on demand" application, it is logical to have just encryption from the service provider to the customer, and to have just Authentication from the customer to the service provider traffic. In this situation there is a requirement for two SA's to the same destination IP address, one for outgoing traffic only and another for incoming traffic only. How do I negotiate such SA's using ISAKMP? Thanks in advance regards narasimha E-mail: pcn@teil.soft.net From owner-ipsec Wed Apr 9 08:48:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17299 for ipsec-outgoing; Wed, 9 Apr 1997 08:47:06 -0400 (EDT) Date: Tue, 8 Apr 1997 23:36:10 -0400 (Eastern Daylight Time) From: Rob Glenn Reply-To: Rob Glenn Subject: Comments on draft-ietf-ipsec-new-auth-00.txt To: ipsec@tis.com cc: rob.glenn@nist.gov Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk General comments: I'm a little concerned that by specifying the HMAC MD5 and HMAC SHA-1 algorithms in this draft, we are now one step away from the goal of algorithm independence. - I think it is now more difficult to specify other algorithms for use with AH since the mechanism to do so has been removed (i.e. transform documents) and new algorithm documents will have to point to the AH spec instead of the other way around. - As a result, other algorithms may be presented in a form similar to "transform" documents which defeats the main goal of re- writing the RFCs. - A possible solution would be to remove the references to specific algs. from the draft and point to another draft that contains just a list of algorithms, alg-ids, and the implementation conformance requirements(MUST, SHOULD, or MAY). - This comment applies to the new-esp draft as well. More Specific comments: 1. Anti-replay and multicast are problematic together. See the last paragraph of section 2.1 in draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt 2. I think it is too strong to say that "... a compliant implementation must not negotiate this service (Anti-Replay) in conjuction with SAs that are manually keyed." The implication is that only with a full-blown dynamic key management engine will you ever use Anti- Replay. 3. The straw poll taken a few weeks back concluded that we didn't want a variable sized field in the middle of the AH header. By making the Seq. Number field optional this way, once again we have a variable sized field in the header. One way to fix this would be to move the Authentication Data pad to the beginning of the Authentication Data instead of the end. That way when HMAC-{MD5,SHA-1}-96 is used without Anti-replay and 64-bit alignment is desired, the 32-bits of pad will be located in the same position where the SN would have been. Of course, another solution would be to just fix the SN field. 4. If it is decided to still include algs. in the drafts, then the AH draft should: - specify the default 96-bit truncation in the conformance section, and - mention that HMAC-MD5 is MUST and HMAC-SHA-1 is SHOULD (as previously recommended). From owner-ipsec Wed Apr 9 10:45:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18155 for ipsec-outgoing; Wed, 9 Apr 1997 10:44:04 -0400 (EDT) Message-Id: <199704091446.KAA27810@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: pcn@teil.soft.net, ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Edward Russell Subject: RE: isakmp doubts Date: Wed, 09 Apr 1997 10:49:14 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA18152 Sender: owner-ipsec@ex.tis.com Precedence: bulk My turn to be on info duty. >>P.C.Narasimha Reddy (pcn@teil.soft.net) said on 4/9/97 at 3:55 AM > >hi > > I am having some doubts about the isakmp+oakley, > can anyone please clarify them. > > 1) Is the SPI space used by the various protocols > defined anywhere? In page 16 of the ISAKMP draft > it says that "Each security protocol has its own > SPI-space." > The SPI is used for your own implementation's purposes to identify a security association. Use what ever you want (most use a random number, others increment a counter). However below 100 (or is it 500?) is reserved for other purposes. And DON"T use 0 (it will mess up my implementation :-)) Remember, there are 2 SPIs, your SPI and the other guy's SPI. When sending, you must use the other guy's SPI for the SA so he can find the SA. When receiving, you will receive your own SPI for the SA so you can find the SA. > 2) Is SPI unique on a host? Or is it unique for > a particular destination IP address in the > SA Data Base? > That is up to your implementation. You could have unique SPIs per system, per protocol (ESP/AH), or whatever. Just as long as you can find the right SA using the SPI value. > 3) A "PROPOSAL" contains details of one "PROTECTION > SUITE", and a "PROTECTION SUITE", may contain many > "SECURITY PROTOCOLS". But SPI is part of the > proposal payload, and one proposal payload is used > to give the details of one "SECURITY PROTOCOL" only. > To give details of more than one "SECURITY PROTOCOL" > in a proposal we use multiple proposal payloads with > the same proposal# (proposal number). So there can > be different SPI values for the "SECURITY PROTOCOLS" > within the same "PROPOSAL"(ie. multiple proposal > payloads with the same proposal number)? > So my doubt is whether it is mandatory to use different > SPI values for different "SECURITY PROTOCOLS" within the > same "PROPOSAL"? > Or is it mandatory to use the same SPI value? > In the case where different SPI values are mandatory, how > is a SA identified, because an SA will then have more than > one SPI values(one for each "SECURITY PROTOCOL")? > Dealing only with proposal and transform payloads, yes the SPI is in the proposal payload. Proposal payloads may or may not have the same SPI. Again this depends on the uniqueness of your SPIs. If the proposals are of the same number and have the same SPI, you are saying you are using the same SPI for AH and for ESP and that you will be able to find the SA during IPSEC traffic based on both SPI and protocol. If the SPIs have different values for proposals of the same number, you are using SPIs which are unique even across protocols. Either way is fine as long as you can deal with it during IPSEC traffic. As for proposals of different numbers, there is no reason not to use the same AH spi and ESP spi in all proposals since only one will be picked, but again it doesn't matter since the spi for each protocol will be returned to you in the selected proposal response. > 4) The different Exchanges defined in the ISAKMP have > a defined set of messages to be exhanged to negotiate the > ISAKMP SA and the IPSEC SA later. How do you handle > the issue of "TIMEOUT" and "RE-TRANSMITION" of messages > during these Exchanges? Is there an agreed upon way as > to how we should handle this issue? I feel that this > issue needs an agreed upon standard solution for > interoperability reasons. Timeout the message and resend it. After n tries give up and send a notify or delete payload and forget about the negotiation. I do not believe there is an interoperability issue here as long as the implementation can deal with receiving duplicate messages and tossing all but the first. > > 5) ISAKMP can be used to negotiate multiple SA's between > two entities. So when there are multiple active SA's > between any two nodes, how do I decide which of the > active SA to use for the outgoing traffic? Because > in IPSEC, the securing of the IP packets is done > in the IP layer, And in the IP layer the information > of which process had generated this IP packet is all > lost, this information is only available in the socket > layer. When we have a very dynamic situation where we have > each user on the system, using his own ID_USER_FQDN > (example piper@foo.bar.com) and each user negotiates > an SA for his use. So we will ultimately have a > situation where there are more than one active SA > between two nodes(nodes that are identified by IP addresses). > Here when the IP layer is securing outgoing traffic, it > has to use the SA corresponding to the perticular user, > so it has to know which process has generated this traffic, > and who is the owner of that process. How can this situation > be supported using IPSEC? This is user based IPSEC and is in great demand but is not solved yet. Note, I say user based in the sense that multiple "people" or "personalities" on a machine want to talk to the same host using different SAs. We CAN do psuedo-user where authentication of the entire machine is done via a user based certificate, say. But this is not the multiple user case. > > 6) In a "Video on demand" application, it is logical to have > just encryption from the service provider to the customer, and > to have just Authentication from the customer to the service > provider traffic. In this situation there is a requirement for > two SA's to the same destination IP address, one for outgoing > traffic only and another for incoming traffic only. How do I > negotiate such SA's using ISAKMP? > Well, I answered 5 out of 6 anyway. I can certainly send with whatever SA I want, but how do I tell the other side to send to me using a particular SA (SPI)? Is there the concept of SA direction in ISAKMP negotiation? Edward Russell erussell@ftp.com From owner-ipsec Wed Apr 9 13:50:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19342 for ipsec-outgoing; Wed, 9 Apr 1997 13:44:32 -0400 (EDT) From: "Marcus Leech" Message-Id: <199704091747.AA190658064@bcarh6dc.ott.bnr.ca> Subject: Effective policy enforcement To: ipsec@tis.com Date: Wed, 9 Apr 1997 13:47:43 -0500 (EDT) Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I've been thinking a fair amount about the question of, once we have IPSEC, what kinds of access control (and other) policy may actually be implemented by system administrators using IPSEC with ISAKMP. The current implementations of ISKMP use X.509 certificates, which allow the administrator to establish very broad policy, like: "I will establish an SA with any entitiy bearing a certificate signed by my CA" "I will establish an SA with an entity named Marcus Leech, provided that the certificate was signed by Nortel". Both of these policy directives are implementable with the existing ISAKMP assumptions about certificates. Note, however, that in the second case, if I want to produce (for example) a "group" policy, I must enumerate the Distinguished Names of each member in the group, or I must establish a group CA, and use the first type of policy statement mentioned above. The work of the SPKI group allows for much richer policy enforcement than is possible with an X.509 scheme. I would like to see three things: (1) ISAKMP implementation hooks for SPKI certificate formats. I understand that the SPKI group doesnt' yet have any implementable output, but I don't want to see us do anything to prevent its incorporation at a later date. (2) Viable policy engines in IPSEC/ISAKMP systems that make rich policy enforcement possible, and easy to administer. (3) Availability to the applications of any and all attributes and/or authorizations carried in a certificate used to establish an SA (this applies to both X.509 and SPKI). In other words, it ought to be possible for an application to determine all of the security-relevant attributes for incoming connections to those applications. This kind of support SHOULD NOT be delegated to the application layer. There are HUGE efficency and code-maintability gains to be had by offering this kind of policy management at the IPSEC layer. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBM0vWPKp9EtiCAjydAQGCHwH/WzMrzBdQfiC7z23s3exJwKw6pLklIxhM J9aefOrXQJeoAKfL2Gpiq1uRd9QHVLCC3v2pL9q/QngtbE+7vPqmmg== =oNgJ -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 238, CAR Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Systems Security Services Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Wed Apr 9 16:59:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20485 for ipsec-outgoing; Wed, 9 Apr 1997 16:55:03 -0400 (EDT) Message-Id: <199704092056.QAA26512@relay.hq.tis.com> Date: Wed, 9 Apr 1997 16:58:21 -0400 From: gary flynn To: ipsec@tis.com, owner-ipsec@tis.com Subject: Re: Effective policy enforcement Sender: owner-ipsec@ex.tis.com Precedence: bulk > This kind of support SHOULD NOT be delegated to the application layer. > There are HUGE efficency and code-maintability gains to be had by > offering this kind of policy management at the IPSEC layer. Not to mention the realization of universal, interoperable authentication/authorization implementations. Gary Flynn Network Analyst James Madison University From owner-ipsec Wed Apr 9 18:43:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21214 for ipsec-outgoing; Wed, 9 Apr 1997 18:42:42 -0400 (EDT) Date: Wed, 9 Apr 1997 17:48:09 -0400 Message-Id: <199704092148.RAA00302@alisan.ibm.net> From: Uri Blumenthal To: ipsec@tis.com Subject: IPSec MIB Reply-to: uri@watson.ibm.com Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy! A good news is, as you should have already heard - IPSec MIB work has begun. Rodney Thayer and myself kindly undertook the mission. (:-) It is possible that we create an ipsec-mib mailing list for information exchange that isn't of interest to "generic" IPSEC crowd. If so, the announcement will come out her shortly. Otherwise we'll stay here, for your benefit and our amusement. In the meanwhile, please inhale, exhale and contemplate the following: what information that one could retrieve would help you monitor, control and DEBUG an IPSEC code? As has been already said, we can give you plenty of counters - but do you care to have 'em? If you are an implementor who has the pleasure of debugging the code, or a NetAdmin who's going to have the sorry job of configuring the installations and figuring out why the hell the dozen of seemingly healthy computers absolutely refuse to talk to each other - please read on and be ready to give us peace of your mind wrt. what we can do to make your life easier. IPSEC MIB can offer you knowb and dials to monitor what the protocol is doing and to affect (control) its operations. Probably IPSEC MIB will be used in conjunction with the other MIBs your box is likely to have ("interfaces" group, for example, that gives you some info on what's going on with the interface cards - how much traffic went through, error rate etc). A first shot. Dials: - a list of SPIs with the parameter values might be helpful; - a list of the hashes of the keys in use might assist in debugging; - some counters (number of rekeys, number of bad auth, garbled crypto, etc.) could be of some use; - do you care to have anything else? Precisely what? What for (i.e. how would you use it)? Knobs/buttons: - enforce rekey now; - control of various windows and timeouts (make 'em narrower or wider); - enabling/disabling certain algorithms (that could be then used in the negotiations); - enabling/disabling certain modes (i.e. from now on only encrypting SA can be negotiated); - set certain parameters (length of something...?); - again, anything else? If this MIB is to be useful and not just a placeholder (like too many of the existing MIBs) - please give us your input. If you have anything [constructive] to say, please either post it here, or e-mail to BOTH of us: uri@watson.ibm.com rodney@sabletech.com Thanks for your attention, you may get back to work now (:-). Regards, Uri -=-=-==-=-=- uri@watson.ibm.com From owner-ipsec Wed Apr 9 18:52:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21271 for ipsec-outgoing; Wed, 9 Apr 1997 18:52:11 -0400 (EDT) To: ipsec@tis.com Subject: slicing and dicing From: Marc Horowitz Date: 09 Apr 1997 18:57:31 -0400 Message-ID: Lines: 11 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk There has recently been interest in my draft which explains (partially by reference) a method for using a bunch of bits to generate a set of keys. Here is a pointer to the i-d: ftp://ietf.org/internet-drafts/draft-horowitz-key-derivation-01.txt This document needs a few tweaks (in particular, I should inline the necessary part of blumenthal & bellovin's paper, as it's very simple), but it should be easily modified for IPsec use. Marc From owner-ipsec Thu Apr 10 00:14:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA22759 for ipsec-outgoing; Thu, 10 Apr 1997 00:12:48 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704100418.AA54137@hawpub.watson.ibm.com> Subject: Re: IPSec MIB To: angelos@dsl.cis.upenn.edu (Angelos D. Keromytis) Date: Thu, 10 Apr 1997 00:18:23 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199704100311.XAA19424@codex.cis.upenn.edu> from "Angelos D. Keromytis" at Apr 9, 97 10:10:59 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 Angelos D. Keromytis says: > > - a list of the hashes of the keys in use > > might assist in debugging; > > I'll point out that this allows for exhaustive search. It just *helps* an exhaustive search, making it slightly easier than a known-plaintext-exhaustive-search attack. An access to these particular objects should be restricted in any case, or these objects may not exist at all. The question here is whether the usefulness of these objects justifies their existence (and so we should devise a way to remove or minimize the exposure), or the benefit is too small to bother. When trying to figure out how come that the two boxes refuse to talk to each other, observing that: - the counter of "rejected 'cause of bad auth" is increasing rapidly; - the hashes of the key presumably used are different, one can make a pretty good guess what is happening. This assumes that there is an "authorized" NetAdmin whose job is to get the things working on his whole admin domain. As I said earlier, I'm not really sure what info is absolutely necessary to quickly determine the cause of the problem, nor whether the existing (plus those being designed now) protection methods of SNMP are deemed adequate. That is one of the reasons I'm asking all these questions. > > - some counters (number of rekeys, number of > > bad auth, garbled crypto, etc.) could be > > of some use; > > Yes. Two implementations use the netstat mechanism to display such > information. Good. Let's have it solidified, what counters could be of use. Obviously the ones I mentioned. Anything else? > >Knobs/buttons: > > I'd argue against *setting* anything. This is best done through the > key management daemon and policy engine. SNMP would complicate matters. Possibly. I tend to prefer to "concentrate" my control (i.e. both "watching" and "tweaking") in the same spot/tool... Anybody else cares to comment on this? > This however is a very critical MIB. I'm not sure whether setting > IPsec related SNMP variables makes any sense, since most of the > decisions are taken at a user level process (the KMP). This is a very good point. I didn't think about it. Of course KMP can be instrumented too... Should it be...? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 10 07:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25363 for ipsec-outgoing; Thu, 10 Apr 1997 07:51:23 -0400 (EDT) Message-Id: <199704101151.HAA25363@portal.ex.tis.com> To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: IPSec MIB In-reply-to: Your message of "Wed, 09 Apr 1997 17:48:09 -0400." <199704092148.RAA00302@alisan.ibm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12366.860641859.1@dsl.cis.upenn.edu> Date: Wed, 09 Apr 1997 22:10:59 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704092148.RAA00302@alisan.ibm.net>, Uri Blumenthal writes: > > - a list of SPIs with the parameter values > might be helpful; Absolutely. Three implementations right now use the kernfs/procfs interface for this. > - a list of the hashes of the keys in use > might assist in debugging; I'll point out that this allows for exhaustive search. > - some counters (number of rekeys, number of > bad auth, garbled crypto, etc.) could be > of some use; Yes. Two implementations use the netstat mechanism to display such information. >Knobs/buttons: > - enforce rekey now; > - control of various windows and timeouts (make > 'em narrower or wider); > - enabling/disabling certain algorithms (that > could be then used in the negotiations); > - enabling/disabling certain modes (i.e. from now > on only encrypting SA can be negotiated); > - set certain parameters (length of something...?); > - again, anything else? I'd argue against *setting* anything. This is best done through the key management daemon and policy engine. SNMP would complicate matters. >If this MIB is to be useful and not just a placeholder >(like too many of the existing MIBs) - please give us >your input. This however is a very critical MIB. I'm not sure whether setting IPsec related SNMP variables makes any sense, since most of the decisions are taken at a user level process (the KMP). My $.02 + tax. -Angelos From owner-ipsec Thu Apr 10 10:38:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27200 for ipsec-outgoing; Thu, 10 Apr 1997 10:36:44 -0400 (EDT) Date: Thu, 10 Apr 1997 10:40:22 -0400 (EDT) Message-Id: <199704101440.KAA23886@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Inconsistent Specs. Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk It seems that there is an inconsistency between the most recent drafts on IPsec and ISAKMP with respect to SPI/SA spaces. The IPsec draft seems to indicate that there is a single SPI space shared by all protocols, whereas the ISAKMP spec clearly indicates that this should not be the case. from draft-ietf-ipsec-arch-sec-01.txt: SPI Acronym for "Security Parameters Index." The combination of an SPI and a destination address uniquely identifies a simplex security association (SA, see below). The SPI is carried in IPsec protocols to select the set of parameters bound to an SA. An SPI has only local significance, defined by the creator of the SA; thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. [SNIP] 1.5 Security Association Management The concept of a "Security Association" is fundamental to both the IP Encapsulating Security Payload and the IP Authentication Header. The combination of a given Security Parameter Index (SPI) and Destination Address uniquely identifies a particular "Security Association". An implementation of the Authentication Header or the Encapsulating Security Payload MUST support this concept of a Security Association. A single IPsec Security Association is a simplex (unidirectional) connection with which either AH or ESP (but not both) is employed. If both AH and ESP protection is to be applied to a traffic stream, then two (or more) security associations are created to control processing of the traffic stream. from draft-ietf-ipsec-isakmp-07.txt: Security Parameter Index (SPI) An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. From owner-ipsec Thu Apr 10 12:29:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27864 for ipsec-outgoing; Thu, 10 Apr 1997 12:26:59 -0400 (EDT) Message-Id: <199704100013.TAA00333@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Effective policy enforcement In-reply-to: Your message of "Wed, 09 Apr 1997 13:47:43 CDT." <199704091747.AA190658064@bcarh6dc.ott.bnr.ca> Date: Wed, 09 Apr 1997 19:13:52 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Marcus" == Marcus Leech writes: Marcus> (2) Viable policy engines in IPSEC/ISAKMP systems that Marcus> make rich policy enforcement possible, and easy to Marcus> administer. I too want to see this too. I know that this is planned for several implementations. I'm hoping that the "FreeSWAN" implementations will be one of them. Marcus> (3) Availability to the applications of any and all Marcus> attributes and/or authorizations carried in a certificate Marcus> used to establish an SA (this applies to both X.509 and Marcus> SPKI). In other words, it ought to be possible for an Marcus> application to determine all of the security-relevant Marcus> attributes for incoming connections to those applications. This requires an extensive API. I'd like to see, as a first step, a work new ipsec wg work item: we should be writing drafts to describe SPKI auth/tag fields. I suggest that this be scheduled for post-Proposed Status for the existing drafts. ] IETF #38. In Memphis, TN. Elvis is in the terminal room! | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM0wwu8mxxiPyUBAxAQElCAL/ai1DXZOvAzhIBgGINaLQfJ0Q5MC5QmcB FVHxExmWrbhDGrHv5I54lio+z0rXFLUhMlv9hgVNdUEVpbidWIrwS3Vmi1wqsiWS t1hX77QSX915n0dAuJAR7PJSBCKDplXE =6eZq -----END PGP SIGNATURE----- From owner-ipsec Thu Apr 10 17:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29667 for ipsec-outgoing; Thu, 10 Apr 1997 17:22:10 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9704061421.AA285590@hawpub.watson.ibm.com> References: from "Stephen Kent" at Apr 5, 97 07:54:54 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 1997 17:26:08 -0400 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, >> IPsec defines a protocol, and a protocol definition inlcludes the >> processing that takes place at the sender and receiver in response to the >> transmission and reception of packets, not just the format of the packet >> bits on the wire. > >Yes, but what to do with the INFORMATION AFTER it is processed clearly >is beyond the scope. Verify auth - within. Enter a certain state when >the auth failed - within. Define what the alert contains, who it is >sent to etc. - questionably outside. Insisting that this alert >really gets somewhere - clearly outside. The events that trigger audit activities are part of the protocol spec, as are other specifications of error conditions. A requirement that an implementation be capable of creating audit log entries in response to such events is also a legitimate part of the protocol processing spec. [SNIP] >> I also believe that the IPsec architecture document is a good place >> to discuss when to audit, and what systems MUST/SHOULD provide an audit >> capability and what is meant by "secure audit." That audit records can be >> maintained locally, or transmitted to a remote location, is an appropriate >> elaboartion of the audit concept and I'm happy to include that as well. > >Let us not mix the two things! It is good and well to ADVISE the user >and RECOMMEND the best spots to insert certain implementation-dependent >features, like auditing. It is BAD to ENFORCE this 100% imlementation- >dependent thing. Responses from other WG members suggests that so long as we restrict the specs to requring support for what COULD be audited, IF auditing is turned on and IF the system in which IPsec is embedde supports auditing, then this is a reasonable part of the IPsec specifications. Steve From owner-ipsec Thu Apr 10 17:50:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29817 for ipsec-outgoing; Thu, 10 Apr 1997 17:50:02 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704101440.KAA23886@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 1997 17:54:29 -0400 To: ben@Ascend.COM (Ben Rogers) From: Stephen Kent Subject: Re: Inconsistent Specs. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, You're right! We will modify the AH and ESP specs to note that an SPI uniquely identifies an SA on a per destination AND per security protocol basis. Thanks for picking up on that inconsistency. Steve From owner-ipsec Thu Apr 10 19:14:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00188 for ipsec-outgoing; Thu, 10 Apr 1997 19:13:51 -0400 (EDT) Message-Id: <199704102118.RAA06537@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: Slicing and Dicing in new-esp Date: Thu, 10 Apr 1997 17:18:25 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk The new esp draft, draft-ietf-ipsec-new-esp-00.txt, has two "slots" into which algorithms can be plugged -- an encryption slot, and an integrity slot. This is somewhat different from the previous monolithic transform architecture in the Hughes draft. The consensus on slice & dice at the meeting today was that transforms get one key, and are responsible for dividing the "key blob" between the various uses they have for it. In the case of new-esp, we have a hierarchical arrangement, with ESP in the middle, key management above, and algorithms beneath; the new-esp document really defines both ESP and a "meta" transform. I presume that the new-esp meta-transform gets a (single) key blob from "above" and needs to break it up and pass "key blobs" down into the algorithms which plug into it. Now, there are certain, obvious to a non-cryptographer, problems with passing the exact same blob to both algorithms. I believe that the right thing to do here is to specify that new-ESP is responsible for dividing the blob into two pieces and feeding one to the encryption algorithm and the other into the integrity algorithm; the individual algorithms are resposible for any relevant algorithmic-specific key processing. - Bill From owner-ipsec Fri Apr 11 07:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04255 for ipsec-outgoing; Fri, 11 Apr 1997 07:49:47 -0400 (EDT) Message-Id: <199704111149.HAA04255@portal.ex.tis.com> To: Michael Richardson cc: ipsec@tis.com Subject: Re: Effective policy enforcement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13733.860736298.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:24:58 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704100013.TAA00333@morden.sandelman.ottawa.on.ca>, Michael Richa rdson writes: > This requires an extensive API. Well, i would think that the important attributes are whether the link is: a) encrypted b) authenticated c) tunneled (ie the options are protected) d) compressed (?) These are addressed (at least to some extend) in Dan McDonald's draft. > I'd like to see, as a first step, a work new ipsec wg work item: we >should be writing drafts to describe SPKI auth/tag fields. I suggest >that this be scheduled for post-Proposed Status for the existing drafts. I agree. I wouldn't even mind working towards it. -Angelos From owner-ipsec Fri Apr 11 07:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04247 for ipsec-outgoing; Fri, 11 Apr 1997 07:48:46 -0400 (EDT) Message-Id: <199704111148.HAA04247@portal.ex.tis.com> To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: IPSec MIB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13466.860733942.1@dsl.cis.upenn.edu> Date: Thu, 10 Apr 1997 23:45:43 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704100418.AA54137@hawpub.watson.ibm.com>, Uri Blumenthal writes: >An access to these particular objects should be restricted in >any case, or these objects may not exist at all. The question >here is whether the usefulness of these objects justifies >their existence (and so we should devise a way to remove >or minimize the exposure), or the benefit is too small >to bother. Well, i think that: a) this is useful mostly for debugging (-> development) b) why open a potential hole there if it's not going to be used by your every-day user/admin/whoever >Of course KMP can be instrumented too... Should it be...? I believe that mandating KMPs to monitor SNMP variables is unreasonable (i will admit i have little knowledge of the inner workings of SNMP). If you make it optional, router vendors will probably support it. For all other implementations (ie. non-routers), i think it's not realistic to use a network monitoring protocol to control a user application (the KMP). My 4.8 drachmas (about $0.02). -Angelos From owner-ipsec Fri Apr 11 07:50:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04279 for ipsec-outgoing; Fri, 11 Apr 1997 07:50:46 -0400 (EDT) Message-Id: <199704111150.HAA04279@portal.ex.tis.com> To: Stephen Kent cc: uri@watson.ibm.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13869.860737233.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:40:33 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > >Responses from other WG members suggests that so long as we restrict the >specs to requring support for what COULD be audited, IF auditing is turned >on and IF the system in which IPsec is embedde supports auditing, then this >is a reasonable part of the IPsec specifications. Well, today's implementor's meeting at the IPsec decided that auditing *should* be done. I strongly disagree with going into details of the sort "well, if you have auditing and you have it turned on then you should log this and that event". -Angelos From owner-ipsec Fri Apr 11 07:58:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04347 for ipsec-outgoing; Fri, 11 Apr 1997 07:57:49 -0400 (EDT) Message-Id: <199704111157.HAA04347@portal.ex.tis.com> To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13892.860737473.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:44:33 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704102118.RAA06537@thunk.ch.apollo.hp.com>, Bill Sommerfeld writ es: >Now, there are certain, obvious to a non-cryptographer, problems with >passing the exact same blob to both algorithms. I believe that the >right thing to do here is to specify that new-ESP is responsible for >dividing the blob into two pieces and feeding one to the encryption >algorithm and the other into the integrity algorithm; the individual >algorithms are resposible for any relevant algorithmic-specific key >processing. I fully agree. -Angelos From owner-ipsec Fri Apr 11 08:24:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA04573 for ipsec-outgoing; Fri, 11 Apr 1997 08:24:25 -0400 (EDT) Message-Id: <199704111227.HAA00308@smb.research.att.com> To: "Angelos D. Keromytis" cc: uri@watson.ibm.com, ipsec@tis.com Subject: Re: IPSec MIB Date: Fri, 11 Apr 1997 07:27:56 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704100418.AA54137@hawpub.watson.ibm.com>, Uri Blumenthal writes: >An access to these particular objects should be restricted in >any case, or these objects may not exist at all. The question >here is whether the usefulness of these objects justifies >their existence (and so we should devise a way to remove >or minimize the exposure), or the benefit is too small >to bother. Well, i think that: a) this is useful mostly for debugging (-> development) b) why open a potential hole there if it's not going to be used by your every-day user/admin/whoever >Of course KMP can be instrumented too... Should it be...? I believe that mandating KMPs to monitor SNMP variables is unreasonable (i will admit i have little knowledge of the inner workings of SNMP). If you make it optional, router vendors will probab ly support it. Current IETF policy requires that every protocol have a MIB, and that all network elements be manageable via SNMP. After all, if we can mandate security, others can mandate manageability... From owner-ipsec Fri Apr 11 10:40:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05503 for ipsec-outgoing; Fri, 11 Apr 1997 10:39:04 -0400 (EDT) Date: Fri, 11 Apr 1997 10:41:31 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704111441.KAA08079@earth.hpc.org> To: sommerfeld@apollo.hp.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704102326.QAA09456@baskerville.CS.Arizona.EDU> Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk The discussion seems to cover only slicing the key blob, not inflating. If the key blob is shorter than the total key length needed by the transform algorithms, then it must be inflated, and the inflation should be done on the total key blob, not slices of it. E.g., integrity needs 160 bits of key, encryption needs 112, the key blob is 200 bits. I've recommended using something like K' = hash(K,0) | hash(K,1) as the inflated key blob, and then 160 and 112 can be sliced from K', assuming that the output of the hash function is large enough. And the hash function is the one used for the key negotiation. BTW, it's not obvious to me that having encryption and integrity use the same key blob is so very awful. Hilarie From owner-ipsec Fri Apr 11 14:19:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06767 for ipsec-outgoing; Fri, 11 Apr 1997 14:17:00 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704111822.AA22459@hawpub.watson.ibm.com> Subject: Re: IPSec MIB To: angelos@dsl.cis.upenn.edu (Angelos D. Keromytis) Date: Fri, 11 Apr 1997 14:22:41 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199704110446.AAA25757@codex.cis.upenn.edu> from "Angelos D. Keromytis" at Apr 10, 97 11:45:43 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 Angelos D. Keromytis says: > Well, i think that: > a) this is useful mostly for debugging (-> development) > b) why open a potential hole there if it's not going to be used by > your every-day user/admin/whoever You might be surprised, but most OTHER vendors do have bugs in their code, and systems do get misconfigured more often than not. Thus, "debugging" isn't only done by the vendor quality control - but often by the customers as well. > >Of course KMP can be instrumented too... Should it be...? > I believe that mandating KMPs to monitor SNMP variables is > unreasonable (i will admit i have little knowledge of the inner > workings of SNMP). If you make it optional, router vendors will probably > support it. Oh no, either IPSEC nor KMP would ever *monitor* SNMP variables! They might *maintain* those variables so that SNMP may *access* them (i.e. "request" the values of those variables, if al the proper credentials are shown). > For all other implementations (ie. non-routers), i think it's not > realistic to use a network monitoring protocol to control a user > application (the KMP). Well, there's megabucks market for application management, and there are at least two WG's in the IETF that are working on application management via SNMP (ApplMIB and SysAplMIB to name a few)... And those aim at monitoring (and managing?) various applications running on different systems... > My 4.8 drachmas (about $0.02). (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Fri Apr 11 16:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07587 for ipsec-outgoing; Fri, 11 Apr 1997 16:37:58 -0400 (EDT) Message-Id: <199704112041.QAA05594@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp In-reply-to: Your message of "Fri, 11 Apr 1997 10:41:31 EDT." <199704111441.KAA08079@earth.hpc.org> Date: Fri, 11 Apr 1997 16:41:13 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hilarie" == Hilarie Orman writes: Hilarie> not inflating. If the key blob is shorter than the total Hilarie> key length needed by the transform algorithms, then it Hilarie> must be inflated, and the inflation should be done on the This keeps coming up. My understanding is that this won't happen: the key management daemon can produce as many bits as needed for the security bundle. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM06ftKZpLyXYhL+BAQF2cAL+LKH6FUpdjITciiJIhDHk8EicRiq8F0f0 TUqseC0uQ0aF+3hLUsu+IeUWoxcyqS50A6Xg4sdauCyMBL1JGp59GEg+e/toSGHW amwj/Bka8r9jPLHR/tGUjwCdbFYa1Py9 =xSOt -----END PGP SIGNATURE----- From owner-ipsec Fri Apr 11 17:26:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07845 for ipsec-outgoing; Fri, 11 Apr 1997 17:24:53 -0400 (EDT) Date: Fri, 11 Apr 1997 17:25:43 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704112125.RAA20181@earth.hpc.org> To: mcr@sandelman.ottawa.on.ca Cc: ipsec@tis.com In-reply-to: Yourmessage <199704112057.NAA14171@baskerville.CS.Arizona.EDU> Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk > My understanding is that this won't happen: the key management > daemon can produce as many bits as needed for the security bundle. I hope it won't happen. The key management can produce as many bits of entropy as are needed for the security bundle; whether or not it presents that entropy in a string with as many bits as the security bundle desires is less clear. If it does produce the correct number of bits, then it might as well present them pre-sliced, it seems to me. If the transforms still wish to twiddle the bits, they can do so. Hilarie From owner-ipsec Sat Apr 12 12:13:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12319 for ipsec-outgoing; Sat, 12 Apr 1997 12:09:17 -0400 (EDT) Message-ID: <01BC4732.ADC2E860@tastid.cisco.com> From: Rob Adams To: "mcr@sandelman.ottawa.on.ca" , "'Hilarie Orman'" Cc: "ipsec@tis.com" Subject: RE: Slicing and Dicing in new-esp Date: Sat, 12 Apr 1997 11:14:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In the implementors meeting we agreed that the key management layer will create for the transform a minimum number of bits of key material specified by the transform. We shouldn't have a problem anymore. -Rob ---------- From: Hilarie Orman[SMTP:ho@earth.hpc.org] Sent: Friday, April 11, 1997 2:25 PM To: mcr@sandelman.ottawa.on.ca Cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp > My understanding is that this won't happen: the key management > daemon can produce as many bits as needed for the security bundle. I hope it won't happen. The key management can produce as many bits of entropy as are needed for the security bundle; whether or not it presents that entropy in a string with as many bits as the security bundle desires is less clear. If it does produce the correct number of bits, then it might as well present them pre-sliced, it seems to me. If the transforms still wish to twiddle the bits, they can do so. Hilarie From owner-ipsec Sat Apr 12 12:25:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12423 for ipsec-outgoing; Sat, 12 Apr 1997 12:25:35 -0400 (EDT) Message-Id: <199704111939.PAA07189@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp In-Reply-To: ho's message of Fri, 11 Apr 1997 10:41:31 -0400. <199704111441.KAA08079@earth.hpc.org> Date: Fri, 11 Apr 1997 15:39:54 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm trying to make sure that the boundary between key management and ESP/AH is well specified. Assuming I understand it correctly, the current new-esp draft mentions receiving two keys from key management (one auth key, one encryption key), while the current ipsec DOI draft specifies providing one key blob to ESP. This sounds like a mismatch to me.. > The discussion seems to cover only slicing the key blob, not > inflating. If the key blob is shorter than the total key length > needed by the transform algorithms, then it must be inflated, and the > inflation should be done on the total key blob, not slices of it. Right, but this expansion should happen in key management, not the transforms/algorithms; ESP should not need to know which prf was used for key negotiation. During the implementors meeting, there seemed to be no objection to the concept that the transform should ask for a specific amount of keying material, and that key management is responsible for delivering at least that much. - Bill From owner-ipsec Sat Apr 12 12:26:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12436 for ipsec-outgoing; Sat, 12 Apr 1997 12:26:05 -0400 (EDT) Message-Id: <199704112048.QAA07306@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Angelos D. Keromytis" Cc: Stephen Kent , uri@watson.ibm.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: angelos's message of Fri, 11 Apr 1997 00:40:33 -0000. <199704111150.HAA04279@portal.ex.tis.com> Date: Fri, 11 Apr 1997 16:48:53 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Responses from other WG members suggests that so long as we restrict the > >specs to requring support for what COULD be audited, IF auditing is turned > >on and IF the system in which IPsec is embedde supports auditing, then this > >is a reasonable part of the IPsec specifications. > > Well, today's implementor's meeting at the IPsec decided that auditing > *should* be done. I strongly disagree with going into details of > the sort "well, if you have auditing and you have it turned on then > you should log this and that event". Ok, between Steve's message and what I saw at the meeting yesterday, there seems to be general agreement that the drafts should define the "audit points" in the protocol (that may not be quite the right term, but I think people know what I mean), and that if ipsec auditing is supported by an implementation, it should be possible for an administrator to enable/disable it. The remaining point of contention appears to be the difference between "SHOULD support auditing" and "MUST support auditing if the platform supports auditing". I think that there's not going to be a whole lot of difference in practice between these two points, so I don't see a need to overspecify on this point -- the documents are long enough as it is.. - Bill From owner-ipsec Sun Apr 13 00:10:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA15274 for ipsec-outgoing; Sun, 13 Apr 1997 00:08:31 -0400 (EDT) Message-Id: <2.2.32.19970413041321.0068e7a8@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Apr 1997 21:13:21 -0700 To: ipsec@tis.com From: Avram Shacham Subject: IPComp presentation URL Sender: owner-ipsec@ex.tis.com Precedence: bulk Per several requests, the IP Compression data, as presented to the IPSec working group in Memphis, Tennessee, on 4-9-97, are located at http://www.tgv.cisco.com/public/shacham/ipcomp.ppt The file is in PowerPoint v7.0 format. Regards, avram From owner-ipsec Mon Apr 14 07:55:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24659 for ipsec-outgoing; Mon, 14 Apr 1997 07:45:57 -0400 (EDT) Date: Mon, 14 Apr 1997 01:40:02 -0400 From: Ran Canetti Message-Id: <9704140540.AA25094@ornavella.watson.ibm.com> To: ipsec@tis.com Subject: Re: IPSec MIB Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > - a list of the hashes of the keys in use > > > might assist in debugging; > > > > I'll point out that this allows for exhaustive search. > > It just *helps* an exhaustive search, making it slightly easier > than a known-plaintext-exhaustive-search attack. Let me just point out that making public the hash of the secret key can be disastrous to the security is some scenarios (I slightly elaborate below.) So, if the intention is to publicize the hash only during development stage than that's ok (as long as this option is later turned off). But doing that in real deployment of the protocol is a no-no. Assume for simplicity that Alice wants to encrypt only one word: either "yes" or "no". Also, not trusting DES, Alice uses the most secure encryption protocol, namely one-time-pad. That is, the ciphertext is the cleartext xored with the key. If Alice uses a key derived from the current ISAKMP/Oakley protocol then the transmission will be secure. But if the protocl publishes a hash of the key, then it's easy to find out whether the message was "yes" or "no"! (Simply xor the ciphertext with "yes", hash, and compare with the hashed key.) Even if we do not know the possible messages and cannot do exhaustive search, then by making public the hash of the key we're making a very strong assumption on the hash function: we assume that the hash does not reveal *any relevant information* on the key. The existing hash functions were not designed for such a purpose and it's far from clear that they are strong enough for this use. Hope I'm not barging through an already open door, Ran From owner-ipsec Mon Apr 14 07:55:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24740 for ipsec-outgoing; Mon, 14 Apr 1997 07:51:02 -0400 (EDT) Date: Fri, 11 Apr 97 23:01:59 GMT From: "William Allen Simpson" Message-ID: <2264.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: IPSec MIB Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Uri Blumenthal > Angelos D. Keromytis says: > > a) this is useful mostly for debugging (-> development) > > b) why open a potential hole there if it's not going to be used by > > your every-day user/admin/whoever > > You might be surprised, but most OTHER vendors do have bugs > in their code, and systems do get misconfigured more often > than not. Thus, "debugging" isn't only done by the vendor > quality control - but often by the customers as well. > Gentlefolk, in my experience, it has been a long standing policy of the network management area that protocol debugging and development variables are _not_ appropriate for MIBs. I expect that IESG integration of management with operations should make that even more clear. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 14 12:13:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26716 for ipsec-outgoing; Mon, 14 Apr 1997 12:10:04 -0400 (EDT) Date: Mon, 14 Apr 1997 12:14:52 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704141614.MAA17818@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Effective policy enforcement X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Marcus Leech" > > I've been thinking a fair amount about the question of, once we have > IPSEC, what kinds of access control (and other) policy may actually > be implemented by system administrators using IPSEC with ISAKMP. > > The current implementations of ISKMP use X.509 certificates, which allow > the administrator to establish very broad policy, like: > > "I will establish an SA with any entitiy bearing a certificate signed by > my CA" > > "I will establish an SA with an entity named Marcus Leech, provided that > the certificate was signed by Nortel". > > Both of these policy directives are implementable with the existing ISAKMP > assumptions about certificates. Note, however, that in the second case, > if I want to produce (for example) a "group" policy, I must enumerate > the Distinguished Names of each member in the group, or I must establish > a group CA, and use the first type of policy statement mentioned above. > > The work of the SPKI group allows for much richer policy enforcement than > is possible with an X.509 scheme. This is certainly not true. The evolving SPKI mechanism can allow a richer set of authorizations than the two broad examples you specified above. But so does X.509. The richness of expression (and the attendent complexity) of an access control mechanism is determined by the capabilities of the mechanism, not by a particular certificate encoding format. A recent message by David Simonetti (in a non-IETF forum) listed seven access control mechanisms currently being developed for a specific (X.509-based, non-IETF) application, and proposed that they be consolidated into four categories: "ISO 10181-3, Access Control Framework, provides the following classification of access control mechanisms: Cabability-based, Label-based, List-based, and Contextual-based." The point of this quotation is not that the MISSI access control framework or ISO 10181-3 are the be-all and end-all of "policy administration". The point is that characterizing X.509 certificates based on the capabilities of current IPSEC/ISAKMP implementations is a tad myopic, and ignores a large body of prior art. From owner-ipsec Mon Apr 14 16:12:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28606 for ipsec-outgoing; Mon, 14 Apr 1997 16:11:08 -0400 (EDT) Date: Mon, 14 Apr 1997 16:16:20 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: ipsec@tis.com Subject: ESP with stream ciphers Message-Id: <97Apr14.161245edt.11650@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I am wondering how to handle stream ciphers like RC4 in ESP. In particular, where does the stream offset go? I can think of three possibilities: 1. Abuse the IV field. The draft remains unchanged. 2. Consider the stream offset field part of the payload data, as suggested by Steve Bellovin. The draft remains unchanged. 3. Rename the IV field. (Algorithm Specific Data?) A simple textual substitution in the draft and in the drafts for the individual encryption algorithms. 4. Consider the IV and stream offset fields part of the payload data, as suggested by Steve Bellovin. This is a more substantive change, and also affects the drafts for the individual encryption algorithms. But it would simplify ESP by eliminating an optional variable-length field. It would also generalize ESP to accommodate any encryption algorithm with or without any algorithm-specific data at all. What do you think? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Mon Apr 14 16:45:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28844 for ipsec-outgoing; Mon, 14 Apr 1997 16:45:41 -0400 (EDT) Date: Mon, 14 Apr 1997 16:51:13 -0400 From: Ran Canetti Message-Id: <9704142051.AA26905@ornavella.watson.ibm.com> To: ho@earth.hpc.org, sommerfeld@apollo.hp.com Subject: Re: Slicing and Dicing in new-esp Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, >BTW, it's not obvious to me that having encryption and integrity use >the same key blob is so very awful. I must strongly differ on that issue. As was pointed out several times before, using the same keying material for two different purposes (or even for the same purpose but with two different algorithms) can result in totally insecure systems, even if the individual components are secure. A "quintessential" example is DES-CBC for encryption and DES-CBC-MAC for authentication. If you use the same key for both then your authentication is useless: the MAC output will always be identical to the last block of the ciphertext. Thus an attacker can change the ciphertext at wish. More generally, different algorithms may have weakenesses on different parts of the key, in a way that makes the combination insecure. For instance, assume the same key k is used for two imaginary algorithms A and B. Algorithm A leaks the first half of its key, but is still secure based on the second half. Algorithm B leaks the second half of its key, but is still secure based on the first half. If, however, you use the same key for both A and B then the entire key is leaked and both algorithms become insecure... Ran Canetti From owner-ipsec Mon Apr 14 17:54:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29284 for ipsec-outgoing; Mon, 14 Apr 1997 17:45:33 -0400 (EDT) Date: Mon, 14 Apr 1997 17:51:04 -0400 From: Ran Canetti Message-Id: <9704142151.AA26313@ornavella.watson.ibm.com> To: ipsec@tis.com, sommerfeld@apollo.hp.com Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The consensus on slice & dice at the meeting today was that transforms > get one key, and are responsible for dividing the "key blob" between > the various uses they have for it. > > In the case of new-esp, we have a hierarchical arrangement, with ESP > in the middle, key management above, and algorithms beneath; the > new-esp document really defines both ESP and a "meta" transform. > > I presume that the new-esp meta-transform gets a (single) key blob > from "above" and needs to break it up and pass "key blobs" down into > the algorithms which plug into it. > > Now, there are certain, obvious to a non-cryptographer, problems with > passing the exact same blob to both algorithms. I believe that the > right thing to do here is to specify that new-ESP is responsible for > dividing the blob into two pieces and feeding one to the encryption > algorithm and the other into the integrity algorithm; the individual > algorithms are resposible for any relevant algorithmic-specific key > processing. > > - Bill > I concur. This is the "cryptographically right" way to do it. A transform gets as much keying material as it needs from the key exchange module, and is responsible to slice it and use it in the correct way. In the case of ESP this means to partition the keying material to two DISJOINT parts, hand one part to the authentication algorithm and the other part to the encryption algorithm. Ran From owner-ipsec Mon Apr 14 19:22:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29694 for ipsec-outgoing; Mon, 14 Apr 1997 19:19:00 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 19:17:17 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I agree with Steve Bellovin's suggestion that we should view the IV as the beginning of the payload, since each encryption algorithm mode will "know" whether an IV is explicitly present, or not, and how big it is, etc. This tact was adopted in some other security protocols, e.g., the IEEE SDE protocol, while others opted for an explicit IV field. In an effort to simplify the format and minimize optional variable length fields, I'm in favor of adopoting Steve's suggestion. In this vein, a stream cipher offset(or an IV for a stream cipher) could also appear as the beginning of an encrypted payload. If there are no objections, I'll plan to make these changes to the next rev of the ESP spec. Steve From owner-ipsec Tue Apr 15 00:03:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA01010 for ipsec-outgoing; Tue, 15 Apr 1997 00:01:30 -0400 (EDT) Date: Tue, 15 Apr 1997 00:05:35 -0400 From: Ran Canetti Message-Id: <9704150405.AA24745@ornavella.watson.ibm.com> To: ipsec@tis.com Subject: A pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Pau-Chen and I just stumbled over a pretty significant security pothole in the ISAKMP/Oakley draft. I believe it's important enough to mandate the appropriate change, as annoying as it may be. Luckily, the required change is small. Assume that the same instance of quickmode is used to create two different SA's (say, one for AH and one for ESP). The current method for deriving KEYMAT allows unsuspecting implementations to have the same KEYMAT for the two SA's. This situation - two SA's with the same KEYMAT - is a cryptographic show stopper. (See my note to the list from earlier today about the hazards of using the same key for two different algorithms/purposes.) Details: The problem: Currently, KEYMAT is calculated as follows: (page 15) KEYMAT = prf(SKEYID_d, SPI | Ni | Nr) or KEYMAT = prf(SKEYID_d, g^xy | SPI | Ni | Nr) In either case, the only field that makes the KEYMAT of the two SA's different is the SPI. However, do the SPIs of the two SA's need to be different? Here the opinions differ... ISAKMP draft 07 (section 2.1) says: "Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA." The IPSEC architecture document says: "The combination of an SPI and a destination address uniquely identifies a simplex security association". In practice, we have actually encountered during interop tests an implementation where two such SA's had the same SPI! The fix: The goal is, as usual, to avoid having the security of the protocol rely on architectural issues such as whether the SPI's should be different or not. Specifically, A relatively simple fix is to add protocol-ID as an additional input to the prf in the computation of KEYMAT. This way, we will be assured that the inputs to the prf differ between the two SA's, thus the two SA's will have cryptographically independent values of KEYMAT. That is, define KEYMAT = prf(SKEYID_d, protocol-ID | SPI | Ni | Nr) or KEYMAT = prf(SKEYID_d, protocol-ID | g^xy | SPI | Ni | Nr) Ran Canetti From owner-ipsec Tue Apr 15 08:46:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03934 for ipsec-outgoing; Tue, 15 Apr 1997 08:41:19 -0400 (EDT) Message-Id: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 15 Apr 1997 08:44:50 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: ESP with stream ciphers In-Reply-To: References: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Exactly what will this look like? I guess the current scheme is: <8 byte IV> and the new scheme will be: <8 byte IV> -OR- So... Am I correct this stream offset is a 32-bit animal not a 64-bit animal? We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? Why do we need a stream offset anyway? I assume that, since it's a stream, the data order is significant, and if you get packets out of order you have to be careful how you feed them into the decryption logic. But wouldn't the IP header give you enough information to detect out-of-order anyway? Also, regardless of how you determine stream offset, what are you going to do when you get bytes out of order? At 07:17 PM 4/14/97 -0400, you wrote: >Norm, > > I agree with Steve Bellovin's suggestion that we should view the IV >as the beginning of the payload, since each encryption algorithm mode will >"know" whether an IV is explicitly present, or not, and how big it is, etc. >This tact was adopted in some other security protocols, e.g., the IEEE SDE >protocol, while others opted for an explicit IV field. In an effort to >simplify the format and minimize optional variable length fields, I'm in >favor of adopoting Steve's suggestion. In this vein, a stream cipher >offset(or an IV for a stream cipher) could also appear as the beginning of >an encrypted payload. If there are no objections, I'll plan to make these >changes to the next rev of the ESP spec. > >Steve > > > > From owner-ipsec Tue Apr 15 09:49:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04377 for ipsec-outgoing; Tue, 15 Apr 1997 09:48:05 -0400 (EDT) Date: Tue, 15 Apr 1997 09:50:44 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151350.JAA26384@earth.hpc.org> To: canetti@watson.ibm.com Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com In-reply-to: Yourmessage <199704150414.VAA27630@baskerville.CS.Arizona.EDU> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk The basic problem was noted in January, and the fragility of the use of the SPI was also noted then. My preference is to include a state variable with SKEYID that is an instance number; the state variable gets incremented every time keying material is generated, and the keying material depends on the variable. I will note, however, that if the SPI's are pseudo-randomly generated, as is required by the spec, then the probability of using the same SPI twice should be extremely low. So the implementations that revealed this problem were defective. Hilarie From owner-ipsec Tue Apr 15 10:53:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04822 for ipsec-outgoing; Tue, 15 Apr 1997 10:52:13 -0400 (EDT) Date: Tue, 15 Apr 1997 10:57:20 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Rodney Thayer cc: ipsec@tis.com Subject: Re: ESP with stream ciphers In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Message-Id: <97Apr15.105340edt.11653@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 15 Apr 1997, Rodney Thayer wrote: > Am I correct this stream offset is a 32-bit animal not a 64-bit animal? The first draft for stream ciphers specified a 64 bit offset. The second draft specifies an offset of 32 or 64 bits, with 32 bits recommended. > We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? DES requires a 64 bit IV, but for ESP a 32 bit folded IV is often transmitted. Early 3DES drafts require a 64 bit IV (outer, not inner). > Why do we need a stream offset anyway? I assume that, since it's a stream, > the data order is significant, > and if you get packets out of order you have to be careful how you feed > them into the decryption > logic. But wouldn't the IP header give you enough information to detect > out-of-order anyway? > Also, regardless of how you determine stream offset, what are you going to > do when you get > bytes out of order? The ciphers are stream ciphers, but IP has no concept of streams. Stream offsets are needed by stream ciphers for the same reason that IVs are needed by chained block ciphers: so that packets can be decrypted even if they are received out of order. Using the ip_id field to detect out-of-order packets is problematic for a couple of reasons. First, this value is unique for all IP packets sent by a host, so on any given connection it is not necessarily contiguous. This complicates window management. Second, this is a 16-bit value initialized from the system clock, so you would have to deal with wraparound. Given an out-of-order packet with a stream offset, what you do depends on the cipher. For SEAL, the pad can be computed directly. RC4 can move forward or backward in the key stream; cacheing state can save work here. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 15 11:03:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04934 for ipsec-outgoing; Tue, 15 Apr 1997 11:03:45 -0400 (EDT) Date: Tue, 15 Apr 97 08:08:00 PDT From: John H Wilson Message-ID: To: ipsec@tis.com Subject: Re[2]: ESP with stream ciphers Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: Rodney Thayer wrote: > > >So... >Am I correct this stream offset is a 32-bit animal not a 64-bit animal? I really think we ought to go with 64 bits. Video conferencing streams could persist for some time at quite a high bit rate. 2^32 just doesn't seem enough to me. (Unless you could negotiate 32 v 64). >Also, regardless of how you determine stream offset, what are you going to >do when you get bytes out of order? Did you mean packets out of order? In the case of audio/video streams, reset the algorithm to that bit position, and recover from the missing/late packet(s). John Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 References: <97Apr14.161245edt.11650@janus.border.com> In-Reply-To: Subject: Re: ESP with stream ciphers From: Rodney Thayer To: ipsec@tis.com Date: Tue, 15 Apr 1997 08:44:50 -0400 X-Mailer: Windows Eudora Light Version 3.0.1 (32) X-Sender: rodney@pop3.pn.com Message-Id: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA039 34 for ipsec-outgoing; Tue, 15 Apr 1997 08:41:19 -0400 (EDT) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.5/8.7.3) with ESMTP id HAA07610 for ; Tue, 15 Apr 1997 07:42:44 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id HAA22623 for ; Tue, 15 Apr 1997 07:40:25 -0700 (PDT) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Tue Apr 15 11:09:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04966 for ipsec-outgoing; Tue, 15 Apr 1997 11:08:48 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 11:20:18 -0400 Message-Id: <9704151520.AA21376@secpwr.watson.ibm.com> To: canetti@watson.ibm.com, ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: YezaRzTis0oi+pnfJrzO/w== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA04963 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From ho@earth.hpc.org Tue Apr 15 10:15:11 1997 > Date: Tue, 15 Apr 1997 09:50:44 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151350.JAA26384@earth.hpc.org> > To: canetti@watson.ibm.com > Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com > In-Reply-To: Yourmessage <199704150414.VAA27630@baskerville.CS.Arizona.EDU> > Subject: Re: A pothole in ISAKMP/Oakley > Content-Length: 563 > Status: RO > Hilarie : > The basic problem was noted in January, and the fragility of the use > of the SPI was also noted then. My preference is to include a state > variable with SKEYID that is an instance number; the state variable > gets incremented every time keying material is generated, and the > keying material depends on the variable. This may require some tight synchorization between I and R to keep the instance number in sync. I prefer not to do that. > > I will note, however, that if the SPI's are pseudo-randomly generated, > as is required by the spec, then the probability of using the same SPI > twice should be extremely low. So the implementations that revealed > this problem were defective. Yes. But the fix suggested in Ran's msg make the protocol immune to such "defect". Besides, there is value to use non pseudo-random SPI's for ESP and AH SA's (such as array indices to speed up SA look-up); I agree that for ISAKMP SA's the SPI's (cookies) should be pseudo-random to counter clogging attacks. > > Hilarie Regards, Pau-Chen From owner-ipsec Tue Apr 15 11:27:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05121 for ipsec-outgoing; Tue, 15 Apr 1997 11:27:26 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704151532.AA244730@hawpub.watson.ibm.com> Subject: Re: ESP with stream ciphers To: norm@border.com (Norman Shulman) Date: Tue, 15 Apr 1997 11:32:48 -0400 (EDT) Cc: rodney@sabletech.com, ipsec@tis.com In-Reply-To: <97Apr15.105340edt.11653@janus.border.com> from "Norman Shulman" at Apr 15, 97 10:57:20 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Norman Shulman says: > On Tue, 15 Apr 1997, Rodney Thayer wrote: > > We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? > > DES requires a 64 bit IV, but for ESP a 32 bit folded IV is often transmitted. > Early 3DES drafts require a 64 bit IV (outer, not inner). 3DES is secure only if used as a black-box engine (see Biham's paper). That means - no inner feedbacks. That in turn means - only one IV for the first DES is needed. It has to be 64 bits, and it can be folded for transmission to 32 bits, just like the good ESP draft says. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Tue Apr 15 12:38:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05593 for ipsec-outgoing; Tue, 15 Apr 1997 12:37:05 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704151642.JAA14702@kebe.eng.sun.com> Subject: Re: A pothole in ISAKMP/Oakley To: ho@earth.hpc.org (Hilarie Orman) Date: Tue, 15 Apr 1997 09:42:43 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 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 > I will note, however, that if the SPI's are pseudo-randomly generated, > as is required by the spec, then the probability of using the same SPI > twice should be extremely low. So the implementations that revealed > this problem were defective. Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I remember the specs correctly. Implementations that do otherwise are probably broken. Dan From owner-ipsec Tue Apr 15 13:14:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05851 for ipsec-outgoing; Tue, 15 Apr 1997 13:13:25 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 13:25:16 -0400 Message-Id: <9704151725.AA22888@secpwr.watson.ibm.com> To: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: s6Gwv0HOKs6iwmnFRSQuGw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA05848 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 12:57:42 1997 > From: Dan.McDonald@Eng.sun.com (Dan McDonald) > Message-Id: <199704151642.JAA14702@kebe.eng.sun.com> > Subject: Re: A pothole in ISAKMP/Oakley > To: ho@earth.hpc.org (Hilarie Orman) > Date: Tue, 15 Apr 1997 09:42:43 -0700 (PDT) > Cc: ipsec@tis.com > In-Reply-To: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 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 > Content-Length: 415 > Status: RO > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > as is required by the spec, then the probability of using the same SPI > > twice should be extremely low. So the implementations that revealed > > this problem were defective. > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > remember the specs correctly. Implementations that do otherwise are probably > broken. Dan, the spec does say so. But if an implementation uses a montonically increasing counter to generate SPI's for ESP and AH, it can interop with others. So I think it is worthwhile to put in a safeguard. Also, I would like to emphasize that Ran's msg is about QUICK Mode KEYMAT derivation in Phase 2. It is NOT about Phase 1. > Dan > Regards, Pau-Chen From owner-ipsec Tue Apr 15 14:22:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06317 for ipsec-outgoing; Tue, 15 Apr 1997 14:21:08 -0400 (EDT) Date: Tue, 15 Apr 1997 14:23:33 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151823.OAA04580@earth.hpc.org> To: pau@watson.ibm.com Cc: Dan.McDonald@Eng.sun.com, canetti@watson.ibm.com, ipsec@tis.com In-reply-to: Yourmessage <9704151748.AA23438@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > Also, it is possible to run a pseudo-random generator once, and use the > new random value as SPI for both ESP and AH (since the spec also says > they > have separate SPI-spaces, see section 2.1 of ISAKMP draft 7). Is this > broken ? > I guess it is a border-line case. The requirement for pseudo-random SPI's was not motivated by key management concerns, but rather to protect against denial of service attacks, I thought. > Will it interop, I think so. I didn't realize that the IETF had strict constructionists! Hilarie From owner-ipsec Tue Apr 15 14:33:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06528 for ipsec-outgoing; Tue, 15 Apr 1997 14:33:18 -0400 (EDT) Message-Id: <199704151838.LAA09674@fluffy.cisco.com> To: pau@watson.ibm.com cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-reply-to: Your message of "Tue, 15 Apr 1997 13:25:16 EDT." <9704151725.AA22888@secpwr.watson.ibm.com> Date: Tue, 15 Apr 1997 11:38:38 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > > as is required by the spec, then the probability of using the same SPI > > > twice should be extremely low. So the implementations that revealed > > > this problem were defective. > > > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > > remember the specs correctly. Implementations that do otherwise are probably > > broken. > > Dan, the spec does say so. But if an implementation uses a montonically > increasing counter to generate SPI's for ESP and AH, it can interop with > others. So I think it is worthwhile to put in a safeguard. > > Also, I would like to emphasize that Ran's msg is about QUICK Mode > KEYMAT derivation in Phase 2. It is NOT about Phase 1. Correct me if I'm wrong, but there's no longer any security basis for having the Phase 2 SPI's be pseudo-randomly generated. In fact, there were implementations at the IPSEC bake-off that used monotonically increasing SPI's. This argues for fixing this in the protocol. On the other hand, this is not a problem if you're doing the combined ESP for authentication, as you wouldn't then have a separate SA for an AH key. I think this is the normal case. I would like to reitterate what Douglas Maughan pointed out at the implementor's discussion last week, which is to remind everyone that the ISAKMP framework is specifically designed to accomodate multiple and divergent key exchange protocols. This allows us to cleanly define a new key exchange identifier in the future with fixes for "problems" like this. This might also include the performance improvements requested by Hugo. I don't think this is worth reopening the document to fix. I'd like to see it corrected in the next rev of the protocol, which should have a new key exchange identifier in the IPSEC DOI. In the mean time, the suggested use of pseudo-randomly generated Phase 2 SPI's remains a useful recommendation. Derrell, last seen rooting around his office for the Nomex suit... From owner-ipsec Tue Apr 15 15:16:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06822 for ipsec-outgoing; Tue, 15 Apr 1997 15:15:40 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 15:27:04 -0400 Message-Id: <9704151927.AA22368@secpwr.watson.ibm.com> To: pau@watson.ibm.com, ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: Dan.McDonald@Eng.sun.com, canetti@watson.ibm.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: dTSiU+E84Wkotzl+GVVvMg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA06819 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From ho@earth.hpc.org Tue Apr 15 14:32:44 1997 > Date: Tue, 15 Apr 1997 14:23:33 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151823.OAA04580@earth.hpc.org> > To: pau@watson.ibm.com > Cc: Dan.McDonald@Eng.Sun.COM, canetti@watson.ibm.com, ipsec@tis.com > In-Reply-To: Yourmessage <9704151748.AA23438@secpwr.watson.ibm.com> > Subject: Re: A pothole in ISAKMP/Oakley > Content-Length: 537 > Status: RO > > > Also, it is possible to run a pseudo-random generator once, and use the > > new random value as SPI for both ESP and AH (since the spec also says > > they > > have separate SPI-spaces, see section 2.1 of ISAKMP draft 7). Is this > > broken ? > > I guess it is a border-line case. > > The requirement for pseudo-random SPI's was not motivated by key management > concerns, but rather to protect against denial of service attacks, I thought. You are right. But since Quick Mode Exchange is proteted (encrypted and authenticated) by the phase 1 ISAKMP SA, clogging attack should not be a big problem. Ran's msg is about OAKLEY Quick Mode KEYMAT derivation, NOT phase 1 main mode. Regards, Pau-Chen From owner-ipsec Tue Apr 15 15:39:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06997 for ipsec-outgoing; Tue, 15 Apr 1997 15:38:30 -0400 (EDT) Date: Tue, 15 Apr 1997 15:41:03 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151941.PAA06920@earth.hpc.org> To: pau@watson.ibm.com Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com In-reply-to: Yourmessage <9704151927.AA22368@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > You are right. But since Quick Mode Exchange is proteted > (encrypted and authenticated) by the phase 1 ISAKMP SA, > clogging attack should not be a big problem. Maybe we are talking about different attacks. The requirement for AH and ESP SPI generation was there before there was key management. We should ask why. I'd guess that the worry has been that an attacker could predict the SPI sequence and insert bogus messages with valid SPI's into the traffic stream, forcing the recipient to go through at least the trouble of checking the hash if not also decrypting. Hilarie From owner-ipsec Tue Apr 15 15:43:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07062 for ipsec-outgoing; Tue, 15 Apr 1997 15:43:03 -0400 (EDT) Message-Id: <2.2.32.19970415195448.00ba9240@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, 15 Apr 1997 15:54:48 -0400 To: Ran Canetti From: Naganand Doraswamy Subject: Re: Slicing and Dicing in new-esp Cc: ipsec@tis.com, sommerfeld@apollo.hp.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran > >I concur. This is the "cryptographically right" way to do it. >A transform gets as much keying material as it needs from the >key exchange module, and is responsible to slice it and use >it in the correct way. In the case of ESP this means to >partition the keying material to two DISJOINT parts, >hand one part to the authentication algorithm and the other part to >the encryption algorithm. > > This is what we agreed in the working group. The transform knows how many bits it requires. The transforms need to define how they are going to split the keying material into disjoint parts. They may have to check for weak keys etc. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Apr 15 15:46:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07133 for ipsec-outgoing; Tue, 15 Apr 1997 15:46:37 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 15:58:33 -0400 Message-Id: <9704151958.AA22946@secpwr.watson.ibm.com> To: piper@cisco.com Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: Tb/P7lanKZnbuqvuYcqbWg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA07130 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From piper@cisco.com Tue Apr 15 14:45:12 1997 > Message-Id: <199704151838.LAA09674@fluffy.cisco.com> > To: pau@watson.ibm.com > Cc: ho@earth.HPC.ORG, Dan.McDonald@eng.sun.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > In-Reply-To: Your message of "Tue, 15 Apr 1997 13:25:16 EDT." <9704151725.AA22888@secpwr.watson.ibm.com> > Date: Tue, 15 Apr 1997 11:38:38 -0700 > From: Derrell Piper > Content-Length: 2040 > Status: RO > > > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > > > as is required by the spec, then the probability of using the same SPI > > > > twice should be extremely low. So the implementations that revealed > > > > this problem were defective. > > > > > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > > > remember the specs correctly. Implementations that do otherwise are probably > > > broken. > > > > Dan, the spec does say so. But if an implementation uses a montonically > > increasing counter to generate SPI's for ESP and AH, it can interop with > > others. So I think it is worthwhile to put in a safeguard. > > > > Also, I would like to emphasize that Ran's msg is about QUICK Mode > > KEYMAT derivation in Phase 2. It is NOT about Phase 1. > Derrell: > Correct me if I'm wrong, but there's no longer any security basis for > having the Phase 2 SPI's be pseudo-randomly generated. In fact, there were > implementations at the IPSEC bake-off that used monotonically increasing > SPI's. This argues for fixing this in the protocol. > > On the other hand, this is not a problem if you're doing the combined ESP > for authentication, as you wouldn't then have a separate SA for an AH key. > I think this is the normal case. AH still has its value in that it protects the "invariant" parts of IP header. I remember there was a (big) debate on this in the ipsec list and we end up with the AH we have today. > > I would like to reitterate what Douglas Maughan pointed out at the > implementor's discussion last week, which is to remind everyone that the > ISAKMP framework is specifically designed to accomodate multiple and > divergent key exchange protocols. This allows us to cleanly define a new > key exchange identifier in the future with fixes for "problems" like this. > This might also include the performance improvements requested by Hugo. > > I don't think this is worth reopening the document to fix. I'd like to see > it corrected in the next rev of the protocol, which should have a new key > exchange identifier in the IPSEC DOI. In the mean time, the suggested use > of pseudo-randomly generated Phase 2 SPI's remains a useful recommendation. If this were a change for performance, I think we should wait for the next rev.. But it is really a change to close a potential security loop hole. This is a 2-line change to the ISAKMP-OAKLEY doc. As for the code, the current doc requires the code to take the SPI value from the PROPOSAL payload header when computing Quick Mode KEYMAT. The proposed change requires the code to also take the "Protocol-ID" value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. I don't think that is a difficult change. > > Derrell, last seen rooting around his office for the Nomex suit... Regards, Pau-Chen From owner-ipsec Tue Apr 15 15:58:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07216 for ipsec-outgoing; Tue, 15 Apr 1997 15:58:47 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704151642.JAA14702@kebe.eng.sun.com> References: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:02:15 -0400 To: ipsec@tis.com From: Stephen Kent Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I'm somehwat at fault here. In re-writing the AH and ESP specs I re-worded the brief description of SPIs to deemphasize any notion of randomness for secruity purposes, as there was no documentation explaining the motivation for such selection in the previous documents and those documents merely hinted that the SPis should be "arbitrary," if I recall correctly. I presume that the anti-D0S argument put forth here is based on the notion that one can very quickly reject traffic that claims to be AH or ESP is there is no matching SPI, rather than expending any effort for further processing. If so, we need to be explicit about that in our documentation, i.e., provide a brief statement of motivation as well as a requirement specification. I guess that the threat model that motivates this technique assumes that the attacker has no passive wiretap capability, which we also need to mention in the architecture document. Note that requiring pseudo-random SPIs does have potentially adverse performance implications, e.g., simple index SPIs are outlawed and that makes table lookups harder. So, we should be convinced that making this a requirement is worthwhile, e.g., we believe in the threat model I mentioned, before insisting on this characteristic for SPIs. Steve From owner-ipsec Tue Apr 15 16:00:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07237 for ipsec-outgoing; Tue, 15 Apr 1997 16:00:17 -0400 (EDT) Date: Tue, 15 Apr 1997 16:06:04 -0400 Message-Id: <9704152006.AA29509@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: pau@watson.ibm.com Cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: pau@watson.ibm.com's message of Tue, 15 Apr 1997 13:25:16 -0400, <9704151725.AA22888@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 13:25:16 -0400 Dan, the spec does say so. But if an implementation uses a montonically increasing counter to generate SPI's for ESP and AH, it can interop with others. So I think it is worthwhile to put in a safeguard. It sounds like testing for a monotonically increasing counter would be a good thing to put into a conformance test suite; if a implementation dues that, it should be considered broken. Is this important enough that we want to put more explicit words in the spec? (I will note that in general, this is really about how much we trust the intelligence and/or competence of the implementors that come after us. There are certainly those who believe we shouldn't trust their competence at all --- although if that's really true, the situation is probably hopeless.) - Ted From owner-ipsec Tue Apr 15 16:09:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07304 for ipsec-outgoing; Tue, 15 Apr 1997 16:08:59 -0400 (EDT) Message-Id: <199704152013.QAA02665@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: pau@watson.ibm.com, ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: ho's message of Tue, 15 Apr 1997 15:41:03 -0400. <199704151941.PAA06920@earth.hpc.org> Date: Tue, 15 Apr 1997 16:13:49 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. I'll re-state that to clarify my view of the benefit: Random SPI's serve a similar function as cookies: they make it harder to do an off-path active attack against someone not in the communication path between the peers. Given that certain off-path active attacks (e.g., SYN floods) are known to be in the bag of tricks in the cracker community, I think resistance to such threats should be considered fairly important. An ESP/AH implementation which does sequential SPI generation is asking for trouble. It's probably OK to kludge it while you're coming up to speed, but it should take all of a dozen lines of code in an implementation to do random SPI generation. (BTW, I hope the implementations doing sequential assignment are doing collision checks against manually-configured SPI's while they're at it..). - Bill From owner-ipsec Tue Apr 15 16:17:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07369 for ipsec-outgoing; Tue, 15 Apr 1997 16:17:35 -0400 (EDT) Message-Id: <3.0.1.32.19970415160749.0073f58c@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 15 Apr 1997 16:07:49 -0400 To: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, ho@earth.hpc.org From: "David P. Jablon" Subject: Another pothole in ISAKMP/Oakley In-Reply-To: <199704151350.JAA26384@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Another pothole of note in ISAKMP is Diffie-Hellman small-subgroup confinement. Although ISAKMP refers to X9.42, which I believe will have a description of how to avoid the problem, it should also probably be mentioned in some IETF document relevant to DH in ISAKMP. There are just too many published descriptions of DH that fail to mention the problem, so that there's a good chance of trapping an unwary implementor. -- David From owner-ipsec Tue Apr 15 16:21:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07412 for ipsec-outgoing; Tue, 15 Apr 1997 16:21:08 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 16:32:37 -0400 Message-Id: <9704152032.AA23062@secpwr.watson.ibm.com> To: ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: msLW7lllUmNfbpEjjJyA3Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA07409 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 15:55:29 1997 > Date: Tue, 15 Apr 1997 15:41:03 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151941.PAA06920@earth.hpc.org> > To: pau@watson.ibm.com > Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com > In-Reply-To: Yourmessage <9704151927.AA22368@secpwr.watson.ibm.com> > Subject: Re: A pothole in ISAKMP/Oakley > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > Content-Length: 584 > Status: RO > > > You are right. But since Quick Mode Exchange is proteted > > (encrypted and authenticated) by the phase 1 ISAKMP SA, > > clogging attack should not be a big problem. > > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. Maybe we have been. But let's focus on the phase 2 OAKLEY Quick mode in this msg. > > I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. Correct me if I am wrong. But my understanding of the OAKLEY quick mode as defined in section 5.4 of is like this : 1. The cookies in the ISAKMP msg header are the I-cookie and R-cookie of the phase-1 SA which is protecting the quick mode exchange. 2. the SPI's for the would-be ESP and AH SA's are placed in their corresponding PROPOSAL payloads which are inside an SA payload. 3. A keyed-hash (HMAC) defined by the phase-1 SA is computed over the Quick mode payloads and the msg-ID in the ISAKMP msg header. 4. Everything, including the keyed-hash digest but excluding the ISAKMP msg header, is ENCRYPTED through the phase-1 SA. Point 4 is worth noticing because the receiver of a Quick mode msg has to decrypt the msg then authenticate it (by veryfing the keyed hash) before doing anything else. I think the anit-clogging value of the SPI has vanished in this case. Since a relatively expensive decryption has always to be done first and an active attack is defeated by the keyed-hash (and of course also by the fresh nonces in the msgs). Regards, Pau-Chen > > Hilarie > From owner-ipsec Tue Apr 15 16:24:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07446 for ipsec-outgoing; Tue, 15 Apr 1997 16:24:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> References: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:30:19 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, As I mentioned in an earlier message to Norm, the size of the IV depends on the algorithm and mode. The DES specs (in terms of FIPS) call for 4 or 8 bytes IVs, depending on the mode. Some proposals for ESP transforms have implicit IVs (generated from other packet info), while others have also allowed for 4 or 8 byte ecplicit IVs. As for stream ciphers for which an offset is employed for crypto synch, the offset value size will vary depending on the algorithm. But, at least the size of these values is fixed as part of the SA negotiation process and not variable. Steve From owner-ipsec Tue Apr 15 16:36:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07511 for ipsec-outgoing; Tue, 15 Apr 1997 16:35:51 -0400 (EDT) Message-Id: <2.2.32.19970415204817.00bc9520@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, 15 Apr 1997 16:48:17 -0400 To: Bill Sommerfeld From: Naganand Doraswamy Subject: Re: A pothole in ISAKMP/Oakley Cc: ho@earth.hpc.org (Hilarie Orman), pau@watson.ibm.com, ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >(BTW, I hope the implementations doing sequential assignment are doing >collision checks against manually-configured SPI's while they're at >it..). It will be good if implementations in addition to generating random SPI's also check for collision so that if the SPI is already allocated then we generate another random number till we find one that is unused. I do it in my implementation. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Apr 15 16:40:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07552 for ipsec-outgoing; Tue, 15 Apr 1997 16:39:55 -0400 (EDT) Date: Tue, 15 Apr 1997 16:45:22 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Hilarie Orman cc: ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: <199704151941.PAA06920@earth.hpc.org> Message-Id: <97Apr15.164137edt.11659@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 15 Apr 1997, Hilarie Orman wrote: > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. An attacker could only predict the SPI sequence if they could read the traffic stream. If they can do this, then they can see actual SPIs and use these in bogus packets. So why would AH and ESP require pseudorandom SPIs? (The current drafts just say that the SPI is an arbitrary value.) Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 15 16:44:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07611 for ipsec-outgoing; Tue, 15 Apr 1997 16:43:58 -0400 (EDT) Message-Id: <199704152049.NAA10076@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: piper@cisco.com, ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: Your message of "Tue, 15 Apr 1997 15:58:33 EDT." <9704151958.AA22946@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 13:49:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen, > This is a 2-line change to the ISAKMP-OAKLEY doc. > As for the code, the current doc requires the code to take the SPI value > from the PROPOSAL payload header when computing Quick Mode KEYMAT. > The proposed change requires the code to also take the "Protocol-ID" > value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. > I don't think that is a difficult change. The size of the change isn't the issue, it's the merit of the change. Another way of looking at this is that we're changing the document to accomodate incorrect implementations (monotonically increasing a counter to generate a SPI is probably unwise regardless of this pothole). In that light, is this change meritorious? Personally, I'm in favor of this change but I'd like to note that the cement is drying on this document. If we have some consensus that this is really a problem that really needs to be addressed it can be changed, but I'd like to avoid what is becoming an even bigger problem: document creep. Dan. From owner-ipsec Tue Apr 15 16:56:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07671 for ipsec-outgoing; Tue, 15 Apr 1997 16:56:12 -0400 (EDT) Message-Id: <199704152101.OAA10099@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "David P. Jablon" Cc: ipsec@tis.com, carrel@ipsec.org, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Tue, 15 Apr 1997 16:07:49 EDT." <3.0.1.32.19970415160749.0073f58c@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 14:01:10 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk David, Is this really a pothole in ISAKMP/Oakley? > Another pothole of note in ISAKMP is Diffie-Hellman > small-subgroup confinement. > > Although ISAKMP refers to X9.42, which I believe will > have a description of how to avoid the problem, it > should also probably be mentioned in some IETF document > relevant to DH in ISAKMP. There are just too many published > descriptions of DH that fail to mention the problem, so that > there's a good chance of trapping an unwary implementor. Are you suggesting a reference to X9.42 in the ISAKMP/Oakley document? Also, for the benefit of those of us who are not cryptographers, can you elaborate on the problem of "small sub-group confinement" and how ISAKMP/Oakley fails to address it? thanks, Dan. From owner-ipsec Tue Apr 15 17:18:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07843 for ipsec-outgoing; Tue, 15 Apr 1997 17:18:32 -0400 (EDT) Date: Tue, 15 Apr 1997 17:21:01 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704152121.RAA10084@earth.hpc.org> To: dharkins@cisco.com Cc: dpj@world.std.com, carrel@ipsec.org, ipsec@tis.com In-reply-to: Yourmessage <199704152101.OAA10099@dharkins-ss20> Subject: Re: Another pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk wrt to the subgroup question ... If one is using new group mode, one might be advised to acquire some expertise in determining the size of largest subgroup. One cannot simply pick a number at random and use it as a modulus. Photuris had good practical advice on this score, and Oakley had a brief discussion of the problem, some words about Sophie-Germaine primes, Schnorr subgroups, etc. But this is a piece of cake. Solving the problem for elliptic curve groups is much harder. That's why there are no new EC groups (it's not that they eat their young). Hilarie From owner-ipsec Tue Apr 15 17:18:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07842 for ipsec-outgoing; Tue, 15 Apr 1997 17:18:31 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 17:30:13 -0400 Message-Id: <9704152130.AA23206@secpwr.watson.ibm.com> To: pau@watson.ibm.com, dharkins@cisco.com Subject: Re: A pothole in ISAKMP/Oakley Cc: piper@cisco.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: enRKANXiuuj5weVcwbQmbA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA07834 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From dharkins@cisco.com Tue Apr 15 16:56:27 1997 > Message-Id: <199704152049.NAA10076@dharkins-ss20> > X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol > To: pau@watson.ibm.com > Cc: piper@cisco.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > In-Reply-To: Your message of "Tue, 15 Apr 1997 15:58:33 EDT." <9704151958.AA22946@secpwr.watson.ibm.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Date: Tue, 15 Apr 1997 13:49:47 -0700 > From: Daniel Harkins > Content-Length: 1036 > Status: RO > > Pau-Chen, > > > This is a 2-line change to the ISAKMP-OAKLEY doc. > > As for the code, the current doc requires the code to take the SPI value > > from the PROPOSAL payload header when computing Quick Mode KEYMAT. > > The proposed change requires the code to also take the "Protocol-ID" > > value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. > > I don't think that is a difficult change. > > The size of the change isn't the issue, it's the merit of the change. > Another way of looking at this is that we're changing the document to > accomodate incorrect implementations (monotonically increasing a counter to > generate a SPI is probably unwise regardless of this pothole). In that light, > is this change meritorious? > > Personally, I'm in favor of this change but I'd like to note that the > cement is drying on this document. If we have some consensus that this is > really a problem that really needs to be addressed it can be changed, but > I'd like to avoid what is becoming an even bigger problem: document creep. > > Dan. > Dan, I agree that document creeping should be avoided, especially now. There has been discussion on "SPI usage". It seems that there are opinions on both sides. However, if OAKLEY adopts the change suggested in Ran's note, OAKLEY is cryptographiocally more sound and can stay out of the discusion on "SPI usage", whichever end the discussion will lead to. Regards, Pau-Chen From owner-ipsec Tue Apr 15 17:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08003 for ipsec-outgoing; Tue, 15 Apr 1997 17:41:12 -0400 (EDT) Date: Tue, 15 Apr 97 14:45:00 PDT From: John H Wilson Message-ID: To: kent@bbn.com, rodney@sabletech.com cc: ipsec@tis.com Subject: Re[2]: ESP with stream ciphers Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: On 4/15, Stephen Kent wrote: > As for stream ciphers for which an offset is employed for crypto >synch, the offset value size will vary depending on the algorithm. But, at >least the size of these values is fixed as part of the SA negotiation >process and not variable. Why doesn't the offset value depend on the (potential) length of the stream, rather than the encryption algorithm involved? John Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Cc: ipsec@tis.com Subject: Re: ESP with stream ciphers From: Stephen Kent To: Rodney Thayer Date: Tue, 15 Apr 1997 16:30:19 -0400 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 References: <97Apr14.161245edt.11650@janus.border.com> In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Message-Id: X-Sender: kent@po1.bbn.com Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA074 46 for ipsec-outgoing; Tue, 15 Apr 1997 16:24:09 -0400 (EDT) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.5/8.7.3) with ESMTP id OAA04004 for ; Tue, 15 Apr 1997 14:38:45 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id OAA02958 for ; Tue, 15 Apr 1997 14:36:26 -0700 (PDT) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Tue Apr 15 18:26:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA08247 for ipsec-outgoing; Tue, 15 Apr 1997 18:26:06 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 18:30:42 -0400 To: John H Wilson From: Stephen Kent Subject: Re[2]: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, In general, I'd view the recommended safe stream length as an intrinsic part of the "algorithm" definition. In that context, the algorithm ID suffices for this purpose. In the context of ISASKMP SA negotiation, we can certainly ensure that the algorithm IDs that are negotiated suffice to represent this info. Steve From owner-ipsec Tue Apr 15 18:27:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA08272 for ipsec-outgoing; Tue, 15 Apr 1997 18:27:07 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Apr15.164137edt.11659@janus.border.com> References: <199704151941.PAA06920@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 18:27:39 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, If one selects SPIs to be small integers so that they represent indices into local tables, then they may be very predictable and thus an attacker without passive wiretapping ability may be able to formulate credible-loooking SPIs for existing SAs. Remember, the SPI plus destination address completely defines the SA, so there is no source address check that would be pereformed at this stage of packet processing. Steve From owner-ipsec Wed Apr 16 09:08:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA12933 for ipsec-outgoing; Wed, 16 Apr 1997 09:04:24 -0400 (EDT) Date: Wed, 16 Apr 1997 09:09:21 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704161309.JAA20179@argon.ncsc.mil> To: ipsec@tis.com Subject: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > > If one selects SPIs to be small integers so that they represent > indices into local tables, then they may be very predictable and thus an > attacker without passive wiretapping ability may be able to formulate > credible-loooking SPIs for existing SAs. Remember, the SPI plus > destination address completely defines the SA, so there is no source > address check that would be pereformed at this stage of packet processing. If one believes that inject-only attackers are a threat, then it is possible to get both unpredictable (to the attacker) SPIs and efficient SPI lookup at the destination by picking a random offset once at boot time and adding it to small integer indices to form the SPIs. Since SPI selection does not affect interoperability, since DOS in general is a hard problem, and since entropy testing of SPI sequences for conformance testing purposes is impossible, it seems unwise to write a MUST requirement on SPI generation. I'd write a note on the rationale for unpredictable SPIs in the Security Considerations section and leave it at that. From owner-ipsec Wed Apr 16 11:46:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14043 for ipsec-outgoing; Wed, 16 Apr 1997 11:45:38 -0400 (EDT) Date: Wed, 16 Apr 1997 18:42:05 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161542.SAA21433@ee.technion.ac.il> To: ipsec@tis.com Subject: Re: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) Sender: owner-ipsec@ex.tis.com Precedence: bulk Although I have trouble following this list these days I want to addd my voice to those that recommend decoupling the issue of SPI randomness/predictability from the key derivation question. As in many other cases I am in favor of making the crypto right and robust independently of changing system requirements. The structure or lack of structure of an SPI is mainly a system requirement not a cryptographic one. Even if decisions are made on this issue on the basis of defending against denial of service attacks one cannot compare the importance of this functionality relative to having a robust key derivation mechanism in place. The suggestion by Pau-Chen and Ran solves the problem independently of the SPI decisions. Hugo From owner-ipsec Wed Apr 16 11:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14173 for ipsec-outgoing; Wed, 16 Apr 1997 11:55:16 -0400 (EDT) Message-Id: <3.0.1.16.19970416115729.1d8f0f5c@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Wed, 16 Apr 1997 11:57:29 -0400 To: Daniel Harkins From: "David P. Jablon" Subject: Re: Another pothole in ISAKMP/Oakley Cc: :@world.std.com In-Reply-To: <199704152101.OAA10099@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Regarding: > Is this really a pothole in ISAKMP/Oakley? >> Another pothole of note in ISAKMP is Diffie-Hellman >> small-subgroup confinement. Well, it's a problem in Diffie-Hellman itself, on which ISAKMP/Oakley depends. Apparently not enough people know about it. > Are you suggesting a reference to X9.42 in the ISAKMP/Oakley > document? Also, for the benefit of those of us who are not > cryptographers, can you elaborate on the problem of "small > sub-group confinement" and how ISAKMP/Oakley fails to address it? Yes. See my reply to Hilarie's message for more elaboration. -- David From owner-ipsec Wed Apr 16 11:55:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14174 for ipsec-outgoing; Wed, 16 Apr 1997 11:55:16 -0400 (EDT) Message-Id: <3.0.1.16.19970416115934.1d8f2d58@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Wed, 16 Apr 1997 11:59:34 -0400 To: ho@earth.hpc.org (Hilarie Orman) From: "David P. Jablon" Subject: Re: Another pothole in ISAKMP/Oakley Cc: ipsec@tis.com, dharkins@cisco.com, carrel@ipsec.org In-Reply-To: <199704152121.RAA10084@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, Regarding your comments on subgroup confinement ... > If one is using new group mode, one might be advised to acquire some > expertise in determining the size of largest subgroup. One cannot > simply pick a number at random and use it as a modulus. Photuris had > good practical advice on this score, and Oakley had a brief discussion > of the problem, some words about Sophie-Germaine primes, Schnorr > subgroups, etc. But this is a piece of cake. Solving the problem for > elliptic curve groups is much harder. That's why there are no new > EC groups (it's not that they eat their young). To clarify my concern, I am not referring to the problems with poorly-chosen DH parameters, but rather to the subgroup attack on Diffie-Hellman assuming the use of well-chosen parameters. The attack is possible in any ordinary DH groups as well as typical choices for EC groups. Also, for both ordinary and EC groups, the attack is easily prevented. For any DH group where the order of the full group (m) is not prime, DH computations are restricted to a large subgroup of prime order (q), where q divides m. This leaves a co-factor t = m/q. Small subgroups always exist in Z_p*. For Sophie-Germain primes, often called "safe-primes", where p = 2q+1, the cofactor is 2. Suitable elliptic curve groups also typically have a small co-factor t, where t > 1. A problem occurs when a man-in-the-middle forces each DH exponential into a small subgroup, by raising each number to the power of q. Both legitimate parties will derive the same key K, but it will be confined to one of "t" possible values, making it easy for the middleman to guess it. Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q K = g^(Ra Rb q q) Two papers published last year describe these attacks, this one in a paper by Wiener and vanOorschot, and a related attack relevant to authenticated- Diffie-Hellman in a paper of mine. The solution is to have each party make sure that the derived key K is in the proper subgroup, or at least not confined to a small subgroup. One way to prevent the problem is to use K' = K^t, which "forces" K' into the group of order q, and then test to make sure that K' is not the identity element. Although discussion of this will be in the forthcoming P1363 and X9.62 standards, given the current limited awareness of the problem, I think this or some other solution or specific reference to a solution should be included in all standards that specify a DH exchange. -- David From owner-ipsec Wed Apr 16 12:11:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14268 for ipsec-outgoing; Wed, 16 Apr 1997 12:11:22 -0400 (EDT) Date: Wed, 16 Apr 1997 12:14:07 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704161614.MAA13550@earth.hpc.org> To: dpj@world.std.com Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com In-reply-to: Yourmessage <3.0.1.16.19970416115934.1d8f2d58@world.std.com> Subject: Re: Another pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk OK, but for a Sophie Germaine prime, (g^a)^q = +- 1, so a check for this is sufficient, as is authentication of the offered exponentials. I can see adding the +-1 check to the spec, just for belt and suspenders. The EC group recommended in the original Oakley has a subgroup of order 12; I suppose that before using it one should be warned to implement the small group check, again as belt and suspenders. Hilarie From owner-ipsec Wed Apr 16 12:57:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14678 for ipsec-outgoing; Wed, 16 Apr 1997 12:56:27 -0400 (EDT) Message-Id: <199704161701.KAA11219@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "David P. Jablon" Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com, carrel@ipsec.org Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Wed, 16 Apr 1997 11:59:34 EDT." <3.0.1.16.19970416115934.1d8f2d58@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:01:45 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > A problem occurs when a man-in-the-middle forces each DH exponential into > a small subgroup, by raising each number to the power of q. Both > legitimate parties > will derive the same key K, but it will be confined to one of "t" possible > values, > making it easy for the middleman to guess it. But since each exponential is authenticated I don't see how this is a problem. A middleman changing *anything*-- exponentials, initial offer of EHA-- will result in a failed authentication (page 9 of draft). This does seem to be a particularly devious sort of attack but I don't think ISAKMP/Oakley is susceptible. Dan. From owner-ipsec Wed Apr 16 13:12:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14809 for ipsec-outgoing; Wed, 16 Apr 1997 13:12:03 -0400 (EDT) Date: Wed, 16 Apr 1997 13:17:15 -0400 From: Ran Canetti Message-Id: <9704161717.AA21561@ornavella.watson.ibm.com> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "David P. Jablon" > > A problem occurs when a man-in-the-middle forces each DH exponential into > a small subgroup, by raising each number to the power of q. Both > legitimate parties > will derive the same key K, but it will be confined to one of "t" possible > values, > making it easy for the middleman to guess it. > > Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q > Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q > K = g^(Ra Rb q q) > > Two papers published last year describe these attacks, this one in a paper by > Wiener and vanOorschot, and a related attack relevant to authenticated- > Diffie-Hellman in a paper of mine. The solution is to have each party make > sure > that the derived key K is in the proper subgroup, or at least not confined > to a > small subgroup. > Let me point out that such an attack is possible only against the signature mode of ISAKMP/Oakley. In the encryption mode this doesn't work since the DH challenges are sent encrypted by the public key encryption algorithm (eg, RSA). This is another example where the encryption mode is more secure than the signature mode... Ran Canetti From owner-ipsec Wed Apr 16 13:12:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14834 for ipsec-outgoing; Wed, 16 Apr 1997 13:12:34 -0400 (EDT) Date: Wed, 16 Apr 1997 19:39:16 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161639.TAA22501@ee.technion.ac.il> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >A problem occurs when a man-in-the-middle forces each DH exponential into >a small subgroup, by raising each number to the power of q. Both >legitimate parties >will derive the same key K, but it will be confined to one of "t" possible >values, >making it easy for the middleman to guess it. > >Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q >Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q >K = g^(Ra Rb q q) > David, If I understand correctly your point then it is NOT a problem in isakmp-oakley. There HASH_I and HASH_R are computed over the values of g^xr and g^xr. Thus, a man in the middle cannot change them without detection. (This attack holded against earlier versions of the draft but not after the later corrections) Or am I missing something in your argument? Hugo From owner-ipsec Wed Apr 16 13:16:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14894 for ipsec-outgoing; Wed, 16 Apr 1997 13:16:42 -0400 (EDT) Message-Id: <199704161722.KAA11241@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Canetti Cc: dpj@world.std.com, ho@earth.hpc.org, carrel@ipsec.org, ipsec@tis.com Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Wed, 16 Apr 1997 13:17:15 EDT." <9704161717.AA21561@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:22:07 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Cannetti wrote: > > From: "David P. Jablon" > > > > A problem occurs when a man-in-the-middle forces each DH exponential into > > a small subgroup, by raising each number to the power of q. Both > > legitimate parties > > will derive the same key K, but it will be confined to one of "t" possible > > values, > > making it easy for the middleman to guess it. > > > > Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q > > Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q > > K = g^(Ra Rb q q) > > Let me point out that such an attack is possible only against the signature > mode of ISAKMP/Oakley. In the encryption mode this doesn't work since > the DH challenges are sent encrypted by the public key encryption algorithm > (eg, RSA). This is another example where the encryption mode is more > secure than the signature mode... I'll agree that encryption mode is more secure but how is this attack made against signature mode (or pre-shared key for that matter)? HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDii) This is signed in signature mode (and generated directly in pre-shared key mode). Since both exponentials are there how can any man-in-the-middle change them without each party being aware of that? Dan. From owner-ipsec Wed Apr 16 14:33:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15395 for ipsec-outgoing; Wed, 16 Apr 1997 14:32:31 -0400 (EDT) Date: Wed, 16 Apr 1997 20:39:11 +0200 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199704161839.AA09834@orfeo.gc.ssr.upm.es> To: tytso@MIT.EDU Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 22:41:40 1997 > Date: Tue, 15 Apr 1997 16:06:04 -0400 > From: "Theodore Y. Ts'o" > To: pau@watson.ibm.com > Cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > Address: 1 Amherst St., Cambridge, MA 02139 > Phone: (617) 253-8091 > Sender: owner-ipsec@ex.tis.com > Content-Length: 863 > > From: pau@watson.ibm.com > Date: Tue, 15 Apr 1997 13:25:16 -0400 > > Dan, the spec does say so. But if an implementation uses a montonically > increasing counter to generate SPI's for ESP and AH, it can interop with > others. So I think it is worthwhile to put in a safeguard. > > It sounds like testing for a monotonically increasing counter would be a > good thing to put into a conformance test suite; if a implementation > dues that, it should be considered broken. Non-monotonically doesn't implies (strong)pseudorandomness. Must we check for randomness too? > > Is this important enough that we want to put more explicit words in the > spec? (I will note that in general, this is really about how much we > trust the intelligence and/or competence of the implementors that come > after us. There are certainly those who believe we shouldn't trust > their competence at all --- although if that's really true, the > situation is probably hopeless.) > > - Ted > Regards, Luis Saiz --------------------------------------------------------------------- Protocol cryptanalysis is essentially formalized paranoia. G. Simmons. --------------------------------------------------------------------- From owner-ipsec Wed Apr 16 15:07:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15647 for ipsec-outgoing; Wed, 16 Apr 1997 15:06:49 -0400 (EDT) Date: Wed, 16 Apr 1997 20:42:35 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161742.UAA24164@ee.technion.ac.il> To: canetti@watson.ibm.com, dharkins@cisco.com Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dpj@world.std.com, ho@earth.hpc.org, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >I'll agree that encryption mode is more secure but how is this attack made >against signature mode (or pre-shared key for that matter)? > > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDii) > >This is signed in signature mode (and generated directly in pre-shared key >mode). Since both exponentials are there how can any man-in-the-middle change >them without each party being aware of that? > > Dan. > Dan is correct. The inclusion of g^xr and g^xi in HASH solves the problem in all the modes. This is no particular advantage of the encryption mode. It is an advantage of having the same HASH in all modes and all include the exponents. Befoere doing that, draft-01 was susceptible to this problem. Hugo From owner-ipsec Wed Apr 16 15:19:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15791 for ipsec-outgoing; Wed, 16 Apr 1997 15:18:56 -0400 (EDT) Date: Wed, 16 Apr 1997 15:24:43 -0400 Message-Id: <9704161924.AA00059@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Cc: ipsec@tis.com In-Reply-To: "LUIS SAIZ GIMENO"'s message of Wed, 16 Apr 1997 20:39:11 +0200, <199704161839.AA09834@orfeo.gc.ssr.upm.es> Subject: Re: A pothole in ISAKMP/Oakley Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 16 Apr 1997 20:39:11 +0200 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Non-monotonically doesn't implies (strong)pseudorandomness. Must we check for randomness too? No, but it's an easy check to prevent really bad implementations. Yes, it's easy enough to pass that check without doing it with good random number generator... but see my question about what level of stupidity/hostility are we expecting from our implementors? - Ted From owner-ipsec Wed Apr 16 18:25:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16893 for ipsec-outgoing; Wed, 16 Apr 1997 18:23:50 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:03:28 -0500 To: Rob Glenn From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com, rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, I included HMAC with MD5 and SHA-1 in the I-D as a means of expressing the default algorithm support requirements. Additional algrotihms can be specified by separate RFCs; the difference is that these RFCs need not include the rest of the AH (or ESP) spec. Instead, they will just be algorithm defintions, perhaps with a few references to the relevent RFCs. The additional algorithms will be registered with the IANA. We can improve the I-Ds by emphasizing this means of adding other algorithms. However, I don't think the current I-Ds are unduly algorithm dependent as a result of the approach adopted here, but there is a clear intent to establish default, required algorithms. I'm not sure that the indirection through another RFC for specifying requirement algorithms is an improvement. If we change the defaults, another RFC gets produced and the indirection doesn't seem to buy us that much. As for anti-replay and manual keys, I think other messages have addressed that topic. Mostly, we need to refine the terminology, but I think the intent is correct. If one uses a manually positioned key for AH, then AR seems incompatible in that reliable state retention would be required across crashes and some means would be needed to prevent cycling, despite the lack of an automated ability to load new keys. Since we are trying to minimize creating situations where procedural errors will result in insecurities, I think it is appropropriate to rule out the use of AR with static, manual authentication keys. As for the optional nature of the AR counter, I'm quite happy to make it permanent field if that's what the WG wants, but as the I-D points out, this will result in an extra 4 bytes of overhead for IPv4. Given that some folks have produced ESP drafts that employ implicit IVs specifically to reduce per-packet transmission overhead in the 4-8 byte range, it seems a bit inconsistent to mandate this 4 byte field. I have also heard that there was some concern expressed over the issue of making anti-replay optional, because of the overhead of negotiating this security service, especially in terms of window size negotiation. I've had some private communication with folks immediately preceeding the meeting, and one suggestion that arose was making a window size of 32 the default, if AR is negotiated. One might eliminate the need to negotiate a window size at all if this default were considered adequate, and the receiver were free to implement a larger window as a local option. This would simplify the negotiation process, and allow it to be expressed as just a compound "transform" along with the algorithm negotiation. That would require no additional ISAKMP messages and thus should not raise objections re added negotiation complexity. Steve From owner-ipsec Wed Apr 16 19:11:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17160 for ipsec-outgoing; Wed, 16 Apr 1997 19:11:17 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 16 Apr 1997 17:16:17 -0600 From: John Kennedy To: ho@earth.hpc.org, dpj@world.std.com Cc: dharkins@cisco.com, carrel@ipsec.org, ipsec@tis.com Subject: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk All, David is right that this problem should be addressed in a DH standard. In X9.42, the following checks are mandatory for an implementation: 1) Received public numbers are checked to insure that they are not equal to 1 or -1. (note -1 = (p-1) mod p) 2) The shared-secret number Z=g(xy) mod p is checked to make sure that (Z ^j)) mod p <> 1, where j=(p-1)/q. I.e. j is the "co-factor" used to multiply q: p = jq+1. Typically, j is fairly small so this is a quick operation to detect the small sub-group attack. 3) Finally, the generation of the prime modulus p may be optionally checked because X9.42 specifies a repeatable method for prime generation similar to that specified in the DSS standard. Also, the order of the generator g may be check to make sure the order is q. Since I haven't gotten around to the new and improved OAKLEY draft, I don't know how much of this is there or not. During X9.42 development discussion it was not necessarily a man-in-the-middle that was feared with regards to the small sub-group attack. Conceivably, one of the communicating parties could send a "bad" public number on purpose. Is this a realistic scenario? Whatever your opinion it makes since to do the relatively inexpensive checks outlined above. Finally, with regards to elliptic curve DH I think it would be best to refer to the work being done by IEEE P1363. You might want to consider deferring to P1363 for the GF(P) DH stuff too. ANSI X9.42 is much more application specific than the work in P1363. (P1363 can be profiled into something X9.42 compliant however.) Also, the P1363 drafts are all freely-avaliable on-line and not as subject to US-centric interests. See http://stdsbbs.ieee.org/groups/1363/ . IMHO, the P1363 work is the most comprehensive and up-to-date standards work on public-key technology available right now and deserves to be a primary reference for all IETF standards on crypto. With regards to elliptic curve PK it is unparalled. -John Kennedy >>> "David P. Jablon" 04/16/97 09:59AM >>> Hilarie, Regarding your comments on subgroup confinement ... > If one is using new group mode, one might be advised to acquire some > expertise in determining the size of largest subgroup. One cannot > simply pick a number at random and use it as a modulus. Photuris had > good practical advice on this score, and Oakley had a brief discussion > of the problem, some words about Sophie-Germaine primes, Schnorr > subgroups, etc. But this is a piece of cake. Solving the problem for > elliptic curve groups is much harder. That's why there are no new > EC groups (it's not that they eat their young). To clarify my concern, I am not referring to the problems with poorly-chosen DH parameters, but rather to the subgroup attack on Diffie-Hellman assuming the use of well-chosen parameters. The attack is possible in any ordinary DH groups as well as typical choices for EC groups. Also, for both ordinary and EC groups, the attack is easily prevented. For any DH group where the order of the full group (m) is not prime, DH computations are restricted to a large subgroup of prime order (q), where q divides m. This leaves a co-factor t = m/q. Small subgroups always exist in Z_p*. For Sophie-Germain primes, often called "safe-primes", where p = 2q+1, the cofactor is 2. Suitable elliptic curve groups also typically have a small co-factor t, where t > 1. A problem occurs when a man-in-the-middle forces each DH exponential into a small subgroup, by raising each number to the power of q. Both legitimate parties will derive the same key K, but it will be confined to one of "t" possible values, making it easy for the middleman to guess it. Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q K = g^(Ra Rb q q) Two papers published last year describe these attacks, this one in a paper by Wiener and vanOorschot, and a related attack relevant to authenticated- Diffie-Hellman in a paper of mine. The solution is to have each party make sure that the derived key K is in the proper subgroup, or at least not confined to a small subgroup. One way to prevent the problem is to use K' = K^t, which "forces" K' into the group of order q, and then test to make sure that K' is not the identity element. Although discussion of this will be in the forthcoming P1363 and X9.62 standards, given the current limited awareness of the problem, I think this or some other solution or specific reference to a solution should be included in all standards that specify a DH exchange. -- David ! ! ! From owner-ipsec Wed Apr 16 19:54:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17357 for ipsec-outgoing; Wed, 16 Apr 1997 19:53:00 -0400 (EDT) Date: Wed, 16 Apr 1997 19:55:51 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704162355.TAA27524@earth.hpc.org> To: JKENNEDY@novell.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704162320.QAA22212@baskerville.CS.Arizona.EDU> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk The 1,-1 check should be added to the spec, but I think the rest of the good work of IEEE and X9.42 is beyond the intended scope of ISAKMP/OAKLEY; there's no intent to reference all possible attacks. I recommend adding a comment that only strong/Sophie Germaine/j=2 primes be used for the modulus in the New Group exchange, but the consenting parties must either trust each other's math or be able to independently validate the Sophie Germaineness of the modulus (off-line beforehand or in-line on a fast machine). With regard to having one party force a bad key, it is still possible for the second party to choose and exponential that forces many of the key bits to a known value, thus opening up some room for a passive attacker. There's no trick to this, it simply requires a lot of fast computation. Hilarie From owner-ipsec Wed Apr 16 21:41:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18025 for ipsec-outgoing; Wed, 16 Apr 1997 21:39:29 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 16 Apr 1997 19:44:20 -0600 From: John Kennedy To: ho@earth.hpc.org Cc: ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk What you suggest is probably a good minimum check. There is also some wisdom to allowing implementors to compete based what types of additional checks they choose to perform and the performance they deliver. Regarding ANSI and IEEE, my main point was to get implementors to read these documents to educate themselves, not to necessarily have IETF tie itself to this related work. On the Sophie-Germaine/j=2 thing: Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. -John >>> Hilarie Orman 04/16/97 05:55PM >>> The 1,-1 check should be added to the spec, but I think the rest of the good work of IEEE and X9.42 is beyond the intended scope of ISAKMP/OAKLEY; there's no intent to reference all possible attacks. I recommend adding a comment that only strong/Sophie Germaine/j=2 primes be used for the modulus in the New Group exchange, but the consenting parties must either trust each other's math or be able to independently validate the Sophie Germaineness of the modulus (off-line beforehand or in-line on a fast machine). With regard to having one party force a bad key, it is still possible for the second party to choose and exponential that forces many of the key bits to a known value, thus opening up some room for a passive attacker. There's no trick to this, it simply requires a lot of fast computation. Hilarie ! From owner-ipsec Wed Apr 16 21:47:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18071 for ipsec-outgoing; Wed, 16 Apr 1997 21:47:02 -0400 (EDT) Message-ID: <33558269.41C6@cs.umass.edu> Date: Wed, 16 Apr 1997 21:52:41 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: Small subgroups and ISAKMP/Oakley References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Kennedy writes: > During X9.42 development discussion it was not necessarily a > man-in-the-middle that was feared with regards to the small sub-group > attack. Conceivably, one of the communicating parties could send a > "bad" public number on purpose. Is this a realistic scenario? One of the legitimate parties might be a broken implementation that doesn't correctly check whether it has computed a public exponential that lies in the small subgroup. -Lewis From owner-ipsec Thu Apr 17 07:59:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21287 for ipsec-outgoing; Thu, 17 Apr 1997 07:57:21 -0400 (EDT) Message-Id: <199704171157.HAA21287@portal.ex.tis.com> Date: Wed, 16 Apr 1997 18:40:43 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: palamber@us.oracle.com CC: ipsec@tis.com, isakmp-oakley@cisco.com Subject: notes from developer's portion of IETF meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, here are the notes that I took at the developers portion of the IPSEC meetings. Please include these in the official minutes. Thanks Dave Carrel carrel@ipsec.org ------------------------------------------------------------- anti-replay decision is that it is not optional! The bits are always in the header It MUST be used by sender. Always starts at 1. key management will NOT negotiate whether it's used. integrity decicion is that it is optional but if not used in ESP, it must be used in AH. Words to this effect must be added to arch docs. optional encryption not optional in ESP A tunnel mode must be added to the specs for AH encrypt/auth order encrypt first, auth next but IV MUST NOT be constant and MUST be included in every packet IV size is transform dependant and must be specified in the transform docs signature format Dan will send to list, with comments from Eric Rescolla IBM- rsa encryption format leave current format as is to avoid document creep Ran and Hugo will write a draft of their exchange slice and dice remove current key derivation text from Hughes draft It is based on who is initiator and responder (*** action item for Paul Lambert ***) All transforms MUST specify a number of keying bits required and how to generate keys, IVs, etc from that (# keying bits requested equals the # bits of entropy) transform must specify what to do in case of weak key if alg has a small number of weak keys then the recommendation is to request a new SA Name space to IANA need algorithm ids forward issue to list Audit Decision is that this will be documented as "SHOULD implement" MIB take issue to list ---------------------- The following issues were discussed and agreed upon in the Wednesday mtg. ISAKMP ISAKMP should be bound to port 500 (i.e. send and receive on port 500) No need to negotiate replay window size. replay window size is 32. Increase it to a higher value later on if necesary. Situation and DOI must be included in calculating hash for the quick mode for public-key encryption, SKEYID = prf(Ni | Nr, g^xy) (it was hash(Ni | Nr). HASH(2) in Quick Mode includes the initiator's nonce. For ease of processing stick it after the message-id, i.e. HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | IDur ] ) ^^^^ From owner-ipsec Thu Apr 17 09:19:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21691 for ipsec-outgoing; Thu, 17 Apr 1997 09:12:45 -0400 (EDT) Date: Thu, 17 Apr 1997 09:17:30 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704171317.JAA21004@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > > As for the optional nature of the AR counter, I'm quite happy to > make it permanent field if that's what the WG wants, but as the I-D points > out, this will result in an extra 4 bytes of overhead for IPv4. Given that > some folks have produced ESP drafts that employ implicit IVs specifically > to reduce per-packet transmission overhead in the 4-8 byte range, it seems > a bit inconsistent to mandate this 4 byte field. > > I have also heard that there was some concern expressed over the > issue of making anti-replay optional, because of the overhead of > negotiating this security service, especially in terms of window size > negotiation. I've had some private communication with folks immediately > preceeding the meeting, and one suggestion that arose was making a window > size of 32 the default, if AR is negotiated. One might eliminate the need > to negotiate a window size at all if this default were considered adequate, > and the receiver were free to implement a larger window as a local option. > This would simplify the negotiation process, and allow it to be expressed > as just a compound "transform" along with the algorithm negotiation. That > would require no additional ISAKMP messages and thus should not raise > objections re added negotiation complexity. Perhaps I am missing something important, but I've never understood the justification for negotiating replay window sizes. Replay window size is entirely a property of the receiver, no? Does the transmitter do anything different with a window size of 32 than it would with a window size of, say, 128? If there is no difference in the bits on the wire, why do window size negotiation at all? Your point about replay yes/no negotiation is well taken - it seems inconsistent to mandate 4 bytes of AR overhead while negotiating IVs to save 4-8 bytes. Nonetheless, I think Cheryl's suggestion towards the end of the first IPSEC session has great merit: never negotiate AR, always transmit the AR counter, then the receiver can unilaterally decide whether or not to do AR, and if so, what window size to use. That is the ultimate in simplicity, and it gets my vote^H^H^H^H straw poll ballot. From owner-ipsec Thu Apr 17 09:40:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21837 for ipsec-outgoing; Thu, 17 Apr 1997 09:40:28 -0400 (EDT) Date: Thu, 17 Apr 1997 09:42:08 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171342.JAA22336@earth.hpc.org> To: JKENNEDY@novell.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704170149.SAA01801@baskerville.CS.Arizona.EDU> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > On the Sophie-Germaine/j=2 thing: > > Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. One reason that it is bad is that it may force implementors to become number theorists. While in the greater scheme of things, this would be a positive development, in the small it is merely quixotic. Is there some reason that j=2 is an unreasonable restriction? The only reason I can see for non-Sophie-Germaineness* is that it might be possible for one party to propose a new group of a particular type and for the recipient to verify its subgroup structure quickly (a few minutes). Hilarie Why not simply Germaine primes? No one says Emma-Noetherian rings. From owner-ipsec Thu Apr 17 09:50:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21901 for ipsec-outgoing; Thu, 17 Apr 1997 09:50:30 -0400 (EDT) Date: Thu, 17 Apr 1997 09:53:12 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171353.JAA22585@earth.hpc.org> To: carrel@redbacknetworks.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704171209.FAA21072@baskerville.CS.Arizona.EDU> Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Wouldn't it be easiest to have the transforms present a callback routine for key generation? The routine would take a variable precision integer as input (length >= requested entropy) and produce a list of bitstrings as output. > slice and dice ... > All transforms MUST specify a number of keying bits > required and how to generate keys, IVs, etc from that > (# keying bits requested equals the # bits of entropy) Hilarie From owner-ipsec Thu Apr 17 10:27:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22171 for ipsec-outgoing; Thu, 17 Apr 1997 10:26:48 -0400 (EDT) Message-Id: <199704171428.KAA11109@relay.hq.tis.com> Date: Thu, 17 Apr 97 10:32:54 EDT From: Charles Lynn To: David Carrel cc: palamber@us.oracle.com, ipsec@tis.com, CLynn@bbn.com Subject: Tunnel mode AH (Was: notes from developer's portion of IETF meeting) Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > optional encryption > not optional in ESP > A tunnel mode must be added to the specs for AH Did the working group decide on a mechanism, e.g., a bit in the RESERVED field, to indicate a "tunnel mode" in which none of the headers preceding the AH are to be covered by the integrity mechanism? Such a mode is needed both for efficiency (hop-by-hop protection of every packet sent between two systems) and for extensibility (as new extension header versions, etc. are defined). This was provided by the "ESP with integrity but not confidentiality" combination. Charlie From owner-ipsec Thu Apr 17 10:33:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22232 for ipsec-outgoing; Thu, 17 Apr 1997 10:33:21 -0400 (EDT) Message-Id: <3.0.1.16.19970417103637.22bf37a0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Thu, 17 Apr 1997 10:36:37 -0400 To: ho@earth.hpc.org (Hilarie Orman) From: "David P. Jablon" Subject: Re: Small subgroups and ISAKMP/Oakley Cc: John Kennedy , Lewis McCarthy , ipsec@tis.com In-Reply-To: <199704162355.TAA27524@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, In light of Dan Harkin's comments about the HASH'ed authenticated exponentials preventing middleman confinement attack in the latest draft of ISAKMP/Oakley, I presume we're now talking about DH in general. In regards to John's and Lewis' comments about end-party confinement, I think the significance of this is largely for other uses of DH. With this in mind, ... At 07:55 PM 4/16/97 -0400, you wrote: > With regard to having one party force a bad key, it is still possible for > the second party to choose and exponential that forces many of the key > bits to a known value, thus opening up some room for a passive attacker. > There's no trick to this, it simply requires a lot of fast computation. By "still possible" do you mean even if the first party checks for confinement? I think the problem of known key bits is only there if the chosen exponential is of small order. If the "bad" exponential is a generator of a large-order group, then the good party's large random exponent should prevent any predictable bits. There was some discussion related to this at the last P1363 meeting. Specifically, does one need to insure that the result is in the correct large subgroup, or is it enough to prevent it from being in a small subgroup? And then if so, how small is small? How to properly deal with prime moduli with large co-factors was left as an open issue. Raising the result to the co-factor works, but may not be the most efficient solution. -- David ------------------------------------ David P. Jablon Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Thu Apr 17 10:51:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22376 for ipsec-outgoing; Thu, 17 Apr 1997 10:51:35 -0400 (EDT) Date: Thu, 17 Apr 1997 10:54:14 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171454.KAA24458@earth.hpc.org> To: dpj@world.std.com Cc: ipsec@tis.com, lmccarth@cs.umass.edu, JKENNEDY@novell.com In-reply-to: Yourmessage <3.0.1.16.19970417103637.22bf37a0@world.std.com> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > > With regard to having one party force a bad key, it is still possible for > > the second party to choose and exponential that forces many of the key > > bits to a known value, thus opening up some room for a passive attacker. > > There's no trick to this, it simply requires a lot of fast computation. > By "still possible" do you mean even if the first party checks for > confinement? Yes. There's no number theory involved, just trial-and-error. The reason I mention this is that I think that confinement is overall a minor problem (because there are so many reasonable ways to avoid it) and that worrying about confinement with an authenticated but unscrupulous conversant is even more minor. For comparison I offer the brute force method, an attack that is ignored because there is no cure. At least, I don't know of one. Hilarie From owner-ipsec Thu Apr 17 11:54:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22990 for ipsec-outgoing; Thu, 17 Apr 1997 11:53:47 -0400 (EDT) Message-Id: <199704171558.LAA03975@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Charles Lynn Cc: David Carrel , palamber@us.oracle.com, ipsec@tis.com Subject: Re: Tunnel mode AH (Was: notes from developer's portion of IETF meeting) In-Reply-To: clynn's message of Thu, 17 Apr 1997 10:32:54 -0400. <199704171428.KAA11109@relay.hq.tis.com> Date: Thu, 17 Apr 1997 11:58:32 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Did the working group decide on a mechanism, e.g., a bit in the > RESERVED field, to indicate a "tunnel mode" in which none of the > headers preceding the AH are to be covered by the integrity > mechanism? If we were going to do this (and I'm not sure it's the right thing to do), I'd think that this should be an attribute of the SA, not a bit in the header.. - Bill From owner-ipsec Thu Apr 17 12:39:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23359 for ipsec-outgoing; Thu, 17 Apr 1997 12:39:07 -0400 (EDT) Message-ID: <335639C2.59C0@newoak.com> Date: Thu, 17 Apr 1997 10:54:58 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: CBC IV generation in ISAKMP/Oakley X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk In the latest (-03) version of the ISAKMP/Oakley resolution draft, there's a change in how the IV for ISAKMP message encryption is performed. Previously, in the -02 draft, a hash of the D-H public values was used as the IV for all messages. Now, that hash is only used for the first encrypted message in Phase 1; all other Phase 1 messages use the last CBC encryption block from the previous message. The first message of a Phase 2/Quick Mode exchange uses a hash of the last Phase 1 CBC output block output block with the Phase 2 message ID as its IV, with later messages in that particular exchange using the last CBC encryption block from the previous message in the exchange. (One can read Appendix B of the -03 draft for the rest of the details.) I guess that changing the IV for every message is a good thing from a cryptographic point of view (at least to this non-cryptographer), but I'm concerned that it might not be such a good thing from a protocol point of view. Specifically, I have two concerns: 1. Handling retransmissions: ISAKMP entities MUST retransmit when a response is not received after some period of time (isakmp-07 draft, section 5.1). This, coupled with the fact that IVs change now, makes the following scenario possible: i. Once Phase 1 is complete, one of the ISAKMP peers sends out an initial Phase 2/Quick Mode message. ii. No response is received, so the initiator retransmits. iii. The intended responder finally receives the first message. The IV for the initial message is calculated, the message is decrypted and processed, the reply is sent out, and the responder is now prepared to decrypt the next message using the last CBC block of that message as the IV. iv. The responder receives the retransmission of the first message. It cannot be decrypted cleanly, because the IV is now wrong. Since there is no sequence number or other "hint" in the ISAKMP header which allows one to detect retransmissions, about the only thing a Phase 2 responder can do is "guesstimate" the likely size of the initiator's second Phase 2 message, and throw out anything larger than that as being a likely retransmission of the first message. Or recalculate the initial IV and try to decrypt the message over again. Both of these approaches are, at best, workarounds for something for which the protocol itself really ought to handle better (or at least document the proper workaround...). 2. Informational exchange messages (Notify and Delete): isakmp-07 states that Informational exchange messages MUST be protected by the ISAKMP SA once it is established (section 4.8). However, isakmp-oakley-03 does not state what one should use for an IV when sending an Informational exchange message. One could assume that a Notify payload sent in reply to some Phase 2 message should use the CBC output block from the previous message as the IV. (One should not have to assume this; it should be stated clearly somewhere.) If, however, there are several Phase 2 exchanges going on at the same time, how does one tell which IV to use? Is it legal to use the Message ID in an Informational exchange? What if a message is not decrypted cleanly (due perhaps to an IV problem with a retransmission as described above?). Should one send a Notify payload back? Encrypted or not? If encrypted, what IV does one use? Better still, what about Delete payloads? Those may not arrive until much later. They should obviously be protected by an ISAKMP SA, but what should one use for an IV? I'm certain all of these can be handled one way or another. Maybe it would make sense to include the IV as part of the message, the way ESP transforms do. Or perhaps it just requires some clarifying text in the draft(s). Or maybe I'm missing something really obvious... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Thu Apr 17 13:35:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23879 for ipsec-outgoing; Thu, 17 Apr 1997 13:34:09 -0400 (EDT) Message-Id: <199704171739.KAA11940@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: smamros@newoak.com (Shawn Mamros) Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley In-Reply-To: Your message of "Thu, 17 Apr 1997 10:54:58 EDT." <335639C2.59C0@newoak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 10:39:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, In the -02 draft the IV was not constant. That might not have been explained very clearly but that was the intent (and in fact, the most recent bake-off was against -02 and everyone had a running IV). > I guess that changing the IV for every message is a good thing from > a cryptographic point of view (at least to this non-cryptographer), > but I'm concerned that it might not be such a good thing from a > protocol point of view. Specifically, I have two concerns: A changing IV is mandatory. There is no point in having an IV if it is the same for all messages. > 1. Handling retransmissions: ISAKMP entities MUST retransmit when > a response is not received after some period of time (isakmp-07 > draft, section 5.1). This, coupled with the fact that IVs change > now, makes the following scenario possible: > > i. Once Phase 1 is complete, one of the ISAKMP peers sends out an > initial Phase 2/Quick Mode message. > > ii. No response is received, so the initiator retransmits. > > iii. The intended responder finally receives the first message. > The IV for the initial message is calculated, the message is > decrypted and processed, the reply is sent out, and the responder > is now prepared to decrypt the next message using the last CBC > block of that message as the IV. > > iv. The responder receives the retransmission of the first message. > It cannot be decrypted cleanly, because the IV is now wrong. I've seen this happen in testing. > Since there is no sequence number or other "hint" in the ISAKMP > header which allows one to detect retransmissions, about the only > thing a Phase 2 responder can do is "guesstimate" the likely > size of the initiator's second Phase 2 message, and throw out anything > larger than that as being a likely retransmission of the first message. > Or recalculate the initial IV and try to decrypt the message over > again. Both of these approaches are, at best, workarounds for > something for which the protocol itself really ought to handle > better (or at least document the proper workaround...). No, the 2nd one is dropped because the decryption failed. The protocol handles this just fine. > 2. Informational exchange messages (Notify and Delete): isakmp-07 > states that Informational exchange messages MUST be protected by > the ISAKMP SA once it is established (section 4.8). However, > isakmp-oakley-03 does not state what one should use for an IV > when sending an Informational exchange message. This needs some wordsmithing and coordination with the ISAKMP authors. The solution is to require Informational exchanges to have a message-ID in the header. The IV for these exchanges would then be derived in an identical manner as that for Quick Mode exchanges. Your concerns about IVs getting out of sync if messages are dropped can be alleviated by retaining the encrypted payload for retransmission purposes. If your counter times out, resend the encrypted payload, don't retain the cleartext payload and re-encrypt it. Like I said, I've seen this happen and there is a brief hiccup and then they get back into sync. > I'm certain all of these can be handled one way or another. Maybe > it would make sense to include the IV as part of the message, the > way ESP transforms do. Or perhaps it just requires some clarifying > text in the draft(s). Or maybe I'm missing something really obvious... Clarification in the drafts is the way to go. I think it was Idi Amin who said, "Sometimes people mistake the things I say for the way I think." For me it's: the way I write for what I think. Dan. From owner-ipsec Thu Apr 17 13:35:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23907 for ipsec-outgoing; Thu, 17 Apr 1997 13:35:39 -0400 (EDT) Date: Thu, 17 Apr 1997 13:38:19 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171738.NAA29401@earth.hpc.org> To: smamros@newoak.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704171650.JAA07669@baskerville.CS.Arizona.EDU> Subject: Re: CBC IV generation in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Surely this is true. > Maybe > it would make sense to include the IV as part of the message, the > way ESP transforms do. Hilarie From owner-ipsec Thu Apr 17 14:18:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24293 for ipsec-outgoing; Thu, 17 Apr 1997 14:18:16 -0400 (EDT) Message-ID: <33566146.49F@redbacknetworks.com> Date: Thu, 17 Apr 1997 10:43:34 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting References: <199704171353.JAA22585@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, that might be a fine implementation detail. I'll spare everyone my opinion on that. However, the only point that was decided upon in the meeting is the onus of specifying the details for generating keys, IVs, etc... If the working group wishes to work on an API or ABI for ISAKMP and/or IPSEC (such as PF_KEY) then issues such as what you mention will need to be decided upon. Dave Hilarie Orman wrote: > > Wouldn't it be easiest to have the transforms present a callback > routine for key generation? The routine would take a variable > precision integer as input (length >= requested entropy) and produce a > list of bitstrings as output. > > > slice and dice > ... > > All transforms MUST specify a number of keying bits > > required and how to generate keys, IVs, etc from that > > (# keying bits requested equals the # bits of entropy) > > Hilarie From owner-ipsec Thu Apr 17 14:20:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24318 for ipsec-outgoing; Thu, 17 Apr 1997 14:20:18 -0400 (EDT) Message-ID: <335661D9.6B5A@redbacknetworks.com> Date: Thu, 17 Apr 1997 10:46:01 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Charles Lynn CC: palamber@us.oracle.com, ipsec@tis.com Subject: Re: Tunnel mode AH (Was: notes from... IETF meeting) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, no such decision was made (that I am aware of) in Memphis. It would be good to start thrashing that out here. Dave Charles Lynn wrote: > > David, > > > optional encryption > > not optional in ESP > > A tunnel mode must be added to the specs for AH > > Did the working group decide on a mechanism, e.g., a bit in the > RESERVED field, to indicate a "tunnel mode" in which none of the > headers preceding the AH are to be covered by the integrity > mechanism? > > Such a mode is needed both for efficiency (hop-by-hop protection of > every packet sent between two systems) and for extensibility (as new > extension header versions, etc. are defined). This was provided by > the "ESP with integrity but not confidentiality" combination. > > Charlie From owner-ipsec Thu Apr 17 14:21:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24370 for ipsec-outgoing; Thu, 17 Apr 1997 14:21:20 -0400 (EDT) Date: Thu, 17 Apr 1997 18:42:16 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704171542.SAA25241@ee.technion.ac.il> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Small subgroups and ISAKMP/Oakley Cc: JKENNEDY@novell.com, ipsec@tis.com, lmccarth@cs.umass.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk A feature of isakmp/oakley's public key encryption mode, which I do not think is enjoyed by any of the other mentioned standards, is that even if an attacker derives g^xy (by means of preprocessing against a "universal" prime p, or by degenarate choices of one of the parties in the exchange) it still cannot decrypt the traffic since the key also depends on an ephemeral key exchanged under RSA. (That is, both the RSA AND DH exchanges need to be broken simultaneously). The current drawback of this mode in isakmp-oakley is that it requires an additional exponentiation for protecting id's. Unfortunately, the simple correction of this problem will need to wait until the next draft revision... Hugo From owner-ipsec Thu Apr 17 14:23:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24418 for ipsec-outgoing; Thu, 17 Apr 1997 14:23:50 -0400 (EDT) Message-ID: <33557F9B.72A1@redbacknetworks.com> Date: Wed, 16 Apr 1997 18:40:43 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: palamber@us.oracle.com CC: ipsec@tis.com, isakmp-oakley@cisco.com Subject: notes from developer's portion of IETF meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, here are the notes that I took at the developers portion of the IPSEC meetings. Please include these in the official minutes. Thanks Dave Carrel carrel@ipsec.org ------------------------------------------------------------- anti-replay decision is that it is not optional! The bits are always in the header It MUST be used by sender. Always starts at 1. key management will NOT negotiate whether it's used. integrity decicion is that it is optional but if not used in ESP, it must be used in AH. Words to this effect must be added to arch docs. optional encryption not optional in ESP A tunnel mode must be added to the specs for AH encrypt/auth order encrypt first, auth next but IV MUST NOT be constant and MUST be included in every packet IV size is transform dependant and must be specified in the transform docs signature format Dan will send to list, with comments from Eric Rescolla IBM- rsa encryption format leave current format as is to avoid document creep Ran and Hugo will write a draft of their exchange slice and dice remove current key derivation text from Hughes draft It is based on who is initiator and responder (*** action item for Paul Lambert ***) All transforms MUST specify a number of keying bits required and how to generate keys, IVs, etc from that (# keying bits requested equals the # bits of entropy) transform must specify what to do in case of weak key if alg has a small number of weak keys then the recommendation is to request a new SA Name space to IANA need algorithm ids forward issue to list Audit Decision is that this will be documented as "SHOULD implement" MIB take issue to list ---------------------- The following issues were discussed and agreed upon in the Wednesday mtg. ISAKMP ISAKMP should be bound to port 500 (i.e. send and receive on port 500) No need to negotiate replay window size. replay window size is 32. Increase it to a higher value later on if necesary. Situation and DOI must be included in calculating hash for the quick mode for public-key encryption, SKEYID = prf(Ni | Nr, g^xy) (it was hash(Ni | Nr). HASH(2) in Quick Mode includes the initiator's nonce. For ease of processing stick it after the message-id, i.e. HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | IDur ] ) ^^^^ From owner-ipsec Thu Apr 17 17:27:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25759 for ipsec-outgoing; Thu, 17 Apr 1997 17:26:05 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 17 Apr 1997 15:31:03 -0600 From: John Kennedy To: ho@earth.hpc.org Cc: ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with you that implementors should not have to become number theorists. Given the rather protracted development time for this family of standards I think it is advisable to nail down as much as possible in Oakley. No doubt, other key management mechanisms will be developed in the future to fit under the ISAKMP framework. In other words, I think there is a lot of wisdom to restricting the degrees of freedom offered in Oakley. Using j=2 is a nice conservative choice and any potential loss of efficiency by not allowing a larger j (i.e. smaller q) is negligible at this point. -John Kennedy >>> Hilarie Orman 04/17/97 07:42AM >>> > On the Sophie-Germaine/j=2 thing: > > Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. One reason that it is bad is that it may force implementors to become number theorists. While in the greater scheme of things, this would be a positive development, in the small it is merely quixotic. Is there some reason that j=2 is an unreasonable restriction? The only reason I can see for non-Sophie-Germaineness* is that it might be possible for one party to propose a new group of a particular type and for the recipient to verify its subgroup structure quickly (a few minutes). Hilarie Why not simply Germaine primes? No one says Emma-Noetherian rings. ! From owner-ipsec Thu Apr 17 17:59:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25914 for ipsec-outgoing; Thu, 17 Apr 1997 17:58:53 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 17 Apr 1997 16:03:55 -0600 From: John Kennedy To: lmccarth@cs.umass.edu, ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Given the nature of modular exponentiation I would expect the chances of "accidently" generating such a public number to be pretty small. In other words, I wouldn't expect there to be much value in a sender doing this check. Creating such a public number is something a communicant would do on purpose. The reason a communicant would do this is because he wants to enable a third party to listen in. As far as this being realistic, some argue that it is just as easy for the bad party to just leak the plaintext out to the third party through another channel. Thus, I think testing of the public number is something that is the responsiblity of the the receiver. Balancing the risk and cost of doing or not doing most of these different types of checks is something best left to implementors. Where there is clear value to a check that is easy to do then we should include it as mandatory. Otherwise, let the implementors make these choices based on the application, value of the information being protected, and the implementation platform. The more conservative implementors may not get market share due to performance problems, but when their competitor gets raked over the coals because they took a little "shortcut", suddenly the conservative guys look a lot better. That's what makes this business so much fun. :) -John >>> Lewis McCarthy 04/16/97 07:52PM >>> John Kennedy writes: > During X9.42 development discussion it was not necessarily a > man-in-the-middle that was feared with regards to the small sub-group > attack. Conceivably, one of the communicating parties could send a > "bad" public number on purpose. Is this a realistic scenario? One of the legitimate parties might be a broken implementation that doesn't correctly check whether it has computed a public exponential that lies in the small subgroup. -Lewis ! From owner-ipsec Fri Apr 18 09:05:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00796 for ipsec-outgoing; Fri, 18 Apr 1997 09:00:31 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199704181301.JAA13339@relay.hq.tis.com> Date: Fri, 18 Apr 97 08:58:10 EDT To: IPSEC@tis.com Subject: ...IPSEC-ISAKMP-07.TXT Sender: owner-ipsec@ex.tis.com Precedence: bulk To Doug Maughan, Mark Schertler, Mark Schneider, or Jeff Turner I recognize that this comment is not of the lofty caliber of the current discussions but may I point out that on page 21, in figure 2 'ISAKMP Header Format', the initiator and responder cookies are represented as 4 octet entities? Each is described as an 8 octet entity in the rest of the document. -- Jim From owner-ipsec Fri Apr 18 09:21:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00918 for ipsec-outgoing; Fri, 18 Apr 1997 09:19:07 -0400 (EDT) Message-Id: <199704181321.JAA13845@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Edward Russell Subject: RE: CBC IV generation in ISAKMP/Oakley Date: Fri, 18 Apr 1997 09:23:48 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA00915 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Shawn Mamros (smamros@newoak.com) said on 4/17/97 at 1:05 PM >The first message of a Phase 2/Quick Mode exchange uses >a hash of the last Phase 1 CBC output block output block with the >Phase 2 message ID as its IV, with later messages in that particular >exchange using the last CBC encryption block from the previous message >in the exchange. (One can read Appendix B of the -03 draft for the >rest of the details.) > Dan, How does this solve the IV situation when there are two simultaneous quick modes going on. We had discussed a while ago that if each side is negotiating a quick mode with each other simultaneously (which can happen if SAs expire at the sime time) there's no way that using the last CBC encryption block from the previous message in the exchange would work. You had indicated that this was solved in V3. I don't see the solution. Edward Russell erussell@ftp.com From owner-ipsec Fri Apr 18 09:21:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00924 for ipsec-outgoing; Fri, 18 Apr 1997 09:19:37 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199704181320.JAA14013@relay.hq.tis.com> Date: Fri, 18 Apr 97 09:23:41 EDT To: IPSEC@tis.com Subject: Cookies Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm sorry. I didn't take into account the 2 !'s worth of vertical page space. Please disregard my previous comment. -- Jim From owner-ipsec Fri Apr 18 09:26:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00985 for ipsec-outgoing; Fri, 18 Apr 1997 09:26:16 -0400 (EDT) Message-Id: <9704181331.AA15062@cichlid.raleigh.ibm.com> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Thu, 17 Apr 1997 09:17:30 EDT." <199704171317.JAA21004@argon.ncsc.mil> Date: Fri, 18 Apr 1997 09:31:20 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk > Perhaps I am missing something important, but I've never understood the > justification for negotiating replay window sizes. I also agree, and have been disheartened by the number of times the above question has been asked but not answered. Indeed, it has been my impression that the vast majority of IP packets are delivered in order (one reason why TCP's header prediction works well in practice). It is rare in practice to have packets arrive out of order. Which begs the question of whether a window is even needed. Does someone have data that argues otherwise? In any case, this is certainly a receiver issue *only*. Thomas From owner-ipsec Fri Apr 18 09:53:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01158 for ipsec-outgoing; Fri, 18 Apr 1997 09:53:25 -0400 (EDT) Date: Fri, 18 Apr 1997 09:59:07 -0400 Message-Id: <9704181359.AA18730@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: Thomas Narten , dpkemp@missi.ncsc.mil (David P. Kemp) From: Naganand Doraswamy Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:31 AM 4/18/97 -0300, Thomas Narten wrote: >> Perhaps I am missing something important, but I've never understood the >> justification for negotiating replay window sizes. > >I also agree, and have been disheartened by the number of times the >above question has been asked but not answered. Indeed, it has been >my impression that the vast majority of IP packets are delivered in >order (one reason why TCP's header prediction works well in >practice). It is rare in practice to have packets arrive out of >order. Which begs the question of whether a window is even >needed. Does someone have data that argues otherwise? > This issue has been resolved. The replay window isnot negotiated any more and it is upto the receiver to decide what size to use. The recommended size is 32. Naganand From owner-ipsec Fri Apr 18 10:25:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01377 for ipsec-outgoing; Fri, 18 Apr 1997 10:24:12 -0400 (EDT) Message-Id: <199704181426.KAA08328@raptor.research.att.com> To: Thomas Narten cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Date: Fri, 18 Apr 1997 10:26:58 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > Perhaps I am missing something important, but I've never understood the > justification for negotiating replay window sizes. I also agree, and have been disheartened by the number of times the above question has been asked but not answered. Indeed, it has been my impression that the vast majority of IP packets are delivered in order (one reason why TCP's header prediction works well in practice). It is rare in practice to have packets arrive out of order. Which begs the question of whether a window is even needed. Does someone have data that argues otherwise? Yes, there is data. I've heard Vern Paxson's talk on his measurements, and a reasonably high percentage of TCP connections do see out-of-order packets. Furthermore, since dropped packets have a very serious effect on TCP throughput, it's really worth some effort to avoid any extra drops. The incidence of out-of-order delivery seems to depend on the site involved. This suggests that it's useful if a site can tune its own replay window. (There was at least one incident where a window of *54* would have been necessary to accept the packet!) Vern felt that currently, a window of 32 was quite sufficient. But it does seem prudent to plan ahead for 64 some day. In any case, this is certainly a receiver issue *only*. Yes. I still don't understand what a sender can possibly do differently, even if a receiver indicates that it needs a larger replay window. From owner-ipsec Fri Apr 18 11:12:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01683 for ipsec-outgoing; Fri, 18 Apr 1997 11:12:15 -0400 (EDT) Message-Id: <199704181515.LAA07342@amaterasu.sandelman.ottawa.on.ca> To: anx-sec@dot.netrex.net Reply-To: ipsec@tis.com CC: ipsec@tis.com Subject: Re: introduction; certificates & proxy authentication. In-reply-to: Your message of "Thu, 17 Apr 1997 16:59:36 EDT." <199704172059.QAA00244@thunk.ch.apollo.hp.com> Date: Fri, 18 Apr 1997 11:15:02 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> Now, perhaps the following belongs on the ipsec WG list, but Bill> since the topic came up on the conference call today. Yes, it *does* belong on ipsec. Will you repost to ipsec? Bill> For instance, you may have a network looking vaguely like: Bill> user <-> GWA <-> GWB ... Bill> where user already has set up SA's with GWA, and GWA is Bill> negotiating with GWB and proxying for `user'. Bill> Now, certificates bind a set of attributes to a public key, Bill> and implicitly link those attributes to the *holder* of the Bill> private part of that key; there's not much point in passing Bill> around a certificate except to link the attributes in the Bill> certificate to something signed by the certified key. This was the crux of my point in Montreal. I am still hoping that Bob will release his document RSN. I (at least) never got a copy of his requirements document for his "challenge" either... I have come to the conclusion that this signature shall be done out of band to ISAKMP for now. Bill> I don't see any place where a protocol is defined which Bill> allows `GWA' to ask `user' to sign something destined for Bill> GWB, to prove to GWB that the user is really there.. Merely Bill> forwarding the cert doesn't prove anything; GWA could have Bill> pulled the cert out of the certificate directory.. There needs to be certificates which grant "gateway" or "firewall" authority from "user" to "GWA". This is one of the most important certificates that the IPSEC group has to define later this summer. (Does the chair agree that this is important work, and to the timing of this work?) Bill> So, is the model that GWB trusts GWA's claim that `user' has Bill> successfully authenticated to GWA? If so, this may be Bill> expedient, but I don't think it's a scalable trust model.. Bill> What am I missing? Nothing I think. You are bang on. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM1eP7qZpLyXYhL+BAQFXmwMAwSnPxu4aHkcosT9xOvrGtl3akcrzqk3s tHKA74HRf3KPD+Gr4yM859RECrDYvoHyjBpamIIi1kaSKQdCQnjqScnMrWfUCrJA 4nZjCXP3T3rsDy1NDwM8lpi5TWUYy5bG =iw/g -----END PGP SIGNATURE----- From owner-ipsec Fri Apr 18 11:32:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01798 for ipsec-outgoing; Fri, 18 Apr 1997 11:31:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704171157.HAA21287@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:37:44 -0500 To: David Carrel From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, The implementors' meeting notes say that the proposal for encryption as an optional aspect of ESP was rejected, yet no rationale was provided. I was surprized to see this recommendation from this group since I briefed this notion back in San Jose and received no negative feedback at that time, nor do I recall any negative feedback on the list since then, with the exception of one message from Ran. Since I expect to see noticeable performance differences between AH and ESP authentication, because of the complexity of omitting some fields from the calculation in AH, I'm surprized that implementors would not consider encryptionless ESP to be an attractive feature for clients. Also, in light of the message from Charlie Lynn, it would seem that ESP w/o encryption provides an important facility in various contexts. So, why did this group recommend not supporting that security service combination for ESP? Also under the optional encryption heading, there is a mantion of tunnel mode needing to be described in the AH specs. Since the current AH I-D contains an extensive tunnel mode discussion, to what do these notes refer? The anti-replay notes do not distinguish between AH and ESP. Is the intent that this field is mandatory in ESP too, if authentication is negotiated? As for the IV comments, these too seem odd to me. Not all encryption modes require an IV, yet your notes suggest otherwise. Both the presence and size of an IV is an algorithm/mode dependent feature. The suggested requirement would undermine the algorithm independence of ESP. What I assumed the group was moving toward is collapsing the IV into the payload field (for ESP with encryption) to avoid having another optional field in the header, a suggestion voiced by Steve Bellovin. Steve From owner-ipsec Fri Apr 18 11:32:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01797 for ipsec-outgoing; Fri, 18 Apr 1997 11:31:53 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704171317.JAA21004@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:31:42 -0500 To: dpkemp@missi.ncsc.mil (David P. Kemp) From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, You raise two points that I'll address separately: - it is true that the AR window protects the receiver, and imposes no changes in how the sender operates. However, I think that the use or non-use of use of AR is of interest to the sender. If communication performance problems arise between two IPSEC sites, one reason might be the rejection of some number of packets due to the size of the AR and the out-of-order delivery characteristics associated with the path. Certainly, if a default window size of 1 were adopted (as had been suggested), there would be a significant opportunity for such behavior. However, if the use of AR is purely at the discretion of the receiver, I have no way of knowing if that might be a problem, if I am troubleshooting the problem from the sender's end. So, at a minimum, I'd like to know if AR is a characteristic of each SA. With a minimum window size of 32, excessive packet rejection (leading to performance problems) seems unlikely, but it may not be impossible for paths with long delay pipes. If I were responsible for the management of the sending end of the IPSEC SA being affected, I'd like to be able to determine the window size in use by the receiver. If the window size in use by the receiver was merely reported as a side effect of SA establishment (vs. being negotiated) that would suffice. However, this seemed less in keeping with the general SA parameter management philosophy we've adopted. Also, the sender may have more knowledge about the nature of the application using the SA and, if source routing is employed, may know more about the path being used, and hence may be better equipped to suggest an appropriate windwo size, i.e., one that is less likely to experience problems due to substantial out-of-order arrivals. Maybe that's pushing the point, but it would argue for sender input into a window size negotiaion. Yes, always carrying the field, and always maintaining the counter and letting the receiver dedice whether to pay attention is the simplest approach in some respects. But leaving the sender not knowing the security characteristics of an SA is bothersome. It also suggests that conformamce testing is hard (or maybe just useless?), as any behavior by the receiver would appear to be OK re AR! Steve From owner-ipsec Fri Apr 18 11:39:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01876 for ipsec-outgoing; Fri, 18 Apr 1997 11:38:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9704181359.AA18730@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:45:07 -0500 To: Naganand Doraswamy From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand, I just want to point out that the WG is not composed exclusively of attendees at IETF meetings and thus the anti-replay issue is not necessarily resolved. We've had discussions on the list and there were discissions at the WG meetings and the two don't necessarily seem to be completely consistent yet. maybe a straw poll will be required, but let's see how messages sort out over the next week before we state too strongly that this issie is closed. Steve From owner-ipsec Fri Apr 18 11:46:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01937 for ipsec-outgoing; Fri, 18 Apr 1997 11:44:58 -0400 (EDT) Message-Id: <199704181550.IAA12511@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Edward Russell Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley In-Reply-To: Your message of "Fri, 18 Apr 1997 09:23:48 EDT." <199704181321.JAA13845@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 08:50:33 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ed Russell wrote: > >Shawn Mamros (smamros@newoak.com) said on 4/17/97 at 1:05 PM > >The first message of a Phase 2/Quick Mode exchange uses > >a hash of the last Phase 1 CBC output block output block with the > >Phase 2 message ID as its IV, with later messages in that particular > >exchange using the last CBC encryption block from the previous message > >in the exchange. (One can read Appendix B of the -03 draft for the > >rest of the details.) > > How does this solve the IV situation when there are two simultaneous > quick modes going on. We had discussed a while ago that if each side > is negotiating a quick mode with each other simultaneously (which can > happen if SAs expire at the sime time) there's no way that using the last CBC > encryption block from the previous message in the exchange would work. > You had indicated that this was solved in V3. I don't see the solution. The IV for Quick Mode is hash(phase1-IV | message-ID). Since the message-ID is unique for each quick mode the IV will be different. This is the IV for this Quick Mode, after it's over the IV and all associated state goes away. The next Quick Mode has another (new and different) IV. If two start simultaneously they'll each have a different IV. The message-id in the header lets you identify the state (incl. the IV) for this particular exchange. The IVs are still running, there is a defined start (so each side has the same one) but after processing each Quick Mode packet it changes until the Quick Mode ends then it goes away. Dan. From owner-ipsec Fri Apr 18 12:13:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02116 for ipsec-outgoing; Fri, 18 Apr 1997 12:12:41 -0400 (EDT) Message-Id: <199704181618.JAA12563@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com, anx-sec@dot.netrex.net Subject: Re: introduction; certificates & proxy authentication. In-Reply-To: Your message of "Fri, 18 Apr 1997 11:15:02 EDT." <199704181515.LAA07342@amaterasu.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 09:18:09 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > There needs to be certificates which grant "gateway" or "firewall" > authority from "user" to "GWA". This is one of the most important > certificates that the IPSEC group has to define later this > summer. (Does the chair agree that this is important work, and to the > timing of this work?) How about adding another record in (secure) DNS analogous to the MX record? This thing (KX?) would say "if you want to talk to blah.cisco.com negotiate with gw1.cisco.com or gw2.cisco.com". That idea has been floated around several times. It solves the problem and scales beautifully. It seems better than defining another certificate. And isn't SPKI doing that work anyway? Dan. From owner-ipsec Fri Apr 18 12:33:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02211 for ipsec-outgoing; Fri, 18 Apr 1997 12:31:30 -0400 (EDT) Message-Id: <01BC4BF5.3F239AE0@erussell-2.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" , "'Daniel Harkins'" Subject: RE: CBC IV generation in ISAKMP/Oakley Date: Fri, 18 Apr 1997 12:37:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- From: Daniel Harkins[SMTP:dharkins@cisco.com] Sent: Friday, April 18, 1997 11:51 AM To: Edward Russell Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley > The IV for Quick Mode is hash(phase1-IV | message-ID). Since the message-ID >is unique for each quick mode the IV will be different. This is the IV >for this Quick Mode, after it's over the IV and all associated state >goes away. The next Quick Mode has another (new and different) IV. If >two start simultaneously they'll each have a different IV. The message-id >in the header lets you identify the state (incl. the IV) for this particular >exchange. The IVs are still running, there is a defined start (so each side >has the same one) but after processing each Quick Mode packet it changes >until the Quick Mode ends then it goes away. > Dan. O.K. It still makes me nervous that the "running" is dependent on messages not passing in the night. What if each side decides to send notifies simultaneously within the same Main Mode. I guess that goes along with what Shawn was referring to. I almost wish the IV were the last block of the CURRENT message, but that's the same as sending the IV along with the message (in fact it is). Ed Russell erussell@ftp.com From owner-ipsec Fri Apr 18 13:11:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02541 for ipsec-outgoing; Fri, 18 Apr 1997 13:10:52 -0400 (EDT) Message-Id: <199704181716.NAA00721@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: certificates & proxy authentication. Date: Fri, 18 Apr 1997 13:16:46 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [This is the message which Michael Richardson was referring to.. As he said, I wasn't missing anything; proxy identities are merely assertions by the proxy.] There was some discussion of proxy authentication in ISAKMP, which is mentioned in passing in a couple places in the drafts, but is not discussed in very much detail. It appears the functionality is intended to be used to allow a gateway to act as a proxy for a principal behind the gateway; the gateway presents its identity and the identity of the principal (user or host) behind the gateway. For instance, you may have a network looking vaguely like: user <-> GWA <-> GWB ... where user already has set up SA's with GWA, and GWA is negotiating with GWB and proxying for `user'. Now, certificates bind a set of attributes to a public key, and implicitly link those attributes to the *holder* of the private part of that key; there's not much point in passing around a certificate except to link the attributes in the certificate to something signed by the certified key. I don't see any place where a protocol is defined which allows `GWA' to ask `user' to sign something destined for GWB, to prove to GWB that the user is really there.. Merely forwarding the cert doesn't prove anything; GWA could have pulled the cert out of the certificate directory.. So, is the model that GWB trusts GWA's claim that `user' has successfully authenticated to GWA? If so, this may be expedient, but I don't think it's a scalable trust model.. What am I missing? - Bill From owner-ipsec Fri Apr 18 13:42:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02682 for ipsec-outgoing; Fri, 18 Apr 1997 13:39:37 -0400 (EDT) Message-Id: <9704181745.AA17250@cichlid.raleigh.ibm.com> To: Steven Bellovin Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com, Vern Paxson Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 10:26:58 EDT." <199704181426.KAA08328@raptor.research.att.com> Date: Fri, 18 Apr 1997 13:45:07 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin writes: > Yes, there is data. I've heard Vern Paxson's talk on his measurements, > and a reasonably high percentage of TCP connections do see out-of-order > packets. Furthermore, since dropped packets have a very serious effect > on TCP throughput, it's really worth some effort to avoid any extra drops. > The incidence of out-of-order delivery seems to depend on the site > involved. This suggests that it's useful if a site can tune its own > replay window. (There was at least one incident where a window of *54* > would have been necessary to accept the packet!) This is very useful data/rational to have. I certainly hope suitable (discussion) text along these lines makes it into the draft. Also, is there a pointer to Vern's measurements on this particular topic? Thomas From owner-ipsec Fri Apr 18 14:11:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02864 for ipsec-outgoing; Fri, 18 Apr 1997 14:11:28 -0400 (EDT) Message-Id: <199704181817.LAA12734@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Thomas Narten Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 09:31:20 -0300." <9704181331.AA15062@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:17:12 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Now perhaps I'm missing something.... > > Perhaps I am missing something important, but I've never understood the > > justification for negotiating replay window sizes. > > I also agree, and have been disheartened by the number of times the > above question has been asked but not answered. Indeed, it has been > my impression that the vast majority of IP packets are delivered in > order (one reason why TCP's header prediction works well in > practice). It is rare in practice to have packets arrive out of > order. Which begs the question of whether a window is even > needed. Does someone have data that argues otherwise? The replay window is not meant to address the issue of packets arriving out-of-order it's meant to address an attack where a previously processed packet is replayed by some attacker forcing the receiver to spin his wheels authenticating and possibly decrypting a packet which he's already authenticated and possibly decrypted. Out-or-order packets can be handled just fine by IPsec. I will 2nd that emotion, though, that negotiating a replay window size is silly. Dan. From owner-ipsec Fri Apr 18 15:13:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03242 for ipsec-outgoing; Fri, 18 Apr 1997 15:11:47 -0400 (EDT) Message-ID: <01BC4BF4.54CB6310@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , David Carrel Cc: "ipsec@tis.com" Subject: RE: notes from developer's portion of IETF meeting Date: Fri, 18 Apr 1997 12:30:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Friday, April 18, 1997 9:38 AM To: David Carrel Cc: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Dave, The implementors' meeting notes say that the proposal for encryption as an optional aspect of ESP was rejected, yet no rationale was provided. I was surprized to see this recommendation from this group since I briefed this notion back in San Jose and received no negative feedback at that time, nor do I recall any negative feedback on the list since then, with the exception of one message from Ran. Since I expect to see noticeable performance differences between AH and ESP authentication, because of the complexity of omitting some fields from the calculation in AH, I'm surprized that implementors would not consider encryptionless ESP to be an attractive feature for clients. Also, in light of the message from Charlie Lynn, it would seem that ESP w/o encryption provides an important facility in various contexts. So, why did this group recommend not supporting that security service combination for ESP? My belief is that the slight gain in performance that you get from not hashing over the headers isn't worth another option. If you want integrity, use AH. If we're going to go this route, why not bag AH and always do ESP with an option for header inclusion in the integrity calculation? One option is the same as another at this point. I'm not suggesting this because I think it is too late for this magnitude of change, but it would reduce the complexity. Also under the optional encryption heading, there is a mantion of tunnel mode needing to be described in the AH specs. Since the current AH I-D contains an extensive tunnel mode discussion, to what do these notes refer? I think this is in reference to the next point that ESP without AH is more or less useless. If you do ESP without AH you have to at least wrap the thing in an AH tunnel. I might be stupid here but this is what I remember. Ran, do you recall what we decided here? You came up with the proposed solution to this problem if I recall correctly, and at the time it struck me as very well put and spot on. The anti-replay notes do not distinguish between AH and ESP. Is the intent that this field is mandatory in ESP too, if authentication is negotiated? Not negotiated, always sent, regardless of use. Since we require the packet to have some sort of integrity (tunnel or otherwise) there is no sense in not sending the replay field. As for the IV comments, these too seem odd to me. Not all encryption modes require an IV, yet your notes suggest otherwise. Both the presence and size of an IV is an algorithm/mode dependent feature. The suggested requirement would undermine the algorithm independence of ESP. What I assumed the group was moving toward is collapsing the IV into the payload field (for ESP with encryption) to avoid having another optional field in the header, a suggestion voiced by Steve Bellovin. IV is specific to the algorithm correct, and your last assumption about moving the IV into the payload field is also correct. This comment had a lot to do with the Hughes transform. We decided to bag the fixed IV you get from key mangling that Hughes originally did. And because of other changes to the format, fixed IV's in this context are now deemed very bad. Therefore, for what was Hughes, we decided to always send the IV. Somone correct me if I blew it on any of these questions -Rob From owner-ipsec Fri Apr 18 16:23:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03617 for ipsec-outgoing; Fri, 18 Apr 1997 16:21:19 -0400 (EDT) Message-ID: <01BC4BFE.0833F350@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , "'David Carrel'" Cc: "'ipsec@tis.com'" Subject: RE: notes from developer's portion of IETF meeting Date: Fri, 18 Apr 1997 13:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk After getting a few complaints about the format of my message, I'm sending it again.. Sorry, Microsoft Outlook got me.. I didn't realize that the formatting I see isn't what I actually got back when I received my own reply.... Here it is again.. sorry for the inconvience.. > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Friday, April 18, 1997 9:38 AM > To: David Carrel > Cc: ipsec@tis.com > Subject: Re: notes from developer's portion of IETF meeting > Dave, > The implementors' meeting notes say that the proposal for >encryption as an optional aspect of ESP was rejected, yet no rationale was >provided. I was surprized to see this recommendation from this group since >I briefed this notion back in San Jose and received no negative feedback at >that time, nor do I recall any negative feedback on the list since then, >with the exception of one message from Ran. Since I expect to see >noticeable performance differences between AH and ESP authentication, >because of the complexity of omitting some fields from the calculation in >AH, I'm surprized that implementors would not consider encryptionless ESP >to be an attractive feature for clients. Also, in light of the message >from Charlie Lynn, it would seem that ESP w/o encryption provides an >important facility in various contexts. So, why did this group recommend >not supporting that security service combination for ESP? My belief is that the slight gain in performance that you get from not hashing over the headers isn't worth another option. If you want integrity, use AH. If we're going to go this route, why not bag AH and always do ESP with an option for header inclusion in the integrity calculation? One option is the same as another at this point. I'm not suggesting this because I think it is too late for this magnitude of change, but it would reduce the complexity. > Also under the optional encryption heading, there is a mantion of >tunnel mode needing to be described in the AH specs. Since the current AH >I-D contains an extensive tunnel mode discussion, to what do these notes >refer? I think this is in reference to the next point that ESP without AH is more or less useless. If you do ESP without AH you have to at least wrap the thing in an AH tunnel. I might be stupid here but this is what I remember. Ran, do you recall what we decided here? You came up with the proposed solution to this problem if I recall correctly, and at the time it struck me as very well put and spot on. > The anti-replay notes do not distinguish between AH and ESP. Is >the intent that this field is mandatory in ESP too, if authentication is >negotiated? Not negotiated, always sent, regardless of use. Since we require the packet to have some sort of integrity (tunnel or otherwise) there is no sense in not sending the replay field. > As for the IV comments, these too seem odd to me. Not all >encryption modes require an IV, yet your notes suggest otherwise. Both the >presence and size of an IV is an algorithm/mode dependent feature. The >suggested requirement would undermine the algorithm independence of ESP. >What I assumed the group was moving toward is collapsing the IV into the >payload field (for ESP with encryption) to avoid having another optional >field in the header, a suggestion voiced by Steve Bellovin. IV is specific to the algorithm correct, and your last assumption about moving the IV into the payload field is also correct. This comment had a lot to do with the Hughes transform. We decided to bag the fixed IV you get from key mangling that Hughes originally did. And because of other changes to the format, fixed IV's in this context are now deemed very bad. Therefore, for what was Hughes, we decided to always send the IV. Somone correct me if I blew it on any of these questions -Rob From owner-ipsec Sat Apr 19 15:46:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09308 for ipsec-outgoing; Sat, 19 Apr 1997 15:42:11 -0400 (EDT) Date: Sat, 19 Apr 1997 15:48:03 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704161309.JAA20179@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dpkemp@missi.ncsc.mil (David P. Kemp) From: Stephen Kent Subject: Re: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk David, I like your suggestion re unpredictable SPIs and easy indexing, but it does seem that there is a minor vulnerability. If I am not able to establish an SA to the target IPSEC implementation (and we assume that passive wiretapping of valid SPIs is not generally feasible), then the approach you describe does allow for easy indexing into an SPI table, while making SPI values hard to guess. However, if I can establish one such SA, then I'll know the range in which the SPIs are being generated (since they must be in the neighborhood of the one I have). Thus, there is an opportunity for me to use this info to generate probably SPIs that could be inserted into packets carrying spurious source addresses, to divert attention away from me as an attacker. If the implementation is robust, then the random offset would be relatively long lived, and thus this vulnerability might be exploitable for some time. Another concern arises relative to the ease of getting any valid SPI from an implemenattion. I don't recall at what point in an ISAKMP exchange does the target of an SA transmit the SPI that the initiator will employ? Can an attacker manage to get the SPI without successfully completing the exchange? If so, it might be easy for an attacker to get a valid SPI to use as input to the sort of attack I noted above. Steve From owner-ipsec Mon Apr 21 07:41:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19425 for ipsec-outgoing; Mon, 21 Apr 1997 07:33:22 -0400 (EDT) Message-Id: <199704211133.HAA19425@portal.ex.tis.com> To: Thomas Narten Cc: Steven Bellovin , dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-reply-to: Your message of Fri, 18 Apr 1997 13:45:07 PDT. Date: Fri, 18 Apr 1997 22:38:26 PDT From: Vern Paxson Sender: owner-ipsec@ex.tis.com Precedence: bulk A draft paper that discusses out-of-order delivery, among a bunch of other things, is available from: ftp://ftp.ee.lbl.gov/.vp-pkt-dyn-sigcomm-draft.ps.gz A revised version will by available by the end of May (to appear in SIGCOMM '97). The out-of-order results won't be changed much. I filed my dissertation today, and will have an on-line version of it available shortly. It goes into greater detail than the paper (naturally!). Something to keep in mind is that large reordering events will often lead to unnecessary retransmissions anyway, because the out-of-order packets will cause duplicate acks that in turn trigger fast retransmission. So if this is aggravated by dropping some packets on the floor due to other reasons, it may not actually cause much of an *additional* performance hit. Steve & I discussed this a couple of weeks ago. As I recall, the question is whether accommodating reorderings of up to 32 packets suffices. It should - while larger reorderings can happen, they are very rare (at least in today's Internet), and furthermore will already cause performance problems, as noted above. > > The incidence of out-of-order delivery seems to depend on the site Right, it's strongly site-specific. Some sites see a whole lot of reordering and some see very little. This is because some sites have load-balancing routing near them and others don't. Also, some sites are much more prone to large reordering events than are others, which is due to their proximity to certain types of routers (though I haven't identified the make) that are much more prone to causing such events than are others. Vern From owner-ipsec Mon Apr 21 17:22:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23661 for ipsec-outgoing; Mon, 21 Apr 1997 17:19:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01BC4BFE.0833F350@BIGHUGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Apr 1997 17:29:05 -0400 To: Rob Adams From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk ROb, Thanks for the responses. Let me see if I can follow through on your comments to help close the loop on these matters: >> The implementors' meeting notes say that the proposal for >>encryption as an optional aspect of ESP was rejected, yet no rationale was >>provided. I was surprized to see this recommendation from this group since >>I briefed this notion back in San Jose and received no negative feedback at >>that time, nor do I recall any negative feedback on the list since then, >>with the exception of one message from Ran. Since I expect to see >>noticeable performance differences between AH and ESP authentication, >>because of the complexity of omitting some fields from the calculation in >>AH, I'm surprized that implementors would not consider encryptionless ESP >>to be an attractive feature for clients. Also, in light of the message >>from Charlie Lynn, it would seem that ESP w/o encryption provides an >>important facility in various contexts. So, why did this group recommend >>not supporting that security service combination for ESP? > >My belief is that the slight gain in performance that you get from not hashing >over the headers isn't worth another option. If you want integrity, use >AH. If >we're going to go this route, why not bag AH and always do ESP with an option >for header inclusion in the integrity calculation? One option is the same as >another at this point. I'm not suggesting this because I think it is too >late >for this magnitude of change, but it would reduce the complexity. Use of AH is not the same as use of ESP w/o encryption, precisely because of the coverage issue, and the associated performance hit. Remember that to compute AH , one must perform the logical equivalent of copying the IP header (and all options) over to a new buffer, then zeroing each header field that is always excluded, then examine every option to see if it is included or excluded. For IPv6, with more header extentions/options/etc. this might be come a more time consuming task. My guess is that use of ESP in tunnel mode will be popular, with one end of the SA at a firewall. Under those circumstances, AH in tunnel mode does not buy one much, because the outer header is not very interesting, i.e., it will be discarded. (Only rarely would it make sense to copy portions of it into an inner header.) Thus tunnel mode ESP would provide suitable protection for traffic with greater efficiency and less per-packet overhead. What I'm hearing from this discussion is that the motivation for not offering ESP w/o encryption is added complexity. I'm all in favor of reducing complexity, if it doesn't cost functionality, but I'm really surprized to hear that offering ESP w/o encryption is percieved as a significant increase in complexity. >> Also under the optional encryption heading, there is a mantion of >>tunnel mode needing to be described in the AH specs. Since the current AH >>I-D contains an extensive tunnel mode discussion, to what do these notes >>refer? > >I think this is in reference to the next point that ESP without AH is more >or less >useless. If you do ESP without AH you have to at least wrap the thing in >an AH >tunnel. I might be stupid here but this is what I remember. Ran, do you >recall >what we decided here? You came up with the proposed solution to this problem >if I recall correctly, and at the time it struck me as very well put and >spot on. I assume you meat to say that ESP with authentication was useless, but I have to disagree. I know folks who are sending packet voice and packet video on an end-to-end basis. I recommend use of ESP w/o authentication in this context. With an appropriate encryption mode (such as CBC), the nature of the application makes it unlikely that one can twiddle bits in an effective manner, given use of a suitable encryption mode (e.g., CBC). Also, since people are the consumers of this data, we can rely on them to discard obviously errored traffic. Reordering and replay will be detected by the builtin timestamp facility. However, per-packet overhead is a big concern here and thus stripping out everyting but the encryption support is an important feature. Thus the flexibility offered by modular use of ESP and AH is important to these folks and is in keeping with the original intent of IPSEC. >> The anti-replay notes do not distinguish between AH and ESP. Is >>the intent that this field is mandatory in ESP too, if authentication is >>negotiated? > >Not negotiated, always sent, regardless of use. Since we >require the packet to have some sort of integrity (tunnel or otherwise) >there is no sense in not sending the replay field. I sent a separate message arguing for why I'd like to be able to negotiate use of AR for eithe protocol, although I can see merit to adopting a default window size of 32 to minimize the need for negotiating a window size. However, the comment about "no sense in not sending the replay" counter since integrity is always rerquired puzzles me. As noted above, I can cite real applications where encryption w/o authenitcation is appropriate. Sending it takes up space that may be critical to such applications, especially when it's not going to be used. I think the better argument is that AR counter inclusion makes alignment "work" for AH in the IPv6 context, and in ESP this inclusion aligns the start of the payload (assuming that we fold the IV into the payload) on an 8-byte boundary as well, to facilitate crypto processing. Also, by always sending this field, one simplifies packet parsing, by eliminating variability. If these are the reasons for mandating inclusion of the AR counter in every AH and ESP packet, then so be it, but at least lets agree on a rationale that makes it clear what tradeoffs were considered in coming to this conclusion. Also, even if we do include it in every packet, for these alignment and parsing reasons, whether we negotiate use of the field > >> As for the IV comments, these too seem odd to me. Not all >>encryption modes require an IV, yet your notes suggest otherwise. Both the >>presence and size of an IV is an algorithm/mode dependent feature. The >>suggested requirement would undermine the algorithm independence of ESP. >>What I assumed the group was moving toward is collapsing the IV into the >>payload field (for ESP with encryption) to avoid having another optional >>field in the header, a suggestion voiced by Steve Bellovin. > >IV is specific to the algorithm correct, and your last assumption >about moving the IV into the payload field is also correct. This comment had >a lot to do with the Hughes transform. We decided to bag the fixed IV you get >from key mangling that Hughes originally did. And because of other changes >to the format, fixed IV's in this context are now deemed very bad. Therefore, >for what was Hughes, we decided to always send the IV. This clarifies the last comment. In general I propose that we remove the IV as an explcit, optional field and fold it into the beginning of the payload. The text will be modified to state this convention, noting that each algorithm document must state the presence/absence of an IV (or a sequence space pointer for some types of stream ciphers) and the size of the IV. That way we can keep the ESP document simple and algorithm independent. Steve From owner-ipsec Tue Apr 22 10:23:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29321 for ipsec-outgoing; Tue, 22 Apr 1997 10:16:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-02.txt Date: Tue, 22 Apr 1997 09:39:54 -0400 Message-ID: <9704220939.aa26685@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-02.txt Pages : 14 Date : 04/21/1997 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of thers who might also adopt and use the API, thus providing increased portability of key management applications (e.g. an ISAKMP daemon, a Photuris daemon or SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-02.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-mcdonald-pf-key-v2-02.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: <19970421155501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970421155501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Apr 22 11:12:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29688 for ipsec-outgoing; Tue, 22 Apr 1997 11:05:25 -0400 (EDT) Message-Id: <199704221509.LAA19920@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting In-reply-to: Your message of "Mon, 21 Apr 1997 17:29:05 EDT." Date: Tue, 22 Apr 1997 11:09:22 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> consuming task. My guess is that use of ESP in tunnel Stephen> mode will be popular, with one end of the SA at a Stephen> firewall. Under those circumstances, AH in tunnel mode Stephen> does not buy one much, because the outer header is not Stephen> very interesting, i.e., it will be discarded. (Only Stephen> rarely would it make sense to copy portions of it into an Stephen> inner header.) Thus tunnel mode ESP would provide Stephen> suitable protection for traffic with greater efficiency Stephen> and less per-packet overhead. What I'm hearing from this Stephen> discussion is that the motivation for not offering ESP Stephen> w/o encryption is added complexity. I'm all in favor of As long as you are optimizing in favour of the VPN application, then let's be explicit and do that. The reason why ESP without encryption is not interesting is because the P in VPN means private. If there comes to exist a strong encrypting transform with built in integrity, VPN people will want that. Stephen> reducing complexity, if it doesn't cost functionality, Stephen> but I'm really surprized to hear that offering ESP w/o Stephen> encryption is percieved as a significant increase in Stephen> complexity. We know AH is complex. Fine. AH isn't interesting for VPN applications. Fine. Let's allow a VPN-only to deal with lower complexity, and do only what it needs to do. That means it might not do AH. It will encrypt. I realize that is in oposition to the IPv6 MUST implement (AH, but not ESP). An encryption-less ESP could then become a MUST implement for IPv6. Remember: fewer options == interoperability. Stephen> support is an important feature. Thus the flexibility Stephen> offered by modular use of ESP and AH is important to Stephen> these folks and is in keeping with the original intent of Stephen> IPSEC. Authentication-less ESP was left as an option. I'm not sure I completely agree that audio data is not that sensitive to integrity problems, but I see your point. You have provided a motivation for continuing to include authentication-less ESP. I'm not convinced that if you are encrypting, that authentication costs that much more: I know Stephen saw this talk at NDSS, but for others: @inproceedings{Nahum1996, AUTHOR="Erich Nahum and David J. Yates and Sean O'Malley and Hilarie Orman and Richard Schroeppel", TITLE="Parallelized Network Security Protocols", BOOKTITLE="Proceedings of the 1996 Symposium on Network and Distributed Systems Security", YEAR=1996, note = "NDSS online proceedings \htmladdnormallink{http://bilbo.isu.edu/sndss/nahum.ps}{http://bilbo.isu.edu/sndss/nahum.ps}", } :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM1zUiaZpLyXYhL+BAQGFngL+JKb0Qn11mdj6kTkzm8IoGW4rics3KFDX dB48gnvVrng95AuRMxWL/3ys31lsmEX40N6tunvOg/Xr0I6dvaX6Uy2mSPnZF4ou Ma3lmSX6FXqAue6L4bB9rWXg4Xo+tZJK =5dZ1 -----END PGP SIGNATURE----- From owner-ipsec Tue Apr 22 13:13:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00212 for ipsec-outgoing; Tue, 22 Apr 1997 12:42:45 -0400 (EDT) Date: Tue, 22 Apr 97 14:36:02 GMT From: "William Allen Simpson" Message-ID: <5749.bsimpson@morningstar.com> To: Stephen Kent Cc: "ipsec@tis.com" Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry that you couldn't be there Steve, as the implementors meeting was the most useful of any IPSec meeting in recent memory. But, part of the problem seems to be that the "notes" sent to the list don't quite match my understanding of the decisions reached, and have little of the rationale that was voiced in the meeting. I thought that someone else was taking notes; could they send their writeup, instead? In my view, the result was that we have _finally_ returned to the packet formats and functionality agreed in Amsterdam in July 1993. We have come full circle. > From: Stephen Kent > Use of AH is not the same as use of ESP w/o encryption, precisely because > of the coverage issue, and the associated performance hit. (analysis omitted) > What I'm > hearing from this discussion is that the motivation for not offering ESP > w/o encryption is added complexity. I'm all in favor of reducing > complexity, if it doesn't cost functionality, but I'm really surprized to > hear that offering ESP w/o encryption is percieved as a significant > increase in complexity. > The verbal rationale that I remember was that the main use of AH would be for the tunnelling gateways that Moskowitz diagrammed, where you need to authenticate the IP addresses of the routers. This keeps the tunnel down to a single tunnel across the net. I remember Richardson giving us the same (single tunnel level) recommendation over a year ago. The orthogonal use of AH provides function that would not be available with ESP alone. And, it _also_ reduces complexity in implementation of ESP. You are correct, the implementors seemed quite taken with that idea.... :-) No rationale was given for the practical need for authentication-only ESP, and thus it was not chosen as an option. Is there any reason other than the minor performance gain that you mention, that cannot be handled by AH as it stands? > I assume you meat to say that ESP with authentication was useless, but I > have to disagree. I know folks who are sending packet voice and packet > video on an end-to-end basis. I recommend use of ESP w/o authentication in > this context. Here, the notes are simply wrong (by omission). The group agreed that ESP encryption without integrity needs an external AH _only_ where required for security! You are correct, and was elaborated by Bellovin's paper long ago, there are many instances where extra authentication for integrity is not required. As I recall, integrity is required for security _only_ when there are mutually hostile users on multi-user systems at both ends of the connection/path. These multi-user systems "know" that they require integrity, and can negotiate it appropriately. OTOH, a dialup user encrypting to a firewall (or even their target multi-user host) from a laptop would _not_ require added integrity. Big interactive RTT savings on a low speed link. > However, per-packet overhead is a big > concern here and thus stripping out everyting but the encryption support is > an important feature. Thus the flexibility offered by modular use of ESP > and AH is important to these folks and is in keeping with the original > intent of IPSEC. > Could you put that in the architecture for posterity? > I think the better argument is that AR counter inclusion makes alignment > "work" for AH in the IPv6 context, and in ESP this inclusion aligns the > start of the payload (assuming that we fold the IV into the payload) on an > 8-byte boundary as well, to facilitate crypto processing. Also, by always > sending this field, one simplifies packet parsing, by eliminating > variability. If these are the reasons for mandating inclusion of the AR > counter in every AH and ESP packet, then so be it, but at least lets agree > on a rationale that makes it clear what tradeoffs were considered in coming > to this conclusion. > Could you cite all of the above in the architecture for posterity? I will note that there were questions raised by several in the room about mandating the field in AH, as this would be a change in bits on the wire for older implementations. Perhaps someone could post their arguments here for the rest of the group. I don't think we had agreement on AH. Just ESP. > In general I propose that we remove the > IV as an explcit, optional field and fold it into the beginning of the > payload. The text will be modified to state this convention, noting that > each algorithm document must state the presence/absence of an IV (or a > sequence space pointer for some types of stream ciphers) and the size of > the IV. That way we can keep the ESP document simple and algorithm > independent. > Yes, that was my understanding of the agreement; please put that rationale in the ESP document. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Apr 22 15:44:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01331 for ipsec-outgoing; Tue, 22 Apr 1997 15:41:31 -0400 (EDT) Message-Id: <199704221942.PAA04915@relay.hq.tis.com> Date: Tue, 22 Apr 97 15:41:57 EDT From: Karen Seo To: ipsec@tis.com cc: skent@bbn.com, clynn@bbn.com, nyuan@bbn.com, kseo@bbn.com Subject: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, The text below discusses some IPSEC/PMTU/DF issues and the corresponding proposed changes to the IPSEC Architecture document. The initial section is the text we propose to include in the IPSEC Architecture document. That is followed by more detailed discussion/analysis which will be in an Appendix. The term "communication association" refers to the "connection" defined by source and destination addresses, transport protocol, source and destination ports, and user id. ICMP PMTU is used to refer to an ICMP message for: IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Thank you, IPSEC Document Editing Team ========================================================================= We propopse to add the following text to the IPSEC Architecture document re: Fragmentation and PMTU -- The analysis/discussion of these topics will be included in Appendix X to the Architecture document. 1. DF bit: In cases where a system (host or gateway) adds an encapsulating header (ESP or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix X for rationale.) 2. Fragmentation: Fragmentation MUST be done after outbound IPSEC processing and reassembly MUST be done before inbound IPSEC processing. (See Appendix X for analysis of how this is impacted by the location (where in the stack) of the IPSEC implementation.) (Footnote) Any IPSEC implementation that is not integrated into an IP implementation MUST support constructing any encapsulating IP headers and doing any necessary fragmentation and re-assembly. (See Appendix X for further discussion.) 3. Path MTU Discovery: The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix X for more detailed discussion of this topic.) A. If the ICMP PMTU message contains only 64 bits of the IPSEC header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host(s) can be determined, send the PMTU information to all the possible originating hosts. b. if the originating host(s) cannot be determined, store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host(s) . B. If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPSEC header -- ESP or AH transport, or ESP or AH tunnel. (See Appendix X for discussion of implementation issues.) In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix X for detailed discussion of this issue): a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PTMUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. ========================================================================= Appendix X -- Analysis/Discussion of PMTU/DF/Fragmentation Issues The legend for the diagrams is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Sx = socket x SGx = security gateway x X* = X supports IPSEC 1. DF bit -- In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. 2. Fragmentation -- Fragmentation MUST be done after outbound IPSEC processing. Reassembly MUST be done before inbound IPSEC processing. The general reasoning is shown below (delimited by the *******'s). NOTE: IPSEC always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPSEC and is intrinsic to the definition of IPSEC. Therefore any IPSEC implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer **************************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPSEC processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPSEC module in a given system's stack. There isn't an IPSEC module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPSEC module B. 2. There are several places where IPSEC could be implemented (as shown in the table above). a. Hosts with integration of IPSEC into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPSEC is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPSEC code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPSEC into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Prty,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Opt?ions Opt?ions Opt ? = AH covers Option-Type and Option-Length, but not Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPSEC processing, reassembles before inbound IPSEC processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and network drivers. In this case, the IPSEC module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPSEC module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPSEC would need to know the LAN interface and the next-hop gateway for the tunnel end. OR - pass the IPSEC'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPSEC module would have to check and let IPSEC'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPSEC has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPSEC into the IP stack NOTE: The IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works **************************************************************************** 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. A. The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose H0 sends a data packet to H5 via SG1 and SG2 and there is a security association between SG1 and SG2. SG1 maps the IPSEC selectors (source address, destination address, next protocol, source port, destination port) into a security association that defines the SPI, source and destination gateways, and how to process the packet. It determines that this packet should go through the IPSEC ESP (or AH) tunnel between SG1 and SG2. It then does the IPSEC processing needed for the SG1/SG2 hop and sends the packet -- adds encapsulating IP header with SRC = SG1, DEST = SG2 and adds ESP header before data packet and ESP trailer after. Now suppose R1 sends an ICMP PMTU to SG1. How does SG1 determine the PMTU selectors to use to return the ICMP message to the originating host (H1)? original after IPSEC ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), unknown (32 bits) -- could be the optional Replay counter but one can't be sure. - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPSEC header (minimum for IPv4), then the 5 original IPSEC selectors will have been lost -- Source and Destination addresses, Next Protocol, Source and Destination ports. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one host. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B. The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPSEC header by H1 -- ESP or AH transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. The diagram below illustrates several possible combinations of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = transport mode) Socket 1 ----------------------------------------------- I | n Socket 2 (ESPt/SPI-A) ------------------------------- | t \ | e Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r / n Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e t In order to figure out the PMTU for each socket that maps to SPI-E, it will be necessary to have backpointers from SPI-E to each of the 4 paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H. C. In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues: a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPSEC implementation in H1 can store/update the PMTU for the associated socket. In cases (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly ToS, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPSEC processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly ToS. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. D. Implementation of the calculation of PMTU (B) and support for PTMUs at the granularity of individual "communication association s" (C) is a local matter. However, a socket-based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. E. The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). F. In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) has to be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. From owner-ipsec Tue Apr 22 16:49:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01843 for ipsec-outgoing; Tue, 22 Apr 1997 16:42:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5749.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 16:26:42 -0400 To: "William Allen Simpson" From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, NIce to hear from you again. Here are some responses to your comments: >> Use of AH is not the same as use of ESP w/o encryption, precisely because >> of the coverage issue, and the associated performance hit. >(analysis omitted) >> What I'm >> hearing from this discussion is that the motivation for not offering ESP >> w/o encryption is added complexity. I'm all in favor of reducing >> complexity, if it doesn't cost functionality, but I'm really surprized to >> hear that offering ESP w/o encryption is percieved as a significant >> increase in complexity. >> >The verbal rationale that I remember was that the main use of AH would >be for the tunnelling gateways that Moskowitz diagrammed, where you need >to authenticate the IP addresses of the routers. This keeps the tunnel >down to a single tunnel across the net. I remember Richardson giving us >the same (single tunnel level) recommendation over a year ago. It's good to see an exmaple of the rationale behind the proposal. In general, if I am tunneling traffic between two security gateways, why do I need to protect the outer IP header? Would I not generally discard it upon arrival? The inner IP header is the real focus of protection. There is no reason why I cannot multiplex the same scope of traffic in a tunnel with ESP as I can with an AH tunnel, so I don't view that as a differentiator. >The orthogonal use of AH provides function that would not be available >with ESP alone. > >And, it _also_ reduces complexity in implementation of ESP. You are >correct, the implementors seemed quite taken with that idea.... :-) > >No rationale was given for the practical need for authentication-only >ESP, and thus it was not chosen as an option. Is there any reason other >than the minor performance gain that you mention, that cannot be handled >by AH as it stands? I guess I look at the question from the opposite perspective: if all I need is provided by an authentication-only ESP, why pay any additional performance penalty by requiring AH? I remember when ESP had no authentication transforms and one had to use AH in conjunction with ESP to achieve both sets of services. I was among those who argued for autehntication/integrity features for ESP precisely to avoid the overhead of using AH. I like the logical completeness of having ESP be modular, allowing selected subsets of security services to be applied to payloads in a clean, encapsulated fashion. >> I assume you meat to say that ESP with authentication was useless, but I >> have to disagree. I know folks who are sending packet voice and packet >> video on an end-to-end basis. I recommend use of ESP w/o authentication in >> this context. > >Here, the notes are simply wrong (by omission). The group agreed that >ESP encryption without integrity needs an external AH _only_ where >required for security! > >You are correct, and was elaborated by Bellovin's paper long ago, there >are many instances where extra authentication for integrity is not >required. > >As I recall, integrity is required for security _only_ when there are >mutually hostile users on multi-user systems at both ends of the >connection/path. These multi-user systems "know" that they require >integrity, and can negotiate it appropriately. > >OTOH, a dialup user encrypting to a firewall (or even their target >multi-user host) from a laptop would _not_ require added integrity. Big >interactive RTT savings on a low speed link. Glad to see we agree here! >> However, per-packet overhead is a big >> concern here and thus stripping out everyting but the encryption support is >> an important feature. Thus the flexibility offered by modular use of ESP >> and AH is important to these folks and is in keeping with the original >> intent of IPSEC. >> >Could you put that in the architecture for posterity? Yes, I'll make sure that the architecture document captures the rationale that motivates the various combinations of AH and ESP use, etc. >> I think the better argument is that AR counter inclusion makes alignment >> "work" for AH in the IPv6 context, and in ESP this inclusion aligns the >> start of the payload (assuming that we fold the IV into the payload) on an >> 8-byte boundary as well, to facilitate crypto processing. Also, by always >> sending this field, one simplifies packet parsing, by eliminating >> variability. If these are the reasons for mandating inclusion of the AR >> counter in every AH and ESP packet, then so be it, but at least lets agree >> on a rationale that makes it clear what tradeoffs were considered in coming >> to this conclusion. >> >Could you cite all of the above in the architecture for posterity? If we decide to mandate inclusion of the AR counter, then rest assured that the AH and ESP documents will cite the rationale for this, since inclusion of a field that might not be used by the receiver demands an explanation! >I will note that there were questions raised by several in the room >about mandating the field in AH, as this would be a change in bits on >the wire for older implementations. Perhaps someone could post their >arguments here for the rest of the group. > >I don't think we had agreement on AH. Just ESP. I'm asking these questions precisely to clairfy the minutes and make sure that the WG as a whole, not just those attending the most recent meeting, understand what is being proposed and why. >> In general I propose that we remove the >> IV as an explcit, optional field and fold it into the beginning of the >> payload. The text will be modified to state this convention, noting that >> each algorithm document must state the presence/absence of an IV (or a >> sequence space pointer for some types of stream ciphers) and the size of >> the IV. That way we can keep the ESP document simple and algorithm >> independent. >> >Yes, that was my understanding of the agreement; please put that >rationale in the ESP document. Will do. From owner-ipsec Tue Apr 22 16:49:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01849 for ipsec-outgoing; Tue, 22 Apr 1997 16:43:04 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704221509.LAA19920@amaterasu.sandelman.ottawa.on.ca> References: Your message of "Mon, 21 Apr 1997 17:29:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 16:42:46 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, >>>>>> "Stephen" == Stephen Kent writes: > Stephen> consuming task. My guess is that use of ESP in tunnel > Stephen> mode will be popular, with one end of the SA at a > Stephen> firewall. Under those circumstances, AH in tunnel mode > Stephen> does not buy one much, because the outer header is not > Stephen> very interesting, i.e., it will be discarded. (Only > Stephen> rarely would it make sense to copy portions of it into an > Stephen> inner header.) Thus tunnel mode ESP would provide > Stephen> suitable protection for traffic with greater efficiency > Stephen> and less per-packet overhead. What I'm hearing from this > Stephen> discussion is that the motivation for not offering ESP > Stephen> w/o encryption is added complexity. I'm all in favor of > > As long as you are optimizing in favour of the VPN application, then >let's be explicit and do that. > The reason why ESP without encryption is not interesting is because >the P in VPN means private. If there comes to exist a strong >encrypting transform with built in integrity, VPN people will want >that. Well, many systems that claim to provide virtual private nets do so without confidentiality. The closed user group facility in X.25 and frame relay nets, the analogous facility in ATM nets, and similar soft configuration options in switched ethernets are all cited as bases for VPNs. Today, we rely on firewalls to provide access control at the perimeter of local/campus nets. However, we do so with authentictaion of traffic sources, or we sdo so based on bind time (vs. continuous) authentication. So, using IPSEC to authenticate traffic provides a solid basis for making the same access control decision, a noticeable improvement. We will not always want to provide confidentiality for traffic at the firewall boundary. For example, the traffic might be encrypted to the desktop or server behind the firewall, so the extra layer of encryption might be seen as unnecessary and an unwarrented performence hit. Higher layer encryption might be employed, e.g., for e-mail, and here too layer 3 encryption may be deemed redundant and not worth the cost. So, a flexible architectuire should allow for SAs that terminate at a firewall and provide just authentication . The debatem then, is whether it's better to provide this service using ESP in tunnel mode or AH in tunnel mode. > Stephen> reducing complexity, if it doesn't cost functionality, > Stephen> but I'm really surprized to hear that offering ESP w/o > Stephen> encryption is percieved as a significant increase in > Stephen> complexity. > > We know AH is complex. Fine. AH isn't interesting for VPN >applications. Fine. > Let's allow a VPN-only to deal with lower complexity, and do only >what it needs to do. That means it might not do AH. It will encrypt. > I realize that is in oposition to the IPv6 MUST implement (AH, but >not ESP). An encryption-less ESP could then become a MUST implement >for IPv6. > Remember: fewer options == interoperability. Yes, fewer options does increase the likelihood of interoperability. But, as my comments describe above, there are valid reasons for authentication-only tunnels in firewalls. So far we don't have v4 compliance reuqirements re AH and ESP, but we will need to address that issue later, e.g., must one implement both to claim "IPSEC compliance?" The architecture document can address this issue. > Stephen> support is an important feature. Thus the flexibility > Stephen> offered by modular use of ESP and AH is important to > Stephen> these folks and is in keeping with the original intent of > Stephen> IPSEC. > > Authentication-less ESP was left as an option. I'm not sure I >completely agree that audio data is not that sensitive to integrity >problems, but I see your point. You have provided a motivation for >continuing to include authentication-less ESP. I'm not convinced that >if you are encrypting, that authentication costs that much more: The meeting minutes suggested that ESP must always be used with authentication, either intrinsic to ESP or via a separate AH, hence my concern and an example of why I felt such a requirement would be unduly restrictive. Authentication costs more in packet processing time, and especially in space for the small packets that characterize compressed audio. We've been sending packet voice around the Internet in experimental implementations for well over 15 years. The folks at Lincoln Labs have been pioneers in this area, in DoD-sponsored work. Their continuing activities motivated my comments about authenticationless-ESP. Steve From owner-ipsec Tue Apr 22 17:12:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02158 for ipsec-outgoing; Tue, 22 Apr 1997 17:11:54 -0400 (EDT) Message-Id: <199704222025.QAA01680@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "William Allen Simpson" Cc: Stephen Kent , "ipsec@tis.com" Subject: Re: notes from developer's portion of IETF meeting In-Reply-To: bsimpson's message of Tue, 22 Apr 1997 14:36:02 +0000. <5749.bsimpson@morningstar.com> Date: Tue, 22 Apr 1997 16:25:48 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > As I recall, integrity is required for security _only_ when there are > mutually hostile users ... One terminology nit: I say "mutually suspicious" rather than "mutually hostile", as actual hostility is not required, merely suspicion that the other guys are, or may become, hostile.. > ... on multi-user systems at both ends of the > connection/path. These multi-user systems "know" that they require > integrity, and can negotiate it appropriately. This is true only if you consider an encrypting router fronting for multiple mutually suspicious end users to be a multi-user system. > OTOH, a dialup user encrypting to a firewall (or even their target > multi-user host) from a laptop would _not_ require added integrity. Big > interactive RTT savings on a low speed link. This is simply not true if the firewall is fronting for mutually suspicious users. This may seem improbable, but I know of sites where (for historical reasons) two different organizations sharing a building also share a large chunk of the network infrastructure.. Here's a very specific, concrete example, of a case where lack of integrity leads to lack of confidentiality. A / C =====M==== GW \ B assume a pair of ESP SA's between C and GW (one in each direction) so there's a single key in use in each direction between C and GW; assume also that the encryption in question is a block cipher in CBC mode. assume that B can't tap the A-GW link because it's physically secure, but wants to spy on A->C traffic; it also has a wiretap/traffic injection point at M, where it can inject arbitrary messages into the network. assume C runs an ICMP echo service. B sends a large ICMP echo request packet to C, and captures the encrypted form of the packet at M. so, what it has is: IV ciphertext of B->C ICMP header ciphertext of B->C ICMP data ciphertext of pad (at least one full block's worth) ciphertext of B->C ESP trailer B also captures traffic it wants decrypted. it then constructs a packet of the form: IV ciphertext of B->C ICMP header IV of the A->C message <---+-- same length as ciphertext from A->C message <---+ ICMP data above ciphertext of pad ciphertext of B->C ESP trailer Because of the properties of CBC-mode ciphers, C will receive an ICMP packet with a valid header, a garbled data block corresponding to the A->C IV, the plaintext of a sequence of blocks from A->C message, another garbled block (conveniently located in the middle of the padding) and then a valid ESP trailer. C will then promply return the decrypted plaintext to B in an ICMP echo reply. One might think that the icmp checksum might get in the way, but there's at least one way around this which only adds a work factor of 2**16-1: B can construct echo packets with all 2**16-1 possible checksums, and try all of them; C returns the one for which the checksum matches. Tapping the C->A traffic is even easier: pull the encrypted packets at M, substitute the ciphertext into the middle of the encrypted ICMP reply from C to B, and send them (again) to GW; B simply "forgets" to check the ICMP checksum on reciept. - Bill From owner-ipsec Tue Apr 22 17:54:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02512 for ipsec-outgoing; Tue, 22 Apr 1997 17:53:23 -0400 (EDT) Date: Tue, 22 Apr 1997 17:56:06 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704222156.RAA12940@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199704222101.OAA01764@baskerville.CS.Arizona.EDU> Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Authonly ESP seems both simple and useful, to me. And the performance penalty due to AH header handling might turn out to be the limiting factor at high speeds. RE the recollection: >As I recall, integrity is required for security _only_ when there are >mutually hostile users on multi-user systems at both ends of the >connection/path. These multi-user systems "know" that they require >integrity, and can negotiate it appropriately. This idea has always puzzled me. Surely block ciphers without some kind of integrity are insecure in any active attack environment. Hilarie From owner-ipsec Tue Apr 22 18:13:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02590 for ipsec-outgoing; Tue, 22 Apr 1997 18:13:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704222025.QAA01680@thunk.ch.apollo.hp.com> References: bsimpson's message of Tue, 22 Apr 1997 14:36:02 +0000. <5749.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 18:18:44 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You provide a good example of how to exploit a tunnel mode use of ESP w/o integrity. I would note that it does require a confluence of wiretap capabilities that often will not be easy to attain, in conjunction with other wiretap capabilities not being available. Specificlally, the lack of a local passive wiretap ability in conjunction with an active and passive remote capability may seem odd in many circumstances, although it certainly is possible in others. However, in a transport mode environment, not involving multi-user end systems, ESP w/o authentication seems very reasonable. In tunnel mode with a firewall at one end, whether this form of ESP is OK depends on one's threat model. We could be very cautious and have the architectrure document prohibit such use, or we could have that document merely warn users (system administrators) about the pitfalls of such use. Steve From owner-ipsec Tue Apr 22 19:34:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02937 for ipsec-outgoing; Tue, 22 Apr 1997 19:32:34 -0400 (EDT) Date: Tue, 22 Apr 1997 16:38:47 -0700 From: David Wagner Message-Id: <199704222338.QAA11325@joseph.cs.berkeley.edu> To: kent@bbn.com, ipsec@ex.tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk kent@bbn.com writes: > The meeting minutes suggested that ESP must always be used with > authentication, either intrinsic to ESP or via a separate AH, hence my > concern and an example of why I felt such a requirement would be unduly > restrictive. Authentication costs more in packet processing time, and > especially in space for the small packets that characterize compressed > audio. Now that I read this paragraph, I know how to phrase my objection more clearly. If packet voice folks are worried about the performance hit from the extra couple of words of overhead for AH, they shouldn't be using ipsec; they should be using some higher-level application-level authentication, which lets them do all sorts of application-specific optimizations (e.g. MACing entire kilobytes at a time). (By the way, typically authentication should require significantly less CPU time than encryption -- at least in my limited experience, though I admit I haven't written any ipsec code in two years.) We dare not carve a hole out of ipsec for each special-purpose group who wants their own optimization. The great value of ipsec is in its robustness across the great diversity of internet applications. An authentication-less ESP detracts from ipsec robustness, and I think that's bad for everyone. All IMHO, of course. -- Dave From owner-ipsec Tue Apr 22 19:59:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03065 for ipsec-outgoing; Tue, 22 Apr 1997 19:59:10 -0400 (EDT) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: notes from developer's portion of IETF meeting Date: 22 Apr 1997 17:05:17 -0700 Organization: ISAAC Group, UC Berkeley Lines: 38 Message-ID: <5jjjnt$b31@joseph.cs.berkeley.edu> References: <199704222101.OAA01764@baskerville.CS.Arizona.EDU> <199704222156.RAA12940@earth.hpc.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <199704222156.RAA12940@earth.hpc.org>, Hilarie Orman wrote: > >As I recall, integrity is required for security _only_ when there are > >mutually hostile users on multi-user systems at both ends of the > >connection/path. These multi-user systems "know" that they require > >integrity, and can negotiate it appropriately. > > This idea has always puzzled me. Surely block ciphers without some kind of > integrity are insecure in any active attack environment. Well, yes, I think that's roughly the case, in practice. Bellovin's cut-and-paste attack shows that block ciphers aren't secure against chosen-ciphertext attacks (where the attacker gets the target to release the decryption of a stretch of attacker-chosen ciphertext). Multi-user systems (with host-pair keying) are one practical environment where chosen-ciphertext queries can be mounted; but there are others, too. For instance, imagine: a mail message comes in over the ipsec-encrypted link A->B; B's sendmail forwards the message to C; host C doesn't do ipsec, and so the message is sent unencrypted on the B->C link. B's sendmail is letting A mount a chosen-ciphertext query; now A can cut-and-paste ciphertext from B's other ipsec connections to get them decrypted. This is an instance of application-layer forwarding. Also, short-block attacks work even against single-user machines. Of course, the proper immunization against chosen-ciphertext attacks is authentication of the ciphertexts. This is just a robustness argument: if you're using encryption in an active attack environment, I say you'd better authenticate the connection too, or you may very well be subject to pernicious, subtle, and unanticipated attacks. Let's learn from earlier mistakes, and be extremely wary of integrity-less encryption transforms. From owner-ipsec Wed Apr 23 07:34:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06556 for ipsec-outgoing; Wed, 23 Apr 1997 07:33:19 -0400 (EDT) Date: Tue, 22 Apr 1997 20:30:45 -0700 (PDT) From: Jan Vilhuber To: David Wagner cc: kent@bbn.com, ipsec@ex.tis.com Subject: Re: notes from developer's portion of IETF meeting In-Reply-To: <199704222338.QAA11325@joseph.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Er... I must be missing something. I apologize if this is wrong, or has been mentioned (or if I'm misunderstanding something), but weren't there some serious security flaws in ESP without Authentication (AH)? See Belovin's paper. I've heard that ESP by nature now includes an authentication to cover those cases. Is that what is being discussed here? I MUST be missing something.. jan On Tue, 22 Apr 1997, David Wagner wrote: > kent@bbn.com writes: > > The meeting minutes suggested that ESP must always be used with > > authentication, either intrinsic to ESP or via a separate AH, hence my > > concern and an example of why I felt such a requirement would be unduly > > restrictive. Authentication costs more in packet processing time, and > > especially in space for the small packets that characterize compressed > > audio. > > Now that I read this paragraph, I know how to phrase my objection > more clearly. > > If packet voice folks are worried about the performance hit from > the extra couple of words of overhead for AH, they shouldn't be using > ipsec; they should be using some higher-level application-level > authentication, which lets them do all sorts of application-specific > optimizations (e.g. MACing entire kilobytes at a time). > > (By the way, typically authentication should require significantly > less CPU time than encryption -- at least in my limited experience, > though I admit I haven't written any ipsec code in two years.) > > We dare not carve a hole out of ipsec for each special-purpose group > who wants their own optimization. The great value of ipsec is in its > robustness across the great diversity of internet applications. An > authentication-less ESP detracts from ipsec robustness, and I think > that's bad for everyone. > > All IMHO, of course. -- Dave > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec Wed Apr 23 08:27:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06795 for ipsec-outgoing; Wed, 23 Apr 1997 08:27:01 -0400 (EDT) Message-Id: <2.2.32.19970423121920.006e7a08@wasted.zk3.dec.com> X-Sender: ewong@wasted.zk3.dec.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Apr 1997 08:19:20 -0400 To: Stephen Kent From: "Eric L. Wong" Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > ......... We could be very cautious and have the architectrure >document prohibit such use, or we could have that document merely warn >users (system administrators) about the pitfalls of such use. > I think these should be mentioned in the document. It also brings up the issue of 'policy' of enforcing security. After all, it is a policy thing. /eric From owner-ipsec Wed Apr 23 12:00:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08331 for ipsec-outgoing; Wed, 23 Apr 1997 11:55:43 -0400 (EDT) Date: Wed, 23 Apr 1997 19:01:22 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704231601.TAA13455@ee.technion.ac.il> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk I am worried about this (revived) integrity-less encryption mood. It does not make sense to justify this approach under the argument that in some circumstances some particular attack (e.g. Bellovin's) will not work. Even if not said explicitly most of the arguments are based on the never-to-disappear illusions on the (pseudo) integrity properties inherent to CBC mode (would anyone suggest integrity-less encryption using a stream cipher?). It is time to abandon such illusions. The only people that can use integrity-less security are those that DO NOT CARE about their traffic being changed in route and do not care about chosen ciphertext attacks. If there are applications that consciously decide to take all these risks I suggest they negotiate the EMPTY-MAC as their authentication algorithm (no processing penalty) rather than having ipsec explictly allowing integrity-less IP security. As for computation time we keep seeing MAC algorithms getting much faster than encryption algorithms (although the effeect on ipsec processing speed of these faster algorithms is not entirely clear). Hugo From owner-ipsec Wed Apr 23 12:43:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08617 for ipsec-outgoing; Wed, 23 Apr 1997 12:43:31 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704231646.JAA25014@kebe.eng.sun.com> Subject: Re: notes from developer's portion of IETF meeting To: hugo@ee.technion.ac.il (Hugo Krawczyk) Date: Wed, 23 Apr 1997 09:46:36 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199704231601.TAA13455@ee.technion.ac.il> from "Hugo Krawczyk" at Apr 23, 97 07:01:22 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 It's kinda interesting watching this discussion. The _only_ reason integrity-less encryption is still allowed is because AH+ESP(transport) is a valid and useful combination. I'll bet small sums of money that AH+ESP(transport) was probably an original suggestion to solve Steve Bellovin's [Bel96] cut-and-paste attacks. I'm not sure why the two-algorithms-in-one-SA approach was ever adopted, but it's too late to argue these questions. Auth-less ESP is dangerous for the very reasons documented both here on the mailing list and in [Bel96]. We all know that, and it's nice to see the reasons being brought up here. It helps any newbies out there, as well as remind us implementors what to watch out for. BTW, I can see an ESP module issuing a warning or logging a danger sign that an auth-less ESP SA has been added. It could even say so again if such an SA is actually being USED. Dan From owner-ipsec Wed Apr 23 12:57:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08746 for ipsec-outgoing; Wed, 23 Apr 1997 12:57:38 -0400 (EDT) Date: Wed, 23 Apr 1997 13:00:19 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704231700.NAA17206@earth.hpc.org> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Block ciphers like DES without integrity are intensely vulnerable to active attacks, for any kind of machine, and in more ways than have been described on this list. Block splicing based on captured ciphertext with known plaintext allows the attacker great latitude for inserting bogus traffic with only minimal integrity violations. The last block attack shows how you can use this general technique even without knowing all the plaintext, and traffic modification poses yet another problem. Weak integrity checks in the application are an illusionary defense. I'd thought the goal of the group was to protect the Internet environment, i.e. an active attack environment. Thus, it seems to me that leaving integrity as an administrator option is contrary to the charter of the group. The conditions for safely dispensing with integrity are very narrow, i.e. one of 1. Physical impossibility of active attacks (NB analysis must be end-to-end) 2. Encryption method has strong internal integrity (not DES) 3. Connection limited to use by applications with strong internal integrity 4. Attacker can never know or guess ciphertext/plaintext pairs from observed traffic I am hesitant to leave this analysis to the system administrator; item 1 might arguably be an administrator decision, being highly environmental, but are these environments of concern to the Internet? Depending on implementations, the ratio of MD5 speed to DES speed can be between 3 to 1 and 10 to 1*, according to my notes, so integrity should not be eliminated based on performance considerations. However, the time to transmit 128 bytes on a slow connection is considerable and especially annoying if the data is shorter than the checksum, so that I can well understand the reluctance to include the it. Nonetheless, it seems very unlikely to me that a risk analysis would show that elimination of integrity was a winning trade-off, even at low speeds. Hilarie * ratios reported outside this range may depend on cache effects or byte reordering subtleties From owner-ipsec Wed Apr 23 14:42:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09611 for ipsec-outgoing; Wed, 23 Apr 1997 14:41:39 -0400 (EDT) Message-Id: <97Apr23.144337edt.11650@janus.border.com> To: Thomas Narten cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt References: <9704181331.AA15062@cichlid.raleigh.ibm.com> In-reply-to: narten's message of "Fri, 18 Apr 1997 08:31:20 -0400". <9704181331.AA15062@cichlid.raleigh.ibm.com> From: "C. Harald Koch" Date: Wed, 23 Apr 1997 14:47:40 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704181331.AA15062@cichlid.raleigh.ibm.com>, Thomas Narten writes: > I also agree, and have been disheartened by the number of times the > above question has been asked but not answered. Indeed, it has been > my impression that the vast majority of IP packets are delivered in > order (one reason why TCP's header prediction works well in > practice). It is rare in practice to have packets arrive out of > order. Which begs the question of whether a window is even > needed. Does someone have data that argues otherwise? Two sample points, my internet firewalls (A good place to look, since they re-synthesize all TCP streams in/out. This is roughly akin to combining the statistics for all 100 hosts behind the firewalls...). ----- elgreco ----- 2:39pm up 11 days, 4:51, 1 user, load average: 0.25, 0.16, 0.05 5796665 packets received 2703533 acks (for 1066489852 bytes) 3301088 packets (900448165 bytes) received in-sequence 107878 completely duplicate packets (10966707 bytes) 987 packets with some dup. data (122695 bytes duped) 198927 out-of-order packets (40226774 bytes) ----- janus ----- 2:38pm up 11 days, 4:52, 1 user, load average: 0.02, 0.06, 0.02 28417190 packets received 19533317 acks (for 371944057 bytes) 21278080 packets (176197867 bytes) received in-sequence 51170 completely duplicate packets (12418673 bytes) 519 packets with some dup. data (63691 bytes duped) 199859 out-of-order packets (69912188 bytes) That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets received out-of-order. I wouldn't define that as "rare", especially given the (additional) performance penalties for dropping them instead of queueing them. -- Harald Koch From owner-ipsec Wed Apr 23 15:04:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09829 for ipsec-outgoing; Wed, 23 Apr 1997 15:03:49 -0400 (EDT) Message-ID: <01BC4FDF.39536800@Tastid.cisco.com> From: Rob Adams To: "ipsec@tis.com" , "'Hilarie Orman'" Subject: RE: notes from developer's portion of IETF meeting Date: Wed, 23 Apr 1997 12:09:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thank you Hugo, Dan, and Hilarie for stating clearly why the group at the IETF chose to make integrity mandatory. Btw, Dan, I think you're correct in stating why we are still having this discussion and where it came from in the first place.. At any rate, if MAC is optional for ESP, I think you'll be seeing a lot of implementations that don't allow the negotiation of a MACless ESP, or force policy to include a MAC algorithm with any ESP policy... %) As for optional encryption... I still think, if you don't want encryption you should use AH. I don't really buy the argument that processing the headers takes that more processing time. Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will do 174 Mbytes a second on a 33MHz 486SX... so that means that your average 1500 byte packet, assuming 1/3 is headers (being very conservative) would... oh well, you can do the math... Looks like it doesn't add a noticable overhead per packet to me... And probably over the course of the exchange will get lost in the noise... So, can we agree? Optional integrity for ESP? No.? yes...? I'd say no. Optional confidentiality for ESP? I'd also say no. How 'bout other people? -Rob ---------- From: Hilarie Orman[SMTP:ho@earth.hpc.org] Sent: Wednesday, April 23, 1997 10:00 AM To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Block ciphers like DES without integrity are intensely vulnerable to active attacks, for any kind of machine, and in more ways than have been described on this list. Block splicing based on captured ciphertext with known plaintext allows the attacker great latitude for inserting bogus traffic with only minimal integrity violations. The last block attack shows how you can use this general technique even without knowing all the plaintext, and traffic modification poses yet another problem. Weak integrity checks in the application are an illusionary defense. I'd thought the goal of the group was to protect the Internet environment, i.e. an active attack environment. Thus, it seems to me that leaving integrity as an administrator option is contrary to the charter of the group. The conditions for safely dispensing with integrity are very narrow, i.e. one of 1. Physical impossibility of active attacks (NB analysis must be end-to-end) 2. Encryption method has strong internal integrity (not DES) 3. Connection limited to use by applications with strong internal integrity 4. Attacker can never know or guess ciphertext/plaintext pairs from observed traffic I am hesitant to leave this analysis to the system administrator; item 1 might arguably be an administrator decision, being highly environmental, but are these environments of concern to the Internet? Depending on implementations, the ratio of MD5 speed to DES speed can be between 3 to 1 and 10 to 1*, according to my notes, so integrity should not be eliminated based on performance considerations. However, the time to transmit 128 bytes on a slow connection is considerable and especially annoying if the data is shorter than the checksum, so that I can well understand the reluctance to include the it. Nonetheless, it seems very unlikely to me that a risk analysis would show that elimination of integrity was a winning trade-off, even at low speeds. Hilarie * ratios reported outside this range may depend on cache effects or byte reordering subtleties From owner-ipsec Wed Apr 23 15:53:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10264 for ipsec-outgoing; Wed, 23 Apr 1997 15:52:17 -0400 (EDT) Message-Id: <9704231957.AA16928@cichlid.raleigh.ibm.com> To: "C. Harald Koch" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Wed, 23 Apr 1997 14:47:40 EDT." <97Apr23.144337edt.11650@janus.border.com> Date: Wed, 23 Apr 1997 15:57:13 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk > That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets > received out-of-order. I wouldn't define that as "rare", especially given the > (additional) performance penalties for dropping them instead of queueing them. Are these "netstat -s" numbers that come from a BSD-derived TCP stack? If so, I believe that numbers like: 198927 out-of-order packets (40226774 bytes) also include TCP segments that arrive *after* a packet loss, i.e., they are out of order in the sense that they aren't the packet TCP expects to see next. However, they aren't out of order in the sense that the missing packet will arrive later due to reordering by the network. More likely, the missing segment was lost and needs to be retransmitted. So unless I'm mistaken about what this stat means, I don't think it counts the right quantity (unfortunately). Thomas From owner-ipsec Wed Apr 23 15:55:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10302 for ipsec-outgoing; Wed, 23 Apr 1997 15:55:22 -0400 (EDT) Date: Wed, 23 Apr 1997 15:58:01 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704231958.PAA22586@earth.hpc.org> To: adams@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704231915.MAA15719@baskerville.CS.Arizona.EDU> Subject: RE: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk > Btw, Dan, I think you're correct in stating why we are still > having this discussion and where it came from in the first place.. Not the way I remember it, but having followed this discussion for so many years is nothing to be bragged about. > Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will > do 174 Mbytes a second on a 33MHz 486SX... Ridiculous by a factor of 100. Note the spelling of snefru for an indication of the dedication to accuracy in that table. > Optional integrity for ESP? No.? yes...? I'd say no. Well, for AH+ESP, my numbers indicate that would be a 10% to 30% penalty, besides the bytes for the extra checksum. A sort of heavy penalty for authenticating the header. All I'm saying is that you must have SOME integrity, not that you need it twice. > Optional confidentiality for ESP? I'd also say no. Unless you've got AH with it. Why not use AH instead? Because, it may well turn out that at high speeds (> OC-3), AH will have regrettable performance no overwhelming benefit. Hilarie From owner-ipsec Wed Apr 23 16:44:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10702 for ipsec-outgoing; Wed, 23 Apr 1997 16:43:53 -0400 (EDT) Date: Wed, 23 Apr 1997 16:49:33 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: "C. Harald Koch" cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: <97Apr23.144337edt.11650@janus.border.com> Message-Id: <97Apr23.164528edt.11656@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 23 Apr 1997, C. Harald Koch wrote: > In message <9704181331.AA15062@cichlid.raleigh.ibm.com>, Thomas Narten writes: > > I also agree, and have been disheartened by the number of times the > > above question has been asked but not answered. Indeed, it has been > > my impression that the vast majority of IP packets are delivered in > > order (one reason why TCP's header prediction works well in > > practice). It is rare in practice to have packets arrive out of > > order. Which begs the question of whether a window is even > > needed. Does someone have data that argues otherwise? > > Two sample points, my internet firewalls (A good place to look, since they > re-synthesize all TCP streams in/out. This is roughly akin to combining the > statistics for all 100 hosts behind the firewalls...). > > ----- elgreco ----- > 2:39pm up 11 days, 4:51, 1 user, load average: 0.25, 0.16, 0.05 > > 5796665 packets received > 2703533 acks (for 1066489852 bytes) > 3301088 packets (900448165 bytes) received in-sequence > 107878 completely duplicate packets (10966707 bytes) > 987 packets with some dup. data (122695 bytes duped) > 198927 out-of-order packets (40226774 bytes) > > > ----- janus ----- > 2:38pm up 11 days, 4:52, 1 user, load average: 0.02, 0.06, 0.02 > > 28417190 packets received > 19533317 acks (for 371944057 bytes) > 21278080 packets (176197867 bytes) received in-sequence > 51170 completely duplicate packets (12418673 bytes) > 519 packets with some dup. data (63691 bytes duped) > 199859 out-of-order packets (69912188 bytes) > > > That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets > received out-of-order. I wouldn't define that as "rare", especially given the > (additional) performance penalties for dropping them instead of queueing them. This is interesting data, but I think the percentages were miscalculated. Apparently the formula used was out-of-order/(total - acks). But note that acks + in-sequence > total, so it seems that acks includes all acks, isolated and piggy-backed. I'm not sure exactly how all the statistics fit together, but using a conservative formula that considers everything except isolated acks out-of-order/(in-sequence + duplicates + out-of-order) gives 5.5% on elgreco and 0.9% on janus. These proportions are too high to ignore. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Wed Apr 23 17:00:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10797 for ipsec-outgoing; Wed, 23 Apr 1997 16:59:02 -0400 (EDT) Date: Wed, 23 Apr 1997 17:03:34 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Hilarie Orman cc: ipsec@tis.com Subject: RE: notes from developer's portion of IETF meeting In-Reply-To: <199704231958.PAA22586@earth.hpc.org> Message-Id: <97Apr23.170023edt.11654@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 23 Apr 1997, Hilarie Orman wrote: > > Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will > > do 174 Mbytes a second on a 33MHz 486SX... > > Ridiculous by a factor of 100. Note the spelling of snefru for an > indication of the dedication to accuracy in that table. The column mislabeled Encryption Speed is in KB/sec. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Wed Apr 23 22:07:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA12396 for ipsec-outgoing; Wed, 23 Apr 1997 22:05:50 -0400 (EDT) Message-Id: <3.0.1.32.19970423215014.006b724c@alphy.lkg.dec.com> X-Sender: altamatt@alphy.lkg.dec.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 23 Apr 1997 21:50:14 -0400 To: Rob Adams From: Matt Thomas Subject: RE: notes from developer's portion of IETF meeting Cc: ipsec@tis.com In-Reply-To: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Optional integrity for ESP? No.? yes...? I'd say no. I was one of ones arguing for option integrity for ESP. Why? Because Mobile-IPv6 requires authentication of the entire packet (especially the routing and/or destination option headers) I didn't want to have to do an AH and then integrity again for ESP. However I did think of an alternative after the meeting (and since this topic has been reopened...): Define AH such if AH and ESP are in the same packet but are not separated by an IPv4 or IPv6 header (ie. not tunnelled), define the AH such that it stops after the first 12 bytes of ESP header. If this was the case, I would not mind having ESP always include integrity since I would be not doing integrity twice over the entire packet. >Optional confidentiality for ESP? I'd also say no. Agreed. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Apr 24 07:47:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15451 for ipsec-outgoing; Thu, 24 Apr 1997 07:46:00 -0400 (EDT) From: Uwe Ellermann Date: Thu, 24 Apr 1997 09:12:33 +0200 (MET DST) Message-Id: <199704240712.JAA03901@wave.fwl.dfn.de> To: ipsec@tis.com, ho@earth.hpc.org, adams@cisco.com Subject: RE: notes from developer's portion of IETF meeting X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Optional integrity for ESP? No.? yes...? I'd say no. Considering a VPN scenario using tunnel-mode ESP, mandatory integrity for ESP wouldn't gain much more security, iff all tunneled IP packets are already required to use AH by the site's policy. It should be possible to save the additional overhead of applying integrity mechanisms twice (ie. AH and ESP) on the same data. Greetings, Uwe Ellermann -- Uwe Ellermann, Ellermann@fwl.dfn.de, Tel.:+49-40-5494-2262, Fax: -2241 DFN-FWL, University of Hamburg, Vogt-Koelln-Strasse 30, D-22527 Hamburg PGP-key available via http://www.cert.dfn.de/~ue/pgp.html or Keyserver From owner-ipsec Thu Apr 24 17:08:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA19366 for ipsec-outgoing; Thu, 24 Apr 1997 17:02:29 -0400 (EDT) Message-Id: <199704242108.RAA21948@codex.cis.upenn.edu> To: Uwe Ellermann cc: ipsec@tis.com, ho@earth.hpc.org, adams@cisco.com Subject: Re: notes from developer's portion of IETF meeting In-reply-to: Your message of "Thu, 24 Apr 1997 09:12:33 +0200." <199704240712.JAA03901@wave.fwl.dfn.de> Date: Thu, 24 Apr 1997 17:06:52 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199704240712.JAA03901@wave.fwl.dfn.de>, Uwe Ellermann writes: > >Considering a VPN scenario using tunnel-mode ESP, mandatory >integrity for ESP wouldn't gain much more security, iff all >tunneled IP packets are already required to use AH by the >site's policy. It should be possible to save the additional >overhead of applying integrity mechanisms twice (ie. AH and ESP) >on the same data. So your end host is creating packets with an AH header. Who can verify this AH header ? - - Your local firewall: Not useful in the general case. All it does it further assure the firewall that you're who you claim you are. But since the packets appear on the trusted network, this is already implied. In this case, the local firewall would strip that header, add an ESP(*) header to the remote firewall and send the packet out. - - The remote end host: How would the remote firewall know when to let packets in ? Remember, it can't verify them. In this case, your local firewall would add the ESP header to prove to the other firewall that the packet came from a trusted network (VPN and all that). Usually, this AH SPI would be established after the firewalls themselves have established an ESP SPI. - - The remote firewall: In that case, you don't really need the local firewall to do anything; you should use ESP to the remote firewall, and the local firewall should do nothing. This would imply that your administrator trusts you not to violate the VPN. If he doesn't, then you shouldn't be able to establish an SPI with the remote firewall/host in the first place (wouldn't allow the KMP to run in proxy mode, or whatever it's called today). - - A (sub)set of the above: we don't have group shared keys (yet ?). (*) ESP with authentication So i think the scenario you presented is unrealistic. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM1/La70pBjh2h1kFAQFw8QP/aUZQ+RPttO4kr6K1W44NBaVV86tPpBNU zVl7VVF3bYILoqmLvFuYeehAr5b5WWJL51wlYU8lH6tpCXMAZAxWzFmopHjGTQxj XM4SQIVdxAshW59zsmkcSIHCWR+Hqqfn0AEHde0x6YhNMp8WjETesvzamfIIM5r1 Wys6kEgz/DU= =i+KC -----END PGP SIGNATURE----- From owner-ipsec Mon Apr 28 21:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14129 for ipsec-outgoing; Mon, 28 Apr 1997 21:47:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704222338.QAA11325@joseph.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:30:47 -0400 To: David Wagner From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, I agree that it is always approrpiate to ask whether one is distorting a protocol like ESP to accommodate a "special need" for some application. If so, then leave the common protocol alone and suggest that the application do something application-specific. However, this is not the case here. The example you cite "...MACing entire kilobytes at a time..." is completely off base for this context. One of the aspects of packet voice and packet video that makes use of crypto authentication relatively expensive is the small size of the packets. So the "custom optimazation" you cite is totally inapprorpiate here. You note that authentication should be faster than encryption, which is often true, but I don't see why this is relevant to the argument. If I am willing top accept the delay and the possible throughptu limitations imposed by encryption, is that supposed to imply that I will not mind the additional delay and the throughout limits that adding HMAC will imply? Unless we have parallel processing of the ESP packet (which probably will not be common), the delay imposed by the HMAC computation is serial and thus one ought not assume that this added delay is not a problem just because the encryption delay may have been acceptable. I think we're loosing sight of the issues here. Contrary to your comment, we are not "carving out a hole" in the specs. I suggested that it is reasonable to allow negotiation of an ESP-protected SA without authentication. This is a characteristic of the current IPSEC RFCs and I merely indicated a plan to preserve this modularity. This is not a change from the previously issued specs. We have had additional transforms that have been published since the base RFCs, but the current RFCs don't require combined encryption and authentiction for ESP (the default transforms don't do this), nor do they precude definition of new transforms that have that requirement. The objections to retaining this modular feature seem to be based on several different observations: 1. Under some circumstances, use of encryption w/o authentication can result in violations of confidentiality, as Steve Bellovin has pointed out. I agree that use of ESP with encryption (but w/o authentication) would be inappropriate in most cases where such attacks could be mounted. If one is electing encryption, it is inappropriate to use ESP in a fashion that could undermine the confidentiality service that is implied. However, one can safely use encryption w/o authentication in some contexts because the network enviromment effectively precluded the sort of attacks that would compromise confidentiality. So the thrust of this argument is that we ought to foolproof IPSEC to prevent selection ofpotentially dangerous security service combinations. I'll address this arguemnt below. 2. Some forms of chosen plaintext attack are facilitated by use of encryption w/o authentication. This is true, but I am not at all persuaded by the argument. History has sihown many ways in which chosen plainetext attack scan be launched against systems, so closing this one attack path does not, by itself, seem worth removing a potentially useful function. 3. Encryption w/o authentication is dangerous because all packets should be authenticated. This seems like another insistance on foolproofing IPSEC, i.e., preventing selection/configuration of any combination of options that could lead to insecurity. I argue that one may use higher level authentication mechanisms in conjunction with lower level encryption to achieve a reasonable set of security features for an application. This may be more attractive than either turing on all of the security services offered at a lower layer, or implementing all of the services in the application. I appreciate the notion that most users are not prepared to make determinations of when selective use of encryption w/o authentication is appropriate, and thus one can argue that we ought to change the spec to prevent use of ESP in a fashion that might subject them to such attacks. However, I am hesitant to take this approach. Experience shows that we cannot do that for all elements of a system; trying to do it in this narrow context deprives users/system designers of flexibility. Why don't we also say that you cannot implement IPSEC if the crypto will be done in software, which is susceptibale to many forms of attack that hardware crypto would prevent? Why not preclude implemenmtation in a typically managed Unix workstation, since such a worksta tion is subject to many attacks that will circumvent IPSEC, as opposed to use with a more secure Unix platform? These and other vulnerabilities associated with use of IPSEC present significant opportunities for attack, but we're willing to live with them. If we decide to insist on authentication for all encrypted packets, then we must do so without the expectation that this decision will really foolproof use of IPSEC, and with the understanding that it will impose additional burdens on some users. Also, as noted in another message I just sent, there may be crypto modes that are not subject to the sorts of attacks that Steve Bellovin has cited, in which case precluding authenticationless ESP is unduly restrictive for a protocol that is supposed to be algorithm independent. Steve From owner-ipsec Mon Apr 28 21:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14123 for ipsec-outgoing; Mon, 28 Apr 1997 21:47:21 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704290153.SAA22730@kebe.eng.sun.com> Subject: Test... To: ipsec@tis.com Date: Mon, 28 Apr 1997 18:53:09 -0700 (PDT) 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 Sorry 'bout this, but I haven't received any IPsec mail lately. Curious, Dan From owner-ipsec Mon Apr 28 22:23:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14602 for ipsec-outgoing; Mon, 28 Apr 1997 22:23:29 -0400 (EDT) Message-Id: <199704281959.MAA00938@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 11:31:42 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 12:59:00 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, In Memphis there was general agreement that AR must always be sent but that the receiver could elect to check it or not (it is in the receiver's best interest to do so anyway). You objected with the following point: > - it is true that the AR window protects the receiver, and imposes > no changes in how the sender operates. However, I think that the use or > non-use of use of AR is of interest to the sender. If communication > performance problems arise between two IPSEC sites, one reason might be the > rejection of some number of packets due to the size of the AR and the > out-of-order delivery characteristics associated with the path. Certainly, > if a default window size of 1 were adopted (as had been suggested), there > would be a significant opportunity for such behavior. However, if the use > of AR is purely at the discretion of the receiver, I have no way of knowing > if that might be a problem, if I am troubleshooting the problem from the > sender's end. So, at a minimum, I'd like to know if AR is a characteristic > of each SA. I don't see this as a compelling arguement. If you want to troubleshoot the problem from the sender's end, you always assume it is being used. (If it is not then AR is not the problem). I can't see such troubleshooting being done in a vacuum anyway. For the sender to determine the cause of a large number of his packets being rejected by the receiver, some coordination with the receiver is necessary (like phoning the site and asking whether anything interesting is in the audit logs, or accessing some IPsec MIB on the receiver). This WG seems to have a tendancy to say "oh, just let key management handle that" and AR (and the size of the AR window!) seems to fall into this category. A problem with this is that the more things key management must negotiate the more likely all offers from initiator will be rejected by the responder. And (the voice of experience talking here) that is a difficult problem to troubleshoot. Another point raised in Memphis is that complexity can introduce subtle bugs in code. Since we're talking about security code, a subtle bug can be a security hole. Is a relatively simple, secure 95% solution better than a complex, potentially problematic 97% solution? I think so. There will always be obscure edge conditions for which IPsec is a solution but not an optimal one. (Also, note that the more options to negotiate the more complex the method of configuration-- and the more complex the configuration itself-- and the more likely that a system can be misconfigured, with potentially tragic results). AR being always sent, optionally used, and a window size of 32 is a relatively simple solution that can be implemented straighforwardly without worrying about special case coding. It may not be the best solution for every single potential use of IPsec but for the vast majority it is. regards, Dan. From owner-ipsec Mon Apr 28 22:26:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14628 for ipsec-outgoing; Mon, 28 Apr 1997 22:26:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970423215014.006b724c@alphy.lkg.dec.com> References: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:36:57 -0400 To: Matt Thomas From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: Rob Adams , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, I think we're too far along to change the definition of what is covered by AH, as per your suggestion. (I was pleasantly surprized that the meeting was amenable to the most significant proposed change, i.e., the reversal of the order of encryption and authentcation in ESP.) The proposals we're deabting now involve allowing certain combinations of security services that are already part of the ESP spec; we're merely arguing over how bundled these service are. Steve From owner-ipsec Mon Apr 28 22:26:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14629 for ipsec-outgoing; Mon, 28 Apr 1997 22:26:31 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:28:46 -0400 To: Rob Adams From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" , "'Hilarie Orman'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Another message addresses the question of whether ESP w/o crypto authentication is meaningful, so I'll just comment on ESP w/o encryption. The issue I have raised is not so much the raw speed of the algorithm, but rather the overhead of data manipulation related to the fields in the IP header that have to be copied and those that have to be zeroed and the logic to make sure we treat each one appropriately. AH is a somewhat awkward protocol because it reaches forward in the protocol stream, in a selective fashion, unlike ESP which is a traditional encapsulation protocol and "cleaner." But, AH can be appropriate in some circumstances, as I have cited in previous messages. However, some of the examples cited for AH vs. encryptionless ESP are not good ones. For example, if we have a tunnel-mode SA between two IPSEC sites, the outer IP header doesn't seem to require protection and thus ESP-based authentication would be just fine. So, no, it's not settled yet ... Steve From owner-ipsec Mon Apr 28 22:33:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14747 for ipsec-outgoing; Mon, 28 Apr 1997 22:33:01 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704231601.TAA13455@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 12:59:50 -0400 To: Hugo Krawczyk , ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo + Hilarie, You made some good points why CBC mode, w/o cryptographic-based authentication, is not generally adequate to protect traffic from disclosure given the ability to launch more subtle attacks at the IP or higher layers. However, ESP is intended to be an algorithm and mode independent protocol, What about other modes? I recall a plaintext/ciphertext block chaining mode developed by IBM in the early 80s (late 70s?) that would seem to be more resistant to any form of packet modification. Would use of this mode with ESP still require separate, cryptographic-based authentication, in your opinion? Might there be other modes that would provide adequate protection? if so, then we ought not preclude use of ESP with encryption but without cryptographic-based authentication. Also, let me suggest another application example of where I think this would be approrpriate, perhaps even with CBC mode. The directory access protocol for X.500, DAP, has built-in signature autehntication and integrity mechansims, and even a weak form of timestamp-based anti-replay. However, because of the use of chaining in X.500, no confidentiality is provide at the application layer. Instead, the spec calls for use of lower layer encrytion for that purpose, e.g., at the network layer. So, this would seem to be a reasonable context in which to use ESP w/o authentication. Steve From owner-ipsec Mon Apr 28 22:35:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14825 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:05 -0400 (EDT) Date: Mon, 28 Apr 97 15:50:24 GMT From: "William Allen Simpson" Message-ID: <5752.wsimpson@greendragon.com> To: ipsec@tis.com Subject: policy versus protocol Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 23 Apr 1997 13:00:19 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > I'd thought the goal of the group was to protect the Internet > environment, i.e. an active attack environment. Thus, it seems to me > that leaving integrity as an administrator option is contrary to the > charter of the group. > Nobody is talking about leaving _anything_ to an administrator. We are talking about how to make a _protocol_ specification (bits on a wire) generic enough to handle current and future needs. > The conditions for safely dispensing with integrity are very narrow, > i.e. one of > > 1. Physical impossibility of active attacks (NB analysis must be > end-to-end) > 2. Encryption method has strong internal integrity (not DES) > 3. Connection limited to use by applications with strong > internal integrity > 4. Attacker can never know or guess ciphertext/plaintext pairs > from observed traffic > This is good (although I'd put #2 first), and should be in the architecture document! Then, implementors can read the architecture to decide what threat scenarios apply to their product. This is supposed to be a protocol Working Group, not a policy debate group. Document the applicability, and let the implementors make the choices.... For example, only the implementor knows whether the encryption method includes integrity. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14820 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:04 -0400 (EDT) Date: Mon, 28 Apr 97 15:59:30 GMT From: "William Allen Simpson" Message-ID: <5753.wsimpson@greendragon.com> To: ipsec@tis.com Subject: policy versus protocol Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 23 Apr 1997 19:01:22 +0300 (IDT) > From: Hugo Krawczyk > If there are applications that consciously decide to take all these risks > I suggest they negotiate the EMPTY-MAC as their authentication > algorithm (no processing penalty) rather than having ipsec explictly allowing > integrity-less IP security. > I think that Hugo has hit the nail on the head here. Instead of arguing about whether _WE_ should or should not allow this or that combination, let's stick to documenting the protocol, and leave the policy up to the application. If NO_INTEGITY is negotiated, we need to know what the ESP packet looks like. (I'd say, elide the trailing field.) If NO_ENCRYPTION is negotiated, we need to know what the ESP packet looks like. (I'd say, no fields would change.) Let's stick to our mission, and not be sidetracked by policy. If we had followed the lead of the I_R_TF security WG, we'd never have had any progress.... Leave the research to the researchers, and let's keep our nose to the engineering grindstone. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14826 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:08 -0400 (EDT) Date: Mon, 28 Apr 97 16:07:37 GMT From: "William Allen Simpson" Message-ID: <5754.wsimpson@greendragon.com> To: ipsec@tis.com Subject: AH versus authentication-only ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Tue, 22 Apr 1997 16:26:42 -0400 > From: Stephen Kent > It's good to see an exmaple of the rationale behind the proposal. In > general, if I am tunneling traffic between two security gateways, why do I > need to protect the outer IP header? Would I not generally discard it upon > arrival? I'd prefer that Moskowitz (and Richardson) speak as to their own rationale. But my recollection is, there is a demonstrated trust relationship between the firewalls themselves, and between the end-points and the firewalls. The only protocol tag we have to identify these firewalls is the IP address. The SPI is coupled to the IP address. Therefore, the IP address needs to be protected. > The inner IP header is the real focus of protection. There is no > reason why I cannot multiplex the same scope of traffic in a tunnel with > ESP as I can with an AH tunnel, so I don't view that as a differentiator. > I am not sure that this is true. Depends on the trust relationship. If the firewall is proxying a trust relationship for the end-point, I don't think that the same tunnel keys would be used (differing SPIs). To put the shoe on the other foot, please demonstrate to us that there is _no_ use for _ever_ authenticating the source and destination of an IP datagram. If you cannot do that, then we still need AH. And if we still need AH, then we should simplify our _protocol_ implementations to use _one_ method for authentication-only datagrams. Meanwhile, as I noted in a (just written) previous message, this whole argument may be needless. Authentication-only ESP is impossible to prevent, as the key-management can simply negotiate a non-encryption algorithm. So, let's stick to bits on the wire. What would change in the ESP bits? I'd say, nothing. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14828 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:11 -0400 (EDT) Date: Mon, 28 Apr 1997 12:23:40 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Karen Seo cc: ipsec@tis.com, skent@bbn.com, clynn@bbn.com, nyuan@bbn.com Subject: Re: PMTU/DF issues In-Reply-To: <199704221942.PAA04915@relay.hq.tis.com> Message-Id: <97Apr28.121922edt.11651@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 22 Apr 1997, Karen Seo wrote: > ========================================================================= > Appendix X -- Analysis/Discussion of PMTU/DF/Fragmentation Issues > > **************************************************************************** > Overall, the fragmentation/reassembly approach described above works > for all cases examined. > > The results for each of the 24 cases is shown below ("works" = will > work if system fragments after outbound IPSEC processing, reassembles > before inbound IPSEC processing). Notes indicate implementation > issues. > > b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and > network drivers. In this case, the IPSEC module would have to > do something like one of the following for fragmentation and > reassembly. > - do the fragmentation/reassembly work itself and > send/receive the packet directly to/from the network > layer. In AH or ESP transport mode, this is fine. In > AH or ESP tunnel mode where the tunnel is to the > ultimate destination, this is fine. But in AH or ESP > tunnel modes where the tunnel end is different from > the ultimate destination and where the source host is > multi-homed, this approach could result in sub-optimal > routing because the IPSEC module may be unable to > obtain the information needed (LAN interface and > next-hop gateway) to direct the packet to the > appropriate network interface. This is not a problem > if the interface and next-hop gateway are the same for > the ultimate destination and for the tunnel end. But > if they are different, then IPSEC would need to know > the LAN interface and the next-hop gateway for the > tunnel end. Seems to me that if the interface and next-hop gateway are different for the ultimate destination and for the tunnel end, then the tunnel end is not a security gateway. > **************************************************************************** > > 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an > ICMP message used for Path MTU Discovery. > > A. The amount of information returned with the ICMP message is limited > and this affects what selectors are available to identify security > associations, originating hosts, etc. for use in further propagating > the PMTU information. > > The destination security gateway and SPI uniquely define a security > association which in turn defines a set of possible originating > hosts. At this point, SG1 could: > a. send the PMTU information to all the possible originating hosts. > This would not work well if the host list is a wild card or if > many/most of the hosts weren't sending to SG1; but it might work > if the SPI/destination/etc mapped to just one host. Seems to me that if a host wasn't sending to SG1 then it's not an intended recipient of this PMTU information. Am I missing something here? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 29 09:56:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17394 for ipsec-outgoing; Tue, 29 Apr 1997 08:37:11 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199704290153.SAA22730@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 08:31:26 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Edward Lewis Subject: Re: Test... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 9:53 PM -0400 4/28/97, Dan McDonald wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan We (TIS/host of the the list) have been having Internet connectivity problems since sometime over the weekend... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-ipsec Tue Apr 29 14:02:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19092 for ipsec-outgoing; Tue, 29 Apr 1997 14:00:38 -0400 (EDT) Date: Tue, 29 Apr 1997 09:02:34 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704291302.JAA28064@earth.hpc.org> To: kent@bbn.com Cc: hugo@ee.technion.ac.il, ipsec@tis.com In-reply-to: Yourmessage Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, I think my note is consistent with yours, where I listed the conditions where I thought that ESP w/o integrity was OK, but then I expressed doubt as to the wisdom of leaving this judgment up to the individual user or system administrator, given that it is less than straightforward to analyze the safety of such a decision and that, with the exception of very low speed lines, the performance is not greatly impacted by requiring integrity. I could see having it be a property of the transform --- a transform designer can specify the null integrity algorithm if he knows that the encryption algorithm has built-in integrity --- but I don't find the DAP example compelling. Hilarie From owner-ipsec Tue Apr 29 14:05:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19250 for ipsec-outgoing; Tue, 29 Apr 1997 14:05:11 -0400 (EDT) Message-Id: <3.0.1.32.19970429080056.00753230@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 29 Apr 1997 08:00:56 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Rodney Thayer Subject: Re: Test... Cc: ipsec@tis.com In-Reply-To: <199704290153.SAA22730@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee you must be getting all sorts of work done! At 06:53 PM 4/28/97 -0700, you wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan > > 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 Apr 29 14:45:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19892 for ipsec-outgoing; Tue, 29 Apr 1997 14:44:04 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-rc5-cbc-00.txt Date: Tue, 29 Apr 1997 11:42:50 -0400 Message-ID: <9704291142.aa01223@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 Security Protocol Working Group of the IETF. Title : The ESP RC5-CBC Algorithm Author(s) : R. Pereira, R. Baldwin Filename : draft-ietf-ipsec-esp-rc5-cbc-00.txt Pages : 5 Date : 04/25/1997 This draft describes the RC5 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-rc5-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-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-ipsec-esp-rc5-cbc-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: <19970425145805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-rc5-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970425145805.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Apr 29 19:59:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21995 for ipsec-outgoing; Tue, 29 Apr 1997 19:56:34 -0400 (EDT) Date: Tue, 29 Apr 97 23:55:00 GMT From: "William Allen Simpson" Message-ID: <5765.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: ho@earth.hpc.org (Hilarie Orman) > with the exception of very low speed lines, the performance is not > greatly impacted by requiring integrity. I could see having it be a > property of the transform --- a transform designer can specify the > null integrity algorithm if he knows that the encryption algorithm has > built-in integrity --- but I don't find the DAP example compelling. > (sigh) Having lived through the argument between Cisco and NetStar over whether PPP over OC-3 (155 Mbps) needed 2 or 4 bytes of checksum (furtunately PPP will negotiate) -- welcome to the vendor world. People really _do_ care about performance on any speed of line. The argument is compelling to the implementors. And low speed is pretty much defined as less than T1 (1.5 Mbps) these days. ISDN 2B isn't cutting it anymore.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Apr 30 00:31:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23384 for ipsec-outgoing; Wed, 30 Apr 1997 00:26:51 -0400 (EDT) Message-Id: <199704300427.AAA24011@relay.hq.tis.com> Date: Wed, 30 Apr 97 0:29:53 EDT From: Karen Seo To: Norman Shulman cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Norm, >>Seems to me that if the interface and next-hop gateway are different >>for the ultimate destination and for the tunnel end, then the tunnel >>end is not a security gateway. You're right that the tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall. > **************************************************************************** > > 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an > ICMP message used for Path MTU Discovery. > > A. The amount of information returned with the ICMP message is limited > and this affects what selectors are available to identify security > associations, originating hosts, etc. for use in further propagating > the PMTU information. > > The destination security gateway and SPI uniquely define a security > association which in turn defines a set of possible originating > hosts. At this point, SG1 could: > a. send the PMTU information to all the possible originating hosts. > This would not work well if the host list is a wild card or if > many/most of the hosts weren't sending to SG1; but it might work > if the SPI/destination/etc mapped to just one host. >>Seems to me that if a host wasn't sending to SG1 then it's not an >>intended recipient of this PMTU information. >> >>Am I missing something here? H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Assuming I understand your point, you're correct.... Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. Then suppose H0 sends traffic to H5 that causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. At this point, SG1 has the two choices outlined previously: a) send the PMTU information to all 3 hosts. As you observed, H1 and H2 aren't the intended recipients for the PMTU information and won't know what to do with it. b) hold the PMTU information until another too-big packet arrives and then use that packet and the PMTU information to construct a ICMP PMTU for the originating host (H0). Karen From owner-ipsec Wed Apr 30 02:32:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA23957 for ipsec-outgoing; Wed, 30 Apr 1997 02:30:57 -0400 (EDT) Message-Id: <199704300636.XAA09783@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 29 Apr 97 23:36:51 -0700 To: baldwin@RSA.COM, rpereira@TimeStep.com Subject: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some questions and comments regarding draft-ietf-ipsec-esp-rc5-cbc-00.txt. The first question I have is why 40 bits? I am under the impression the IPsec wg, for political reasons, chose to exclude export weakened cipher usage. I am not familiar with RC5's status. Is it a trade secret like RC2? I see RSA has applied for a patent. Will implementaters have to license RC5 from RSA? If it need be licensed could that be a detriment to its wide-spread use in IPsec? I'm a bit confused about the following paragraph from the document. > 2.3 Payload > > RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets > (64 bits) that immediately precedes the cipher-text in the payload. > A new IV must be pseudo-randomly generated for each packet and then > used to encrypt that plain-text. When decrypting, the first 8 > octets of the payload are used as a IV to decrypt the remaining > payload octets. > Those statements are really confusing. They say the IV precedes the cipher-text but then say first 8 octets of the payload (the SPI and sequence number?) are used to decrypt the rest. As Scoobe Doo says, Er? The CBC method seems a bit weird to me too. Is the IV XORed with each block? Regarding key material, why is the key material derived as stated in section 4 rather than slice and dice? -dpg From owner-ipsec Wed Apr 30 10:58:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27368 for ipsec-outgoing; Wed, 30 Apr 1997 10:57:02 -0400 (EDT) Date: Wed, 30 Apr 97 14:49:43 GMT From: "William Allen Simpson" Message-ID: <5769.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Karen Seo > a) send the PMTU information to all 3 hosts. As you > observed, H1 and H2 aren't the intended recipients > for the PMTU information and won't know what to do > with it. This would be the wrong thing to do. Be conservative in what you send. > b) hold the PMTU information until another too-big > packet arrives and then use that packet and the PMTU > information to construct a ICMP PMTU for the > originating host (H0). > This is what is described in RFC-1853: The router uses the ICMP messages it receives from the interior of a tunnel to update the soft state information for that tunnel. When subsequent datagrams arrive that would transit the tunnel, the router checks the soft state for the tunnel. If the datagram would violate the state of the tunnel (such as the MTU is greater than the tunnel MTU when Don't Fragment is set), the router sends an appropriate ICMP error message back to the originator, but also forwards the datagram into the tunnel. Forwarding the datagram despite returning the error message ensures that changes in tunnel state will be learned. Rather than putting all of this into the Architecture document, I'd think it would be more efficacious to update RFC-1853. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Apr 30 10:58:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27367 for ipsec-outgoing; Wed, 30 Apr 1997 10:57:01 -0400 (EDT) Date: Wed, 30 Apr 1997 10:55:19 -0400 (EDT) From: Dave Mason Message-Id: <199704301455.KAA01980@darkstar.rv.tis.com> To: ipsec@tis.com, mjs@terisa.com, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, wdmaugh@tycho.ncsc.mil Subject: isakmp-07.txt Cc: dmason@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Just nitpicking, but the paragraph on page 20 of draft-ietf-ipsec-isakmp-07.txt: >For uniformity, all SPIs are 8 octets long. When negotiating security >associations for security protocols that use 4-octet SPIs, the first four >octets will be used, and the last four will be zero. isn't in sync with section 3.5 which allows for variable length SPIs. Also note that the proposal payloads in the examples given in Section 4.1.1, use fixed (8 octets) sized SPI fields and do not include the SPI size field as specified in Section 3.5. -dave (dmason@tis.com) From owner-ipsec Wed Apr 30 11:24:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27605 for ipsec-outgoing; Wed, 30 Apr 1997 11:23:37 -0400 (EDT) Message-ID: From: Roy Pereira To: "'baldwin@rsa.com'" , "'dennis.glatting@plaintalk.bellevue.wa.us'" Cc: "'ipsec@tis.com'" Subject: RE: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt Date: Wed, 30 Apr 1997 11:29:06 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >I have some questions and comments regarding >draft-ietf-ipsec-esp-rc5-cbc-00.txt. > >The first question I have is why 40 bits? I am under the >impression the IPsec wg, for political reasons, chose to >exclude export weakened cipher usage. What this drafts states is that the key size may be as small as 40 bits. It is more of a flexibility issue than an export one. Policy will be able to reject any proposal that requests a smaller key size than it allows. >I'm a bit confused about the following paragraph from the >document. > >> 2.3 Payload >> >> RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets >> (64 bits) that immediately precedes the cipher-text in the payload. >> A new IV must be pseudo-randomly generated for each packet and then >> used to encrypt that plain-text. When decrypting, the first 8 >> octets of the payload are used as a IV to decrypt the remaining >> payload octets. >> > >Those statements are really confusing. They say the IV >precedes the cipher-text but then say first 8 octets of the >payload (the SPI and sequence number?) are used to decrypt the >rest. As Scoobe Doo says, Er? The CBC method seems a bit weird to >me too. Is the IV XORed with each block? This draft relates to the upcoming ESP draft (draft-ietf-ipsec-new-esp-01). In that draft, the explicit IV has been taken out of the ESP 'template' and must be documented in the individual ESP algorithm drafts. Thus ESP starts off like: SPI (32 bits) Sequence Number (32 bits) Payload (variable) ...... So within the Payload we start off with a 64 bit IV followed by the cipher text. That explicit IV is then used to decrypt the cipher text. > >Regarding key material, why is the key material derived as >stated in section 4 rather than slice and dice? Section 4 does talk about 'slicing and dicing'. This is inline with what was discussed and agreed upon in Memphis. The specific algorithm would dictate how many bits of keying material it would require, so that ISAKMP (or any other higher layer) can provide it. Then the algorithm simply slices the key material into sections (x bits for the cipher key, y bits for the authentication key). > From owner-ipsec Wed Apr 30 11:47:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27837 for ipsec-outgoing; Wed, 30 Apr 1997 11:46:40 -0400 (EDT) Message-Id: <199704301552.IAA09982@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 30 Apr 97 08:52:52 -0700 To: Roy Pereira Subject: Re: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt cc: "'baldwin@rsa.com'" , "'ipsec@tis.com'" Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Roy Pereira Date: Wed, 30 Apr 1997 11:29:06 -0400 > >Regarding key material, why is the key material derived as > >stated in section 4 rather than slice and dice? > > Section 4 does talk about 'slicing and dicing'. This is inline > with what was discussed and agreed upon in Memphis. The > specific algorithm would dictate how many bits of keying > material it would require, so that ISAKMP (or any other higher > layer) can provide it. Then the algorithm simply slices the key > material into sections (x bits for the cipher key, y bits for the > authentication key). > I was unclear. I was referring to the Horowitz draft. I went back and reread previous wg e-mail. I read the developers decided the key management daemon will generate "enough" key material and the AH/ESP algorithms will slice it; however, it isn't clear to me how the key management daemon will generate it. I must reread the other drafts. -dpg From owner-ipsec Wed Apr 30 12:52:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28272 for ipsec-outgoing; Wed, 30 Apr 1997 12:51:21 -0400 (EDT) Message-ID: <33677AEA.F7D23E48@newoak.com> Date: Wed, 30 Apr 1997 13:01:30 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b3 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: ISAKMP/Oakley pre-shared key issue X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk (I wish I had realized this one earlier...) A while back, we discussed the fact that the latest (-03) version of the ISAKMP/Oakley resolution draft now requires that one use Oakley Aggressive Mode whenever using pre-shared keys, if one plans on using IDs that aren't IP addresses. If I remember right, an idea was proposed to add a new ID type to the DOI draft which would allow an opaque ID to be used to find the proper key. This is all fine and good. However, this opens up something else that I hadn't realized until just now. In Aggressive Mode, HASH_R is transmitted in the clear. That isn't a problem by itself, but what is a problem is that the only "secret" used to derive HASH_R in the -03 draft is the pre-shared key itself (as part of SKEYID). Everything else is something that is transmitted in the clear between the two parties. This means that one can open up the whole exchange by doing a brute-force key search; moreover, one can then impersonate either party, assuming the key isn't changed. The previous version of the ISAKMP/Oakley resolution draft (-02) was not as vulnerable, because the Diffie-Hellman shared secret (g^xy) was also used to help derive HASH_R. (Of course, that version was vulnerable to the man-in-the-middle D-H attack that was discussed here just a short while ago; that was fixed by using the D-H public values in the hash calculations in the -03 draft. But g^xy is now left out, at least when using pre-shared keys.) It seems to me that this situation can be handled by adding g^xy to the derivation of SKEYID when using pre-shared keys, as follows: SKEYID = prf(pre-shared key, Ni | Nr | g^xy) Since signatures (and now public-key encryption, according to the notes from Memphis that were sent recently) both use g^xy to derive SKEYID, I would hope that this would not be too great of a change for the draft authors. And I can't see that this would weaken anything, if the other authentication methods use it, but I'm not a "real" cryptographer. Do the real cryptographers here believe that this change would be a good idea? -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Apr 30 21:41:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA01608 for ipsec-outgoing; Wed, 30 Apr 1997 21:39:47 -0400 (EDT) Message-Id: <199705010140.VAA18887@relay.hq.tis.com> Date: Wed, 30 Apr 97 21:44:47 EDT From: Karen Seo To: wsimpson@greendragon.com cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, > b) hold the PMTU information until another too-big > packet arrives and then use that packet and the PMTU > information to construct a ICMP PMTU for the > originating host (H0). > >>This is what is described in RFC-1853: >> >> The router uses the ICMP messages it receives from the interior of a >> tunnel to update the soft state information for that tunnel. When >> subsequent datagrams arrive that would transit the tunnel, the router >> checks the soft state for the tunnel. If the datagram would violate >> the state of the tunnel (such as the MTU is greater than the tunnel >> MTU when Don't Fragment is set), the router sends an appropriate ICMP >> error message back to the originator, but also forwards the datagram >> into the tunnel. Forwarding the datagram despite returning the error >> message ensures that changes in tunnel state will be learned. >> >>Rather than putting all of this into the Architecture document, I'd >>think it would be more efficacious to update RFC-1853. Assuming that by "this" you mean the entire PMTU/DF discussion and appendix (as opposed to just the section you copied in your email).... Certainly referencing RFC-1853 seems appropriate. However, since PMTU/DF is only one of several IPSEC issues that are relevant to IPSEC tunneling and this decision, we'd like to discuss the other issues before deciding where to document them. For example, RFC-1853 addresses only IPv4 and we plan to discuss IPv4 and IPv6 tunneling. Thank you, Karen From owner-ipsec Thu May 1 08:46:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA04822 for ipsec-outgoing; Thu, 1 May 1997 08:42:54 -0400 (EDT) Date: Thu, 1 May 1997 15:48:07 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705011248.PAA22358@ee.technion.ac.il> To: ipsec@tis.com, smamros@newoak.com Subject: Re: ISAKMP/Oakley pre-shared key issue Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, I do not find any reason for concern in the issue you bring up below. You talk about a brute-force search of the pre-shared key. Since this key is used only with prf's there is no reason to choose it from a small space (like 40 bits, etc). Brute-force search should be just infeasible. In addition, even if brute force search would be possible (a bit of rethorics in the ipsec mailing list is unavoidable :) the addition of g^xy to the hashed parameters does not add anything. If you want to find the key between A and B just initiate an exchange with B pretending to be A. Choose g^x, wait for B's responese (which will include HASH-R, where R=B) and now do an off-line search for the pre-shared key. On the other hand, adding g^xy to HASH-R and HASH-I does have a DISadvantage. Currently, the computation of g^xy out of g^x and g^y can be done after the exchange is finished. If you add the g^xy into the hashes you'll have to introduce the delay of this computation into the communication which is undesirable. Finally, regarding your comment >Since signatures (and now public-key encryption, according to the >notes from Memphis that were sent recently) both use g^xy to derive >SKEYID, as far as I know g^xy is NOT used in the public key encryption mode to derive SKEYID, only to derive SKEYID_a/e/g. ANd that's the right way to do it. In the signature mode we do use g^xy for SKEYID but the reason there is different (and one of the disadvantages of the signature mode). Hugo >A while back, we discussed the fact that the latest (-03) version >of the ISAKMP/Oakley resolution draft now requires that one use >Oakley Aggressive Mode whenever using pre-shared keys, if one plans >on using IDs that aren't IP addresses. If I remember right, an >idea was proposed to add a new ID type to the DOI draft which would >allow an opaque ID to be used to find the proper key. This is all >fine and good. > >However, this opens up something else that I hadn't realized until >just now. In Aggressive Mode, HASH_R is transmitted in the clear. >That isn't a problem by itself, but what is a problem is that the >only "secret" used to derive HASH_R in the -03 draft is the >pre-shared key itself (as part of SKEYID). Everything else is >something that is transmitted in the clear between the two parties. >This means that one can open up the whole exchange by doing a >brute-force key search; moreover, one can then impersonate either >party, assuming the key isn't changed. > >The previous version of the ISAKMP/Oakley resolution draft (-02) was >not as vulnerable, because the Diffie-Hellman shared secret (g^xy) >was also used to help derive HASH_R. (Of course, that version >was vulnerable to the man-in-the-middle D-H attack that was discussed >here just a short while ago; that was fixed by using the D-H public >values in the hash calculations in the -03 draft. But g^xy is now >left out, at least when using pre-shared keys.) > >It seems to me that this situation can be handled by adding g^xy >to the derivation of SKEYID when using pre-shared keys, as follows: > SKEYID = prf(pre-shared key, Ni | Nr | g^xy) >Since signatures (and now public-key encryption, according to the >notes from Memphis that were sent recently) both use g^xy to derive >SKEYID, I would hope that this would not be too great of a change >for the draft authors. And I can't see that this would weaken >anything, if the other authentication methods use it, but I'm not >a "real" cryptographer. Do the real cryptographers here believe >that this change would be a good idea? > >-Shawn Mamros >E-mail to: smamros@newoak.com > From owner-ipsec Thu May 1 10:02:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05364 for ipsec-outgoing; Thu, 1 May 1997 10:01:36 -0400 (EDT) Date: Thu, 1 May 1997 17:03:41 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705011403.RAA24818@ee.technion.ac.il> To: ho@earth.hpc.org, kent@bbn.com Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk On the issue of ESP with optional AH I worte a few days ago: > If there are applications that consciously decide to take all these risks > I suggest they negotiate the EMPTY-MAC as their authentication > algorithm (no processing penalty) rather than having ipsec explictly > allowing integrity-less IP security. Hilarie recently wrote: >From ho@earth.hpc.org Tue Apr 29 17:01:47 1997 > > ... > I expressed doubt as to the wisdom of leaving this judgment up to the >individual user or system administrator, given that it is less than >straightforward to analyze the safety of such a decision and that, >with the exception of very low speed lines, the performance is not >greatly impacted by requiring integrity. I could see having it be a >property of the transform --- a transform designer can specify the >null integrity algorithm if he knows that the encryption algorithm has >built-in integrity --- but I don't find the DAP example compelling. > Following these sugestions and Steve's recent comments I propose to mandate integrity with ESP and to have editorial notes that 1) emphasize the importance of integrity in ESP and 2) suggest that in the particular cases where an application decides that the costof authentication together with ESP is not worthwhile (e.g., since integrity is provided by a different mechanism in that application) then the communicating parties can negotiate a "null integrity algorithm". Hugo From owner-ipsec Fri May 2 00:07:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA10530 for ipsec-outgoing; Fri, 2 May 1997 00:06:01 -0400 (EDT) Message-Id: <199705020428.AAA21555@relay.rv.tis.com> Date: Fri, 2 May 97 0:04:05 EDT From: Karen Seo To: wsimpson@greendragon.com cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk William, >>> From: Karen Seo >>> a) send the PMTU information to all 3 hosts. As you >>> observed, H1 and H2 aren't the intended recipients >>> for the PMTU information and won't know what to do >>> with it. >>> >>This would be the wrong thing to do. Be conservative in what you send. (Apologies for missing this part of your message in my previous reply...) Good point. This is what the Appendix is trying to say. Just to clarify... the above option was included for completeness. In cases where the security gateway cannot determine the originating source, the Appendix recommends the that the security gateway "hold the PMTU information until another too-big packet arrives and then use that packet and the PMTU information to construct a ICMP PMTU for the originating host (H0). Thanks again, Karen From owner-ipsec Fri May 2 07:30:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12737 for ipsec-outgoing; Fri, 2 May 1997 07:29:13 -0400 (EDT) Date: Thu, 1 May 1997 16:51:02 -0400 (EDT) From: David Mason Message-Id: <199705012051.QAA06728@dira.rv.tis.com> To: ipsec@tis.com, mjs@terisa.com, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, wdmaugh@tycho.ncsc.mil Subject: isakmp-07.txt Cc: dmason@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk You've probably already heard the following a couple hundred times... In draft-ietf-ipsec-isakmp-07.txt: The reference to "Figure 3.2" in the first sentence of Section 3.2 should be "Figure 3". In the section "3.14 Notification Payload", at the end of the paragraph: o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted. "being deleted" should be deleted. At the end of the third paragraph of section "4.1 Security Association Establishment" (.txt page 42), references to certain aspects of the examples in section "4.1.1 Security Association Establishment Examples" are incorrect: Example 1 only shows two transforms for ESP not three and Example 2 only shows one transform for AH AND one transform for ESP OR ... You should probably mention in section 4.1.1 that the Nounce payload in example one was omitted for space reasons. -dave (dmason@tis.com) P.S.: Please let me know if you'd prefer I didn't send you mail like this. From owner-ipsec Fri May 2 11:51:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14619 for ipsec-outgoing; Fri, 2 May 1997 11:46:27 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-cast-128-cbc-00.txt Date: Fri, 02 May 1997 10:44:57 -0400 Message-ID: <9705021044.aa23388@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 Security Protocol Working Group of the IETF. Title : The ESP CAST-128-CBC Algorithm Author(s) : R. Pereira, G. Carter Filename : draft-ietf-ipsec-esp-cast-128-cbc-00.txt Pages : 5 Date : 05/01/1997 This draft describes the CAST-128 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-cast-128-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-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-ipsec-esp-cast-128-cbc-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: <19970501162454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-cast-128-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970501162454.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri May 2 22:07:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA17912 for ipsec-outgoing; Fri, 2 May 1997 22:05:34 -0400 (EDT) Message-Id: <199705030217.TAA10628@mailsun2.us.oracle.com> Date: 02 May 97 19:09:03 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: No Noise was Re: Test... X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:owner-ipsec@portal.ex.tis.com's message of 29-Apr-97 05:00 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_10705989_0_11919705022018120" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=_ORCL_10705989_0_11919705022018120 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Please stop this noise (below) on the mailing list! Paul Lambert (ipsec chair) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_10705989_0_11919705022018120 Content-Type:message/rfc822 Date: 29 Apr 97 05:00:56 From:"Rodney Thayer " To:Dan.McDonald@eng.sun.com,(Dan,McDonald) Subject:Re: Test... Cc:ipsec@tis.com Return-Path: X-Sender:rodney@pop3.pn.com X-Mailer:Windows Eudora Light Version 3.0.1 (32) In-Reply-To:<199704290153.SAA22730@kebe.eng.sun.com> Sender:owner-ipsec@ex.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" Gee you must be getting all sorts of work done! At 06:53 PM 4/28/97 -0700, you wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan > > 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" --=_ORCL_10705989_0_11919705022018120-- From owner-ipsec Tue May 6 14:39:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13388 for ipsec-outgoing; Tue, 6 May 1997 14:27:17 -0400 (EDT) Message-Id: <199705061833.OAA01724@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "William Allen Simpson" Cc: ipsec@tis.com Subject: Re: policy versus protocol In-Reply-To: wsimpson's message of Mon, 28 Apr 1997 15:50:24 +0000. <5752.wsimpson@greendragon.com> Date: Tue, 06 May 1997 14:33:01 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [I've been away from my mail for a while]. Bill, While I agree that it's often good to seperate policy from protocol, the policies of two implementations which want to interoperate need to be "compatible"; this means that policy *does* have ramifications for interoperability, and that that discussions about possible policies and policy frameworks *is* in scope for the IETF. - Bill From owner-ipsec Wed May 7 14:55:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22400 for ipsec-outgoing; Wed, 7 May 1997 14:48:53 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 13:49:16 -0500 To: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com From: Tom_Markham@securecomputing.com (Tom Markham) Subject: ISAKMP commit and notify usage Cc: ipsec@tis.com, cwilliams@cylink.com, balenson@tis.com, sabbott@tcel.com, gupta@us.ibm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I am trying to understand the usage of the ISAKMP commit bit flag and notify messages. The ISAKMP header contains a flags field which contains a commit bit. When set by the sender this tells the peer ISAKMP not to use the (ISAKMP or IPSEC ?) SA until the sender transmits an informational exchange. Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that once an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the ISAKMP SA. - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? As an example which of the following Identity Protection Exchanges is correct? 1. No ISAKMP Encryption Until Notified Initiator direction Responder Note (1) HDR: SA ==> Begin ISAKMP - SA (2) <== HDR; SA (3) HDR; KE; Nonce ==> Commit flag set (4) <== HDR; KE; Nonce Key generated (5) HDR; Notify ==> Information Exchange is not protected by the SA (6) HDR*; IDii; AUTH ==> ID is encrypted (7) <== HDR*; IDir; AUTH 2. No IPSEC Encryption Until Notified Initiator direction Responder Note (1) HDR: SA ==> Begin ISAKMP - SA (2) <== HDR; SA (3) HDR; KE; Nonce ==> Commit flag set (4) <== HDR; KE; Nonce Key generated (5) HDR*; IDii; AUTH ==> ID is encrypted (6) <== HDR*; IDir; AUTH (7) HDR; Notify ==> Information Exchange is protected by the SA - What notify message type payload is used to commit/tell the peer ISAKMP that it is time to start using the encryption key/SA? - Is there an integrity check on the Notification Payload? Does each piece of notification data define its own integrity mechanism? The OAKLEY error payload appends a Sig/prf Payload. Thanks, Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Wed May 7 16:08:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22820 for ipsec-outgoing; Wed, 7 May 1997 16:07:34 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705072030.QAA07984@relay.rv.tis.com> Date: Wed, 7 May 97 16:13:53 EDT To: IPSEC@tis.com Subject: ISAKMP/OAKLEY Negotiation Discrepancy and Question Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. 1) Hi. I believe I see a discrepancy between the figure shown in the , section 5.7.1 'Phase 1 using Oakley Main Mode', the first collections of payloads and the figure shown in the , section 3.6 'Transform Payload'. shows the RESERVED area of the Transform Payload (not the generic header RESERVED area), in both Transform 1 and 2 to be between the 'Next Payload' and the 'Transform-ID' fields. In example , I am assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. shows the RESERVED2 area of the Transform Payload (not the generic header RESERVED area), to be following the 'Transform-ID'. 'Next Payload' and the "Payload Length' fields. Question: If this is a discrepancy, which is correct? Ans: ______________________________________________________________ 2) In listed above in question 1), 'OAKLEY' is in the 'Transform-ID' field. I have looked in and but I do not find the transform id values listed anywhere. I also looked in the but I don't see anything that looks like a really good answer there either. Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' of the document? Ans: ______________________________________________________________ Thanks in advance for your help. -- Jim Ryder From owner-ipsec Wed May 7 16:29:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22913 for ipsec-outgoing; Wed, 7 May 1997 16:29:20 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705072029.QAA25968@relay.hq.tis.com> Date: Wed, 7 May 97 16:35:39 EDT To: IPSEC@tis.com Subject: Correction to Previous Question Sender: owner-ipsec@ex.tis.com Precedence: bulk Excuse me. In the discrepancy, I said this: to be between the 'Next Payload' and the 'Transform-ID' fields ************ I meant to be between the 'Transform #' and the 'Transform-ID' fields *********** -- Jim From owner-ipsec Thu May 8 07:25:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29073 for ipsec-outgoing; Thu, 8 May 1997 07:21:33 -0400 (EDT) Message-Id: <199705081121.HAA29073@portal.ex.tis.com> Date: Wed, 07 May 1997 17:05:20 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: discussion list for IPsec SNMP MIB Cc: ietf-ipsec-mib@sneaker.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal and I have set up a mailing list for discussion on an SNMP MIB for IPsec. It's a "Majordomo" list, you subscribe by sending a message to: ietf-ipsec-mib-request@sneaker.net with "subscribe" as the body of the message. We have a (very very) rough draft of a MIB document now and we'll be discussing that for starters. -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Fri May 9 13:46:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09950 for ipsec-outgoing; Fri, 9 May 1997 13:38:31 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705091738.NAA29801@relay.hq.tis.com> Date: Fri, 9 May 97 13:33:07 EDT To: IPSEC@tis.com Subject: Please help with answer to discrepancy question Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. 1) Hi. I believe I see a discrepancy between the figure shown in the , section 5.7.1 'Phase 1 using Oakley Main Mode', the first collections of payloads and the figure shown in the , section 3.6 'Transform Payload'. shows the RESERVED area of the Transform Payload (not the generic header RESERVED area), in both Transform 1 and 2 to be BETWEEN the 'Transform #' and the 'Transform-ID' fields. In example , I am assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. shows the RESERVED2 area of the Transform Payload (not the generic header RESERVED area), to be FOLLOWING the 'Transform-ID'. Question: Which is correct? Ans: ______________________________________________________________ 2) In listed above in question 1), 'OAKLEY' is in the 'Transform-ID' field. I have looked in and but I do not find the transform id values listed anywhere. I also looked in the but I don't see anything that looks like a really good answer there either. Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' of the document? Ans: ______________________________________________________________ Thanks in advance for your help. -- Jim Ryder From owner-ipsec Fri May 9 15:36:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10587 for ipsec-outgoing; Fri, 9 May 1997 15:33:52 -0400 (EDT) Date: Fri, 9 May 97 15:38:36 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9705091938.AA01119@dolphin.ncsc.mil> To: jryder@vnet.ibm.com Subject: Re: Please help with answer to discrepancy question Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim, > 1) > > Hi. I believe I see a discrepancy between > > > the figure shown in the > , section 5.7.1 'Phase 1 using > Oakley Main Mode', the first collections of payloads > > and > > > the figure shown in the > , section 3.6 'Transform Payload'. > > > shows the RESERVED area of the Transform Payload (not the generic > header RESERVED area), in both Transform 1 and 2 to be BETWEEN the > 'Transform #' and the 'Transform-ID' fields. In example , I am > assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. > > shows the RESERVED2 area of the Transform Payload (not the generic > header RESERVED area), to be FOLLOWING the 'Transform-ID'. > > Question: Which is correct? > I'll give you my interpretation, but we'll need to hear the same thing from Dan Harkins and/or Dave Carrel (authors of the ISAKMP/Oakley draft). If you look at section 4.1.1 of you'll see two full examples of the payloads. I think the drawing in is leftover from the format in the ISAKMP-05 or -06 Internet Draft. I believe the agreement made between the ISAKMP, ISAKMP/Oakley, and IPSEC DOI I-D editors was that the Transform # field and the Transform ID field were together followed by the 2 octet RESERVED2 field. Again, we should hear from Dan Harkins and/or Dave Carrel to make sure we're in agreement. > 2) In listed above in question 1), 'OAKLEY' is in the > 'Transform-ID' field. I have looked in and but I do not find the > transform id values listed anywhere. I also looked in the > but I don't see anything that looks > like a really good answer there either. > > Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform > value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' > of the document? > Again, we probably need to hear from Dan and/or Dave and Derrell Piper (author of the IPSEC DOI I-D). All transform values are listed in the IPSEC DOI I-D. I believe you are correct in saying that the Transform ID is the value listed in section 4.2 of the IPSEC DOI I-D. Dan/Dave/Derrell??? Any input? Doug Maughan wdm@tycho.ncsc.mil From owner-ipsec Mon May 12 10:56:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28267 for ipsec-outgoing; Mon, 12 May 1997 10:49:06 -0400 (EDT) Message-Id: <3.0.32.19970512103856.006f8ee0@linus.isoc.org> X-Sender: burack@linus.isoc.org X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 May 1997 10:38:57 -0400 To: ipsec@ans.net From: Martin Burack Subject: INET'97 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings. Because of your interest in security, electronic commerce, privacy, and related areas, we thought you would want to know about the INET'97 conference, taking place next month. INET'97 is the crossroads at which the world's cyberspace leaders meet to exchange experiences, share information, and shape the future of the Internet and its related internetworking technologies. Regardless of your expertise, you'll come away with plenty of practical ideas. It is the one Internet event you must not miss! I look forward to seeing you there. Marty Burack Executive Director Internet Society burack@isoc.org *********************************** PLENARY SPEAKERS Dr. Glenn Ricart Executive Vice President and Chief Technology Officer Novell, Inc. Mr. Ira Magaziner Senior Advisor to the President of the United States for Policy Development. A Minister of the Malaysian government *********************************** A SAMPLING OF INET'97 CONFERENCE SESSIONS (subject to change) Security Privacy on the Internet Seamless VPN Network Access Control for DHCP Envir. E-mail Security Standards Capability-Based Usage Control Scheme A System For Public Keys for Network Transferring Objects Service Internet Commerce EDI: Concepts and Effects 3rd Gen Web Applications, Residential Economics of Internet Access Using Internet & Intranets What the Internet is Telling Us About Itself Small Businesses-Realities Case Studies A WWW Directory Service Architecture Online Stock Transactions Norwegian Tourism Industry NII in Taiwan Collaborative Environments The WebDesk Framework Multi-User Domains InterMUD Communications Multicasting Network Technology and Engineering Measurement and Statistics Network Technology Routing Satellite-based Networking ATM High Bandwidth Apps Plus additional sessions on: Policy and Regulation Education User Applications Regional Development A list of papers and panels, along with abstracts, can be viewed at: http://www.isoc.org/inet97 ********************************************* INET97 "THE INTERNET: GLOBAL FRONTIERS" The Seventh Annual Conference of the Internet Society 24-27 June 1997 Putra World Trade Center, Kuala Lumpur, Malaysia Pre-Conference Events: Technical Tutorial - June 23 and 24, 1997 K-12 Workshop - June 24, 1997 African Networking Symposium - June 24, 1997 Developing Countries Workshop - June 15-22, 1997 *********************************** The INET 97 registration fee covers attendance at all INET 97 conference sessions June 24-June 27, 1997: Opening Reception, Gala evening, luncheons, coffee breaks, and all conference materials, including the conference program, book of abstracts and CD-ROM proceedings. Pre-conference events have separate registration fees. DISCOUNTED ACCOMMODATIONS Discounted housing accommodations are available at three lovely hotels: The Pan Pacific Kuala Lumpur, The Legend and The Dynasty. DISCOUNTED AIRLINE RESERVATIONS Special INET97 airline rates are available for travel to and from Kuala Lumpur. The negotiated arrangements will reflect savings on all flights, and a savings of 15-50% on Malaysia Airlines, the Official Airline for INET97. TOURS Pre-and post-conference tours are available for INET 97 registrants. These tours emphasize culture, people, flora and fauna, with choices for all ages and economic standing. THE INTERNET SOCIETY (ISOC): is a nonprofit, non-governmental organization providing leadership in the management of the many issues and concerns which the new applications of the Internet are generating. Its diverse membership includes more than 100 key organizations and about 7,000 individual members in 150 countries. For more information, or to register: URL: http://www.isoc.org/inet97 Voice: +1 (703) 648-9888 Post: Internet Society Fax: +1 (703) 648-9887 12020 Sunrise Valley Drive, e-mail: Reston, Virginia U.S.A. 20191-3429 DON'T WAIT SIGN UP TODAY! From owner-ipsec Mon May 12 14:05:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29970 for ipsec-outgoing; Mon, 12 May 1997 14:04:21 -0400 (EDT) Message-Id: <199705121810.LAA02365@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: wdm@epoch.ncsc.mil (W. Douglas Maughan) Cc: jryder@vnet.ibm.com, ipsec@tis.com Subject: Re: Please help with answer to discrepancy question In-Reply-To: Your message of "Fri, 09 May 1997 15:38:36 EDT." <9705091938.AA01119@dolphin.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 1997 11:10:49 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, Jim, > > > > the figure shown in the > > , section 5.7.1 'Phase 1 using > > Oakley Main Mode', the first collections of payloads > > > > and > > > > > > the figure shown in the > > , section 3.6 'Transform Payload'. > > > > shows the RESERVED area of the Transform Payload (not the generic > > header RESERVED area), in both Transform 1 and 2 to be BETWEEN the > > 'Transform #' and the 'Transform-ID' fields. In example , I am > > assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. > > > > shows the RESERVED2 area of the Transform Payload (not the generic > > header RESERVED area), to be FOLLOWING the 'Transform-ID'. > > > I'll give you my interpretation, but we'll need to hear the same thing > from Dan Harkins and/or Dave Carrel (authors of the ISAKMP/Oakley > draft). If you look at section 4.1.1 of you'll see two full > examples of the payloads. I think the drawing in is leftover from > the format in the ISAKMP-05 or -06 Internet Draft. I believe the > agreement made between the ISAKMP, ISAKMP/Oakley, and IPSEC DOI I-D > editors was that the Transform # field and the Transform ID field were > together followed by the 2 octet RESERVED2 field. Again, we should hear > from Dan Harkins and/or Dave Carrel to make sure we're in agreement. Yes, that's right. The payload explosions in 5.7.1 of the resolution document are incorrect. The transform payload is as Doug describes. But, 5.7.1 is incorrect for another reason, and section 4.1.1 of the base ISAKMP draft shares this. Figure 6 and section 3.5 of the base ISAKMP draft show a spi-size field which denotes the size of the *variable length* SPI. Section 4.1.1 does not have this field and sets the SPI to 8 octets (same with 5.7.1 in the resolution document). Section 2.4 of the base ISAKMP draft says "For uniformity, all SPIs are 8 octets long" but this I think is a leftover from the ISAKMP-05 or ISAKMP-06 draft which did not contain a spi-size in the proposal payload. Doug, is this correct? The spi is, in fact, variable and it's size is determined by the spi-size field? > > 2) In listed above in question 1), 'OAKLEY' is in the > > 'Transform-ID' field. I have looked in and but I do not find the > > transform id values listed anywhere. I also looked in the > > but I don't see anything that looks > > like a really good answer there either. > > > > Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform > > value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' > > of the document? The transform-ID for phase 1 negotiation (as defined by the resolution doc) is the same as the protocol-- PROTO_ISAKMP from 4.4.1 of the DOI. The transform-IDs for other protocols are described later in the DOI under the respective protocol description. Dan. From owner-ipsec Mon May 12 15:03:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00305 for ipsec-outgoing; Mon, 12 May 1997 15:03:44 -0400 (EDT) Message-Id: <199705121909.MAA02432@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tom_Markham@securecomputing.com (Tom Markham) Cc: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com, ipsec@tis.com, cwilliams@cylink.com, balenson@tis.com, sabbott@tcel.com, gupta@us.ibm.com, isakmp-oakley@cisco.com Subject: Re: ISAKMP commit and notify usage In-Reply-To: Your message of "Wed, 07 May 1997 13:49:16 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 1997 12:09:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Tom, > I am trying to understand the usage of the ISAKMP commit bit flag and > notify messages. > > The ISAKMP header contains a flags field which contains a commit bit. When > set by the sender this tells the peer ISAKMP not to use the (ISAKMP or > IPSEC ?) SA until the sender transmits an informational exchange. > Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that > once an ISAKMP SA has been established, the Informational Exchange MUST be > transmitted under the protection provided by the ISAKMP SA. > > - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? It prevents use of the IPsec SAs. It wouldn't make sense to use this for phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to be intended for the forthcoming phase 2 exchange. The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley doc) is a 3 message exchange and upon receipt of the responder's only message, the initiator has all the information necessary to stuff the IPsec SAs into its SA table. If this is done before the final message is composed (a hash from initiator to responder) there is a possibility of that SA being used by the kernel (or IPsec process or whatever depending on your OS flavor). If the timing is right (or wrong I guess) valid IPsec packets could arrive at the responder before hash which completed the exchange and allowed the responder to stuff the SAs in its own SA table. These packets would be dropped. If the COMMIT bit was set by either party, the Quick Mode exchange would become a 4 message exchange and the initiator would not stuff its SAs until receipt of the notify message. The responder would stuff its SAs first. Yes, this would make it ready for use before the intiator was ready but since the initiator started this its got some packets queued up and waiting to be sent. It's unlikely that the responder also has packets queued up and waiting, it could, but it's just unlikely. The timing would have to be real horrible (and the SA would have to be sharable-- no PFS) for the responder to use the SA before the initiator was ready. Anyway, I personally don't see this as a big problem and haven't had any trouble using ISAKMP and IPsec without the COMMIT bit. > - What notify message type payload is used to commit/tell the peer ISAKMP > that it is time to start using the encryption key/SA? Good question. I think it's the CONNECTED notify message from 3.14.1. > - Is there an integrity check on the Notification Payload? Does each piece > of notification data define its own integrity mechanism? The OAKLEY error > payload appends a Sig/prf Payload. That is to be added to the next rev of the ISAKMP/Oakley document. Once the ISAKMP SA has been established SKEYID_a should be used to protect informational exchanges in the same fashion it is used to protect Quick Mode exchanges-- i.e. HDR*, HASH, NOTIFY. Where HASH = prf(SKEYID_a, M-ID, NOTIFY). regards, Dan. From owner-ipsec Tue May 13 13:30:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08060 for ipsec-outgoing; Tue, 13 May 1997 13:21:11 -0400 (EDT) Message-Id: <3.0.32.19970513102353.00920530@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 10:25:34 -0700 To: ipsec@tis.com From: John Burke Subject: Re: ISAKMP commit and notify usage Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe more needs to be said to clarify the need for Commit, and I believe Dan H. is not right to say, that Commit is not necessary in phase I. The strongest reason which demands use of Commit is, the possibility of losing the final message of an exchange in the network. ISAKMP is being used at the UDP layer and so has no protections against loss except its own prescription for retransmissions. The party who sends the final message has no indication that the message was lost and retransmission is required, particularly for the case where that party is going to send the first message afterward. A party sending the last message of Phase I, will sometimes have a Phase II initiation which they are going to send immediately after. But this should wait until the party receives confirmation from the other side. At 12:09 PM 5/12/97 -0700, Daniel Harkins wrote: > Hi Tom, > >> I am trying to understand the usage of the ISAKMP commit bit flag and >> notify messages. >> >> The ISAKMP header contains a flags field which contains a commit bit. When >> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or >> IPSEC ?) SA until the sender transmits an informational exchange. >> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that >> once an ISAKMP SA has been established, the Informational Exchange MUST be >> transmitted under the protection provided by the ISAKMP SA. >> >> - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? > > It prevents use of the IPsec SAs. It wouldn't make sense to use this for >phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to >be intended for the forthcoming phase 2 exchange. I would disagree that Commit is unnecessary in Phase I, per what I discuss above. > The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley >doc) is a 3 message exchange and upon receipt of the responder's only >message, the initiator has all the information necessary to stuff the IPsec >SAs into its SA table. If this is done before the final message is composed >(a hash from initiator to responder) there is a possibility of that SA >being used by the kernel (or IPsec process or whatever depending on your OS >flavor). If the timing is right (or wrong I guess) valid IPsec packets could >arrive at the responder before hash which completed the exchange and allowed >the responder to stuff the SAs in its own SA table. These packets would be >dropped. While it is okay that one designs protocol which makes it easier to work within the current operating systems, still such problems as Dan describes above actually constitute bugs in implementation either of the operating system or of the ISAKMP. One cannot hope to use net protocol design to fix all the bugs in various implementations. It is necessary however that protocol deal with the hostile net environments in which the user public generally will be operating, and assuming that all messages can be lost is one of the basics which net protocols must cover. > If the COMMIT bit was set by either party, the Quick Mode exchange would >become a 4 message exchange and the initiator would not stuff its SAs >until receipt of the notify message. The responder would stuff its SAs first. >Yes, this would make it ready for use before the intiator was ready but >since the initiator started this its got some packets queued up and waiting >to be sent. It's unlikely that the responder also has packets queued up and >waiting, it could, but it's just unlikely. The timing would have to be real >horrible (and the SA would have to be sharable-- no PFS) for the responder to >use the SA before the initiator was ready. > > Anyway, I personally don't see this as a big problem and haven't had any >trouble using ISAKMP and IPsec without the COMMIT bit. The fact that one hasn't had trouble at this point of experience in ISAKMP protocol does not strike me as evidence that protections are not needed. Some network environments are much more hostile than others and protocol design is supposed to deal with it. Cylink intends to take that line in its implementation. > [ other things: fine.] > regards, > > Dan. A further problem in the ISAKMP draft: it prescribes retransmissions even for the final message, but discusses no way in which one can be provoked to retransmit a final message. I think the following considerations are necessary. The final message can always be lost, even if it is the "Connected" message. The party who expects to receive the final message would in that case receive instead the encrypted traffic which follows (for the case of completing Phase I, read, a Phase II initiation). Now if the party was awaiting the "Connected" message, AND the received message can be verified as correct, they can assume the other party completed the SA. In all other cases the only action one can take here is, to retransmit the last ISAKMP message one sent, trying to provoke the partner to retransmit the final message. This implies that, if you are the party sending the final message, then you should retain that message for a while, with the SA establishment last-state; it can be saved in LRU buffers, and it can be discarded when you get evidence the partner has established the SA. Best regards, John Burke Cylink, Sunnyvale, CA. From owner-ipsec Tue May 13 21:01:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11030 for ipsec-outgoing; Tue, 13 May 1997 20:59:23 -0400 (EDT) Date: Tue, 13 May 1997 21:05:48 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704291302.JAA28064@earth.hpc.org> References: Yourmessage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: hugo@ee.technion.ac.il, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie + Hugo, As in my immediately preceeding message, I apologize for being tardy in my response. I've thought about the idea of including a null integrity transform in ESP, as you have both suggested, and I don't think it's a good idea. Note that there seems to be general agreement that using ESP w/o authentication is OK if one also applies AH to packets, so there is already a precendent for situations where no authentication algorithm would be selected. Thus, adding a null authentication algorithm would, I fear, create the potential for confusion, since it already would be appropriate thing to negotiate in some circumstances. Also, negotiation of a null authentication algorithm seems equivalent to negotiation of NO authentication algorithm, so I don't see the benefit from that perspective either. Instead, I suggest that we leave this section of ESP as it is, and note in the architecture document the security implications of not including authentication in ESP when Ah also is not applied to packets. That discussion will observe that some uses of AH with ESP avoid the need for autentication in ESP but that use of ESP without AH is dangerous in most other ciscumstances and thus such use should be negotiated only under very carefully controlled circumstances. Steve From owner-ipsec Tue May 13 21:01:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11018 for ipsec-outgoing; Tue, 13 May 1997 20:58:55 -0400 (EDT) Date: Tue, 13 May 1997 21:05:41 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199705011403.RAA24818@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@tis.com From: Stephen Kent Subject: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In an effort to reach closure on the suggested changes to the latest ESP spec, I suggest the following revision, in addition to my earlier message about authenticationless ESP: - The optional IV field will be removed; if an encryption algorithm requires an IV, it will be transmitted as the initial portion of the ciphertext payload. The definition of the encryption algorithm as provided for use with ESP, will specify the presence (or absence) or an IV, and describe its length. the recent I-Ds on RC5 and CAST adopt this approach to algorithm definition. I'm still not sure that we have concensus on what to do about the AR counter field in ESP. If authentication is NOT negotiated, then it seems somewhat odd to include this field. It would align the start of the payload on an 8-byte boundary, though this would not appear to be strictly required by IPv6 conventions. However, if folks rellly want the payload to be 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if authentication is not selected. I'm looking for feedback on this, so votes are solicited. Finally, in talking with a couple of active contributors, I've gotten the impression that there is support for encryptionless ESP, as defined in the current I-D. The argumemts are that this should be easy to implement (since it is just ESP without encryption turned on), it is more efficient than AH, and it is both appropriate and adequate in tunnel mode, as an alternative to tunnel mode AH. So, I'd like to conduct a straw poll on this topic too. Steve From owner-ipsec Tue May 13 21:01:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11019 for ipsec-outgoing; Tue, 13 May 1997 20:58:55 -0400 (EDT) Date: Tue, 13 May 1997 21:05:44 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704281959.MAA00938@dharkins-ss20.cisco.com> References: Your message of "Fri, 18 Apr 1997 11:31:42 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Daniel Harkins From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Sorry to be late in responding, but intervening conferences have kept me busy. The message I get is that the idea of negotiating the use of anti-replay, and of negotiating window size in AH (or ESP), is unattractive for several reasons: - this is really a recipient security concern, and thus need not be negotiated with the sender - it adds to the complexity of SA negotiation, making more work for implementors - more complex negotiations introduce the opportunity for security bugs These are all valid observations. However, I do find the argument about sender knowledge of the window size and fault isolation compeling. Just assuming that the receiver is enforcing AR abd that the window size is 32 is simple, but also simplistic. Also, when I tend to use the phrase "I don't find this argument compelling" it is usually wityh regard to changinf the status quo, i.e., an argument should be compelling to warrant changing the existing spec. I note that there are published I-Ds for additional AH transforms call for AR, but the base document does not, so a compliant implementation that chose to implement AR would have to negotiate a transform that included AR, separate from the default AR mode of no AR. So, the argument that needs to be compelling is why one ought to change from the published specs, which would require negotiation of AR. Nonetheless, I propose the following compromise. Have the sender always transmit the AR counter, thus preserving the 8-byte AH alignment when using the default auth data size of 12 bytes. Allow the receiver to determine, unilaterally, whether to check the AR counter, and to do so against a window size chosen byb the receiver. Make 32 the default window size, and allow for large window sizes, in multiples of 32. However, have the receiver notify the sender of the selected window size (if any) as part of the SA negotiation. This simplifies the negotiation since only the receiver needs tell the sender of the former's selected window size, but now the sender has specific info about the security service parameters empoyed on the SA. This differs from the implementors' agreement only in the last detail. Hopefully it does not introduce significant complexity (the receiver need only declare a constant response if it's election of AR is constant) in the code. What does the WG say? I'd like to receive straw poll votes on this. Steve From owner-ipsec Tue May 13 21:50:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11295 for ipsec-outgoing; Tue, 13 May 1997 21:50:33 -0400 (EDT) Message-Id: <3.0.32.19970514015549.008a4100@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 14 May 1997 01:55:55 +0000 To: Stephen Kent From: "Steven M. Bellovin" Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: Daniel Harkins , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:05 PM 5/13/97 -0400, Stephen Kent wrote: > >Nonetheless, I propose the following compromise. Have the sender always >transmit the AR counter, thus preserving the 8-byte AH alignment when using >the default auth data size of 12 bytes. Allow the receiver to determine, >unilaterally, whether to check the AR counter, and to do so against a >window size chosen byb the receiver. Make 32 the default window size, and >allow for large window sizes, in multiples of 32. However, have the >receiver notify the sender of the selected window size (if any) as part of >the SA negotiation. This simplifies the negotiation since only the >receiver needs tell the sender of the former's selected window size, but >now the sender has specific info about the security service parameters >empoyed on the SA. While I'm still not convinced that the receiver need say anything -- there are many more parameters one could send for fault isolation, such as TCP timer parameters and various queue length limits -- this is probably a reasonable compromise. I do feel fairly strongly that the AR field should always be present. When fields are in some sense optional, the question of whether or not to transmit them turns on the relative cost of possibly unneeded bytes versus the complexity of dealing with variable-format headers. In this case, I expect that the AR field will almost always be used; thus, it's worth carrying even for the rare cases where it would be ignored. Besides, the 8-byte alignment is important for IPv6. I ran some calculations on the space overhead for AH, using actual packet size distributions. With no AR field, we could possibly truncate the hash calculation to 8 bytes (though I suspect we'd actually use the full 16 bytes). The total space required was 6% over the base value. With AR, and a 12-byte HMAC, the overhead was 9%. The difference of 3% is a small fraction of the normal monthly traffic growth. I conclude that it's irrelevant to performance. I believe that I'm using old size distribution data, but since the trend has been towards increased packet sizes -- and hence for less of a percentage hit for a fixed increment -- my numbers are quite conservative. From owner-ipsec Wed May 14 10:24:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15643 for ipsec-outgoing; Wed, 14 May 1997 10:15:37 -0400 (EDT) From: svakil@usr.com Mime-Version: 1.0 Date: Wed, 14 May 1997 09:11:53 -0500 Message-ID: <379CD511.3000@usr.com> To: ipsec@tis.com Subject: Re[2]: ISAKMP commit and notify usage Content-Type: multipart/mixed; boundary="IMA.Boundary.334026368" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.334026368 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part John, Your example fits the phase 1 aggressive exchange. From the ISAKMP + Oakley draft: Oakley Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni, IDii --> 2. <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R 3. HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. If the responder sets the Commit flag in message #2, then how is the Initiator going to generate message #3? In 2, the responder tells the initator "Don't use the SA 'till you receive a notification from me". But, the initiator needs to use the signature algorithm from the SA to generate SIG_I in mesasge #3. So, the initiator waits for a notify message from the responder to generate message #3, and the responder waits for message #3 from the initiator to generate the notify!!! Seems like I'm missing something here. Sumit A. Vakil Software Engineer Routing Consulting Engineering US Robotics, Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP commit and notify usage Author: John Burke at Internet Date: 5/13/97 10:25 AM I believe more needs to be said to clarify the need for Commit, and I believe Dan H. is not right to say, that Commit is not necessary in phase I. The strongest reason which demands use of Commit is, the possibility of losing the final message of an exchange in the network. ISAKMP is being used at the UDP layer and so has no protections against loss except its own prescription for retransmissions. The party who sends the final message has no indication that the message was lost and retransmission is required, particularly for the case where that party is going to send the first message afterward. A party sending the last message of Phase I, will sometimes have a Phase II initiation which they are going to send immediately after. But this should wait until the party receives confirmation from the other side. At 12:09 PM 5/12/97 -0700, Daniel Harkins wrote: > Hi Tom, > >> I am trying to understand the usage of the ISAKMP commit bit flag and >> notify messages. >> >> The ISAKMP header contains a flags field which contains a commit bit. When >> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or >> IPSEC ?) SA until the sender transmits an informational exchange. >> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that >> once an ISAKMP SA has been established, the Informational Exchange MUST be >> transmitted under the protection provided by the ISAKMP SA. >> >> - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? > > It prevents use of the IPsec SAs. It wouldn't make sense to use this for >phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to >be intended for the forthcoming phase 2 exchange. I would disagree that Commit is unnecessary in Phase I, per what I discuss above. > The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley >doc) is a 3 message exchange and upon receipt of the responder's only >message, the initiator has all the information necessary to stuff the IPsec >SAs into its SA table. If this is done before the final message is composed >(a hash from initiator to responder) there is a possibility of that SA >being used by the kernel (or IPsec process or whatever depending on your OS >flavor). If the timing is right (or wrong I guess) valid IPsec packets could >arrive at the responder before hash which completed the exchange and allowed >the responder to stuff the SAs in its own SA table. These packets would be >dropped. While it is okay that one designs protocol which makes it easier to work within the current operating systems, still such problems as Dan describes above actually constitute bugs in implementation either of the operating system or of the ISAKMP. One cannot hope to use net protocol design to fix all the bugs in various implementations. It is necessary however that protocol deal with the hostile net environments in which the user public generally will be operating, and assuming that all messages can be lost is one of the basics which net protocols must cover. > If the COMMIT bit was set by either party, the Quick Mode exchange would >become a 4 message exchange and the initiator would not stuff its SAs >until receipt of the notify message. The responder would stuff its SAs first. >Yes, this would make it ready for use before the intiator was ready but >since the initiator started this its got some packets queued up and waiting >to be sent. It's unlikely that the responder also has packets queued up and >waiting, it could, but it's just unlikely. The timing would have to be real >horrible (and the SA would have to be sharable-- no PFS) for the responder to >use the SA before the initiator was ready. > > Anyway, I personally don't see this as a big problem and haven't had any >trouble using ISAKMP and IPsec without the COMMIT bit. The fact that one hasn't had trouble at this point of experience in ISAKMP protocol does not strike me as evidence that protections are not needed. Some network environments are much more hostile than others and protocol design is supposed to deal with it. Cylink intends to take that line in its implementation. > [ other things: fine.] > regards, > > Dan. A further problem in the ISAKMP draft: it prescribes retransmissions even for the final message, but discusses no way in which one can be provoked to retransmit a final message. I think the following considerations are necessary. The final message can always be lost, even if it is the "Connected" message. The party who expects to receive the final message would in that case receive instead the encrypted traffic which follows (for the case of completing Phase I, read, a Phase II initiation). Now if the party was awaiting the "Connected" message, AND the received message can be verified as correct, they can assume the other party completed the SA. In all other cases the only action one can take here is, to retransmit the last ISAKMP message one sent, trying to provoke the partner to retransmit the final message. This implies that, if you are the party sending the final message, then you should retain that message for a while, with the SA establishment last-state; it can be saved in LRU buffers, and it can be discarded when you get evidence the partner has established the SA. Best regards, John Burke Cylink, Sunnyvale, CA. --IMA.Boundary.334026368 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 378B28D0; Tue, 13 May 97 13:27:25 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id NAA24582; Tue, 13 May 1997 13:06:25 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08060 for ipsec-outgoing; Tue, 13 May 1997 13:21:11 -0400 (EDT) Message-Id: <3.0.32.19970513102353.00920530@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 10:25:34 -0700 To: ipsec@tis.com From: John Burke Subject: Re: ISAKMP commit and notify usage Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.334026368-- From owner-ipsec Wed May 14 12:32:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16579 for ipsec-outgoing; Wed, 14 May 1997 12:21:19 -0400 (EDT) Date: Wed, 14 May 1997 09:27:25 -0700 (MST) Message-Id: <199705141627.JAA09792@baskerville.CS.Arizona.EDU> From: "Mason J. Katz" To: ipsec@tis.com Subject: UofA linux ipsec release Sender: owner-ipsec@ex.tis.com Precedence: bulk ANNOUNCEMENT ------------ The University of Arizona, is releasing its first version of Linux IPSEC. Complete information about this software can be found at OVERVIEW -------- This software is based on the x-kernel and runs as a user space process with access to network traffic. A single Linux kernel loadable module is used to divert all incoming and outgoing Ethernet frames to an x-kernel process. Throughput for DES/MD5 traffic, measured on a 120Mhz Pentium, is approximately 220kb/s. Keys must be managed manually, or with Photuris. There is currently no support for ISAKMP/Oakley, and it does not support anti-replay counters. REQUIREMENTS ------------ - Linux Kernel V 2.0.x (Intel only) - Proven's Pthreads (available from webpage) BACKGROUND ---------- Over the course of this project, our research has focused on developing highly modular protocols for network security. We attempted to demonstrate that security enhancements could be added to a well-constructed protocol architecture in a manner that is easy, clean, and without unnecessary performance impact. We felt we demonstrated this with our x-kernel implementation, and chose a more standard platform for distributing our software. We then developed the idea of a dual-stack architecture based on Linux kernel loadable modules. This architecture allowed us to use all our previous work, without modification, and allows Unix applications to take advantage of a platform with stronger security mechanisms. Although we are not currently tracking the IPSEC architecture, we believe that the released version can be brought up to date and extended to allow for more services. It is being released as a reference architecture for adding advanced network capabilities to Linux and for experimenting with security policies. SURVEY ------ Name of Implementation : x-kernel IPSEC Version Described : 1.0 Organization : Univ. of Arizona, Dept of CS Which IP versions are supported : IPv4 Implements RFC-1828 AH MD5 : YES Implements RFC-1829 ESP DES-CBC : YES Implements AH HMAC MD5 : NO Implements AH HMAC SHA-1: NO Implements Combined ESP (DES+MD5+Replay, etc) : NO Other AH Implemented Transforms : NO Other ESP Implemented Transforms : ESP-3DES Transport mode : YES Tunnel mode : YES Key Management : Manual, Photuris (draft 8, Elliptical curves), Platforms : x-kernel, Linux Lineage of IPsec Code : University of Arizona Lineage of Key Mgmt Code: University of Arizona Location of Source Code : http://www.cs.arizona.edu/security/hpcc-blue/ linux.html ftp://ftp.cs.arizona.edu/xkernel/ xkernel.v3.2.security.tar.Z POINTS of Contact : Mason Katz Claimed Interoperability: From owner-ipsec Wed May 14 15:05:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17547 for ipsec-outgoing; Wed, 14 May 1997 14:46:44 -0400 (EDT) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" , "'svakil@usr.com'" Subject: RE: Re[2]: ISAKMP commit and notify usage Date: Wed, 14 May 1997 14:46:14 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the conclusion I came to when implementing the commit bit. For phase 1 I check for exchange type, if its not Aggressive I'll signal Invalid flag if the commit bit is set. It didn't seem to make much sense for Main Mode. ---- Greg Carter Entrust Technologies carterg@entrust.com >---------- >From: svakil@usr.com[SMTP:svakil@usr.com] >Sent: Wednesday, May 14, 1997 10:11 AM >To: ipsec@tis.com >Subject: Re[2]: ISAKMP commit and notify usage > ><> > John, > Your example fits the phase 1 aggressive exchange. > > From the ISAKMP + Oakley draft: > > Oakley Aggressive mode with signatures in conjunction with ISAKMP is > described as follows: > > Initiator Responder > ----------- ----------- > 1. HDR, SA, KE, Ni, IDii --> > > 2. <-- HDR, SA, KE, Nr, IDir, > [ CERT, ] SIG_R > > 3. HDR, [ CERT, ] SIG_I --> > > In both modes, the signed data, SIG_I or SIG_R, is the result of the > negotiated digital signature algorithm applied to HASH_I or HASH_R > respectively. > > If the responder sets the Commit flag in message #2, then how is the > Initiator going to generate message #3? In 2, the responder tells the > initator "Don't use the SA 'till you receive a notification from me". > But, the initiator needs to use the signature algorithm from the SA to > generate SIG_I in mesasge #3. So, the initiator waits for a notify > message from the responder to generate message #3, and the responder > waits for message #3 from the initiator to generate the notify!!! > Seems like I'm missing something here. > > Sumit A. Vakil > Software Engineer > Routing Consulting Engineering > US Robotics, Access Corp. > > > From owner-ipsec Wed May 14 15:20:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17646 for ipsec-outgoing; Wed, 14 May 1997 15:05:21 -0400 (EDT) Message-Id: <199705141911.PAA12081@codex.cis.upenn.edu> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Cc: kent@bbn.com Date: Wed, 14 May 1997 15:11:14 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I oppose encryptionless ESP. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM3oOUb0pBjh2h1kFAQGVVQQAoCGBpO4QJULgv/lDV9kg0TIp9m4EV+fs 2/696TtL/CV6WXqsD7Zo2xrKiCSff8aANBHfS1i3H7pGRQT/Hu40+KG7A/6BfoYh CswuFM7iOVNMEKAa8c1SQQsovnceBlAOdP+9as7Kv5DZM1uAFXoQHIioIJlnFR6Z 9cnT/8nSyCU= =0mHX -----END PGP SIGNATURE----- From owner-ipsec Wed May 14 15:25:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17664 for ipsec-outgoing; Wed, 14 May 1997 15:09:54 -0400 (EDT) Message-Id: <199705141915.PAA12106@codex.cis.upenn.edu> To: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: kent@bbn.com Date: Wed, 14 May 1997 15:15:27 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I don't like negotiating arbitrary AR sizes (even in multiples of 32). If 32 might not sufficient, then have a choice between 32 and 64. I sincerely doubt anyone will bother to implement anything larger. Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM3oPTr0pBjh2h1kFAQFQqwQAkluzPtdPQegly4kHVFfixmeifzXgKCNY UbJ2+bedYbOI+Pf8vdr7A02nwR4GN+lRuBhD6kjWTrdc86p/RoyYnpjiS1nMdJGg ucIOJwLILaQoxpSlQKt093p1f6A4DhOpzbHrK+SI9EuNFRGu7YQxalheLlNlK7PR TRaPjLiCglA= =t+hV -----END PGP SIGNATURE----- From owner-ipsec Wed May 14 15:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17903 for ipsec-outgoing; Wed, 14 May 1997 15:54:17 -0400 (EDT) Date: Wed, 14 May 1997 16:00:59 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705141915.PAA12106@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, Larger window sizes are multiples of 32, so the term "arbitrary" may be no more appropriate for them as it is for the base size of 32. Recall that we chose 32 mostly because of the ability to do efficient window management in a 32-bit machine, which is sort of arbitrary, right? There is no requirement for a receiver to support anything other than 32, so I'm not sure what (non-local) burden is implied if a receiver does choose to support bigger windows. However, if the Wg wants to mandate support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. Steve From owner-ipsec Wed May 14 15:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17909 for ipsec-outgoing; Wed, 14 May 1997 15:54:43 -0400 (EDT) Date: Wed, 14 May 1997 16:01:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705141911.PAA12081@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, I don't mean to say your vote (well, maybe I do ;-)), but could you briefly describe your reason for voting against encryptionless ESP? Steve From owner-ipsec Wed May 14 15:59:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17933 for ipsec-outgoing; Wed, 14 May 1997 15:59:47 -0400 (EDT) Message-Id: <199705142006.AA135450365@relay.hp.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Tue, 13 May 1997 21:05:41 -0400. Date: Wed, 14 May 1997 16:06:04 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > - The optional IV field will be removed; if an encryption algorithm > requires an IV, it will be transmitted as the initial portion of the > ciphertext payload. This makes sense and only impacts document modularity, not interoperability. I strongly support this proposal. > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. I'm mildly opposed to this, on the grounds that it complicates an authentication-only ipsec implementation. - Bill From owner-ipsec Wed May 14 16:10:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18003 for ipsec-outgoing; Wed, 14 May 1997 16:10:19 -0400 (EDT) Message-Id: <199705142017.AA150991028@relay.hp.com> To: Stephen Kent Cc: Daniel Harkins , ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: kent's message of Tue, 13 May 1997 21:05:44 -0400. Date: Wed, 14 May 1997 16:17:07 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Nonetheless, I propose the following compromise. Have the sender always > transmit the AR counter, thus preserving the 8-byte AH alignment when using > the default auth data size of 12 bytes. Allow the receiver to determine, > unilaterally, whether to check the AR counter, and to do so against a > window size chosen byb the receiver. Make 32 the default window size, and > allow for large window sizes, in multiples of 32. However, have the > receiver notify the sender of the selected window size (if any) as part of > the SA negotiation. Seems like a reasonable compromise. It should not require significant code for the sender to ignore the additional attribute; the receiver need only send it if it supports variable replay window sizes (and thus already has significant additional complexity); and, if the receiver erroneously omits the attribute but does support larger-than-default windows, you can still interoperate. The attribute should be defined as "replay window *at least* this large" - Bill From owner-ipsec Wed May 14 16:22:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18108 for ipsec-outgoing; Wed, 14 May 1997 16:21:22 -0400 (EDT) From: Uri Blumenthal Message-Id: <9705142026.AA55965@hawpub.watson.ibm.com> Subject: Re: ESP revisions straw poll To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 14 May 1997 16:26:29 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199705142006.AA135450365@relay.hp.com> from "Bill Sommerfeld" at May 14, 97 04:06:04 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 Bill Sommerfeld says: > > .......impression that there is support for encryptionless ESP, > > as defined in the current I-D. > > I'm mildly opposed to this........... Count me on. I rather dislike this feature and see no reason for its existence. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed May 14 16:32:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18176 for ipsec-outgoing; Wed, 14 May 1997 16:31:57 -0400 (EDT) Message-Id: <199705142034.QAA06294@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Stephen Kent cc: "Angelos D. Keromytis" , ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-reply-to: Your message of "Wed, 14 May 1997 16:00:59 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 May 1997 16:34:32 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > Larger window sizes are multiples of 32, so the term "arbitrary" > may be no more appropriate for them as it is for the base size of 32. > Recall that we chose 32 mostly because of the ability to do efficient > window management in a 32-bit machine, which is sort of arbitrary, right? > There is no requirement for a receiver to support anything other than 32, > so I'm not sure what (non-local) burden is implied if a receiver does > choose to support bigger windows. However, if the Wg wants to mandate > support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. I'm curious -- how wide to TCP windows get on a high bandwidth delay product link? Perry From owner-ipsec Wed May 14 16:57:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18370 for ipsec-outgoing; Wed, 14 May 1997 16:57:01 -0400 (EDT) Message-Id: <199705142103.RAA12759@codex.cis.upenn.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 14 May 1997 16:01:05 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13905.863643757.1@dsl.cis.upenn.edu> Date: Wed, 14 May 1997 17:02:38 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > > I don't mean to say your vote (well, maybe I do ;-)), but could you >briefly describe your reason for voting against encryptionless ESP? > Certainly; for one, i don't see the point. I don't think it's that much of a performance gain over straight AH. Second, it's yet another option, so yet another place where things can go wrong in an implementation. Finally (and most importantly), do we really want to allow some form of authentication where the IP header (the addresses) is *not* authenticated ? I believe we don't, but perhaps there is some reason for it ? -Angelos From owner-ipsec Wed May 14 17:11:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18444 for ipsec-outgoing; Wed, 14 May 1997 17:11:00 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199705142117.OAA10711@kebe.eng.sun.com> Subject: Re: ESP revisions straw poll To: ipsec@tis.com Date: Wed, 14 May 1997 14:17:31 -0700 (PDT) In-Reply-To: <9705142026.AA55965@hawpub.watson.ibm.com> from "Uri Blumenthal" at May 14, 97 04:26:29 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 Encryptionless ESP may cause more harm than good. By its nature, ESP is "encryption enabling technology" and is therefore not exportable w/o jumping through various hoops. Even if your product is only using encryptionless ESP, it may still have to jump through hoops. AH is not encryption enabling technology, and an AH that has IP or IPv6 as its next header (commonly called, "tunnel-mode AH") solves the problems an encryptionless ESP solves. Its only disadvantage is including some of the IP header fields in the AH computation. Given a (possibly slight) performance loss vs. legal headaches and hassles, I'll swallow the loss. Bottom line: I do not like encryptionless ESP. Dan From owner-ipsec Wed May 14 17:38:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18618 for ipsec-outgoing; Wed, 14 May 1997 17:38:07 -0400 (EDT) Message-Id: <199705142144.OAA04294@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Tue, 13 May 1997 21:05:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 14:44:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. I give this a thumbs down. I get the feeling that another generic tunneling protocol is being proposed with authenticationless ESP and encryptionless ESP. We're going to end up with EP and I don't think that's really solving the problem at hand. It has never made sense to me to have ESP not authenticate the outer IP header. I don't have any solid numbers on whether ESP authentication by itself is faster than AH authentication but my gut feeling is there can't be *that* big a difference. I also can't see why one wouldn't want to authenticate as much as possible. We've moved beyond simple wordsmithing in these changes. The patient is now under general anesthetic and we're carving a hole in his chest. In that light, I'd like to propose a final operation (if he was under local anesthetic I wouldn't dare). I'd like to see making authentication uniform. And, of course, doing away with encryptionless (and authenticationless) ESP. regards, Dan. From owner-ipsec Wed May 14 18:04:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18795 for ipsec-outgoing; Wed, 14 May 1997 18:04:16 -0400 (EDT) Message-ID: <337A37C4.6B19@redbacknetworks.com> Date: Wed, 14 May 1997 15:08:04 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Stephen Kent CC: ipsec@tis.com Subject: Re: ESP revisions straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't mean to say your vote (well, maybe I do ;-)), but could you > briefly describe your reason for voting against encryptionless ESP? Steve, I don't mean to sound pissy, but I'm a bit pissed. This issue was discussed quite a bit in Memphis. Quite a few people spoke out on both sides and then a show of hands was taken to see how folks felt. Overwhelmingly the consensus was NOT to have encryptionless ESP. You seem to disagree with this, and now it appears that you are using your handle on the documents to hold this issue in an endless state of discussion until your opinion wins out. Please, let move on and not kill IPSEC with endless document wrangling. Very good points have been made on both sides. But it's time to move on. Dave Carrel From owner-ipsec Wed May 14 18:55:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA19134 for ipsec-outgoing; Wed, 14 May 1997 18:55:23 -0400 (EDT) From: pau@watson.ibm.com Date: Wed, 14 May 1997 19:08:48 -0400 Message-Id: <9705142308.AA24508@secpwr.watson.ibm.com> To: kent@bbn.com Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: jasKIGeBNdcKCsKhmwHdmQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. > > Steve > > Steve, as a person who has been implementing IPSEC and KMP since 1994, I like to offer my $0.02 opinions against encryptionless ESP. 1. It would make it very confusing to distinguish between ESP and AH. This is serious because not all users/administartors of IPSEC are experts on IPSEC. If they are confused, they may define the wrong IPSEC policy and lose all security. 2. It would make it even harder to code/do ISAKMP negotiation. 3. AH does incur some extra overhead because it covers IP header. However, according to our actual measurement (published in the 5th USENIX UNIX Security Conf.), this overhead is trivial compared to time spent in computing MD5 digest. So I feel encryptionless ESP does not save that much. Whoever want peformance should optimize their crypto implementations; the saving would be much greater. Pau-Chen From owner-ipsec Wed May 14 19:33:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19377 for ipsec-outgoing; Wed, 14 May 1997 19:32:36 -0400 (EDT) Message-Id: <3.0.1.32.19970514190803.006fdafc@nntpd.lkg.dec.com> X-Sender: altamatt@nntpd.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 14 May 1997 19:08:03 -0400 To: Stephen Kent From: Matt Thomas Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com In-Reply-To: References: <199705141911.PAA12081@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:01 PM 5/14/97 -0400, Stephen Kent wrote: >Angelos, > > I don't mean to say your vote (well, maybe I do ;-)), but could you >briefly describe your reason for voting against encryptionless ESP? I'll give you mine. The first is that I want to ship an authentication- only IPsec implementation. This is real easy if all I have to deal with AH. If I have to worry about including support encryption-less ESP it will greatly complicate matters. If you want the attributes of an encryptionless ESP, modify the definition of AH to allow it, then get it to be negotiated (the default being the old AH behavior). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed May 14 19:38:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19395 for ipsec-outgoing; Wed, 14 May 1997 19:38:37 -0400 (EDT) Message-Id: <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> X-Sender: altamatt@nntpd.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 14 May 1997 19:43:41 -0400 To: Daniel Harkins , Stephen Kent From: Matt Thomas Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com In-Reply-To: <199705142144.OAA04294@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:44 PM 5/14/97 -0700, Daniel Harkins wrote: > We've moved beyond simple wordsmithing in these changes. The patient >is now under general anesthetic and we're carving a hole in his chest. >In that light, I'd like to propose a final operation (if he was under >local anesthetic I wouldn't dare). I'd like to see making authentication >uniform. And, of course, doing away with encryptionless (and >authenticationless) ESP. Hear. Hear. Except for the authenticationless. If only has to do AH to get the IP header, you don't want to do another authentication. (I'd rather see ESP follow the same exact rules as AH...) -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed May 14 20:04:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA19557 for ipsec-outgoing; Wed, 14 May 1997 20:04:09 -0400 (EDT) Message-Id: <199705150010.RAA04425@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Tue, 13 May 1997 21:05:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 17:10:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Nonetheless, I propose the following compromise. Have the sender always > transmit the AR counter, thus preserving the 8-byte AH alignment when using > the default auth data size of 12 bytes. Allow the receiver to determine, > unilaterally, whether to check the AR counter, and to do so against a > window size chosen byb the receiver. Make 32 the default window size, and > allow for large window sizes, in multiples of 32. However, have the > receiver notify the sender of the selected window size (if any) as part of > the SA negotiation. This simplifies the negotiation since only the > receiver needs tell the sender of the former's selected window size, but > now the sender has specific info about the security service parameters > empoyed on the SA. > > This differs from the implementors' agreement only in the last detail. > Hopefully it does not introduce significant complexity (the receiver need > only declare a constant response if it's election of AR is constant) in the > code. If I understand this correctly, the initiator of the KMP can choose to add this attribute to his security suite offering to inform the responder of his AR window size. He can also choose not to send it and the default is assumed by the responder. Likewise, the responder can choose to send this attribute back describing his AR window size regardless of whether the initiator sent one (and the attribute value the initiator sends has no bearing on the value the responder sends). In other words, this is not a negotiable attribute; it is an informational attribute. If that understanding isn't correct ignore the rest of this email but please straighten me out, While complexity isn't introduced, something else is. We'd always understood that the responder in the KMP would either accept or reject a proposed suite of services in its entirety and not change anything in the offer or add anything that wasn't in the offer. This changes that. Granted, it's a simple change and a check for "didn't add anything or change anything-- except for replay window size" is pretty easy, but I want the WG to realize this change is being proposed before a show of hands. IPsec SA negotiation takes place under the protection of the ISAKMP SA so I don't think this is opening up a security hole. In the way I understand this compromise, I'm fine with it. regards, Dan. From owner-ipsec Wed May 14 21:36:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA20127 for ipsec-outgoing; Wed, 14 May 1997 21:34:56 -0400 (EDT) Message-ID: <01BC6096.46834460@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , "'ipsec@tis.com'" Subject: RE: ESP revisions straw poll Date: Wed, 14 May 1997 18:40:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk No Optional IV. IV is included in payload. A good model now since we don't do varied keys a la Hughes anymore. Replay field always in the packet, always sent, used by receiver or not. Aligns the packet, fewer options, yada yada yada... Replay window size is irrelevant. No encryptionless ESP. Not enough gain (don't do a few byte moves/clears) for the complexity of another option. If we're going to do this, bag AH altogether and just make the MAC cover the header in ESP, as Dan, I think suggested. I believe this is what we agreed on in Memphis. -Rob -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Tuesday, May 13, 1997 6:06 PM To: ipsec@tis.com Subject: ESP revisions straw poll Folks, In an effort to reach closure on the suggested changes to the latest ESP spec, I suggest the following revision, in addition to my earlier message about authenticationless ESP: - The optional IV field will be removed; if an encryption algorithm requires an IV, it will be transmitted as the initial portion of the ciphertext payload. The definition of the encryption algorithm as provided for use with ESP, will specify the presence (or absence) or an IV, and describe its length. the recent I-Ds on RC5 and CAST adopt this approach to algorithm definition. I'm still not sure that we have concensus on what to do about the AR counter field in ESP. If authentication is NOT negotiated, then it seems somewhat odd to include this field. It would align the start of the payload on an 8-byte boundary, though this would not appear to be strictly required by IPv6 conventions. However, if folks rellly want the payload to be 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if authentication is not selected. I'm looking for feedback on this, so votes are solicited. Finally, in talking with a couple of active contributors, I've gotten the impression that there is support for encryptionless ESP, as defined in the current I-D. The argumemts are that this should be easy to implement (since it is just ESP without encryption turned on), it is more efficient than AH, and it is both appropriate and adequate in tunnel mode, as an alternative to tunnel mode AH. So, I'd like to conduct a straw poll on this topic too. Steve From owner-ipsec Wed May 14 23:40:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20674 for ipsec-outgoing; Wed, 14 May 1997 23:39:33 -0400 (EDT) Date: Thu, 15 May 97 03:02:02 GMT From: "William Allen Simpson" Message-ID: <5866.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > - The optional IV field will be removed; if an encryption algorithm > requires an IV, it will be transmitted as the initial portion of the > ciphertext payload. The definition of the encryption algorithm as provided > for use with ESP, will specify the presence (or absence) or an IV, and > describe its length. the recent I-Ds on RC5 and CAST adopt this approach > to algorithm definition. > Yes. This is what we have always wanted. > I'm still not sure that we have concensus on what to do about the AR > counter field in ESP. If authentication is NOT negotiated, then it seems > somewhat odd to include this field. It would align the start of the payload > on an 8-byte boundary, though this would not appear to be strictly required > by IPv6 conventions. However, if folks rellly want the payload to be > 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if > authentication is not selected. I'm looking for feedback on this, so votes > are solicited. > AR field (called "Sequence Number") should immediately follow the SPI. Always present, 8-byte aligned. It should start at 1. It should always be incremented by sender, even when authentication is not present. > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. > No. None of the arguments are compelling. - It is not needed, as we already have another mechanism. - any added complexity to negotiation adds complexity to implementation and testing. - the improvement in efficiency is in the measurement noise -- insignificant. On the other hand, as has been pointed out previously, we are powerless to stop someone from creating a "null encryption" transform. But, it should not be part of the base specification. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu May 15 09:00:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23679 for ipsec-outgoing; Thu, 15 May 1997 08:59:10 -0400 (EDT) Message-Id: <3.0.32.19970515130122.008ade80@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 15 May 1997 13:02:24 +0000 To: perry@piermont.com From: "Steven M. Bellovin" Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: Stephen Kent , "Angelos D. Keromytis" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:34 PM 5/14/97 -0400, Perry E. Metzger wrote: > >Stephen Kent writes: >> Larger window sizes are multiples of 32, so the term "arbitrary" >> may be no more appropriate for them as it is for the base size of 32. >> Recall that we chose 32 mostly because of the ability to do efficient >> window management in a 32-bit machine, which is sort of arbitrary, right? >> There is no requirement for a receiver to support anything other than 32, >> so I'm not sure what (non-local) burden is implied if a receiver does >> choose to support bigger windows. However, if the Wg wants to mandate >> support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. > >I'm curious -- how wide to TCP windows get on a high bandwidth delay >product link? We're talking apples and oranges here -- the "window" under discussion for ipsec is the out-of-order packet window, which has little to do with the size of a TCP window. The former is intended to protect us against routing and network-level weirdnesses; the latter is a bound on performance. But if you're interested in the TCP window size, see RFC1323. Briefly, though, the effective window size variable is raised to 32 bits from 16. Thus, you can get really good performance if you can allocate 4 gigabytes of main memory for TCP input buffers... From owner-ipsec Thu May 15 10:49:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24448 for ipsec-outgoing; Thu, 15 May 1997 10:46:58 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 09:46:45 -0500 To: Greg Carter From: Tom_Markham@securecomputing.com (Tom Markham) Subject: RE: Re[2]: ISAKMP commit and notify usage Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >This is the conclusion I came to when implementing the commit bit. >For phase 1 I check for exchange type, if its not Aggressive I'll signal >Invalid flag if the commit bit is set. It didn't seem to make much >sense for Main Mode. >---- I do not see anything in the ISAKMP spec which limits the use of the commit bit to the agressive mode. Granted this may have been the driving reason for the commit. I would like to allow the general use of the commit bit by initiator or responder in any mode. This allows support for security policies and implementations (e.g. multicast) which may require ISAKMP to access another machine prior to allowing encrypted traffic to flow. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 11:37:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24813 for ipsec-outgoing; Thu, 15 May 1997 11:37:13 -0400 (EDT) Message-Id: <199705151533.IAA05289@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tom_Markham@securecomputing.com (Tom Markham) Cc: Greg Carter , ipsec@tis.com Subject: Re: Re[2]: ISAKMP commit and notify usage In-Reply-To: Your message of "Thu, 15 May 1997 09:46:45 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 08:33:36 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > >This is the conclusion I came to when implementing the commit bit. > >For phase 1 I check for exchange type, if its not Aggressive I'll signal > >Invalid flag if the commit bit is set. It didn't seem to make much > >sense for Main Mode. > >---- > > I do not see anything in the ISAKMP spec which limits the use of the commit > bit to the agressive mode. Granted this may have been the driving reason > for the commit. I witnessed the birth of the commit bit and it's driving reason was for phase 2 exchanges (Quick Mode). Period. > I would like to allow the general use of the commit bit by initiator or > responder in any mode. This allows support for security policies and > implementations (e.g. multicast) which may require ISAKMP to access another > machine prior to allowing encrypted traffic to flow. How (and why!) would you use this bit in a phase 1 exchange? How does multicast change anything? Phase 1 merely establishes the ISAKMP peer-to-peer communication channel. I don't see the point in using the commit bit there. Dan. From owner-ipsec Thu May 15 12:19:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24990 for ipsec-outgoing; Thu, 15 May 1997 12:17:51 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 11:20:51 -0500 To: Daniel Harkins From: Tom_Markham@securecomputing.com (Tom Markham) Subject: Re: Re[2]: ISAKMP commit and notify usage Cc: Tom_Markham@securecomputing.com (Tom Markham), Greg Carter , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 8:33 AM 5/15/97, Daniel Harkins wrote: >How (and why!) would you use this bit in a phase 1 exchange? How does >multicast change anything? Phase 1 merely establishes the ISAKMP peer-to-peer >communication channel. I don't see the point in using the commit bit there. I was not clear. I agree that the commit bit is used to hold off phase 2 exchanges. Using commit to hold off part of a phase 1 exchange does not make sense. Greg wrote >This is the conclusion I came to when implementing the commit bit. >For phase 1 I check for exchange type, if its not Aggressive I'll signal >Invalid flag if the commit bit is set. It didn't seem to make much >sense for Main Mode. Greg implied that commit was only valid in agressive mode and I am saying that there may be other times when the commit bit could be used. I gave multicast as an example of when commit *might* be used. I have not seen any multicast, IPSEC/ISAKMP systems yet so I do not want to take away a tool which might be useful to them. Here is a hypothetical situation which does not involve multicast. Imagine someone behind a firewall establishing a SA from their desktop to a remote server. 1. Their workstation does the ISAKMP exchange with the remote server to establish the AH and ESP keys. The firewall would allow ISAKMP exchanges through because it could perform some filtering. 2. Their workstation passes the AH (but not ESP) key to the firewall so the firewall can authenticate packets before letting them pass. 3. The server and workstation begin exchanging IPSEC (AH and ESP) protected traffic. The firewasl allows authenticated AH packets to bypass the remaining firewall filters. In this case I would use the commit bit to hold off IPSEC traffic until I had the AH key in place in the firewall. I hope this reduces the confusion. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 13:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25682 for ipsec-outgoing; Thu, 15 May 1997 13:48:11 -0400 (EDT) Message-Id: <199705151753.NAA14039@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Re[2]: ISAKMP commit and notify usage In-reply-to: Your message of "Thu, 15 May 1997 11:20:51 CDT." Date: Thu, 15 May 1997 13:53:03 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tom" == Tom Markham writes: Tom> Greg implied that commit was only valid in agressive mode and Tom> I am saying that there may be other times when the commit bit Tom> could be used. I don't agree that your scenario is reasonable. I have no opinion about the commit bit though. Tom> I gave multicast as an example of when commit *might* be Tom> used. I have not seen any multicast, IPSEC/ISAKMP systems yet Tom> so I do not want to take away a tool which might be useful to Tom> them. Here is a hypothetical situation which does not involve Tom> multicast. Imagine someone behind a firewall establishing a Tom> SA from their desktop to a remote server. Tom> 1. Their workstation does the ISAKMP exchange with the remote Tom> server to establish the AH and ESP keys. The firewall would Tom> allow ISAKMP exchanges through because it could perform some Tom> filtering. Tom> 2. Their workstation passes the AH (but not ESP) key to the Tom> firewall so the firewall can authenticate packets before Tom> letting them pass. How do you pass the key to the firewall? Write that spec, then let's talk about the commit bit :-) :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM3tNdqZpLyXYhL+BAQHp/QMAtRSWkYAgnVsz4/QqOduabZ/D1ij04qxz rVFXjUucMgUpelvxVrtLURT0AQDJVe470wFPgA0Ig8mnSweXPZA6WWBhcyyUDrNF DSooK0a7k2P7vfamJYUKGE0UmwPo2DPb =xN3/ -----END PGP SIGNATURE----- From owner-ipsec Thu May 15 14:34:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25953 for ipsec-outgoing; Thu, 15 May 1997 14:33:56 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-revised-enc-mode-00.txt Date: Thu, 15 May 1997 14:32:24 -0400 Message-ID: <9705151432.aa13211@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 Security Protocol Working Group of the IETF. Title : A revised encryption mode for ISAKMP/Oakley Author(s) : R. Canetti, P. Cheng, H. Krawczyk Filename : draft-ietf-ipsec-revised-enc-mode-00.txt Pages : 6 Date : 05/06/1997 The ISAKMP/Oakley document [HC97] describes a proposed standard for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. The public-key encryption method of carrying out Phase 1 of the key exchange in the ISAKMP/Oakley document requires two public key encryption and decryption operations from both the Initiator and the Responder. The present document describes a small modification to this method. The resulting method requires only one public key encryption and decryption operation from each party, while maintaining (and even improving on) the strong security properties of the ISAKMP/Oakley public-key encryption mode. Remark: This document is NOT self-contained. It uses notation and definitions of [HC97]. It is best read in conjunction with [HC97]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-enc-mode-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-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-ipsec-revised-enc-mode-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: <19970515142834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-enc-mode-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970515142834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu May 15 15:01:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26067 for ipsec-outgoing; Thu, 15 May 1997 14:58:34 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 14:00:36 -0500 To: dharkins@cisco.com From: Tom_Markham@securecomputing.com (Tom Markham) Subject: Re: Re[2]: ISAKMP commit and notify usage Cc: Greg Carter , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks I am clearly confused about the use of the commit bit. Is the following is a valid interpretation. The commit bit refers to use of the "following association." If the commit bit is set during phase 1, it means not to begin phase 2 until the notify/connected is received. If the commit bit is set during phase 2, it means not to send the IPSEC traffic until the notify/connected is received. Commit does not mean that exchanges within the current phase are not encrypted. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 15:23:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26230 for ipsec-outgoing; Thu, 15 May 1997 15:22:39 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142103.RAA12759@codex.cis.upenn.edu> References: Your message of "Wed, 14 May 1997 16:01:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:26:47 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos and Pau, As I mentioned in my message, the most obvious apporpriate use of ESP w/o encryption is in tunnel mode, where authenitcation of the outer IP addresses does not appear to be critical. This is a common scenario for VPNs, and might be used in conjunction with a transport mode encypted ESP, in nested fashion, e.g., to provide security to a server or desktop behind the firewall. As for the performance concern, we disagree. We are implementing ESP without encryption, in tunnel mode, for inter-router authentication and our analysis suggested that this was preferable to AH in tunnel mode. While I agree with Pau's observation that the greatest gain in a software implementation is to be had in better hash algorithm implementations, there is still the issue of the additional hit due to header copying. Also, I have been approached by some folks who are looking to implement ESP in hardware (e.g., outboard of a supercomputer). The selective authentication characteristics of AH make that hard, while the ESP pure encapsulation design is amenable to efficient DMA processing. Steve From owner-ipsec Thu May 15 15:23:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26224 for ipsec-outgoing; Thu, 15 May 1997 15:22:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142034.QAA06294@jekyll.piermont.com> References: Your message of "Wed, 14 May 1997 16:00:59 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:21:55 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, A good question, but one that requires translating from TCP window measurements (in bytes) to IPSEC units (packets), as Steve Bellovin pointed out. I don't know who has the data to make this translation. However, we have seen smoe statistics cited that note modest numbers of packets arriving out of order in some circumstances, and that prompted us to abandon the window size of 1 that had been in a previous draft of AH. It is the lack of good data in this area, plus the move to bigger, faster pipes, that makes it hard to figure out if 32 or 64 is big enough, although such numbers seem reasonable for today's Internet. Steve From owner-ipsec Thu May 15 15:44:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26359 for ipsec-outgoing; Thu, 15 May 1997 15:44:20 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142144.OAA04294@dharkins-ss20> References: Your message of "Tue, 13 May 1997 21:05:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:47:56 -0400 To: Daniel Harkins From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, We have a serious communication problem here. ESP has always had a tunnel mode; the previous AH I-D and the architecture I-D lacked references to a tunnel mode for AH, and this has been fixed in the latest versions. I'm sure you are familiar with the existing RFCs and they explicitly do not mandate authentication for ESP, i.e., not all transforms include such functionality. I don't recall if you were a participant in the early days of the WG, but originally AH was envisioned as providing just authentication and ESP just encryption. We later expanded ESP to provide authentcation, because it was more efficient than having a separate AH layer. I recall this clearly, because I argued that it was appropriate. ESP is a clean encapsulation protocol, with a header and trailer. AH is a rather ungainly protocol, in that it reaches forward and selectively protects portions of the IP header. As I noted in another message today, this complicates implementations striving for a high degree of hardware integration. In IPv6, what is protected can become even more complex, given the increased complexity of the IP header structure. In most cases, not including the few parts of the IP header that are covered by AH (at least in IPv4) would seem to have relatively few security implications; in tunnel mode it seems largely superflous as most of the outer header fields would be discarded upon receipt anyway. In transport mode the source IP address would be unique relative to the SPI, so here too the need for such coverage seem minor. The obvious v4 motivation for AH is use of security labels, but these are very, very rarely used in the Internet; RFC 1108 is now historical! In v6, the source route extension is the best candiadte for coverage, so far. Thus there appear to be relatively few IP header fields (or options/extensions) that ARE covered by AH and that have security implications. Exactly what security problems do folks feel arise if none of the IP header is integrity protected, in each of the contexts cited above? I do have a suggestion, though, to help reach closure on this topic. What if we say that an IPSEC implementation MAY elect to send packets that are authenticated, but not encrypted? That makes the existing implementations compliant in this regard, yet holds open th opportunity for future implementations to offer this feature if there is sufficinet demand. An attempt to negotiate a set of algorithms that includes no encryption can be rejected just like an attempt to negotiate use of an encryption algorithm that is not supported. One could even encode this as a null encryption algorithm, as Bill Simpsom noted, if that would make processing any more uniform. Steve From owner-ipsec Thu May 15 15:44:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26373 for ipsec-outgoing; Thu, 15 May 1997 15:44:52 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> References: <199705142144.OAA04294@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:50:27 -0400 To: Matt Thomas From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, Proposing that ESP authentication be changed to operate the same way as AH would represent a major change, at a time when I hear implementors arguing strongly against making changes. Let me refer you to my very recent message that questions what security problems arise, in tunnel and transport modes, if undetected modification of IP headers and options take place. In performing the analysis, keep in mind what fields/options/extensions are covered by AH (the answer is very few) and what level of muxing can occur in each mode, relative to the IP address info. Steve From owner-ipsec Thu May 15 16:14:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26489 for ipsec-outgoing; Thu, 15 May 1997 16:09:52 -0400 (EDT) Message-Id: <199705152014.AA072247290@relay.hp.com> To: Matt Thomas Cc: Daniel Harkins , Stephen Kent , ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: matt.thomas's message of Wed, 14 May 1997 19:43:41 -0400. <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> Date: Thu, 15 May 1997 16:14:50 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hear. Hear. Except for the authenticationless. If [one] has to do AH > to get the IP header, you don't want to do another authentication. (I'd > rather see ESP follow the same exact rules as AH...) Hmm. Why can't you just do tunnel mode ESP in that case, where the inner IP header is the one which really needs protecting. - Bill From owner-ipsec Thu May 15 17:29:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26898 for ipsec-outgoing; Thu, 15 May 1997 17:28:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142117.OAA10711@kebe.eng.sun.com> References: <9705142026.AA55965@hawpub.watson.ibm.com> from "Uri Blumenthal" at May 14, 97 04:26:29 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:29:19 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald), Matt Thomas From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan and Matt, If you ship AH by itself, you will be have an authention-only offering, but it won't be a complete IPSEC. That's fine for IPv4, and non-comliant for IPv6. For IP v6 compliance, both AH and ESP are required, thus whether we include or exclude an encryptionless mode of ESP will not affect the export license status of IPv6 implementations that, as required, support IPSEC. For IPv4, you are right that having an encryptionless mode of ESP will not make it easier to export ESP, but then it won't make it any harder either. I don't know about the rest of the WG members, but I do have personal experience in getting export licenses for crypto technology I have developed at BBN, so I appreciate what is involved. Nonetheless, the bottom line is that this proposed feature set for ESP will not change its export status. I don't think that I suggested otherwise in the discussion, but I apologize if anyone misunderstood the intent of the proposal. Steve From owner-ipsec Thu May 15 17:33:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26964 for ipsec-outgoing; Thu, 15 May 1997 17:33:41 -0400 (EDT) Date: Thu, 15 May 1997 17:40:21 -0400 (EDT) Message-Id: <199705152140.RAA10428@jekyll.piermont.com> From: "Perry E. Metzger" To: ipsec@tis.com Subject: ESP without encryption Reply-to: perry@piermont.com X-Reposting-Policy: please ask before redistributing Sender: owner-ipsec@ex.tis.com Precedence: bulk I think the ESP without encryption issue was settled at Memphis -- for good or ill, consensus seemed to be "no ESP without encryption" and it appears that consensus continues to be that way. I think we should accept the consensus and move on. Perry From owner-ipsec Thu May 15 17:45:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27031 for ipsec-outgoing; Thu, 15 May 1997 17:45:41 -0400 (EDT) Message-Id: <199705152152.OAA05636@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Thu, 15 May 1997 15:47:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 14:52:01 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, As Strother Martin said in Cool Hand Luke, "What we haf he-uh, is a faili-yure to com-yune-a-cate". (It's hard to effect an accent in email, but I'm sure you're familiar with that famous quote and the southified manner in which is was made). I'm not a IPsec old timer but I am familiar with the existing RFCs; I know ESP has always had a tunnel mode and I know that the previous AH doc did not. I also remember the discussions to add authentication to ESP. What I was suggesting was to have uniformity in authentication. That is, to have ESP include the intransient fields of the outer IP header in its integrity check in the same fashion as AH does. I was not suggesting that AH be scrapped nor was I suggesting adding tunnelling capability to a protocol that already has it. I know this is a new suggestion and perhaps it will be shot down but since the changes being discussed on this list will change the bits-on-the-wire I felt it was not inappropriate to suggest it. The ungainlyness of such a protocol is in the eye of the beholder, I guess. To me, ESP is a security protocol, not a generic tunnelling protocol. It could be made into a generic tunnelling protocol by making encryption and authentication optional I don't see the point. If you need a "clean encapsulating protocol" then why not use GRE tunnels (RFC1701)? My proposal is that AH does authentication, ESP does encryption with authentication. And the scope of the integrity check is identical for each. Dan. > We have a serious communication problem here. ESP has always had a > tunnel mode; the previous AH I-D and the architecture I-D lacked references > to a tunnel mode for AH, and this has been fixed in the latest versions. > I'm sure you are familiar with the existing RFCs and they explicitly do not > mandate authentication for ESP, i.e., not all transforms include such > functionality. I don't recall if you were a participant in the early days > of the WG, but originally AH was envisioned as providing just > authentication and ESP just encryption. We later expanded ESP to provide > authentcation, because it was more efficient than having a separate AH > layer. I recall this clearly, because I argued that it was appropriate. > > ESP is a clean encapsulation protocol, with a header and trailer. > AH is a rather ungainly protocol, in that it reaches forward and > selectively protects portions of the IP header. As I noted in another > message today, this complicates implementations striving for a high degree > of hardware integration. In IPv6, what is protected can become even more > complex, given the increased complexity of the IP header structure. > > In most cases, not including the few parts of the IP header that > are covered by AH (at least in IPv4) would seem to have relatively few > security implications; in tunnel mode it seems largely superflous as most > of the outer header fields would be discarded upon receipt anyway. In > transport mode the source IP address would be unique relative to the SPI, > so here too the need for such coverage seem minor. The obvious v4 > motivation for AH is use of security labels, but these are very, very > rarely used in the Internet; RFC 1108 is now historical! In v6, the source > route extension is the best candiadte for coverage, so far. Thus there > appear to be relatively few IP header fields (or options/extensions) that > ARE covered by AH and that have security implications. > Exactly what security problems do folks feel arise if none of the IP header > is integrity protected, in each of the contexts cited above? > > I do have a suggestion, though, to help reach closure on this > topic. What if we say that an IPSEC implementation MAY elect to send > packets that are authenticated, but not encrypted? That makes the existing > implementations compliant in this regard, yet holds open th opportunity for > future implementations to offer this feature if there is sufficinet demand. > An attempt to negotiate a set of algorithms that includes no encryption can > be rejected just like an attempt to negotiate use of an encryption > algorithm that is not supported. One could even encode this as a null > encryption algorithm, as Bill Simpsom noted, if that would make processing > any more uniform. From owner-ipsec Thu May 15 18:20:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27171 for ipsec-outgoing; Thu, 15 May 1997 18:20:04 -0400 (EDT) Message-Id: <199705152204.AA225823849@relay.hp.com> To: Stephen Kent Cc: Dan.McDonald@Eng.sun.com (Dan McDonald), Matt Thomas , ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Thu, 15 May 1997 15:29:19 -0400. Date: Thu, 15 May 1997 18:04:07 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Your experiences are directly at odds with my experiences dealing with export control issues, where frameworks (like ESP) which provide for end-user-accessible bulk encryption are problematic even if the encryption functionality is disabled. I suspect that we may be seeing the ... subjective ... nature of the crypto export control process at work here. - Bill From owner-ipsec Thu May 15 19:14:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27419 for ipsec-outgoing; Thu, 15 May 1997 19:12:10 -0400 (EDT) Message-Id: <199705152318.TAA20621@codex.cis.upenn.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Thu, 15 May 1997 15:26:47 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15536.863738248.1@dsl.cis.upenn.edu> Date: Thu, 15 May 1997 19:17:28 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > As I mentioned in my message, the most obvious apporpriate use of >ESP w/o encryption is in tunnel mode, where authenitcation of the outer IP >addresses does not appear to be critical. This is a common scenario for >VPNs, and might be used in conjunction with a transport mode encypted ESP, >in nested fashion, e.g., to provide security to a server or desktop behind >the firewall. I still believe AH is what they should do. > As for the performance concern, we disagree. We are implementing >ESP without encryption, in tunnel mode, for inter-router authentication and >our analysis suggested that this was preferable to AH in tunnel mode. >While I agree with Pau's observation that the greatest gain in a software >implementation is to be had in better hash algorithm implementations, there >is still the issue of the additional hit due to header copying. Also, I >have been approached by some folks who are looking to implement ESP in >hardware (e.g., outboard of a supercomputer). The selective authentication >characteristics of AH make that hard, while the ESP pure encapsulation >design is amenable to efficient DMA processing. I didn't notice any significant differences in performance in any of the pure-software implementations i've been involved in. Following the rule of "optimizing the common case", i'd still optimize the hash function first. Also, i think the cost of header copying is probably overestimated; if one keeps enough space in the begining of the buffer/mbuf/skbuf/whatever, it is possible to do all the copying in the processor cache (L1). This is really minimal overhead. This also solves the hardware hashing problem (and for large packets, copying the header won't matter if you also have to copy the whole packet in a contiguous memory block, as opposed to it being in an mbuf chain or what have you). I'm not saying you don't have some arguments in favour of encryptionless ESP. However: a) the implementors at Memphis decided against it b) i've seen no one speak publically for it on the list except you c) i've talked to two people off the list who are for it, and one changed his mind d) it's about time we stop arguing So, i'll insist on no encryptionless ESP. Regards, -Angelos From owner-ipsec Thu May 15 20:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27775 for ipsec-outgoing; Thu, 15 May 1997 20:18:49 -0400 (EDT) Message-Id: <3.0.1.32.19970515202057.0076ef58@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 15 May 1997 20:20:57 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: revisions denial-of-draft attack Cc: jis@MIT.EDU, iab@ietf.org, PALAMBER@us.oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >From: David Carrel >To: Stephen Kent >Please, let move on and not >kill IPSEC with endless document wrangling. This sentiment might well have rough consensus. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition iQCVAgUBM3uoVcKmlvJNktGxAQHz0AQAqxqr9MHzv1ZowCJYVxngHVSzhWAWkuQT W5zqgKvyFqRwCXQFytiSDskwATGpIc9pB34cOe6wkQAtLElsgpYomKuyDWdrxXxo N8B+OCSu3bsH5OJDVVRJDgG/7T8iT6TaL8/C2HzLWxlKkI941esss3txyv7fviuE xbqcYGG+6sk= =2901 -----END PGP SIGNATURE----- From owner-ipsec Fri May 16 04:48:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00052 for ipsec-outgoing; Fri, 16 May 1997 04:45:05 -0400 (EDT) From: suren@teil.soft.net (S. Arockia Suren) Message-Id: <199705161947.OAA06335@teil.soft.net> Subject: Clarification please! To: ipsec@tis.com Date: Fri, 16 May 1997 14:17:05 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I beleive all negotiated SAs (ISAKMP SA as well Protocol SA) are bidirectional. The exchange of the respective SPI indicates so. Also the new exchanges described in Oakley resolution are also bidirectional. But ISAKMP draft says .. "Thus, ISAKMP SAs are bidirectional in nature". Is this only for ISAKMP SAs are also for Protocol SAs. Is there a possibility that Protocol SAs could be unidirectional either now or in the future. Thankx in advance, Suren. From owner-ipsec Fri May 16 08:55:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01363 for ipsec-outgoing; Fri, 16 May 1997 08:54:22 -0400 (EDT) Date: Fri, 16 May 1997 08:57:23 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705161257.IAA08949@earth.hpc.org> To: suren@teil.soft.net Cc: ipsec@tis.com In-reply-to: Yourmessage <199705160858.BAA04918@baskerville.CS.Arizona.EDU> Subject: Re: Clarification please! Sender: owner-ipsec@ex.tis.com Precedence: bulk ESP and AH SA's are unidirectional. Oakley facilitates negotiation of a pair of SPI's, each one referring to a unique SA, going in "opposite" directions. You might think of the pair as being a bi-directional SA, but the terminology is probably more confusing than helpful. Hilarie From owner-ipsec Fri May 16 10:27:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01837 for ipsec-outgoing; Fri, 16 May 1997 10:25:01 -0400 (EDT) From: suren@teil.soft.net (S. Arockia Suren) Message-Id: <199705170130.UAA21421@teil.soft.net> Subject: Re: Clarification To: ipsec@tis.com Date: Fri, 16 May 1997 20:00:56 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> I beleive all negotiated SAs (ISAKMP SA as well Protocol SA) >> are bidirectional. The exchange of the respective SPI indicates >> so. Also the new exchanges described in Oakley resolution >> are also bidirectional. But ISAKMP draft says .. "Thus, ISAKMP >> SAs are bidirectional in nature". Is this only for ISAKMP SAs >> are also for Protocol SAs. Is there a possibility that Protocol >> SAs could be unidirectional either now or in the future. >> > ESP and AH SA's are unidirectional. > > Oakley facilitates negotiation of a pair of SPI's, each one referring to > a unique SA, going in "opposite" directions. You might think of the pair > as being a bi-directional SA, but the terminology is probably more confusing > than helpful. > > Hilarie I agree. ISAKMP SAs are bidrectional because any of the negotiators can start phase2. Similarly after oakley negotiations any party can start to send IP packets. I would like to know if the later would be true in the future also. Does ISAKMP allow negotiations that will be used in only one direction inspite of SPIs exchanged. Suren. From owner-ipsec Fri May 16 12:43:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02672 for ipsec-outgoing; Fri, 16 May 1997 12:39:46 -0400 (EDT) Date: Fri, 16 May 1997 12:43:00 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705161643.MAA15687@earth.hpc.org> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been very puzzled by the opposition to auth-only ESP, so much so that I went back and reviewed messages from August 1995, in which I had tried to suggest it, and in which I thought there had been rough consensus that it was a good idea. Disappointingly, I now see that I was overly subtle, and the concept was confused with tunneling AH. But for the volume of IPSO argument at the time, I would have continued arguing for it back then. Auth-only ESP seems to be completely consistent with the design goals of the working group; note that encryption is entirely up to the sender in any case, so Steve Kent's suggestion that it MAY be done seems completely reasonable. Seriously, how can a group that bought into AH view an accommodation for auth-only as more than a triviality in terms of implementation? If belief has any merit in this discussion, and I note that more and more responses seem to be appealing to subjectivity, I believe that the market will ultimately choose to use ESP and ignore AH, and I further believe that this will be a good thing. In full honesty, I was concerned about the comment that suggested key negotiation would be more difficult with auth-only ESP, and I was hoping that someone with a little spare time could check on whether or not this is true; key negotiation requires confidentiality for some part of the exchange, and if there is a possibility of specifying an algorithm that was in the confidentiality class but didn't really provide the service, this would be Very Bad. A further belief, don't worry about IPSEC, it has been astoundingly resilient to the ravages of eternal argument. Though sometimes I worry ... IPSEC is a protocol As dead as dead can be First it killed a working group And now its killing me Hilarie From owner-ipsec Fri May 16 13:24:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03023 for ipsec-outgoing; Fri, 16 May 1997 13:23:21 -0400 (EDT) Message-Id: <199705161730.AA281943799@relay.hp.com> To: ho@earth.hpc.org (Hilarie Orman) Cc: suren@teil.soft.net, ipsec@tis.com Subject: Re: Clarification please! In-Reply-To: ho's message of Fri, 16 May 1997 08:57:23 -0400. <199705161257.IAA08949@earth.hpc.org> Date: Fri, 16 May 1997 13:29:58 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > You might think of the pair as being a bi-directional SA, but the > terminology is probably more confusing than helpful. Agreed. This seems to be a common, umm, "terminology barrier" which newcomers (myself included) trip over. Part of the problem is that nobody has yet come up with a decent name for a "set of related SA's". - Bill From owner-ipsec Fri May 16 13:51:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03152 for ipsec-outgoing; Fri, 16 May 1997 13:45:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705152204.AA225823849@relay.hp.com> References: kent's message of Thu, 15 May 1997 15:29:19 -0400. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 13:50:09 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Perhaps I wasn't clear enough in my message. Let me try to restate my position, which may not be different from yours, but which seemed to be at odds with some of the previous messages: - AH and ESP are both (U.S.) export controlled, because they employ crypto - AH, because it does not provide confidentiality (encryption) and because the algorithms mandated for support ar hash/MAC algorithms, should be exportable under commodity jurisdiction license, which is relatively easy to get. Source code may be exportable (not just object code), but that's always a bit trickier. - ESP, with mandatory support for DES encryption, is much more strictly export controlled. Under current practice, unless there is a facility for key recovery, or credible plans in place for such, it iwll be very difficult to export an ESP implementation (even in object code form), and source code is definately a problem. Adding other (e.g., weaker) algorithms doesn't help with export, so long as a 56-bit DES is part of the package, as is currently required for ESP compliance. Adding another protocol feature, such as encryptionless ESP, will not make export any harder, not any easier. Steve From owner-ipsec Fri May 16 14:38:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03539 for ipsec-outgoing; Fri, 16 May 1997 14:36:51 -0400 (EDT) Message-Id: <199705161843.AA095628200@relay.hp.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Fri, 16 May 1997 13:50:09 -0400. Date: Fri, 16 May 1997 14:43:19 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [Maybe I'm just being dense, but there seems to be very broad consensus here against authentication-only ESP..] Steve, Thank you, it turns out that we are closer to agreement than I thought. Now, it may look to some like I'm caving in to the U.S. export control folks here, but no, I'm just being pragmatic about trying to get as much of the functionality deployed as quickly as possible. Pragmatically, there are going to be folks who are interested in deploying *subsets* of ipsec; in particular, an authentication-only implementation which leaves out bulk confidentiality services. My sense is that it will be easier to get export approval for an implementation which leaves out ESP entirely instead of one which "dumbs it down" by making it authentication-only, but like I said, given the subjective nature of the export control process it may well depend on how well you present your case to the gov't. In any event, not having to worry about authentication-only ESP would certainly make it easier to manage a "dual mode" source base.. - Bill From owner-ipsec Fri May 16 15:16:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03792 for ipsec-outgoing; Fri, 16 May 1997 15:12:21 -0400 (EDT) Message-Id: <01BC620C.56F72BA0@erussell-1.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" , "'suren@teil.soft.net'" Subject: RE: Clarification and a single SA Date: Fri, 16 May 1997 15:17:58 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >>S. Arockia Suren (suren@teil.soft.net) said on 5/16/97 at 10:46 AM > > > ISAKMP SAs are bidrectional because any of the negotiators can >start phase2. Similarly after oakley negotiations any party can start to >send IP packets. I would like to know if the later would be true in the >future also. Does ISAKMP allow negotiations that will be used in only >one direction inspite of SPIs exchanged. > >Suren. > The last question in the above paragrah is getting lost. ISAKMP does not allow for a SINGLE one way SA to be negotiated. Always an identical pair (in terms of policy). This is unfortunate since it may be desirable to have bulk outbound transfers of secure data be encrypted, but the inbound acks could be only authenticated or even in the clear in order to save processing time. I suppose there is nothing to prevent TWO pairs of SAs from being negotiated (an secure Inbound/Outbound pair which is really only used for outbound, and an insecure Inbound/Outbound pair which is really only used for inbound) but that seems a bit wasteful and requires some input from the system's policy or application as to which outbound SA to use, for example. Edward Russell erussell@ftp.com From owner-ipsec Fri May 16 17:31:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04690 for ipsec-outgoing; Fri, 16 May 1997 17:28:53 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199705162135.OAA26975@kebe.eng.sun.com> Subject: Re: Clarification please! To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Fri, 16 May 1997 14:35:22 -0700 (PDT) Cc: ho@earth.hpc.org, suren@teil.soft.net, ipsec@tis.com In-Reply-To: <199705161730.AA281943799@relay.hp.com> from "Bill Sommerfeld" at May 16, 97 01:29:58 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 > Agreed. This seems to be a common, umm, "terminology barrier" which > newcomers (myself included) trip over. > > Part of the problem is that nobody has yet come up with a decent name > for a "set of related SA's". I've heard these tossed around by myself and others from time to time: SA PAIR - A pair of unidirectional SAs that provide protection on a unicast session by covering each direction. They are otherwise matched. e.g. SA spi=0x2112, AH, HMAC-MD5, A -> B SA spi=0x5150, AH, HMAC-MD5, B -> A SA BUNDLE - A set of SAs that provide different protections. e.g. SA spi=0x1001001, ESP, 3DES, , A -> B SA spi=0x82069, AH, HMAC-SHA1, A -> B Any comments? Dan From owner-ipsec Fri May 16 18:21:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04935 for ipsec-outgoing; Fri, 16 May 1997 18:20:22 -0400 (EDT) Message-Id: <199705162244.SAA01135@relay.rv.tis.com> Date: Fri, 16 May 97 18:25:50 EDT From: Charles Lynn To: ipsec@tis.com cc: Stephen Kent , CLynn@bbn.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I have a few comments on the recent postings. First, a procedural issue. > a) the implementors at Memphis decided against it It is my understanding that consensus includes more than implementers who were able to make it to an IETF meeting. It includes the whole working group, whether or not they were able to get to a face to face meeting. Second, there also seems to be a strong feeling that the working group should "Do The Right Thing" to provide the best security services we are collectively able to standardize for the users of the IP layer, i.e., our customers. This philosophy implies that whether or not something is hard to export should not be of primary concern. Thus arguments like: > By its nature, ESP is "encryption enabling technology" and is > therefore not exportable w/o jumping through various hoops. Even if > your product is only using encryptionless ESP, it may still have to > jump through hoops. do not belong in our technical arena. If we do not like what our politicians have decided, we can (more or less easily :-) change the politicians. If they want to provide incentives for businesses in other countries to develop their own IPSEC code, so be it. But if they implement the IETF's IPSEC architecture, they'll be using a good architecture, not one designed around export/import laws. As an example of this philosophy, the decision was made to mandate ESP as MUST be implemented for IPv6, even though ESP might be hard to export. From RFC 1883, "IPv6 Specification", Security Considerations This document specifies that the IP Authentication Header [RFC-1826] and the IP Encapsulating Security Payload [RFC-1827] be used with IPv6, in conformance with the Security Architecture for the Internet Protocol [RFC-1825]. Many have commented on not wanting an encryptionless ESP. One reason given is that AH is fine, and the extra work to munge headers is not very expensive, relative to the crypto code. That argument sounds correct, and if moving the bits were the only issue, that would be fine. I think that the main reason AH, as defined, is not a suitable replacement for an encryptionless ESP is that it does not provide an application with a way to perform end-to-end authentication of a payload without also trying protect other header fields whose value can be predicted a priori. I think that relying on such prediction is a big impediment to further internet growth and evolution. Just because we can predice what an IP base header will look like does not mean that we will be able to predict what, e.g., Routing Extension Header versions 1, 2, ... will look like in the future. I do not think that our customers will appreciate the argument that they can no longer use AH until they and their peers upgrade their systems, because they bought a NAT box or because of a change in the routing system needed to provide additional services or deal with exponential growth. Thus I think AH, as defined, places unnecessary restrictions on the evolution of the internet routing system, which needs all the freedom it can get to get our packets delivered. After all, except for the community using security labels, what additional security is provided by trying to protect the outer headers? In tunnel mode they are discarded. In end-to-end mode, if I get a packet, and verify that it is authentic because the body was processed by someone who shares a secret with me, I don't care what the header looks like. I am willing to leave the "try to protect the outer header" AH functionality for the community that thinks it is useful, if others are willing to provide a mechanism that allows another community to protect bodies without concern for headers. One way this mechanism could be provided would be to use a bit in the AH Reserved field to indicate that the authenticated information begins at the start of the AH header and ends at the end of the IP frame. This would permit evolution while not encountering the export problems folks feel is associated with ESP. Another reason for not trying to protect the IP addresses is that doing so encourages their use as security related identifiers. One of the lessons that I thought was learned from the IPv4 experience was that requiring security to be based on network attachment point identifiers, such as IP, NSAP, or ATM addresses, is a Bad Idea. Given the requirement for plug and play and dynamic address assignment that IPv6 is trying to meet, it seems like promoting the use of the IP address as a security identifier will make it more difficult for our IPSEC customers in the future when the identifiers change and certificates have to be replaced (and, I suspect, associated CRLs updated, etc.). I do not think that this is the direction we want to be going. Third, based on the email that I have seen, most folks agree with moving the IV out of the ESP header and into the beginning of the Payload Data area. I agree that this is a reasonable thing to do. But it has a hidden cost for IPv6. In IPv6 tunnel mode, the inner IPv6 header, which must be aligned on a 64-bit boundary, follows the 64-bit aligned ESP header and the algorithm dependent and negotiated IV. (Some have argued that this alignment is not strictly required. Others that it is. The "be conservative in what you send and liberal in what you accept" argues we follow the strict viewpoint.) Thus the space occupied by the IV field has to be a multiple of 64 bits to meet the IPv6 requirements. It seems this requires that, if the size of the IV is a function of the algorithm or is negotiated, then the negotiation protocol would have to be aware during the negotiation process of the IP version being protected. That seems rather complicated to me. I would instead suggest the architecture or ESP doc require that IV field size MUST be a multiple of 64 bits, and also specify how to pad IVs of other sizes to a multiple of 64 bits. Since most algorithms that I am aware of already use 64-bit IVs, this would not cause any additional processing. It would make it so that (some vendor's) deployed software would not suddenly break when a new algorithm which uses other sized IVs is deployed in the future. What do others think about making this a requirement? In summary: Removal of optional IV from ESP header: Yes, but require any IV field to be a multiple of 64 bits. AR field (both AH and ESP): Independent of any decisions about authentication with ESP: Always present, starts at 1 and always set by the sender. Receiver may process or ignore, with a window size selected by the receiver, minimum of 32 packets. I do not see a need for the sender to be informed of the actual size, but have no objections to it. Encryptionless ESP: In favor, but willing to accept equivalent functionality in AH. Charlie From owner-ipsec Fri May 16 19:03:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05130 for ipsec-outgoing; Fri, 16 May 1997 19:01:22 -0400 (EDT) Message-Id: <199705162307.QAA06419@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Charles Lynn Cc: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Fri, 16 May 1997 18:25:50 EDT." <199705162244.SAA01135@relay.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 16:07:59 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, I take an immediate issue with your first point and therefore your conclusion. Your 2nd and 3rd seem reasonable at first read but your 1st just jumped out and bit me. > I have a few comments on the recent postings. > > First, a procedural issue. > > > a) the implementors at Memphis decided against it > > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. The overwhelming majority of people in Memphis gave encryptionless ESP a big thumbs down. An overwhelming majority of people who are posting to this list are also giving encryptionless ESP a big thumbs down. If that's not a consensus then please define what you feel is a consensus. Do you want 51% of the people who subscribe to this list? [snip] > In summary: [snip] > Encryptionless ESP: > In favor, but willing to accept equivalent functionality in AH. But are you willing to accept the wishes of the working group which may be at odds with yours (collectively, that is, as a member of the "IPSEC Document Editing Team")? If not then I'm sure someone else in this WG will step up-to-the-plate and assume control of the documents. Imagine if one year ago someone said that today key management would be basically solved-- minor edit/clarification notwithstanding-- but the basic architecture and protocol documents would be subject to contentious arguement and document wrangling. I would've laughed in their face! It's kind of funny in a perverted sort of way. Dan. From owner-ipsec Fri May 16 19:24:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05229 for ipsec-outgoing; Fri, 16 May 1997 19:23:22 -0400 (EDT) Message-Id: <199705162329.TAA26820@codex.cis.upenn.edu> To: Charles Lynn cc: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Fri, 16 May 1997 18:25:50 EDT." <199705162244.SAA01135@relay.rv.tis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17127.863825326.1@dsl.cis.upenn.edu> Date: Fri, 16 May 1997 19:28:47 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705162244.SAA01135@relay.rv.tis.com>, Charles Lynn writes: > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. It has also been the IETF "policy" that decisions are made by running code and rough consensus. I believe that a very large percentage of the implementors was at the IETF, and the majority of messages on this list has been against encryptionless ESP. Including yours, that makes 3 messages in favour of e-ESP (Steve, Hillary and you); i've seen many more against. I believe the matter has been discussed for a while and the WG has indeed decided against e-ESP. Let's not talk about this for so long that people will (again) walk away in disgust. > I am willing to leave the "try to protect the outer header" AH > functionality for the community that thinks it is useful, if others > are willing to provide a mechanism that allows another community to > protect bodies without concern for headers. You can do tunneling (IP in IP), with the inner packet being AH protected, ie: [IP][IP][AH][whatever] But more importantly, IPsec is a network layer protocol. It gives some assurances to the application. If the application cannot live with those, it should certainly use some higher layer security protocol (such as TLS). Trying to put in IPsec all the functionality of all protocol layers is a mistake. > One way this mechanism could be provided would be to use a bit in the > AH Reserved field to indicate that the authenticated information > begins at the start of the AH header and ends at the end of the IP > frame. This would permit evolution while not encountering the export > problems folks feel is associated with ESP. I think i could live with this, and it might not be too hard to do. > assignment that IPv6 is trying to meet, it seems like promoting the > use of the IP address as a security identifier will make it more > difficult for our IPSEC customers in the future when the identifiers > change and certificates have to be replaced (and, I suspect, > associated CRLs updated, etc.). I do not think that this is the > direction we want to be going. I'll remind you that IP addresses are supposed to be used as part of a security identifier; an address along with an SPI indicates the SA to use. Additionally, i don't see how dynamic IP will be hampered by IPsec in this respect, assuming a well thought out certificate scheme is in place; specifically, certificates for mobile agents should not include any IP addresses (this is a necessary but probably not sufficient condition). > negotiation protocol would have to be aware during the negotiation > process of the IP version being protected. That seems rather > complicated to me. I would instead suggest the architecture or ESP > doc require that IV field size MUST be a multiple of 64 bits, and > also specify how to pad IVs of other sizes to a multiple of 64 bits. > Since most algorithms that I am aware of already use 64-bit IVs, this > would not cause any additional processing. It would make it so that > (some vendor's) deployed software would not suddenly break when a new > algorithm which uses other sized IVs is deployed in the future. What > do others think about making this a requirement? I'm puzzled by this. Why wouldn't the standard padding at the end of the ESP payload be enough to handle alignment problems ? -Angelos From owner-ipsec Fri May 16 20:50:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05576 for ipsec-outgoing; Fri, 16 May 1997 20:48:22 -0400 (EDT) Message-ID: <337D0139.374D@redbacknetworks.com> Date: Fri, 16 May 1997 17:52:09 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Charles Lynn CC: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll References: <199705162244.SAA01135@relay.rv.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > First, a procedural issue. > > > a) the implementors at Memphis decided against it > > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. Charlie, this working group has suffered a very long time from "procedural issues". The effect is pretty clear. Do we have a nailed down doc yet?? At the wg mtg's we try to agree to something. Then after the mtg, people argue about it on the list and claim "procedure" since they either don't like the outcome or just like to be heard (you know who you are). So things get argued around until the next mtg. Then at the meeting, when things get contentious, someone wearing a hat says: "Let's take this one to the list." On the list nothing get's said or nothing get's decided. Then a bunch of people are frustrated, so at the next mtg we try to agree to something. Then after the mtg, people argue about it on the list and claim procedure ... We need to accept one of our decisions and agree that it represents a reasonable consensus. The folks at the Memphis mtg represent the vast lions share of IPSEC developers. Crying "procedure" at this point is nothing more than sour grapes. It would be nice if the chair(s) would help focus this rather than sit silently in the gallery. The documents need to come out now with the current group consensus, or please let someone else finishe them. Dave Carrel (convinced that the "process" is NOT working.) From owner-ipsec Fri May 16 22:54:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06086 for ipsec-outgoing; Fri, 16 May 1997 22:50:53 -0400 (EDT) Message-Id: <199705170250.WAA18264@relay.hq.tis.com> Date: Fri, 16 May 97 22:55:41 EDT From: Charles Lynn To: Daniel Harkins cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I was not able to attend the WG meeting. I do not know what fraction of the WG was there. I suspect that there are many more WG members than I have seen responded to the straw poll. > But are you willing to accept the wishes of the working group which may > be at odds with yours (collectively, that is, as a member of the "IPSEC > Document Editing Team")? Sure I'm willing to accept the wishes of the working group for IETF standards. Many folk contribute ideas that do not end up in standards, but which help to make the things that get standardized better. Maybe seeing the usefulness of an authentication mechanism that does not require predicting what a packet will look like the future is one of those ideas; maybe not. Time and the customers will decide. For example, a couple minor changes to the IP Routing Extension Header would have made it trivial to process/forward and secure. But for whatever reason it was not done and now we have to spend the cycles living with it (making AH processing more complex), or changing the spec, based on implementation experience, as it works its way through the standardization process. It is a lot easier for all concerned if we can get it right, or as close to right as we can collectively achieve, the first time around. Needless to say, I would like to use as much of the IPSec work as possible as a basis for code I, and probably a lot of other folk with customers, have to deliver Real Soon Now, and not have to reinvent some of the wheel. Charlie BTW, if it was not clear that my comments are my own as an implementer, let me clarify that now. I was not speaking as a member of the "IPSEC Document Editing Team" when I responded to the straw poll. From owner-ipsec Fri May 16 23:15:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA06203 for ipsec-outgoing; Fri, 16 May 1997 23:13:53 -0400 (EDT) Message-Id: <199705170326.UAA26094@mailsun2.us.oracle.com> Date: 16 May 97 20:02:34 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: ESP New Draft Cc: PALAMBER@us.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk There has been considerable debate on the "changes" to the ESP specification. A new draft of ESP will be published before May 23. This new draft should focus the wide ranging discussions on this mailing list. We will expedite the progression of this specification and have a "last call" review start as soon as it is published. When this specification is published I urge the working group to submit concise and constructive comments in a form that could be readily incorporated into the specification. The "changes" in this new specification should not be significant! ESP implementations conforming to the Memphis implementors agreements will be conformant to this specification. The only issues for the ESP specification are the optional "value added" capabilities of ESP that include auth-only-ESP. These capabilities have been intensely debated because they allow a choice between the architectural application of the AH protocol versus the ESP protocol. As working group chair, I see no clear consensus to forbid the use of ESP with a null encryption algorithm (a.k.a auth-only-ESP). There have been many strong statements made to the mailing list recommending that ESP always encrypt. I've also talked to implementors developing auth-only-ESP as a "valued added" option. ESP has the flexibility to support any algorithm. Clear guidelines need to be provided that define the usage of these algorithms including the use of a null encryption algorithm. Auth-only ESP does not provide exactly the same security services as AH. The technical capabilities of AH versus auth-only ESP are best worked out in the market. The proposed text (from Steve Kent) to document this capability in ESP as a "MAY elect" is a reasonable compromise. Standards conformance of IPSEC implementations will not be based on this mode of operation. The implementors that met in Memphis clearly demanded that there be no options at all in ESP. These agreements are appropriate for the mandatory to implement capabilities. The fervor to interoperate should not close off all options for value added capabilities that "may" be implemented. The raging debate on auth-only ESP should be represented by only a small section of text describing when it is appropriate to use a null algorithm ("may" versus "should not"). The release of the new ESP specification next week should provide an opportunity for clear comments on the text representing these issues. Regards, Paul A. Lambert ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Sat May 17 00:09:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06422 for ipsec-outgoing; Sat, 17 May 1997 00:07:23 -0400 (EDT) Message-Id: <199705170409.AAA27578@codex.cis.upenn.edu> To: "PALAMBER.US.ORACLE.COM" cc: ipsec@tis.com, jis@MIT.EDU Subject: Re: ESP New Draft In-reply-to: Your message of "16 May 1997 20:02:34 PDT." <199705170326.UAA26094@mailsun2.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17341.863842069.1@dsl.cis.upenn.edu> Date: Sat, 17 May 1997 00:07:50 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705170326.UAA26094@mailsun2.us.oracle.com>, "PALAMBER.US.ORACLE. COM" writes: > >As working group chair, I see no clear consensus to forbid the use of ESP with >a null encryption algorithm (a.k.a auth-only-ESP). There have been many >strong statements made to the mailing list recommending that ESP always >encrypt. I've also talked to implementors developing auth-only-ESP as a >"valued added" option. ESP has the flexibility to support any algorithm. >Clear guidelines need to be provided that define the usage of these algorithms >including the use of a null encryption algorithm. Paul, we had a straw poll on this list, and we had a large number of implementors decide in the Memphis meeting. Both were against auth-only-ESP. How in heaven can you say that there is no clear consensus ? There are 3 (count, three) people who spoke for auth-only-ESP on this mailing list. I was under the impression the WG chair is NOT supposed to make decisions when there *IS* a rough consensus (and this is not even rough). Finally, even if people do go ahead and hack their code to do encryptionless ESP, this doesn't mean we should ratify their decision by allowing it in the docs if we believe it's wrong. And all the discussion i've seen on this WG (list, meeting) indicates that the majority thinks it's wrong. Cheers, -Angelos PS. You say you've talked to implementors who added this as a "value added" option. Why don't they talk for themselves on this list? I don't doubt your saying so, but i'm curious why they don't express their opinion on the list if they like encryptionless ESP so much. Only implementor i've seen so far was Charlie (from BBN). From owner-ipsec Sat May 17 00:12:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06454 for ipsec-outgoing; Sat, 17 May 1997 00:11:25 -0400 (EDT) From: "Ahmod Bakr El-Sayed: -SC" Organization: Computer Systems Engineering, RMIT To: ho@earth.hpc.org (Hilarie Orman) Date: Sat, 17 May 1997 14:19:04 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: enskip cobfuguration CC: ipsec@tis.com In-reply-to: <199705161257.IAA08949@earth.hpc.org> References: Yourmessage <199705160858.BAA04918@baskerville.CS.Arizona.EDU> X-mailer: Pegasus Mail for Windows (v2.53/R1) Message-ID: <1678EFD02D2@huntsman.cse.rmit.edu.au> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi this is Burt from Australia I am doing thesis on Implemenation of IPSEC with firewalls i have used the ENSKIP and SUN SKKIP I am having a very serious problem with the ENSKIP .. I would be very greateful if i could hear any sugestion I compiled the latest ENSKIP enskip-0.66 successfully on solaris 2.5 box when i started " make install" i got a kernel crash. i repeated the installation step by step on hand from the command line,, and sure it is the add_drv command i.e adding the kernel drive which makes the crash please i appreciate your help. Have a very G'DAY BURT From owner-ipsec Sat May 17 00:43:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06579 for ipsec-outgoing; Sat, 17 May 1997 00:41:54 -0400 (EDT) Message-Id: <199705170441.AAA19459@relay.hq.tis.com> Date: Sat, 17 May 97 0:43:40 EDT From: Charles Lynn To: David Carrel cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > this working group has suffered a very long time from "procedural > issues". The effect is pretty clear. Do we have a nailed down doc > yet?? I sure hope so. I thought that was one of the purposes for the poll. > On the list nothing get's said or nothing get's decided. I think it is the responsibility of the chairs to keep things moving. If there is nothing happening, the chair should send a message to encourage folks to state their thoughts (maybe even have a straw poll :-), judge the responses, and move on. > The documents need to come out now with the current group consensus, Yes. I will do what I can to see that it happens. Charlie From owner-ipsec Sat May 17 01:05:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA06682 for ipsec-outgoing; Sat, 17 May 1997 01:04:24 -0400 (EDT) Message-Id: <199705170503.BAA19674@relay.hq.tis.com> Date: Sat, 17 May 97 0:42:31 EDT From: Charles Lynn To: "Angelos D. Keromytis" cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, > You can do tunneling (IP in IP), with the inner packet being AH > protected, ie: [IP][IP][AH][whatever] Yes, that is one way to work around the problem. Cost: 20 (40) unnecessary bytes per IPv4 (IPv6) packet sent over the lifetime of the protocol. When viewed from the perspective of a security gateway, [IP][IP][AH][IP][whatever], just makes things more likely to run into path MTU / fragmentation problems. > It has also been the IETF "policy" that decisions are made by running > code and rough consensus. Speaking of running code, does anyone have operational experience on how well Path MTU discovery works? It has been standardized for a long time. Re: encryptionless ESP > I believe the matter has been discussed for a while and the WG has > indeed decided against e-ESP. Yes, it has been discussed for a long while. There was a request for a poll and I responded with what I think is the best solution and my rational for thinking so. > But more importantly, IPsec is a network layer protocol. It gives some > assurances to the application. If the application cannot live with > those, it should certainly use some higher layer security protocol > (such as TLS). Trying to put in IPsec all the functionality of all > protocol layers is a mistake. Good points. But providing functionality needed by several layer N protocols at a lower layer has merit. > I'll remind you that IP addresses are supposed to be used as part of a > security identifier; an address along with an SPI indicates the SA to > use. Since you raised the issue, do you know the rational for that decision? I can see how it might make construction of third party wire tapping devices a little easier. However, as an implementor, I would not implement it that way. I would make the SPI space within a box be unique, not have several spaces, one per address -- IPv4, IPv6 link local, IPv6 global, (dare I say multicast?), per interface, ... Why go through all the extra work? Bigger tables, bigger hash keys ... From the outside, things work. If the box receives a packet not addressed to it, it gets dropped before any SPI lookup. If it is addressed to the box, the purported SPI either works or it doesn't. If it works, whoever shared the key, so the packet would be accepted; if it didn't work, it would set off those audit or not alarms and be dropped. > Additionally, i don't see how dynamic IP will be hampered by IPsec in > this respect, assuming a well thought out certificate scheme is in > place; specifically, certificates for mobile agents should not include > any IP addresses (this is a necessary but probably not sufficient > condition). >From what I've had a chance to read, that may be a big assumption. Thinking ahead a few years, what fraction of hosts and networks will be mobile (at the IP level) or be subject to renumbering, possibly due to switching providers? Hopefully, someone is working out all the nasty little details. Re: IV field padding: > I'm puzzled by this. Why wouldn't the standard padding at the end of > the ESP payload be enough to handle alignment problems ? No. Maybe a picture would help. 64-bit boundaries (not to scale) | | | | | | | | | +-------+-------+-------+---- +-------+-------+------------+-------+ |IP6 Hdr|Rtg Hdr|ESP Hdr| IV |IP6 Hdr|Rtg Hdr|User Payload|ESP Pad| +-------+-------+-------+---- +-------+-------+------------+-------+ When the decapsulating system gets this packet, it will "strip off" the headers before the (IV and) inner IPv6 header, and then have to process that header and possibly others beyond it (inner Rtg Hdr in this example). It is expected that the outer IPv6 base header and extension headers are aligned so those systems that demand data alignment can process the packet. But this system has to also process the inner headers. Maybe the inner routing header needs to be advanced, and IPv6 addresses shuffled around. If the IV field is not a multiple of 64 bits, it breaks the alignment between the outer and inner headers, then the vendor is stuck realigning the the packet, which is a good way to reduce performance. Some have argued that the encrypted portion (IV through ESP Pad) would have to be copied anyway so it doesn't really matter. In some cases that argument works. But requiring the IV field to be a multiple of 64 bits would make it work in all cases, allowing the vendors to simplify their implementations. Given current technology, it only costs a few words, and would nail things down unambiguously. I think it is a reasonable requirement. If others feel otherwise, we should know so that the working group documents can warn vendors not to make "assumptions". Thanks for your feedback, Charlie From owner-ipsec Sat May 17 01:49:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA06837 for ipsec-outgoing; Sat, 17 May 1997 01:46:54 -0400 (EDT) Message-Id: <199705170553.BAA27969@codex.cis.upenn.edu> To: Charles Lynn cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Sat, 17 May 1997 00:42:31 EDT." <199705170521.BAA27799@codex.cis.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17487.863848324.1@dsl.cis.upenn.edu> Date: Sat, 17 May 1997 01:52:04 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705170521.BAA27799@codex.cis.upenn.edu>, Charles Lynn writes: > >Yes, that is one way to work around the problem. Cost: 20 (40) >unnecessary bytes per IPv4 (IPv6) packet sent over the lifetime of the >protocol. When viewed from the perspective of a security gateway, >[IP][IP][AH][IP][whatever], just makes things more likely to run into >path MTU / fragmentation problems. That's true. I was only saying that one can do that if one really wants to. But i believe that one shouldn't care. Opinions obviously vary. >Yes, it has been discussed for a long while. There was a request for >a poll and I responded with what I think is the best solution and >my rational for thinking so. Apologies if it seemed like i was dismissing your opinion and rational. I was just counter arguing. >Good points. But providing functionality needed by several layer N >protocols at a lower layer has merit. As long as this doesn't break things or makes them more complicated than they ought to be (and they're complicated enough as it is). >Since you raised the issue, do you know the rational for that >decision? I can see how it might make construction of third party >wire tapping devices a little easier. However, as an implementor, I An SPI is guaranteed (supposedly) to be unique per address. That makes the pair SPI/address unique on any lookup table. SPIs are needed because two boxes might have more than one SAs shared, and addresses are needed to distinguish between the same SPI value among different boxes. Presumably, the issuer of SPIs issues unique SPIs per box, which means the same SPI will not occur for more than one address of that box. Given that, the receiver of an IPsec packet need not concern oneself with the address once he's established that the packet is destined for him. Hope this answers. [At this point, your message was destroyed by MH...fun. So i probably missed what you said about dynamic IP.] >No. Maybe a picture would help. [snip] I see the problem now. About something you mentioned: all the implementations i've been involved in do in-place decryption, so copying would be unnecessary. I suppose 64-bit multiple IVs is reasonable then. Cheers, -Angelos From owner-ipsec Sat May 17 03:40:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07248 for ipsec-outgoing; Sat, 17 May 1997 03:35:23 -0400 (EDT) Message-Id: <3.0.32.19970517073224.008ae900@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 17 May 1997 07:39:00 +0000 To: Charles Lynn From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: "Angelos D. Keromytis" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:42 AM 5/17/97 EDT, Charles Lynn wrote: >Speaking of running code, does anyone have operational experience on >how well Path MTU discovery works? It has been standardized for a >long time. Judging from packet traces, it's barely used. That is, there are very many packets at around 512 or 576 bytes, and almost none above it. > > >> I'll remind you that IP addresses are supposed to be used as part of a >> security identifier; an address along with an SPI indicates the SA to >> use. > >Since you raised the issue, do you know the rational for that >decision? I can see how it might make construction of third party >wire tapping devices a little easier. However, as an implementor, I >would not implement it that way. I would make the SPI space within a >box be unique, not have several spaces, one per address -- IPv4, IPv6 >link local, IPv6 global, (dare I say multicast?), per interface, ... >Why go through all the extra work? Bigger tables, bigger hash keys >... From the outside, things work. If the box receives a packet not >addressed to it, it gets dropped before any SPI lookup. If it is >addressed to the box, the purported SPI either works or it doesn't. >If it works, whoever shared the key, so the packet would be accepted; >if it didn't work, it would set off those audit or not alarms and be >dropped. That's an implementation decision. What's important is that the sender must be prepared to deal with multiple SPIs. Also bear in mind the multicast case, where someone else -- the group leader -- is assigning the SPI. > >> Additionally, i don't see how dynamic IP will be hampered by IPsec in >> this respect, assuming a well thought out certificate scheme is in >> place; specifically, certificates for mobile agents should not include >> any IP addresses (this is a necessary but probably not sufficient >> condition). > >>From what I've had a chance to read, that may be a big assumption. >Thinking ahead a few years, what fraction of hosts and networks will >be mobile (at the IP level) or be subject to renumbering, possibly due >to switching providers? Hopefully, someone is working out all the >nasty little details. With IPv6, 100% of hosts will be subject to renumbering. From owner-ipsec Sat May 17 04:06:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA07380 for ipsec-outgoing; Sat, 17 May 1997 04:05:27 -0400 (EDT) Message-Id: <3.0.32.19970517080913.008c1d80@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 17 May 1997 08:09:22 +0000 To: ho@earth.hpc.org (Hilarie Orman) From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk My original reaction was "no, I don't like this idea". After all, we have permitted ESP through the firewall, based solely on the protocol ID and the destination address pointing to the secure tunnel endpoint on the inside. Do I really want unencrypted traffic flowing that way? Then I realized that someone could define and implement an arbitarily weak "encryption" algorithm and use it, if the tunnel permitted. Anyone for 40-bit RC4? 4-bit RC4? Rot-n? (The spec for Rot-n might make a great April 1 RFC, save that last April 1, someone actually implemented it as an encryption mode for ssh and other folks took it seriously... Me -- I want a monoalphabetic substitution. Done computer-style, there are 256! possible keys -- by my calculations, about 1684 bits, which puts triple IDEA to shame...) In other words, the firewall or its trusted peer have to participate in the key management dialog, if you want to pass encrypted traffic only if it is above a certain strength level. As a complement to AH, it's harmless. As a replacement, it's superior. (Folks may remember my long arguments against the AH architecture. This is much cleaner.) My major concern is that APIs be structured so that *no one* gets this mode by accident. From owner-ipsec Sat May 17 11:01:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08915 for ipsec-outgoing; Sat, 17 May 1997 10:54:25 -0400 (EDT) Date: Sat, 17 May 1997 10:57:53 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171457.KAA25821@earth.hpc.org> To: Dan.McDonald@Eng.sun.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199705162142.OAA24624@baskerville.CS.Arizona.EDU> Subject: Re: Clarification please! Sender: owner-ipsec@ex.tis.com Precedence: bulk > SA PAIR - A pair of unidirectional SAs that provide protection > on a unicast session by covering each direction. They > are otherwise matched. > e.g. SA spi=0x2112, AH, HMAC-MD5, A -> B > SA spi=0x5150, AH, HMAC-MD5, B -> A Asymmetry has been a design goal from the earliest drafts, so I'd never considered the case above to be anything other than a subcase of a normal pair. > SA BUNDLE - A set of SAs that provide different protections. > e.g. SA spi=0x1001001, ESP, 3DES, , A -> B > SA spi=0x82069, AH, HMAC-SHA1, A -> B > Any comments? I'd call it an asymmetric pair, myself. A "bundle" conjures up a more general concept --- I'd use it to describe things like "use AH with spi xxxx and ESP with spi xxxx outgoing, and expect AH with spi yyyy and ESP with spi yyyy incoming" etc. Hilarie From owner-ipsec Sat May 17 11:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09081 for ipsec-outgoing; Sat, 17 May 1997 11:37:24 -0400 (EDT) Date: Sat, 17 May 1997 11:34:52 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171534.LAA26900@earth.hpc.org> To: ipsec@tis.com Subject: Workshop announcement Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm reposting this announcement because a couple of people told me that they didn't notice the first posting (in March) and wanted a repost, and because I wanted to note that much good could come of exposing many of the issues that this group wrestles with exposed to the formal security community (but not a formal spec of the RFC process or the semantics of MUST vs. SHOULD, thank you). Hope this will be of interest to more than a couple of you. ============================================================================= DIMACS Workshop on Design and Formal Verification of Security Protocols Sept. 3-5, 1997 Organizers: Hilarie Orman, DARPA and Catherine Meadows, Naval Research Laboratory As we come to rely more and more upon computer networks to perform vital functions, the need for cryptographic protocols that can enforce a variety of security properties has become more and more important. Thus it is no surprise that in recent years a number of new protocols have been proposed for such applications as electronic credit card transactions, Web browsing, and so forth. Since it is notoriously difficult to design cryptographic protocols correctly, this increased reliance on them to provide security has become cause for some concern. This is especially the case since many of the new protocols are extremely complex. In answer to these needs, research has been intensifying in the application of formal methods to cryptographic protocol verification. Recently this work has matured enough so that it is starting to see application to real-life protocols. The goal of this workshop is to facilitate this process by bringing together those were are involved in the design and standardization of cryptographic protocols, and those who are developing and using formal methods techniques for the verification of such protocols. To this end we plan to alternate papers with panels soliciting new paths for research. We are particularly interested in paper and panel proposals addressing new protocols with respect to their formal and informal analysis. Other topics of interest include, but are not limited to - Progress in belief logics - Use of theorem provers and model checkers in verifying crypto protocols - Interaction between protocols and cryptographic modes of operation - Methods for unifying documentation and formal, verifiable specification - Methods for incorporating formal methods into crypto protocol design - Verification of cryptographic API systems - Formal definition of correctness of a cryptographic protocol - Arithmetic capability required for proofs of security for number theoretic systems - Formal definitions of cryptographic protocol requirements - Design methodologies - Emerging needs and new uses for cryptographic protocols - Multiparty protocols, in particular design and verification methods We encourage attendees to bring tools for demonstration. Information about availability of facilities for demonstration will be posted later. To submit a paper to the workshop, submit a one or two page abstract, in Postscript or ASCII to both organizers at the email addresses given below by June 16, 1997. Authors will be notified of acceptance or rejection of abstracts by July 1. Full papers will be due by August 1. Copies of papers will be distributed at the workshop. We also plan to publish a proceedings. Participation in the workshop is *not* limited to those giving presentations. If you would like to attend the workshop, a registration form is available at http://dimacs.rutgers.edu/Workshops/Cryptographic/reg_form.html. Information on accommodations and travel arrangements is available at http://dimacs.rutgers.edu/Workshops/general/accommodations.html and http://dimacs.rutgers.edu/Workshops/general/travel.html. Information on the workshop in general is at http://dimacs.rutgers.edu/Workshops/Cryptographic. Organizers Hilarie Orman Catherine Meadows DARPA ITO Naval Research Laboratory 3701 N. Fairfax Drive Code 5543 Arlington VA 22203-1714 Washington, DC 20375 phone: (703)696-2234 phone: (202)-767-3490 email: orman@darpa.mil email:meadows@itd.nrl.navy.mil From owner-ipsec Sat May 17 12:41:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09305 for ipsec-outgoing; Sat, 17 May 1997 12:35:56 -0400 (EDT) Date: Sat, 17 May 1997 12:39:29 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171639.MAA28820@earth.hpc.org> To: ipsec@tis.com Subject: Workshop announcement Sender: owner-ipsec@ex.tis.com Precedence: bulk The need for more verification is evident in this problem that was pointed out to me re the workshop: http://dimacs.rutgers.edu/Workshops/Cryptographic The correct URL is: http://dimacs.rutgers.edu/Workshops/Security Hilarie From owner-ipsec Sat May 17 15:22:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09970 for ipsec-outgoing; Sat, 17 May 1997 15:14:27 -0400 (EDT) Date: Sat, 17 May 97 18:39:48 GMT From: "William Allen Simpson" Message-ID: <5889.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Charles Lynn > Speaking of running code, does anyone have operational experience on > how well Path MTU discovery works? It has been standardized for a > long time. > Yes. Since Apple installed OpenTransport on several million machines the past 6 months, I've been getting much nicer packet sizes from many servers, including the mail server indicated above. They didn't get Karns' algorithm, or Nagles' algorithm, or slow start, or TCP PSH, or any number of other details correct, but they do seem to have Path MTU working.... Now, if we could only get all those old SunOS and BSD 4.2 machines upgraded.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 17 20:53:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11431 for ipsec-outgoing; Sat, 17 May 1997 20:51:28 -0400 (EDT) Message-Id: <199705180058.RAA07653@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@tis.com Subject: Re: ESP New Draft In-Reply-To: Your message of "16 May 1997 20:02:34 PDT." <199705170326.UAA26094@mailsun2.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 May 1997 17:58:16 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, I'm confused by your recent note on the new ESP draft. You mention: > The "changes" in this new specification should not be significant! ESP > implementations conforming to the Memphis implementors agreements will be > conformant to this specification. The only issues for the ESP specification > are the optional "value added" capabilities of ESP that include auth-only-ESP. If implementations which conform to the Memphis agreement are conformant to the specification then there can be no "value added" encryptionless ESP since in Memphis there was overwhelming agreement that this not be allowed. > As working group chair, I see no clear consensus to forbid the use of ESP > with a null encryption algorithm (a.k.a auth-only-ESP). I'm really at a loss here. In Memphis I was a bit distracted by the March Of The Peabody Ducks but I do remember that around 4/5 of the people discussing encryptionless ESP were against it. On the list it's about 3:1 against. Presidents claim a mandate with 55% of a vote; this is a veritable landslide! As mentioned on the list recently: a compelling argument must be made for *change*, not for the status quo. The status quo is no encryptionless ESP. There has been no compelling argument for change. (And it's not just me saying this). You also said that you spoke to people implementing encryptionless ESP. Who? And to what specification are they coding? Since ESP currently does not allow encryptionless ESP and there are no published transforms defining such a beast I'm curious who they are. Everybody who has anything close to running code has announced their existance and no one has said they have encryptionless ESP. (Having taken part in recent IPsec bakeoffs, I'm not just spouting off). Lack of a compelling argument; clear consensus against; no running code (and in fact, all running code is contrary). I'm puzzled why you come to the conclusion you did. Dan. From owner-ipsec Mon May 19 09:15:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19988 for ipsec-outgoing; Mon, 19 May 1997 09:07:15 -0400 (EDT) Message-Id: <2.2.32.19970518203632.0073b184@po2.bbn.com> X-Sender: lsanchez@po2.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 May 1997 16:36:32 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: "Luis A. Sanchez" Subject: Re: Clarification please! Cc: sommerfeld@apollo.hp.com, ho@earth.hpc.org, suren@teil.soft.net, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >I've heard these tossed around by myself and others from time to time: > > SA PAIR - A pair of unidirectional SAs that provide protection > on a unicast session by covering each direction. They > are otherwise matched. >Any comments? > Dan, I've used the term SA PAIR as well. Now, suppose HOST A wants to talk to HOST B using AH-ESP(transport) w/3DES end2end. To further complicate things, suppose that both HOST A and B are required to use AH with their Security Gateways (A' and B') for all outgoing traffic as depicted below: |---------- AH-ESP(transport)-----------| HOST A ------- A' ------------ B'------ HOST B |---AH-- -| |---AH---| Using your notation, HOST A would have 3 SA PAIRs "related" to the same session: e.g. SA spi=0x1001001, ESP, 3DES, , A -> B SA spi=0x5150000, ESP, 3DES, , B -> A SA spi=0x2112, AH, HMAC-MD5, A -> B SA spi=0x5150, AH, HMAC-MD5, B -> A SA spi=0x82069, AH, HMAC-SHA1, A -> A' SA spi=0x10738, AH, HMAC-SHA1, A' -> A HOST B would have an equivalent set of SA PAIRs. It might be useful to have a way to describe this SA relationship too. Perhaps we could define: SA Composite (SAC)= {Set of SA PAIRs related to the same unicast session} >I'd call it an asymmetric pair, myself. A "bundle" conjures up a more >general concept --- I'd use it to describe things like "use AH with >spi xxxx and ESP with spi xxxx outgoing, and expect AH with spi yyyy >and ESP with spi yyyy incoming" etc. "SA Bundles" per Hilarie's definition could be elements of a SAC. Luis From owner-ipsec Mon May 19 09:49:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20279 for ipsec-outgoing; Mon, 19 May 1997 09:48:18 -0400 (EDT) Message-Id: <199705181434.KAA03548@codex.cis.upenn.edu> To: wdmaugh@tycho.ncsc.mil Subject: ISAKMP cookies Cc: mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com Date: Sun, 18 May 1997 10:34:08 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Could we remove the wording from the draft that talks about clogging and how cookies prevent it ? Clearly, in ISAKMP, cookies do nothing of that sort; the Responder has to create state after receiving the first message of a Main or Aggressive Mode, to keep the proposal/transforms/attributes it's decided to accept. On the other hand, if we do want to do anti-clogging, a simple HDR exchange before the current Main/Aggressive Mode would suffice. Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM38TX70pBjh2h1kFAQFemgQAgBHqWbuuUBC86y2WhC11+x5p6RRiPD1l qDlC52u5qjV/Q4sBrN4TByE9aibeaW8L2hdjKPGriR6R8rSB9jJxE05mvm0Km99X groLo1swK7JLudEm3SS/uKoMBh8SGm/C1cXFGKO4wpBxppNPziEj0KSfkPGFWWvB qVywHzaTV5o= =WiSd -----END PGP SIGNATURE----- From owner-ipsec Mon May 19 10:56:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20722 for ipsec-outgoing; Mon, 19 May 1997 10:55:18 -0400 (EDT) Date: Mon, 19 May 1997 10:57:14 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705191457.KAA21933@earth.hpc.org> To: angelos@dsl.cis.upenn.edu Cc: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com In-reply-to: Yourmessage <199705191358.GAA01423@baskerville.CS.Arizona.EDU> Subject: Re: ISAKMP cookies Sender: owner-ipsec@ex.tis.com Precedence: bulk There have always been two possible aspects to anti-clogging (or denial of service prevention). One is to defer allocation of space, the other is to defer computation. I'm happy to have the term refer to either one, insofar as the protocol assists either or both. Hilarie From owner-ipsec Mon May 19 12:27:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21226 for ipsec-outgoing; Mon, 19 May 1997 12:24:50 -0400 (EDT) Message-Id: <199705191631.MAA19978@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Charles Lynn cc: Daniel Harkins , ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Fri, 16 May 1997 22:55:41 EDT." <199705170250.WAA18264@relay.hq.tis.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 12:31:32 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles Lynn writes: > I was not able to attend the WG meeting. I do not know what fraction > of the WG was there. I suspect that there are many more WG members > than I have seen responded to the straw poll. I know I'm chiming in a bit late, but let me chime in anyway. The working group in Memphis was almost unanimous in striking down encryptionless ESP. The working group here, on line, obviously has overwhelming consensus in that direction. Continued discussion of this matter is divisive and unnecessary -- it is obvious which way the working group has decided. Regardless of the "platonic truth" of the question of whether encryptionless ESP is good or bad, the world will survive just fine without it, and it is obvious at this point that the only result of continuing the discussion will be the same outcome. I would ask the people pushing encryptionless ESP to gracefully withdraw rather than continue in this disruptive direction. Everyone loses an argument occassionally. We've all been forced to accept things we don't like. Lets move on. Perry From owner-ipsec Mon May 19 12:27:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21236 for ipsec-outgoing; Mon, 19 May 1997 12:26:50 -0400 (EDT) Message-Id: <199705191633.MAA19986@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Angelos D. Keromytis" cc: "PALAMBER.US.ORACLE.COM" , ipsec@tis.com, jis@MIT.EDU Subject: Re: ESP New Draft In-reply-to: Your message of "Sat, 17 May 1997 00:07:50 BST." <199705170409.AAA27578@codex.cis.upenn.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 12:33:36 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Angelos D. Keromytis" writes: > >As working group chair, I see no clear consensus to forbid the use > >of ESP with a null encryption algorithm (a.k.a auth-only-ESP). > >There have been many strong statements made to the mailing list > >recommending that ESP always encrypt. I've also talked to > >implementors developing auth-only-ESP as a "valued added" option. > >ESP has the flexibility to support any algorithm. Clear guidelines > >need to be provided that define the usage of these algorithms > >including the use of a null encryption algorithm. > > Paul, we had a straw poll on this list, and we had a large number of > implementors decide in the Memphis meeting. Both were against > auth-only-ESP. How in heaven can you say that there is no clear > consensus ? I strongly agree. This is one of the few times that I've seen near unanimity for *anything* in the IETF. I didn't see *anyone* at Memphis ask for encryptionless ESP. > I was under the impression the WG chair is NOT supposed to make > decisions when there *IS* a rough consensus (and this is not even > rough). Also true enough. Perry From owner-ipsec Mon May 19 13:09:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21500 for ipsec-outgoing; Mon, 19 May 1997 13:08:51 -0400 (EDT) Message-Id: <199705191715.NAA21137@codex.cis.upenn.edu> To: ho@earth.hpc.org (Hilarie Orman) cc: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com Subject: Re: ISAKMP cookies In-reply-to: Your message of "Mon, 19 May 1997 10:57:14 EDT." <199705191457.KAA21933@earth.hpc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3159.864062022.1@dsl.cis.upenn.edu> Date: Mon, 19 May 1997 13:13:42 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705191457.KAA21933@earth.hpc.org>, Hilarie Orman writes: >There have always been two possible aspects to anti-clogging (or >denial of service prevention). One is to defer allocation of space, >the other is to defer computation. I'm happy to have the term refer >to either one, insofar as the protocol assists either or both. I'm simply puzzled why we moved away from the Photuris model of cookies; as you remember, cookies there prevented both problems. And if you can't do any protocol negotiation (or even worse, if your machine crawls to a halt), it doesn't matter if the reason is memory exhaustion or too much computation. Especially since it will be trivial for anyone, anywhere, to make any ISAKMP daemon run out of memory as it stands now. Cheers, -Angelos PS. Most of the over-the-network attacks i've seen in the last two years cause the target system to run out of memory (usually run out of memory dedicated for some service). Let's not replicate those protocol failures here. From owner-ipsec Mon May 19 16:38:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22821 for ipsec-outgoing; Mon, 19 May 1997 16:36:52 -0400 (EDT) Date: Mon, 19 May 1997 16:40:10 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705192040.QAA02337@earth.hpc.org> To: perry@piermont.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199705191637.JAA12223@baskerville.CS.Arizona.EDU> Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > Regardless of the "platonic truth" of the > question of whether encryptionless ESP is good or bad, the world will > survive just fine without it, It's not a platonic argument, it's a practical one about high-speed nets, perceived utility of AH, and expected market directions. Platonic would be, "And do you not already have an algorithm that hashes contiguous blocks of data? And do you have a framework for handling an extensible set of block-oriented algorithms? And you often process packets without care for the header value, other than destination address? Then, have you not already implemented the spirit of auth-only ESP, and is it not implied by the code base you built, although you thought you were coding to a different spec altogether? Then is not auth-only ESP a done deal, roughly implemented in running code, not merely a shadow thrown on the wall by yahoos in the internet ether?" Hilarie From owner-ipsec Mon May 19 18:05:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23368 for ipsec-outgoing; Mon, 19 May 1997 18:03:54 -0400 (EDT) Message-Id: <199705192210.SAA21465@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Mon, 19 May 1997 16:40:10 EDT." <199705192040.QAA02337@earth.hpc.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 18:10:11 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie Orman writes: > > Regardless of the "platonic truth" of the > > question of whether encryptionless ESP is good or bad, the world will > > survive just fine without it, > > It's not a platonic argument, it's a practical one about high-speed > nets, perceived utility of AH, and expected market directions. I think you don't understand what I meant, Hillarie. Out there, somewhere, floating in Platonic Ideals Space, is the "Truth" with a capital T about whether encryptionless ESP is "good" or "bad". We all make our arguments, try to convince one another, and we come to a consensus. Of course, we never actually reach the "Truth"*. What we get is an approximation that is possibly very far away. However, being finite beings, we can never actually reach the "Truth", and could spend infinite time in a futile attempt to get there (thus never achieving our goal of having a deployed system), so we have developed this procedure to get as close as we can to the "Truth". Well, we went through that process, and we hit an answer which was that we had solid assessed consensus to drop encryptionless ESP. Some people feel this is the wrong decision. However, we can't ever achieve the "right" decision, only what most people think is "right". We have certainly arrived there -- there is strong and obvious consensus. Now, I realize that it might not be pleasant for the losers, but we have *all* been on the losing side of one argument or another in this process, and we just have to accept that we've lost and live with it and move on. This should especially be the case given that western civilization will survive even if we made a not entirely perfect decision here. Indeed, at worst, we will lose some bandwidth or some such. So, given all this, can we just accept that most people think we should drop encryptionless ESP and move on? Perry *By the way, it isn't even clear that there is a "Truth" -- engineering, unlike mathematics, rarely has a single right answer. From owner-ipsec Mon May 19 20:09:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24065 for ipsec-outgoing; Mon, 19 May 1997 20:06:54 -0400 (EDT) Message-Id: <199705200013.RAA03011@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Mon, 19 May 97 17:13:17 -0700 To: perry@piermont.com Subject: Re: ESP revisions straw poll cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705192210.SAA21465@jekyll.piermont.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > Now, I realize that it might not be pleasant for the losers, but > we have *all* been on the losing side of one argument or another > in this process, and we just have to accept that we've lost and > live with it and move on. > I thought the purpose here is collaboration. Why do we have to have winners and losers? -dpg From owner-ipsec Mon May 19 20:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24228 for ipsec-outgoing; Mon, 19 May 1997 20:28:26 -0400 (EDT) Message-Id: <199705200034.UAA21894@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: ESP revisions straw poll In-reply-to: Your message of "Mon, 19 May 1997 17:13:17 PDT." <199705200013.RAA03011@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 20:34:46 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > > Now, I realize that it might not be pleasant for the losers, but > > we have *all* been on the losing side of one argument or another > > in this process, and we just have to accept that we've lost and > > live with it and move on. > > I thought the purpose here is collaboration. Why do we have to > have winners and losers? Because some things are mutually exclusive. We can't both permit and not permit encryptionless ESP, for example. This means that if there are groups arguing in favor of both, one of those groups necessarily does not see its desires adopted. Overall, of course, I think this *is* a collaboration. However, individual arguments end up with people losing on occassion. Perry From owner-ipsec Tue May 20 09:03:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28040 for ipsec-outgoing; Tue, 20 May 1997 08:59:03 -0400 (EDT) Date: Tue, 20 May 1997 09:04:31 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705201304.JAA13211@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: ESP revisions straw poll X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > > Dennis Glatting writes: > > I thought the purpose here is collaboration. Why do we have to > > have winners and losers? > > Because some things are mutually exclusive. We can't both permit and > not permit encryptionless ESP, for example. This means that if there > are groups arguing in favor of both, one of those groups necessarily > does not see its desires adopted. As Bill Simpson and others have pointed out, you can't "not permit" auth-only ESP; the only thing you can do is refuse to include it in the base ESP specification. Someone can always come along and write a Rot-13 or Identity encryption transform document, and implementors can write code to implement it. It becomes a hard sell to claim that IPSEC implementations which support additional ESP transforms over and above the minimum requirements are "non-compliant" - implementations that support both the Standard transforms and value-added transforms will be common. Thus the argument becomes where will the null encryption transform get documented - as a MAY IMPLEMENT component of the base ESP specification having no effect on compliance, or in a separate transform document. I don't have any illusions that there is a Platonic Ideal IPSEC Standard that we mortals can glimpse but dimly - auth-only ESP may be Good, Bad, both, or neither. I just think it's silly to write a separate < 1 page RFC to specify something that: 1) has semantic and performance properties that are useful to some, 2) is short and easy to describe in the base ESP specification, 3) has zero impact on developers' compliance with the standard, and 4) will be implemented if there's market demand and won't be otherwise, *regardless* of where it is documented. From owner-ipsec Tue May 20 09:56:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28392 for ipsec-outgoing; Tue, 20 May 1997 09:51:33 -0400 (EDT) Message-Id: <199705201357.JAA02213@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 May 1997 09:57:57 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk David P. Kemp writes: > I don't have any illusions that there is a Platonic Ideal IPSEC Standard > that we mortals can glimpse but dimly - auth-only ESP may be Good, Bad, > both, or neither. > > I just think it's silly to write a separate < 1 page RFC to specify > something that: > > 1) has semantic and performance properties that are useful to some, > 2) is short and easy to describe in the base ESP specification, > 3) has zero impact on developers' compliance with the standard, and > 4) will be implemented if there's market demand and won't be otherwise, > *regardless* of where it is documented. What you are doing here is having the argument over. My point was that we've had the argument, and that of course there are points on both sides -- naturally good points given that most of the people in the discussion are intelligent -- but a decision was made already and there isn't evidence that consensus has shifted so much or that the arguments have changed so much that the decision should be re-thought. This is not to say we in the IETF carve our decisions in stone, but we *do* have to finally make them every once in a while. Even if in this case by some stretch the consensus changed, in general it is a bad idea to discuss things forever. Engineering is often a tradeoff between time and perfection. We have operated at a very slow pace for many years now in IPSec -- we are getting close to "shoot the engineers and ship" time. After a while, you have to make a decision on outstanding issues and accept it. We made one already. Perry From owner-ipsec Tue May 20 10:14:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28553 for ipsec-outgoing; Tue, 20 May 1997 10:13:06 -0400 (EDT) Message-Id: <199705201419.KAA27177@codex.cis.upenn.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4780.864137881.1@dsl.cis.upenn.edu> Date: Tue, 20 May 1997 10:18:01 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Thus the argument becomes where will the null encryption transform >get documented - as a MAY IMPLEMENT component of the base ESP specification >having no effect on compliance, or in a separate transform document. If some people really want it, then they can go ahead and write their own transform document. It should never appear in the base ESP document. I'd much rather have vendors say they don't support ESP (or that they have two versions of IPsec, one domestic and one exportable), than them claiming they support "a version of ESP that is almost as secure as the standard says, and it's exportable!". And before you go off saying that this statement is (obviously) not true, let me just remind you that truth and marketing are not necessarily compatible terms. Cheers, -Angelos PS. I still think ESP should stand for "Encrypting Security Protocol"...we're IPsec after all, not "Internet Encapsulating Protocol WG". But that's just me (and a few others :) From owner-ipsec Tue May 20 10:21:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28610 for ipsec-outgoing; Tue, 20 May 1997 10:21:35 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-des3-x-01.txt Date: Tue, 20 May 1997 09:48:13 -0400 Message-ID: <9705200948.aa28776@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP Triple DES Transform Author(s) : P. Karn, P. Metzger, W. Simpson Filename : draft-simpson-esp-des3-x-01.txt Pages : 14 Date : 05/19/1997 This document describes the "Triple" DES-EDE3-CBC security transform for the IP Encapsulating Security Payload (ESP). 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-simpson-esp-des3-x-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des3-x-01.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-simpson-esp-des3-x-01.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: <19970519172020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des3-x-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des3-x-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519172020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue May 20 10:52:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28802 for ipsec-outgoing; Tue, 20 May 1997 10:52:05 -0400 (EDT) Message-Id: <2.2.32.19970520150634.00bf8f98@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, 20 May 1997 11:06:34 -0400 To: kent@bbn.com, ipsec@tis.com From: Naganand Doraswamy Subject: Straw Poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I vote for the notify message to indicate the window size. As Bill S mentioned, the initiator can ignore this message if it wants to and it does not add any overhead for ISAKMP or IPsec. I dont like encryptionless ESP. It might be a little bit more efficient than AH but it does introduce lot of confusion. I would say that some one can use AH if they want to authenticate the pckets. Also, I am for making the replay mandatory both in AH and ESP. I hope I am not too late in giving my views. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue May 20 11:00:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28853 for ipsec-outgoing; Tue, 20 May 1997 11:00:06 -0400 (EDT) Message-Id: <2.2.32.19970520151445.00be3c08@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, 20 May 1997 11:14:45 -0400 To: "PALAMBER.US.ORACLE.COM" From: Naganand Doraswamy Subject: Re: ESP New Draft Cc: ipsec@tis.com, PALAMBER@us.oracle.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, I strongly disagree with you statement that there is enough interest for encryptionless ESP that we should add support for it. In Memphis there was overwhelming majority for adding support for it and in my option we SHOULD not add support for this. As Matt Thomas metioned it will much more difficult to ship only auth version of IPsec and this is unnecessary complication without much profit. I request you to seriously reconsider your decision and adding support for this. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue May 20 11:16:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28966 for ipsec-outgoing; Tue, 20 May 1997 11:14:35 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705201357.JAA02213@jekyll.piermont.com> References: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 11:20:33 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, I now have new appreciation for what Ran and Paul have endured as co-chairs for this group. In initiating this straw poll, I clear did a bad job, e.g., by not following the lead that Ran established in the ones that he administered. For example, I failed to establish the duration over whioch the poll would be conducted, and I failed to mention that private "votes" (ones not sent to the list) would be counted, etc. Mea culpa; I was too informal in trying to conduct this informal poll So, let's assume the end of this week is the closing date, thus having about a two-week interval for votes. Also, private votes count too. I criticized Ran privately for this practice in the past, and now I understand his rationale, i.e., I have received a few votes in favor of encryptionless ESP that were not made public because of fear of getting pilloried on this list. It's unfortunate that we have a deserved reputation for such animosity on this list. Meanwhile, I'll try to generate a message that I thibnk captures the major points, pro and con, over this issue, in an effort to clarify the discussion, as I have also received some messages indicating some confusion. Given all of the traffic, and the length of some of the messages, such confusion is to be expected. Steve From owner-ipsec Tue May 20 11:30:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29046 for ipsec-outgoing; Tue, 20 May 1997 11:30:37 -0400 (EDT) Message-Id: <199705201536.AA158672619@relay.hp.com> To: "Angelos D. Keromytis" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: angelos's message of Tue, 20 May 1997 10:18:01 +0100. <199705201419.KAA27177@codex.cis.upenn.edu> Date: Tue, 20 May 1997 11:36:58 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'd much rather have vendors say they don't support ESP (or that > they have two versions of IPsec, one domestic and one exportable), > than them claiming they support "a version of ESP that is almost as > secure as the standard says, and it's exportable!". Right. That's a much clearer expression of my opinion on the subject than I've been able to manage to date.. - Bill From owner-ipsec Tue May 20 11:36:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29106 for ipsec-outgoing; Tue, 20 May 1997 11:36:39 -0400 (EDT) Message-Id: <199705201542.LAA03958@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 11:20:33 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 May 1997 11:42:56 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > I now have new appreciation for what Ran and Paul have endured as > co-chairs for this group. In initiating this straw poll, I clear did a > bad job, e.g., by not following the lead that Ran established in the ones > that he administered. For example, I failed to establish the duration over > whioch the poll would be conducted, and I failed to mention that private > "votes" (ones not sent to the list) would be counted, etc. Mea culpa; I > was too informal in trying to conduct this informal poll Steve; I realize that some other people care passionately about the encryptionless ESP issue. Myself, I don't care much, quite frankly. I'm happy either way, and I have no personal leanings. I also think it makes no real practical difference. *I REALLY MEAN THIS*. I have no personal axe to grind here. However, I'm a bit of a stickler for following procedure. We had a meeting at Memphis and the issue wasn't even close. We had close to unanimity against encryptionless ESP. This being the IETF, we follow the consensus. It wasn't even a rough consensus -- it was pretty damn close to everyone. I don't see any reason to believe this has changed. I understand that some people might perhaps feel that not all ideas have been completely expressed, but I think we've already had closure on this. If we feel free to re-open every possible point just because we dislike the outcomes, then how can we possibly make progress? I wanted 3DES to be mandatory to implement and I gave up on that early on -- I didn't even make much of a public argument, given that it was clear consenus wasn't with me. Should I follow your precedent and begin arguing the point now? Shall we re-open the question of IV lengths? The reason the IETF process works is because people agree to follow the rules. If we don't follow the rules, it falls apart. Perry From owner-ipsec Tue May 20 13:16:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29784 for ipsec-outgoing; Tue, 20 May 1997 13:14:40 -0400 (EDT) Message-Id: <3.0.32.19970520171706.008d11b0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 May 1997 17:17:22 +0000 To: Stephen Kent From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: perry@piermont.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm inclined to write a draft defining a null encryption transform... At 11:20 AM 5/20/97 -0400, Stephen Kent wrote: >Perry, > > I now have new appreciation for what Ran and Paul have endured as >co-chairs for this group. In initiating this straw poll, I clear did a >bad job, e.g., by not following the lead that Ran established in the ones >that he administered. For example, I failed to establish the duration over >whioch the poll would be conducted, and I failed to mention that private >"votes" (ones not sent to the list) would be counted, etc. Mea culpa; I >was too informal in trying to conduct this informal poll > > So, let's assume the end of this week is the closing date, thus >having about a two-week interval for votes. Also, private votes count too. >I criticized Ran privately for this practice in the past, and now I >understand his rationale, i.e., I have received a few votes in favor of >encryptionless ESP that were not made public because of fear of getting >pilloried on this list. It's unfortunate that we have a deserved >reputation for such animosity on this list. > > Meanwhile, I'll try to generate a message that I thibnk captures >the major points, pro and con, over this issue, in an effort to clarify the >discussion, as I have also received some messages indicating some >confusion. Given all of the traffic, and the length of some of the >messages, such confusion is to be expected. > >Steve > > > From owner-ipsec Tue May 20 13:37:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29920 for ipsec-outgoing; Tue, 20 May 1997 13:37:39 -0400 (EDT) Date: Tue, 20 May 1997 13:42:56 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705201742.NAA13520@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: ESP revisions straw poll X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > > I realize that some other people care passionately about the > encryptionless ESP issue. Myself, I don't care much, quite > frankly. I'm happy either way, and I have no personal leanings. I also > think it makes no real practical difference. *I REALLY MEAN THIS*. > I have no personal axe to grind here. > > However, I'm a bit of a stickler for following procedure. We had a > meeting at Memphis and the issue wasn't even close. We had close to > unanimity against encryptionless ESP. This being the IETF, we follow > the consensus. It wasn't even a rough consensus -- it was pretty damn > close to everyone. > > [...] > > The reason the IETF process works is because people agree to follow > the rules. If we don't follow the rules, it falls apart. Well, we are closer to agreement than I thought. I too don't think this issue makes much practical difference, and my personal opinion is based on an intangible aesthetic preference, not hard technical requirements. And I share the discomforting feeling that procedure is being abused. However, I find it interesting that two people can observe the same set of events under the same set of ground rules, and still come to radically different conclusions. My interpretation: * The two public IPSEC sessions in Memphis were not making a great deal of progress, so the developers-only session was convened on the spot to hash out the issues and propose solutions to the WG at large. * The developers group had nearly unanimous agreement not to support ESP without encryption. * The document editor issued a call for comments on the set of open issues, one of the developers objected to including auth-only-ESP in the list of issues to be discussed, and Angelos claimed that no one on the list (and only two persons in private, one of whom later recanted) wanted it. * In response to this claim, at least eight people (including Bellovin, Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed support for it (to varying degrees) on the public list. The IETF process absolutely requires that any "decisions" reached at meetings be confirmed by discussions on the mailing list. In many cases, the decisions reached at the meeting are confirmed on the list, either by active discussion or by silent consent. In this case, the discussion is active. It is incorrect to claim that consensus was reached in Memphis, because by IETF definition no decisions made there can be final. And it is incorrect to claim that consensus was reached earlier on the list and is now being revisited by sore losers, because until the "straw poll" message, no consensus had been requested. Many people don't feel the need to discuss their opinions on the list until an explicit solicitation is issued. The process *is* being followed. When the poll is over, I'll accept the results, whatever they are. From owner-ipsec Tue May 20 18:07:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01823 for ipsec-outgoing; Tue, 20 May 1997 18:06:11 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705201542.LAA03958@jekyll.piermont.com> References: Your message of "Tue, 20 May 1997 11:20:33 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 18:12:57 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, I don't intend to ride roughshood over IETF procedures, and I believe my characterization of how the straw poll is being conducted is consistent with how this WG has conducted such polls in the past. As for the Memphis IETF meeting, I have been informed that the second day implementors meeting did express a clear, overwhelming intent to not support auth-only ESP. No argument there However, consistent with IETF procedures, that decision is not the final say for the WG. I could observe that when I briefed the WG attendees at the San Jose meeting there seemed to be support FOR this mode of ESP. (I admit that the minutes from that meeting don't do a great job of recording all the details, but a completely modular ESP was part of the presentation that I gave. It's also a pity that the proceedings don't include those slides!) That previous show of support (in San Jose) clearly was not the last word, else we could argue that the matter was closed at that point, four months earlier than the Memphis meetings. Steve From owner-ipsec Tue May 20 18:57:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02073 for ipsec-outgoing; Tue, 20 May 1997 18:57:44 -0400 (EDT) Message-Id: <199705202303.TAA18619@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:57:57 EDT." <199705201357.JAA02213@jekyll.piermont.com> Date: Tue, 20 May 1997 19:03:09 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Since it seems that we need to show the support on the list *AGAIN*, I'll add my $0.02. I do not support reopening this issue. I support the consensus reached at memphis. If you need AH, use AH. And, as David has pointed out: > I just think it's silly to write a separate < 1 page RFC to specify > something that: > > 1) has semantic and performance properties that are useful to some, > 2) is short and easy to describe in the base ESP specification, > 3) has zero impact on developers' compliance with the standard, and > 4) will be implemented if there's market demand and won't be otherwise, > *regardless* of where it is documented. Since writing such a document is so very easy, I would suggest that those that are interested in having encryption-less ESP write that document, and advance it to standard on its own. There is no reason to put any mention in the base document. :!mcr!: | Network security programming, currently Michael Richardson | with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM4ItoqZpLyXYhL+BAQGFZwMAiaXWmkjinL5tffn9s7ZbXJ8zZUYBXC9x UNM95s/ONiSGkBZEf5OHkwQrYBY8Tk8QmrrD0dakYpwObr8JOfCqSF1wh4STpX3P WREUuRvWH2I0QDCm78HJC/yInWnnN7BD =UXlg -----END PGP SIGNATURE----- From owner-ipsec Wed May 21 01:13:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03863 for ipsec-outgoing; Wed, 21 May 1997 01:10:49 -0400 (EDT) Date: Wed, 21 May 97 04:50:24 GMT From: "William Allen Simpson" Message-ID: <5906.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > So, let's assume the end of this week is the closing date, thus > having about a two-week interval for votes. Also, private votes count too. > I criticized Ran privately for this practice in the past, and now I > understand his rationale, i.e., I have received a few votes in favor of > encryptionless ESP that were not made public because of fear of getting > pilloried on this list. It's unfortunate that we have a deserved > reputation for such animosity on this list. > Private "votes" do _NOT_ count. Ever. They are not part of the record. When the "process" is examined, in the IESG or in court, the private messages will be meaningless. You want to come to the dance, you have to pay the piper. And that means public position statements are publicly rebutted, fragile egos not-with-standing. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed May 21 01:13:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03862 for ipsec-outgoing; Wed, 21 May 1997 01:10:48 -0400 (EDT) Date: Wed, 21 May 97 04:58:28 GMT From: "William Allen Simpson" Message-ID: <5907.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: dpkemp@missi.ncsc.mil (David P. Kemp) > And I share the discomforting feeling that procedure is being abused. > > * The two public IPSEC sessions in Memphis were not making a great deal > of progress, so the developers-only session was convened on the spot to > hash out the issues and propose solutions to the WG at large. > The IPSec meetings for several years have not made any tangible progress. > * The developers group had nearly unanimous agreement not to support > ESP without encryption. > Yep. > * In response to this claim, at least eight people (including Bellovin, > Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed > support for it (to varying degrees) on the public list. > Woah! You've got me in the wrong camp! I'm against encryptionless ESP, as mandatory to support, or even as _mentioned_ in the ESP base. What I noted was that an "encryptionless" transform could be written. It could have its own RFC number. Bellovin has recently offered. I noted these things in order to bring the argument to a conclusion, since the "encryptionless" camp could have their wishes as a non-mandatory entension. But they don't seem to be satisfied. They want to be mandatory. > The IETF process absolutely requires that any "decisions" reached at > meetings be confirmed by discussions on the mailing list. Absolutely, but that has happened. It's been a month and a half! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed May 21 02:55:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04416 for ipsec-outgoing; Wed, 21 May 1997 02:53:50 -0400 (EDT) Message-Id: <199705210700.AAA03677@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 21 May 97 00:00:24 -0700 To: "William Allen Simpson" Subject: Re: ESP revisions straw poll cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <5906.wsimpson@greendragon.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 21 May 97 04:50:24 GMT From: "William Allen Simpson" > > From: Stephen Kent > > So, let's assume the end of this week is the closing date, thus > > having about a two-week interval for votes. Also, private votes count too. > > I criticized Ran privately for this practice in the past, and now I > > understand his rationale, i.e., I have received a few votes in favor of > > encryptionless ESP that were not made public because of fear of getting > > pilloried on this list. It's unfortunate that we have a deserved > > reputation for such animosity on this list. > > > > Private "votes" do _NOT_ count. Ever. They are not part of the > record. When the "process" is examined, in the IESG or in court, > the private messages will be meaningless. > Why don't private votes count? They do in public elections. What does examination of any IETF process in court have to do with anything? I don't see why private messages cannot be a matter of record. Since you mentioned the court system, private correspondence is often presented as evidence. You need look only as far as McVeigh and Kaczynski. > You want to come to the dance, you have to pay the piper. And that > means public position statements are publicly rebutted, > fragile egos not-with-standing. > Sounds a bit like a fraternity. -dpg From owner-ipsec Wed May 21 03:53:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA04766 for ipsec-outgoing; Wed, 21 May 1997 03:52:53 -0400 (EDT) Message-Id: <199705210759.DAA27328@codex.cis.upenn.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 13:42:56 EDT." <199705201742.NAA13520@argon.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7946.864201449.1@dsl.cis.upenn.edu> Date: Wed, 21 May 1997 03:57:29 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705201742.NAA13520@argon.ncsc.mil>, David P. Kemp writes: > >* The document editor issued a call for comments on the set of open issues, > one of the developers objected to including auth-only-ESP in the list > of issues to be discussed, and Angelos claimed that no one on the list > (and only two persons in private, one of whom later recanted) wanted it. I never said noone; i said 3 (at that point, Kent, Glatting and Hilarie has spoken for it - and i did forget Lynn). As for private, it should be obvious i meant private with me (in response to my first message). I have no idea how many people talked to Steve. >* In response to this claim, at least eight people (including Bellovin, > Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed > support for it (to varying degrees) on the public list. I must have missed Simpson' message, and i thought Steve (Bellovin) was just sick and tired of the arguing, not for e-ESP... -Angelos From owner-ipsec Wed May 21 07:32:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06033 for ipsec-outgoing; Wed, 21 May 1997 07:29:22 -0400 (EDT) Message-Id: <3.0.32.19970521113228.00890250@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 May 1997 11:34:48 +0000 To: "Angelos D. Keromytis" From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:57 AM 5/21/97 +0100, Angelos D. Keromytis wrote: >I must have missed Simpson' message, and i thought Steve (Bellovin) >was just sick and tired of the arguing, not for e-ESP... Both, actually. Encryptionless ESP is the way AH should have been designed. (I objected to the current scheme at least as far back as Stockholm.) But yes, I'm tired of arguing. I'll settle for something that's ugly, less efficient, and unclean if it's here *now*... From owner-ipsec Wed May 21 08:44:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06830 for ipsec-outgoing; Wed, 21 May 1997 08:42:22 -0400 (EDT) Message-Id: <199705211248.IAA28217@codex.cis.upenn.edu> To: "Steven M. Bellovin" cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 11:34:48 -0000." <3.0.32.19970521113228.00890250@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8381.864218820.1@dsl.cis.upenn.edu> Date: Wed, 21 May 1997 08:47:01 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970521113228.00890250@127.0.0.1>, "Steven M. Bellovin" wri tes: > >Both, actually. Encryptionless ESP is the way AH should have been designed. >(I objected to the current scheme at least as far back as Stockholm.) But >yes, I'm tired of arguing. I'll settle for something that's ugly, less >efficient, and unclean if it's here *now*... Several people have mentioned that what the AH computation covers could be negotiated (wether it's the current scheme or just hte payload) by the key management layer. I don't think there would be many objections to that. -Angelos PS. I personally wouldn't object to a separate null encryption transform document either; i just don't want null-encryption in the base document. From owner-ipsec Wed May 21 09:49:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07402 for ipsec-outgoing; Wed, 21 May 1997 09:46:23 -0400 (EDT) Date: Wed, 21 May 1997 16:52:42 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705211352.QAA14416@ee.technion.ac.il> To: smb@research.att.com Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >yes, I'm tired of arguing. I'll settle for something that's ugly, less >efficient, and unclean if it's here *now*... Actualy from a pure cryptographic point of view there is something very clean and nice about an empty encryption: none of the known key search attacks will apply to this method (and I suspect that one can prove that even future attacks will not apply either). :) Hugo From owner-ipsec Wed May 21 09:49:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07412 for ipsec-outgoing; Wed, 21 May 1997 09:48:23 -0400 (EDT) To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-des1-v2-00.txt Date: Wed, 21 May 1997 09:22:46 -0400 Message-ID: <9705210922.aa29493@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC Transform Author(s) : P. Karn, P. Metzger, W. Simpson Filename : draft-simpson-esp-des1-v2-00.txt Pages : 13 Date : 05/19/1997 This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). 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-simpson-esp-des1-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1-v2-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-simpson-esp-des1-v2-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: <19970519171713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des1-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des1-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519171713.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 21 10:30:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07684 for ipsec-outgoing; Wed, 21 May 1997 10:25:27 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5907.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 10:24:54 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You just said: "I noted these things in order to bring the argument to a conclusion, since the "encryptionless" camp could have their wishes as a non-mandatory entension. But they don't seem to be satisfied. They want to be mandatory." While it is true that the current I-D would suggest mandatory support for encryptionless ESP, my message of 5/15 stated: "I do have a suggestion, though, to help reach closure on this topic. What if we say that an IPSEC implementation MAY elect to send packets that are authenticated, but not encrypted? That makes the existing implementations compliant in this regard, yet holds open th opportunity for future implementations to offer this feature if there is sufficinet demand. An attempt to negotiate a set of algorithms that includes no encryption can be rejected just like an attempt to negotiate use of an encryption algorithm that is not supported. One could even encode this as a null encryption algorithm, as Bill Simpsom noted, if that would make processing any more uniform." From owner-ipsec Wed May 21 10:30:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07685 for ipsec-outgoing; Wed, 21 May 1997 10:25:28 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5906.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 10:20:50 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Look back at the straw polls Ran executed and you'll see that he did precisely this. I'm not changing the rules, though I have objected to this way of doing business in the past. The unfortunate fact is that harsh messages from members of this list, and some of your previous messages are often cited as examples of this, have intimidated members of the list, disenfranchising them. This approach was adopted to counter this problem. Steve From owner-ipsec Wed May 21 11:02:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07935 for ipsec-outgoing; Wed, 21 May 1997 10:55:55 -0400 (EDT) From: Kai Martius Organization: UNIKLINIK TUD To: ipsec@tis.com Date: Tue, 21 May 1997 16:50:52 MET Subject: AH-Lite Reply-to: kai@imib.med.tu-dresden.de X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <2D745207181@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm fairly new on this list (unfortunally, because the discussion is -mostly- very interesting), so I apologize for things I write or ask that may have been discussed months ago. First my opinion to the discussion about ESP with or w/o encryption: Authentication and integrity will be in much broader use than encryption, I believe. Beside export regulation issues there are much more nodes on the Net that want to verify authenticity and integrity of hosts/users/servers than nodes that have to provide privacy. Privacy is more an end-to-end issue i.e. application to application. Only in a VPN-construction where a security gateway detects unencrypted packets it has to use Tunnel-ESP. It's much more important the GW can use _autheticated_ adresses or -much better- certificates to make a policy-based decision what to do with that packet. I read the current I-D so that AH already provides authentication over the whole packet (except some header fields) - so why we need auth.-only ESP? (provokative question: why auth. in ESP on the whole? If you need authenticy / integrity use AH , if you need privacy too, use ESP!; ESP allone would only work with 'integrity-enabled' encryption mechanism) Because we won't see public key crypto for auth. purposes very soon, I see a problem in verifying AH on other systems than dst. system. Assuming fragmentation, AH could only be validated on dst. system (even if we use public key crypto). AH-tunnel would be a way, but I think thats a lot of overhead. So, is there a way to use AH for header-authentication only? I could imagine following processing: - Sender uses AH to authenticate the whole packet, SA with ultimate destination. - if there are nodes on the way that want to verify packets, the sender has to establish different SAs to this nodes. But: It only needs to authenticate appropriate header fields, because a concatenation to data portion is given through inclusion of first AH in ICV-computation. Extra AHs should be placed _before_ all other AHs. Problem: how to find the nodes that need a extra AH? (ICMP-message or special DNS-record - like proposed by Dan Harkins some times ago?). Question: Do I need another IP-Header together with extra AH (which would be AH-tunnel-mode without authenticating the whole packet again); but if the node is a router, packet won't be sent with dst. address .. ? Question: how could I maintain a SA without being the addressee of the packet? - this solution would also be possible, if gateways / routers on organisation boundaries don't want to verify packets from inside, but working on a VPN. Now the gateway / router has to establish the appropriate SA and inserts the extra AH. But: If there is no AH yet, it has to authenticate the whole packet. - every verified AH can be extracted from the packet. Any suggestions on this scheme? Thanks, Kai From owner-ipsec Wed May 21 11:40:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08215 for ipsec-outgoing; Wed, 21 May 1997 11:37:24 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 09:44:01 -0600 From: Brad Davis To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll -Reply Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk >>> Dennis Glatting 05/21/97 01:00am >Why don't private votes count? They do in public elections. Public elections are not consensus building exercises. If we were counting votes then this discussion would not even be happening. The proposal would have failed long ago. >I don't see why private messages cannot be a matter of record. >Since you mentioned the court system, private correspondence >is often presented as evidence. You need look only as far as >McVeigh and Kaczynski. Private messages are like private conversations at the IETF meetings, they are useful to discuss ideas and present positions, but they are not at all useful to build consensus. That requires the private messages become public. The WG chair cannot allow private messages to control the WG. If something is so sensitive that it cannot be brought up in a public meeting, then it must either be ignored, brought up to the IETF Board, or each member of the WG must be approached individually (and consensus built). In a court of law (US law), private messages are not part of the "record" until they are made public by being subpoenaed (except in certain cases of national security). They then become part of the public record and are admissible in the court. >> You want to come to the dance, you have to pay the piper. And that >> means public position statements are publicly rebutted, >> fragile egos not-with-standing. >Sounds a bit like a fraternity. We are, in the original sense of the word. Brad Davis U.S. Robotics From owner-ipsec Wed May 21 11:52:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08299 for ipsec-outgoing; Wed, 21 May 1997 11:50:26 -0400 (EDT) Message-Id: <199705211551.LAA07331@raptor.research.att.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Date: Wed, 21 May 1997 11:51:34 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970521113228.00890250@127.0.0.1>, "Steven M. Bell ovin" wri tes: > >Both, actually. Encryptionless ESP is the way AH should have been de signed. >(I objected to the current scheme at least as far back as Stockholm.) But >yes, I'm tired of arguing. I'll settle for something that's ugly, le ss >efficient, and unclean if it's here *now*... Several people have mentioned that what the AH computation covers could be negotiated (wether it's the current scheme or just hte payload) by the key management layer. I don't think there would be many objections to that. Well, count at least one... We should try very hard not to add extra complexity. My objection to the current AH specification is that it is complex to implement. Adding a negotiated variant would just add to the complexity. Besides, each variant would need to be analyzed for safety. Hmm -- we could make the scope of the authentication programmable. AH-scope: { bytes=1-5 byte-order=network bits=2-4 bit-order=intel base=ip bytes=7-8 byte-order=ibm bits=* base=udp bytes=* base=ip-options filter=java::ip_optionfilt(type,len) } Never mind, I'm feeling grouchy this morning... Let me be a bit more blunt than usual. *) I don't like complexity. Apart from the esthetics -- and those are important -- complex structures are buggy. Cryptographic protocols are *hard* to get right; the more of them we have, the less assurance we have that any of them individually are correct. More to the point, we have no assurance that arbitrary combinations are correct. We've already seen that the order of AH and ESP can be important (for example, against short-block guessing attacks). *) I don't like complex code. It's likely to be buggy. *) I don't like unnecessary multiplication of mechanism. This is especially true when there's no clear guidance -- especially guidance amenable to programmed decisions -- about when to use which variant. In this particular case, someone has suggested negotiating what AH covers. What is the basis for making the decision? *) I don't like mutating protocols. The problem with AH is that some fields are sometimes modified in transit. This is not under control of the end systems. In fact, it's rarely knowable to the users of the end systems, since they don't control what happens in the network cloud. The solution, such as it is, was to decree that certain fields have to be zeroed before the MAC computation. Leaving out the layering violation (see the point about code complexity above), in the 21 months since RFC 1826 the network cloud has changed its behavior. Section 3.2.3.1.1 of the Kent/Atkinson AH draft notes (with appropriate snideness) that the TOS field should now be zeroed, too, since some router vendors have chosen to violate RFC 791 and diddle those bits. And it's going to get worse -- see Section 3.2.3.1.2 for examples of what I mean. *) I don't like layering violations. AH requires that the IP header be calculated first, then AH called to fill in data that follows the IP header. *) I don't like meaningless cryptography. Almost two years ago, I posted a field-by-field analysis. I showed that the IP header fields are either irrelevant for security purposes, changed en route (and hence not protectable), or are or should be bound to the security association, and hence need not be authenticated on a per-packet basis. That's all well and good. It's also irrelevant -- others disagreed with me, for good and sufficient reason, and their arguments (and needs) carried the day. I've kept quiet about the issue since then, because I have another dislike: *) I don't like working groups that drag on forever, fine-tuning a protocol to the point of irrelevancy. Folks, we're under a deadline. There are real products out there that implement some version of IPSEC. There are things like PPTP that also include authentication and encryption. We need to finish *now*. The only reason we're discussing this again is because we realized that encryption almost always requires authentication. This may not be sufficient reason to reopen the question, especially given the immediately preceeding point. But yes, in an ideal world I'd opt for a clean AH, aka encryptionless ESP. --Steve Bellovin From owner-ipsec Wed May 21 13:24:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09050 for ipsec-outgoing; Wed, 21 May 1997 13:23:27 -0400 (EDT) Message-Id: <199705211729.NAA26963@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: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 00:00:24 PDT." <199705210700.AAA03677@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 May 1997 13:29:17 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > Why don't private votes count? They do in public elections. This isn't an election. We don't VOTE in the IETF. We express group consensus -- sometimes rough, sometimes not. Things done in private are hard for the group as a whole to assess. Perry From owner-ipsec Wed May 21 13:34:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09116 for ipsec-outgoing; Wed, 21 May 1997 13:33:55 -0400 (EDT) From: rivest@theory.lcs.mit.edu (Ron Rivest) Date: Wed, 21 May 97 10:32:08 EDT Message-Id: <199705211432.AA06746@swan.lcs.mit.edu> To: ipsec@tis.com Subject: Empty encryption Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee, if we christen the identity (null) transform as an encryption technique, does that mean we have to apply for export approval to ship out a file-copy program? ;-) Cheers, Ron From owner-ipsec Wed May 21 15:14:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09970 for ipsec-outgoing; Wed, 21 May 1997 15:12:31 -0400 (EDT) Message-ID: <338300B3.37DA@Philosophers.GR> Date: Wed, 21 May 1997 10:03:32 -0400 From: Plato X-Mailer: Mozilla 3.0 (Macintosh; U; PPC) MIME-Version: 1.0 To: ipsec@tis.com Subject: IPsec and Platonic =?iso-8859-1?Q?Ideals=AE?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA07484 Sender: owner-ipsec@ex.tis.com Precedence: bulk Gentlemen: It has recently come to my attention that your IETF WG is using the term "Platonic Ideal" to refer to certain aspects of ongoing work.  I would like to observe that one of my best known dialogues does, in fact, bear on the area of cryptography used for communication.  Most historians of ancient Greece have terroneously ranslated my text into a question of whether a tree falling in a forrest makes a noise if nobody is present to hear.  In fact, the original text asks the analogous question of whether a passive wiretapper, intercepting an encrypted (at the physical layer) staellite down link can be said to have effected wiretapping.  (I attribute the mis-translation to the fact that most historians are not very technical.)  With this in mind, I suggest that members of your WG exercise due restraint in referring to certain matters as being representative of Platonic Ideals®.  My attorney has suggested that I retroactively apply for a trademark on this term and its scope of applicability will certainly include the area in which the IPsec WG conducts its business, based on the properly translated dialogue I cited above. Sincerely, Plato From owner-ipsec Wed May 21 18:18:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11090 for ipsec-outgoing; Wed, 21 May 1997 18:17:02 -0400 (EDT) Date: Wed, 21 May 1997 18:20:08 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705212220.SAA01890@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199705211925.MAA07040@baskerville.CS.Arizona.EDU> Subject: Re: IPsec and Platonic =?iso-8859-1?Q?Ideals=AE?= Sender: owner-ipsec@ex.tis.com Precedence: bulk > historians of ancient Greece have terroneously ranslated my text into We have some terroneous ranslators on this bus, too. Hilarie PS Thanks for the levity --- it is not falling (rising?) in an empty forest. From owner-ipsec Wed May 21 19:26:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11489 for ipsec-outgoing; Wed, 21 May 1997 19:25:36 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 19:33:00 -0400 To: ipsec@tis.com From: Stephen Kent Subject: new AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, You will soon receive a new I-D for AH, that includes fixes for all but one of the comments made after Memphis. The differences between this version and RFC 1826 are documented in a new section, so I won't bother describing them here. The one unresolved area has to do with AH placement in IPv6 headers. Dan McDonald and Charlie Lynn differed a bit on the wording of the text with regard to the semantics of destination options appearing before or after AH. I'm not sure how critical this residual issue is, but my analysis of the messages suggests that we did not come to a resolution. I'd appreciate it is Charlie and Dan could come up with wording that both are comfortable with, so that we can wrap up this spec. A revsised version of ESP will follow next week. As a reminder, I note that we began a few eeks ago by sending out the first of a series of messages that address topics for inclusion in the Security Architecture document. The first message addressed PMTU processing and elicited just a few responses, to which replies were sent. In the interest of resolving these issues so that implementors can proceed with confidence in releasing compliant IPsec products, we need to make progress on these topics as each is released (before we compose and distribute the Security Architectuire I-D). So, please go back and review the PMTU message, and review and respond to subsequent messages that will be released soon. Thanks, Steve From owner-ipsec Wed May 21 20:00:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11643 for ipsec-outgoing; Wed, 21 May 1997 19:59:34 -0400 (EDT) Message-Id: <199705220006.RAA10511@cs.pdx.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 13 May 1997 21:05:41 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10506.864259571.1@cs.pdx.edu> Date: Wed, 21 May 1997 17:06:11 -0700 From: Bill Trost Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: I've gotten the impression that there is support for encryptionless ESP.... So, I'd like to conduct a straw poll on this topic too. After all this wrangling, I'd like to submit a straw of "whatever, let's get this over with". I think encryptionless ESP is a fine idea, but I see no compelling need to mention it in the ESP draft. On the other hand, Hugo comments on the security characteristics of the Identity transform need to be included in *that* draft.... From owner-ipsec Wed May 21 20:58:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11995 for ipsec-outgoing; Wed, 21 May 1997 20:57:34 -0400 (EDT) Message-Id: <199705220103.SAA07168@greatdane.cisco.com> To: Stephen Kent cc: William Allen Simpson , ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 10:20:50 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 18:03:58 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I'm sure you were against using private "votes" for the very obvious reason that the holder of the straw poll can always ensure his personal viewpoint prevails. Whether there is precedence or not, this is bad-- unless of course we can all include the private discussions we've had in your final tally. Dan. > Look back at the straw polls Ran executed and you'll see that he > did precisely this. I'm not changing the rules, though I have objected to > this way of doing business in the past. The unfortunate fact is that harsh > messages from members of this list, and some of your previous messages are > often cited as examples of this, have intimidated members of the list, > disenfranchising them. This approach was adopted to counter this problem. From owner-ipsec Thu May 22 00:43:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA13110 for ipsec-outgoing; Thu, 22 May 1997 00:42:04 -0400 (EDT) Date: Thu, 22 May 97 04:24:05 GMT From: "William Allen Simpson" Message-ID: <5925.wsimpson@greendragon.com> To: Steven Bellovin Cc: ipsec@tis.com Subject: eliminate AH Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > *) I don't like meaningless cryptography. Almost two years > ago, I posted a field-by-field analysis. I showed that the IP > header fields are either irrelevant for security purposes, > changed en route (and hence not protectable), or are or should > be bound to the security association, and hence need not be > authenticated on a per-packet basis. > I don't remember this message, and cannot find it. Could you please point us to a date (or even a month), so that I can find it in my archives? > *) I don't like working groups that drag on forever, > fine-tuning a protocol to the point of irrelevancy. Folks, > we're under a deadline. There are real products out there that > implement some version of IPSEC. There are things like PPTP > that also include authentication and encryption. We need to > finish *now*. > My view is that we passed the deadline some years ago. Certainly, we passed our charter deadline. I think we passed the Internet commercial usefulness deadline, too. We have at least 4 Working Groups creating their own security protocols, because this WG never got done. We had something, and the "powers that be" declared it obsolete. > The only reason we're discussing this again is because we realized that > encryption almost always requires authentication. This may not be > sufficient reason to reopen the question, especially given the > immediately preceeding point. But yes, in an ideal world I'd opt > for a clean AH, aka encryptionless ESP. > Fine. Then, let's get rid of AH entirely. We started without AH, with swIPe in 1992-1993. I was a convert to the philosophy that orthogonality of function was important in this matter, for both political (export) and practical reasons; thus, that AH and ESP should be separate. Like many converts, I followed that path with zeal. I was willing to have the extra 8 bytes of overhead. But, the leader of that path, Ran Atkinson, recanted last year, saying it was a "serious mistake". He said this into a microphone, and we have his words on file. It is causing too much contention to keep going down this path. I don't want 2 different ways to authenticate. It's too complicated. We only need one way, for all the reasons given by Steve in his earlier message. If we have it in ESP, and cannot agree on when to use it and when not, then let's discard AH. Simplify. From owner-ipsec Thu May 22 08:50:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16194 for ipsec-outgoing; Thu, 22 May 1997 08:48:07 -0400 (EDT) From: Uri Blumenthal Message-Id: <9705221254.AA19036@hawpub.watson.ibm.com> Subject: Re: Empty encryption To: rivest@theory.lcs.mit.edu (Ron Rivest) Date: Thu, 22 May 1997 08:54:06 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199705211432.AA06746@swan.lcs.mit.edu> from "Ron Rivest" at May 21, 97 10:32:08 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ron Rivest says: >Gee, if we christen the identity (null) transform as an encryption technique, >does that mean we have to apply for export approval to ship out a file-copy >program? ;-) No, but be ready to spend some time in a federal facility, if they find out about your "cp" program exported to Mexico (:-). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu May 22 10:01:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16752 for ipsec-outgoing; Thu, 22 May 1997 09:57:51 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199705221403.HAA16250@netcom.netcom.com> Subject: Re: eliminate AH To: wsimpson@greendragon.com (William Allen Simpson) Date: Thu, 22 May 1997 07:03:46 -0700 (PDT) Cc: smb@research.att.com, ipsec@tis.com In-Reply-To: <5925.wsimpson@greendragon.com> from "William Allen Simpson" at May 22, 97 04:24:05 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: 944 You may also be interested in Phil Rogaway's comments on IPSEC. It's a couple of years old now but it is probably still relevant. http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/ draft-rogaway-ipsec-comments-00.txt - Alex > > > From: Steven Bellovin > > *) I don't like meaningless cryptography. Almost two years > > ago, I posted a field-by-field analysis. I showed that the IP > > header fields are either irrelevant for security purposes, > > changed en route (and hence not protectable), or are or should > > be bound to the security association, and hence need not be > > authenticated on a per-packet basis. > > > I don't remember this message, and cannot find it. Could you please > point us to a date (or even a month), so that I can find it in my > archives? > > -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu May 22 10:27:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16904 for ipsec-outgoing; Thu, 22 May 1997 10:26:13 -0400 (EDT) Message-Id: <3.0.1.32.19970522103128.0077e4c0@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 10:31:28 -0400 To: "William Allen Simpson" From: Matt Thomas Subject: Re: eliminate AH Cc: ipsec@tis.com In-Reply-To: <5925.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:24 AM 5/22/97 GMT, William Allen Simpson wrote: >I don't want 2 different ways to authenticate. It's too complicated. I'd rather not have two methods as well. >We only need one way, for all the reasons given by Steve in his earlier >message. If we have it in ESP, and cannot agree on when to use it and >when not, then let's discard AH. Simplify. Or simply define AH as encryptionless ESP. (e.g. the processing rules are identical for both execpt that if you are using null-encryption the protocol field is AH else it's ESP). This does. however, mean that IPv6 routing headers and hop-by-hop options can not be authenticated. (the destination node options can be covered by placing them after the AH/ESP; this technique should work for the Mobile IPv6 routing header as well since it's transmitted in "final form" by the mobile host). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu May 22 10:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16971 for ipsec-outgoing; Thu, 22 May 1997 10:37:43 -0400 (EDT) Message-Id: <3.0.32.19970522104135.00761ff0@mail.bbnplanet.com> X-Sender: smarcus@mail.bbnplanet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 May 1997 10:41:39 -0400 To: uri@watson.ibm.com From: Scott Marcus Subject: Re: Empty encryption Cc: Ron Rivest , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:54 AM 5/22/97 -0400, Uri Blumenthal wrote: >Ron Rivest says: >>Gee, if we christen the identity (null) transform as an encryption technique, >>does that mean we have to apply for export approval to ship out a file-copy >>program? ;-) > >No, but be ready to spend some time in a federal facility, if they >find out about your "cp" program exported to Mexico (:-). No problem! Just make sure that the null encryption (vacuously) uses short keys. ;^) -- Scott From owner-ipsec Thu May 22 10:51:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17039 for ipsec-outgoing; Thu, 22 May 1997 10:51:14 -0400 (EDT) Date: Thu, 22 May 1997 10:59 -0500 From: "Hapeman Dale" To: kent@bbn.com, trost@cs.pdx.edu Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Message-ID: <2EBCC26E@asq8po2.bah.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Below... ---------- >From: Bill Trost >Subject: Re: ESP revisions straw poll > > >After all this wrangling, I'd like to submit a straw of "whatever, let's >get this over with". I think encryptionless ESP is a fine idea, but I see >no compelling need to mention it in the ESP draft. > I'd like to latch on an idea here... "I see no compelling need to mention it in the ESP draft". Currently: We have an *algorithm independent* encryption protocol (ESP) which has a conformance section that specifies which algorithms you must implement. We have an *algorithm independent* key management protocol (ISAKMP) which uses a separate document (a DOI) to describe the negotiation of available algorithms (among other things). We have an IPSec DOI that makes statements like "All implementations within the IPSEC DOI MUST support ESP_DES...". Therefore: I see no compelling need to mention ANY ALGORITHM IMPLEMENTATION REQUIREMENTS in the ESP draft. This means that the IPSec DOI document is more than a supplement to ISAKMP, it is essentially a high level policy for implementing IPSec. (I claim that, as the DOI is written, this is already true.) Now, back to the question at hand: Should encryptionless ESP be qualified as MUST, SHOULD, MAY, MAY NOT, SHOULD NOT, BETTER NOT, or ignored? From the DOI (draft-ietf-ipsec-ipsec-doi-02.txt) Section 4.4.4: _____________ 4.4.4, IPSEC ESP Transform Identifiers The Encapsulating Security Protocol (ESP) defines one mandatory and several optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 ESP_DES_CBC 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 4.4.4.1 ESP_DES_CBC -- MAY be used for compatibility 4.4.4.2 ESP_DES -- MUST support ESP_DES along with the HMAC and REPLAY attributes. 4.4.4.3 ESP_3DES -- strongly encouraged to support ESP_3DES along with the HMAC and REPLAY attributes 4.4.4.4 ESP_RC5 -- (no requirement to implement stated) _____________ I claim that we could add: ESP_NADA 5 (or ESP_IDENTITY, or ... :-) and a section 4.4.4.5 that makes no statement concerning mandatory-ness (just as was done in the case of RC5). Note that this section could include any information needed in the "encryptionless transform" document some are asking for. Dale Hapeman hapemand@bah.com From owner-ipsec Thu May 22 11:15:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17197 for ipsec-outgoing; Thu, 22 May 1997 11:13:15 -0400 (EDT) Message-Id: <97May22.110746edt.11649@janus.tor.securecomputing.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: eliminate AH References: <5925.wsimpson@greendragon.com> In-reply-to: wsimpson's message of "Thu, 22 May 1997 00:24:05 -0400". <5925.wsimpson@greendragon.com> 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, 22 May 1997 11:12:03 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > We have at least 4 Working Groups creating their own security protocols, > because this WG never got done. We had something, and the "powers that > be" declared it obsolete. I wouldn't go that far. They're just solving different problems. Nonetheless, we are way past our deadlines, and people *are* going to get fed up and do it themselves if we don't shape up. The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. If we change the bloody standards every 3 months, we'll *never* get running code, and we'll never obtain significant deployment. -- Harald Koch From owner-ipsec Thu May 22 11:23:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17296 for ipsec-outgoing; Thu, 22 May 1997 11:23:17 -0400 (EDT) Date: Thu, 22 May 97 11:27:27 EST From: "Whelan, Bill" Message-Id: <9704228643.AA864325641@netx.nei.com> To: smb@research.att.com, "William Allen Simpson" Cc: ipsec@tis.com Subject: Re: eliminate AH Sender: owner-ipsec@ex.tis.com Precedence: bulk I second the motion to eliminate AH from IPSec. Given the evolution of ESP, it has become redundant. The ESP document should define the - SPI - Mandatory - Sequence Number - Mandatory (I think?) - Opaque Payload Data - Mandatory but dependent upon the transform. - Authentication Data - Optional ESP may define restrictions on the length (e.g. a multiple of eight bytes) of the Opaque Payload Data, but otherwise not define content. Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Optional - Payload Data - Mandatory - Padding - Optional - Next Header - Mandatory My two cents. Bill Whelan From owner-ipsec Thu May 22 19:01:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA19947 for ipsec-outgoing; Thu, 22 May 1997 18:58:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2EBCC26E@asq8po2.bah.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 1997 19:02:32 -0400 To: Hapeman Dale From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dale, Your comments re algorithm independence are applicable to both AH and ESP. I'd be happy to remove the afor compliant implementations and the ISAKMP DOI specs would not be applicable in such cases. So, unless we mandate ISAKMP use in all instances, we need to specify the required algorithms somewhere. One could have yet another RFC with these listed, but the previous RFCs did not take that approach did not adopt that approach, and so I stuck with the previous model. Steve From owner-ipsec Fri May 23 10:15:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24893 for ipsec-outgoing; Fri, 23 May 1997 10:09:22 -0400 (EDT) Message-Id: <199705231434.KAA27906@relay.rv.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Date: Sat, 24 May 1997 02:57:37 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: V2 - Structuring SA proposals CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by portal.ex.tis.com id KAA24890 Sender: owner-ipsec@ex.tis.com Precedence: bulk RE: PF_key v2· I dont like/understand why/disagree with there being two extensions to achieve one objective - that of prioritising algorithms - this is effectively what the ASSOCIATION EXT and the PROPOSAL EXT achieve. Would it be better to have something like the following :- NOTE: alignment being ignored ;-) Base Header: struct sadb_msg { uint8_t sadb_msg_version; uint8_t sadb_msg_type; uint8_t sadb_msg_errno; uint8_t sadb_sa_type; uint8_t sadb_sa_state; uint8_t sadb_sa_spi; uint16_t sadb_msg_len; uint32_t sadb_msg_seq; uint32_t sadb_msg_pid; } Proposal Extension: struct sadb_prop { uint16_t sadb_prop_len; uint16_t sadb_prop_num_combs; uint16_t sadb_prop_replay; (cant flags indicate we want replay ?) uint16_t sadb_prop_flags; } Combination Extension: struct sadb_comb{ uint8_t sadb_comb_num; uint8_t sadb_comb_len; uint8_t sadb_comb_auth; uint8_t sadb_comb_encr; uint16_t sadb_comb_auth_keylen_min; uint16_t sadb_comb_auth_keylen_max; uint16_t sadb_comb_encr_keylen_min; uint16_t sadb_comb_encr_keylen_max; } Elfed **************************************************** Elfed T. Weaver Defence Evaluation & Research Agency Malvern UK +44 01684 894795 weaver@hydra.dra.hmg.gb From owner-ipsec Fri May 23 11:26:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25451 for ipsec-outgoing; Fri, 23 May 1997 11:22:44 -0400 (EDT) Date: Fri, 23 May 1997 11:25:51 -0400 From: "Waterhouse, Richard" Subject: RE: eliminate AH To: "'William Allen Simpson'" , "'C. Harald Koch'" Cc: "'ipsec@tis.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >We have at least 4 Working Groups creating their own security protocols, > >Nonetheless, we are way past our deadlines, and people *are* going to get >fed up and do it themselves if we don't shape up. > >The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. >>> ISAKMP is supposed to be for more general use than just negotiating IP security. Yet I can detect no trace of any effort to coordinate its use it with any of the other Internet security mechanisms. Is there any such effort underway that is simply not visible to me ? From owner-ipsec Fri May 23 11:36:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25572 for ipsec-outgoing; Fri, 23 May 1997 11:36:24 -0400 (EDT) Message-Id: <97May23.113813edt.11650@janus.tor.securecomputing.com> To: "Waterhouse, Richard" cc: "'ipsec@tis.com'" Subject: Re: eliminate AH References: In-reply-to: Richard.Waterhouse's message of "Fri, 23 May 1997 11:25:51 -0400". From: "C. Harald Koch" Date: Fri, 23 May 1997 11:42:30 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Waterhouse, Richard" writes: > ISAKMP is supposed to be for more general use than just negotiating IP > security. Yet I can detect no trace of any effort to coordinate its > use it with any of the other Internet security mechanisms. Is there > any such effort underway that is simply not visible to me ? If we had: - a STABLE standard - running code I'm sure many of the other security people would adopt it. Since we have neither, they're busy inventing their own. -- Harald Koch From owner-ipsec Fri May 23 12:11:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25819 for ipsec-outgoing; Fri, 23 May 1997 12:11:30 -0400 (EDT) Message-Id: <199705231616.JAA09729@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "C. Harald Koch" Cc: "Waterhouse, Richard" , "'ipsec@tis.com'" Subject: Re: eliminate AH In-Reply-To: Your message of "Fri, 23 May 1997 11:42:30 EDT." <97May23.113813edt.11650@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 09:16:56 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk "C. Harald Koch" wrote: > In message , "Waterhouse, Richard" writes: > > ISAKMP is supposed to be for more general use than just negotiating IP > > security. Yet I can detect no trace of any effort to coordinate its > > use it with any of the other Internet security mechanisms. Is there > > any such effort underway that is simply not visible to me ? > > If we had: > > - a STABLE standard > - running code > > I'm sure many of the other security people would adopt it. > > Since we have neither, they're busy inventing their own. Do you have any constructive comments on how to make the standard STABLE? What makes it un-STABLE? I and quite a few others have been able to code independent interoperable implementations from the existing docs in spite of its few known inconsistencies and issues open to interpretation. If you haven't please share your problems with others. You want running code? Visit http://www.cisco.com/public/library/isakmp/isakmp.html answer the questions and it's yours. Once I get the OK I'll be releasing version 7 compliant code (yes it exists, yes it's interoperated with other independent implementations); what's there is version 6. And to answer Richard: yes, there is movement but its just not visible yet. Dan. From owner-ipsec Fri May 23 12:49:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26051 for ipsec-outgoing; Fri, 23 May 1997 12:46:26 -0400 (EDT) Date: Fri, 23 May 1997 12:51:53 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705231651.MAA16706@argon.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP at other layers (was RE: eliminate AH) X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Waterhouse, Richard" > > >We have at least 4 Working Groups creating their own security protocols, > > > >Nonetheless, we are way past our deadlines, and people *are* going to get > >fed up and do it themselves if we don't shape up. > > > >The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. > > >>> ISAKMP is supposed to be for more general use than just negotiating IP > security. Yet I can detect no trace of any effort to coordinate its > use it with any of the other Internet security mechanisms. Is there > any such effort underway that is simply not visible to me ? There is just more than a trace of effort at this point :-). The use of ISAKMP as the TLS key establishment mechanism was discussed as far back as the very first TLS WG meeting. But at that time the IPSEC WG was deep into KMP battles, first with Photuris, then with SKIP. There was not (and still is not) a referenceable RFC for ISAKMP, and little experience with running code. By contrast, the SSL v2 key negotiation mechanism (the "handshake layer") was already widely deployed, and the lessons learned from v2 were applied in the design of SSL v3, the baseline for TLS. Now that the TLS working group is about to publish TLS 1.0, the schedule pressure is off and a little more thought can be given to designing TLS 1.1 and beyond. The TLS discussions in Memphis included accommodating the needs of SSH, and enabling/migrating to the use of ISAKMP. This is just at the discussion stage, and there is certainly no consensus on what specifically needs to be done, but there is a faction that believes that the IETF should have a single KMP suitable for use at all network layers, reducing the need for security analyses for each different network protocol, and enabling new features/requirements to be designed and defined once and then reused for multiple protocols. Rather than having the IPSEC WG attempt to push ISAKMP out to other applications, it would be more effective for the other working groups to attempt to pull ISAKMP in. If there is a protocol you are particularly interested in, go to it's WG and speak up. From owner-ipsec Fri May 23 13:06:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26164 for ipsec-outgoing; Fri, 23 May 1997 13:05:31 -0400 (EDT) Hops: 0 Host: tis.com. Posted-Date: Fri, 23 May 1997 20:06:39 -0200 (GMT) Message-Id: <199705231707.UAA18667@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Cc: "Whelan, Bill" Subject: Re: eliminate AH In-reply-to: Your message of "Thu, 22 May 1997 11:27:27 EST." <9704228643.AA864325641@netx.nei.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 May 1997 20:07:39 +0300 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk > I second the motion to eliminate AH from IPSec. Given the evolution > of ESP, it has become redundant. > > The ESP document should define the > - SPI - Mandatory > - Sequence Number - Mandatory (I think?) > - Opaque Payload Data - Mandatory but dependent upon the transform. > - Authentication Data - Optional [...] Astute readers of this list will note that this is pretty much what swIPe did more than four years ago. Did we really need four years of bit-shuffling to come back to (almost) the same protocol? /ji From owner-ipsec Fri May 23 13:32:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26339 for ipsec-outgoing; Fri, 23 May 1997 13:31:56 -0400 (EDT) Hops: 0 Host: tis.com. Posted-Date: Fri, 23 May 1997 20:36:50 -0200 (GMT) Message-Id: <199705231738.UAA18740@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Subject: Re: eliminate AH In-reply-to: Your message of "Fri, 23 May 1997 11:42:30 EDT." <97May23.113813edt.11650@janus.tor.securecomputing.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 May 1997 20:38:07 +0300 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk > If we had: > > - a STABLE standard > - running code > > I'm sure many of the other security people would adopt it. We have lots of running code. We had half a dozen interoperable implementations in Dallas. Never mind that we had to go change the transforms again (I know it's for a good reason, but that's besides the point). I think the main thing we lack is a set of documents saying *how* and *where* to use IPSEC, what it buys people, and why they shouldn't just roll their own. Also, building some interfacing mechanisms to the key/certificate management stuff mechanisms such as SSH have may further promote the cause of IPSEC until we have a working generic key management mechanism. /ji PS: Yes, I can hear the shouts now: "Why don't *you* do it, JI?" From owner-ipsec Fri May 23 15:03:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26834 for ipsec-outgoing; Fri, 23 May 1997 15:02:29 -0400 (EDT) Message-Id: <97May23.150439edt.11651@janus.tor.securecomputing.com> To: Daniel Harkins cc: "Waterhouse, Richard" , "'ipsec@tis.com'" Subject: ISAKMP stability (was Re: eliminate AH) References: <199705231616.JAA09729@dharkins-ss20> In-reply-to: dharkins's message of "Fri, 23 May 1997 12:16:56 -0400". <199705231616.JAA09729@dharkins-ss20> From: "C. Harald Koch" Date: Fri, 23 May 1997 15:08:55 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705231616.JAA09729@dharkins-ss20>, Daniel Harkins writes: > > What makes it un-STABLE? >From the point of view of other working groups, which is what we're discussing: - It's a draft document, not an RFC, and not scheduled to be published. - there has been no WG last call. - It's 3 months old, but we're still discussing changes. Given how long we've been working on it, 3 months is no time at all. Draft 3 is from November 1995, after all. - almost every revision has had large changes; even 6 -> 7 changes a couple of on-the-wire packet formats. All of this is fine for the IPsec working group; just don't expect anyone else to pay much attention until we've at least gone through last call. -- Harald From owner-ipsec Fri May 23 15:34:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26943 for ipsec-outgoing; Fri, 23 May 1997 15:31:28 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 15:39:44 -0400 To: ipsec@tis.com From: Karen Seo (by way of Stephen Kent) Subject: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-04.txt 23 May 1997 IP Authentication Header Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng and IPsec Working Groups. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header 23 May, 1997 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................4 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................5 3. Authentication Header Processing..................................5 3.1 Authentication Header Location...............................5 3.2 Outbound Packet Processing...................................7 3.2.1 Security Association Lookup.............................7 3.2.2 Sequence Number Field...................................8 3.2.3 Integrity Check Value Calculation.......................8 3.2.3.1 Handling Mutable Fields............................8 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.2 ICV Computation for IPv6......................9 3.2.3.2 Padding...........................................10 3.2.3.2.1 Authentication Data Padding..................10 3.2.3.2.2 Implicit Packet Padding......................10 3.2.3.3 Authentication Algorithms.........................10 3.2.4 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Reassembly.............................................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................12 3.3.4 Integrity Check Value Verification.....................13 4. Auditing.........................................................13 5. Conformance Requirements.........................................14 6. Security Considerations..........................................14 7. Differences from RFC 1826........................................14 Acknowledgements....................................................15 References..........................................................15 Disclaimer..........................................................16 Author Information..................................................16 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 23 May, 1997 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides an optional confidentiality (encryption) service. [This text will be revised, if necessary, pending the outcome of the auth- only ESP debate.] The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by AH (and by ESP), the concept of Security Associations, the different key management options available for AH (and ESP), and the ways in which AH can be used in conjunction with ESP. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 23 May, 1997 2. Authentication Header Format +---------------+---------------+---------------+---------------+ | Next Header(8)| Payload Len(8)| RESERVED (16) | +---------------+---------------+---------------+---------------+ | Security Parameters Index (32) | +---------------+---------------+---------------+---------------+ | Sequence Number Field (32) | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the ICV computation. 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). 2.2 Payload Length This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion (as defined in the original AH spec) of AH is not counted. (Since the Sequence Number field always present, the fixed portion of AH is now three 32-bit words. However, the "minus 2" length adjustment has been retained for backwards compatibility.) A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "0" value for this field, as there would be no corresponding Authentication Data field. 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 23 May, 1997 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header with which this security header is associated, and relative to the security protocol employed. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" [KA97a] for more details). (A zero value may be used for local debugging purposes, but no AH packets should be transmitted with a zero SPI value.) 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The sequence number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. This field is always present, even if the receiver does not elect to enable the anti-replay service for a specific SA, in order to ensure 8-byte alignment for the IPv6 environment, when the default integrity algorithms are employed. 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.2.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (Use of transport mode in "bump-in-the- stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, is not recommended as these Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 23 May, 1997 implementations may receive outbound IP fragments from the attached host and thus be unable to process these packets according to this specification.) In this mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 23 May, 1997 Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<-- authenticated except for mutable fields ->| -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-------- authenticated except for mutable fields --------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Outbound Packet Processing In transport mode, the transmitter inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 23 May, 1997 3.2.2 Sequence Number Field The transmitter increments the sequence number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number Field. A transmitter MUST not send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. (Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation.) DISCUSSION: For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed here and classified as either mutable or immutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The mutable IPv4 header fields also are enumerated below. The ICV calculation is restricted to the immutable options and specified (base) header fields. Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 23 May, 1997 3.2.3.1.1 ICV Computation for IPv4 The following IPv4 base header fields are zeroed prior to the computation of the ICV: - Time to Live (TTL) - Header Checksum - Offset - Flags - Type of Service (TOS) TTL is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. The TOS field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. Since AH is applied only to non-fragmented IP packets, this field must always be zero, and thus it is excluded (even though it is predictable). The Flags field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Finally, the Header Checksum will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. The following IPv4 options are mutable: record route, timestamp, loose source routing, and strict source routing. These options are treated as zero-filled for purposes of the ICV computation. The IP Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO (option number 134) option are included in the ICV calculation and are not zeroed. 3.2.3.1.2 ICV Computation for IPv6 In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed prior to performing the ICV calculation. IPv6 options contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All other options are also included in the ICV calculation. See the IPv6 specification [DH95] for more information. Note, for example, that the IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as an immutable Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 23 May, 1997 option. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. 3.2.3.2 Padding 3.2.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors: - the length of the ICV - the IP protocol context (v4 or v6) For example, if a default, 96-bit truncated HMAC algorithm is selected, no padding is required for either IPv4 nor IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required for the IPv6 environment. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.2.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.3.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations usually preclude use of such algorithms. As of this writing, the mandatory-to-implement authentication algorithms are Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 23 May, 1997 based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.3 Inbound Packet Processing 3.3.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment,, e.g., the OFFSET field is non-zero, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.3.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA dictates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 23 May, 1997 3.3.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. (Note that there are no provisions for managing transmitted sequence counter values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) If an SA establishment protocol such as Oakley/ISAKMP is employed, then the receiver SHOULD notify the transmitter, during SA establishment, if the receiver will provide anti-replay protection and SHOULD inform the transmitter of the window size. If the receiver has elected to enable the anti-replay service for this SA, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be employed by the receiver. If a larger window size is employed it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Number values lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the sequence number field, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 23 May, 1997 DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number field before updating the bit mask (either turning on a bit or updating the "right" side of the window). 3.3.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.2.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 23 May, 1997 result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the transmitter, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97]): - HMAC with MD5 - HMAC with SHA-1 6. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times, to meet IPv6 alignment requirements (even when anti-replay is not enabled for an SA). The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 23 May, 1997 rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. Acknowledgements For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, 9 June 1994, pp. 21-34. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, April 1993. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, Kent, Atkinson [Page 15] Internet Draft IP Authentication Header 23 May, 1997 February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, November 1991. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, May 1997. [KA97c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, May 1997. [Riv92] Ronald Rivest, "The MD5 Digest Algorithm," RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, March 1996. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent Randall Atkinson BBN Corporation @Home Network 70 Fawcett Street 385 Ravendale Drive Cambridge, MA 02140 Mountain View, CA 94043 USA USA skent@bbn.com rja@inet.org Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 16] From owner-ipsec Fri May 23 17:21:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27556 for ipsec-outgoing; Fri, 23 May 1997 17:18:31 -0400 (EDT) Date: Fri, 23 May 97 20:53:57 GMT From: "William Allen Simpson" Message-ID: <5941.wsimpson@greendragon.com> To: ipsec@tis.com Subject: draft-simpson-esp-des1-v2-00.txt to Draft Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk This is an update of RFC-1829 to comport with the recent format decisions of the group. Although this is a subset of the previous bits-on-the-wire, this subset was required to be supported (32 bit field following the SPI), so there should not be any change in interoperability. This document covers only the following: Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Payload Data - Padding - Payload Type There is a complete list of changes in the document, mostly editorial. In response to JI's recent note: yes, we have returned to swIPe after a 4 year diversion, and I added the acknowledgement and references. Jeff Schiller (the Security Area Director) has indicated that: RFC-1829 is the product of the IPSEC working group. It is for the working group to decide whether or not to advance it. I will happily act upon a recommendation of the working group as communicated to me by the chair. As interoperability has been demonstrated between 2 or more implementations, I ask that this document be immediately forwarded (within a few days) to the Area Director for advancement to Draft Standard. Then, the IESG will issue the 2 week IETF Last Call. By that time, we should have no problem compiling a more comprehensive list of interoperable implementations. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri May 23 19:09:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28003 for ipsec-outgoing; Fri, 23 May 1997 19:07:00 -0400 (EDT) Message-Id: <199705232309.TAA20267@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Date: Fri, 23 May 1997 19:09:33 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff Schiller (the Security Area Director) has indicated that: RFC-1829 is the product of the IPSEC working group. It is for the working group to decide whether or not to advance it. I will happi ly act upon a recommendation of the working group as communicated to me by the chair. As interoperability has been demonstrated between 2 or more implementations, I ask that this document be immediately forwarded (within a few days) to the Area Director for advancement to Draft Standard. I'm afraid I disagree; this document is not ready for advancement. First, it's the wrong document. Given the new structure (i.e., as described in draft-ietf-ipsec-new-esp-00.txt), there's far too much in your draft. The CAST-128 draft (draft-ietf-ipsec-esp-cast-128-cbc-00.txt) or RC5-CBC draft (draft-ietf-ipsec-esp-rc5-cbc-00.txt) are much better models for what's needed. (Bill, I realize you feel differently. I don't like documents that overspecify stuff -- changes to the base document's headers would require changes to your document as well, quite unnecessarily.) Second, given the new structure -- with authentication folded in with ESP -- I don't know of any implementations. I suppose one could say that the DES-CBC part is ready, but it's a bit hard to assess without the framework. From owner-ipsec Sat May 24 00:03:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA29205 for ipsec-outgoing; Sat, 24 May 1997 00:01:36 -0400 (EDT) Date: Sat, 24 May 97 03:27:18 GMT From: "William Allen Simpson" Message-ID: <5944.wsimpson@greendragon.com> To: Steven Bellovin cc: ipsec@tis.com Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > I'm afraid I disagree; this document is not ready for advancement. > First, it's the wrong document. Given the new structure (i.e., as > described in draft-ietf-ipsec-new-esp-00.txt), there's far too much > in your draft. The CAST-128 draft (draft-ietf-ipsec-esp-cast-128-cbc-00.txt) > or RC5-CBC draft (draft-ietf-ipsec-esp-rc5-cbc-00.txt) are much better > models for what's needed. Thanks for reading the document. Funny, Steve Kent sent a private message saying almost the same thing. I looked at those (CAST & RC5), and found them remarkably uninformative. I cannot imagine a "protocol" description without packet formats. They should put some packet formats in! I did move the weak key text from the security considerations up to the key sub-section to match them, though. Keeping related stuff like that together was a good idea. > (Bill, I realize you feel differently. I > don't like documents that overspecify stuff -- changes to the base > document's headers would require changes to your document as well, > quite unnecessarily.) > Changes to the base document headers would be a new protocol, and require a new IP Protocol number! Even "new" ESP is still just an SPI (the same as "old" ESP), with a 32-bit Sequence Number (which was one of the options in RFC-1829 and long described in swIPe). The only true change in "new" ESP is the requirement of the sequence field in all transforms, and adding an optional trailing Authenticator. That's all I've done here, update to match the "new" ESP environment. Can anyone imagine ICMP documents with the packet formats only starting after the Checksum field? Nope. The IETF tradition is to copy those definitions for context. True, it is boilerplate, but it certainly aids the implementor by providing context. Besides, the IV is calculated based on the SPI+Sequence fields. Showing them is pretty helpful to implementors. As an aside, I once tried putting the Photuris Cookies in only a single place, early in the _same_ document. After all, they are just the same boilerplate repeated over and over. Suddenly, the most frequently asked question was "where are the Cookies"? So, I still have that section describing the Cookies, but I also faithfully copy them into each packet format. It was only a little extra work, but it saved a lot of explanation in the long run.... I don't like _under_ specifying stuff. Each transform should stand on its own! > Second, given the new structure -- with authentication folded in with > ESP -- I don't know of any implementations. I suppose one could say > that the DES-CBC part is ready, but it's a bit hard to assess without > the framework. > The Authenticator is an optional field. Its specification and testing are outside the scope of DES-CBC. We don't test frameworks, we test protocols. Again, each transform should stand on its own! Besides, there are plenty of folks who have tested AH+ESP. Seems to work pretty well.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 03:41:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00061 for ipsec-outgoing; Sat, 24 May 1997 03:39:38 -0400 (EDT) Message-Id: <3.0.32.19970524004450.00b0d490@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 24 May 1997 00:44:54 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Cc: Steven Bellovin , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, While the wg and doc editors have been struggling to get the document structure "cleaned up", I respectfully submit that the two drafts you recently submitted appear to subvert that effort. In what is being refered to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd paragraph of section 3.2.3.2, Encryption Algorithms, states: At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. The operative phrase is "but no overlap with this document". While I understand that you believe that it's important for the algorithm/transform documents to repeat certain field definitions from the base ESP document, in this case I find it couter-productive and prone to inducing errors. Let's take an example from from your DES draft (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft and RFC1829. It states: Padding zero or more octets. Prior to encryption, this field is filled with a series of integer values (beginning with zero), to align the Pad Length and Payload Type fields at the end of an eight octet boundary (counted from the beginning of the Payload Data). After decryption, it is examined for a valid series of integer values. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. In the "new" ESP draft (section 2.5) padding is defined as follows: The Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Padding beyond that required for encryption algorithm blocksize alignment may be used to conceal the actual length of the payload, in support of traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. Lastly, RFC1829 states: Padding The size of this field is variable. Prior to encryption, it is filled with unspecified implementation dependent (preferably random) values, to align the Pad Length and Payload Type fields at an eight octet boundary. After decryption, it MUST be ignored. I don't understand how someone can write code to support the padding requirements that conform to RFC1829 or the "new" ESP and find that it will interoperate with code that is written to follow your new draft. An RFC1829 programmer will send the "preferably random" values in for padding and the implementor of your new draft will reject the incoming packet for lack of a "valid series of integer values". While you don't say exactly what to do in this case, it certainly leaves room for various interpretations (read that as potential interoperability problems). Would it not have been simple to create a draft that really matched the goal of matching the intentions of the "new" ESP draft and the wg? That would have been a great service to the wg. At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: >I looked at those (CAST & RC5), and found them remarkably uninformative. >I cannot imagine a "protocol" description without packet formats. They >should put some packet formats in! I see these as algorithm/transform definitions, not protocols. They define how to take a set of data and transform it into another set of data. The context is, as stated simply and elegantly in the abstracts of the RC5 and CAST drafts (and these are the only words in the abstracts): This draft describes the CAST-128 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). This draft describes the RC5 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). (OK, so they share an author) >The only true change in "new" ESP is the >requirement of the sequence field in all transforms, and adding an >optional trailing Authenticator. That's all I've done here, update to >match the "new" ESP environment. Not so. The move to the "new" ESP environment involved a conscious document structure change, not just the protocol changes you mentioned. That structure change is intended to simplify the specifications by eliminating reduntant and potentially conflicting requirements (i.e., factoring out the common elements of the packet formats and leaving the transform docs to specify algorithmic details). >I don't like _under_ specifying stuff. Each transform should stand on >its own! B relating the transform drafts back to the base ESP draft (as you do and the RC5/CAST drafts do), then they DO stand on their own as separable transforms that support the packet formats as defined in ESP. They MUST be read AND used in conjunction with ESP and ONLY in conjunction with ESP. If you REALLY want them to stand on their own in the context of all the working groups, then I would go further to say that they should just describe the algorithms and not refer to any base packet formats. In that way they could be referenced by any base protocol spec such as TLS or ECP by way of IANA numbers. But in my relatively short IETF life, I wouldn't expect to see that happen at this stage and would be grateful to fulfill the intentions of the wg and the ESP draft (and for this purpose, we have the IPSec DOI). [To the doc editors and co-chairs, if no one is preparing drafts of DES and 3DES for use with the "new" ESP (similar in construct to the RC5 and CAST drafts), I volunteer to take on the task as long as I get some volunteers to review them prior to posting to double-check them.] Regards, Bob Monsour rmonsour@hifn.com From owner-ipsec Sat May 24 11:44:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02007 for ipsec-outgoing; Sat, 24 May 1997 11:39:12 -0400 (EDT) Date: Sat, 24 May 97 15:02:46 GMT From: "William Allen Simpson" Message-ID: <5952.wsimpson@greendragon.com> To: Bob Monsour Cc: ipsec@tis.com Subject: definitions versus protocols Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the comments, especially from an implementor; but as a long-time participant, I cannot agree that this was the intent of most of the folks _I_ was talking to.... (a small group of folks reviewed the documents before I sent them off to the drafts repository). So, it looks like we really need a "straw poll" as to whether these should be merely "shims" or true protocols. Let's debate that in this thread for a week (ending May 30th), and see if there's a broader consensus one way or the other. As I mentioned, the CAST and RC5 (sharing an author) don't provide enough information to write any code. They just shim between real documents. That's my objection. I have a strong prejudice for working on code, and therefore have principly limited my efforts to code-generating documents. If these are "algorithm/transform definitions, not protocols", then they would not be able to be on the Standards Track. The IETF standardizes protocols, upon demonstrated interoperability. A shim would be easier to produce, but would only be an Informational RFC. > From: Bob Monsour > In what is being refered > to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd > paragraph of section 3.2.3.2, Encryption Algorithms, states: > > At the time of writing, one mandatory-to-implement encryption > algorithm and mode has been defined for ESP. It is based on the Data > Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode > [NIST80]. Details of use of this mode are contained in [need a new > I-D with DES-CBC and implicit IV generation, but no overlap with this > document]. > > The operative phrase is "but no overlap with this document". ... I do not treat the old "new" ESP draft as gospel. We've already agreed that it oversteps its bounds, and have more clearly defined its scope. My draft is based on the Memphis meeting. We await the "new" "new" ESP. > Would it not have been simple to create a draft that really matched the > goal of matching the intentions of the "new" ESP draft and the wg? That > would have been a great service to the wg. > I did my best, within the limitation of my understanding of what was desired by the broad group of implementors. > At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: > >I looked at those (CAST & RC5), and found them remarkably uninformative. > >I cannot imagine a "protocol" description without packet formats. They > >should put some packet formats in! > > I see these as algorithm/transform definitions, not protocols. They define > how to take a set of data and transform it into another set of data. The > context is, as stated simply and elegantly in the abstracts of the RC5 and > CAST drafts (and these are the only words in the abstracts): > > This draft describes the CAST-128 block cipher algorithm as to be > used with the IPSec Encapsulating Security Payload (ESP). > > This draft describes the RC5 block cipher algorithm as to be used > with the IPSec Encapsulating Security Payload (ESP). > > (OK, so they share an author) > > >The only true change in "new" ESP is the > >requirement of the sequence field in all transforms, and adding an > >optional trailing Authenticator. That's all I've done here, update to > >match the "new" ESP environment. > > Not so. The move to the "new" ESP environment involved a conscious document > structure change, not just the protocol changes you mentioned. That > structure change is intended to simplify the specifications by eliminating > reduntant and potentially conflicting requirements (i.e., factoring out the > common elements of the packet formats and leaving the transform docs to > specify algorithmic details). > The decision by _Steve_ to do this was debated on the list, and I saw dissent. We need a nice general ESP document, but I have always seen the ESP document as the template and "applicability statement", and the transform documents as the protocols. Clearly, you and I have a difference of vision. > >I don't like _under_ specifying stuff. Each transform should stand on > >its own! > > B relating the transform drafts back to the base ESP draft (as you do and > the RC5/CAST drafts do), then they DO stand on their own as separable > transforms that support the packet formats as defined in ESP. They MUST be > read AND used in conjunction with ESP and ONLY in conjunction with ESP. If > you REALLY want them to stand on their own in the context of all the > working groups, then I would go further to say that they should just > describe the algorithms and not refer to any base packet formats. In that > way they could be referenced by any base protocol spec such as TLS or ECP > by way of IANA numbers. But in my relatively short IETF life, I wouldn't > expect to see that happen at this stage and would be grateful to fulfill > the intentions of the wg and the ESP draft (and for this purpose, we have > the IPSec DOI). > A very different vision. I am not in favor of transforms so general that they could be used without packet formats. That's what the algorithm documents (like CAST just published as an RFC) should do. The transforms are specific applications of the generic algorithms in concrete form. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 12:22:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02253 for ipsec-outgoing; Sat, 24 May 1997 12:20:45 -0400 (EDT) Date: Sat, 24 May 97 16:04:37 GMT From: "William Allen Simpson" Message-ID: <5955.wsimpson@greendragon.com> To: Bob Monsour Cc: ipsec@tis.com Subject: padding values Sender: owner-ipsec@ex.tis.com Precedence: bulk On the differences in text on padding values: > From: Bob Monsour > While I understand that you believe that it's important for the > algorithm/transform documents to repeat certain field definitions from the > base ESP document, in this case I find it couter-productive and prone to > inducing errors. Let's take an example from from your DES draft > (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft > and RFC1829. It states: > > Padding zero or more octets. > > Prior to encryption, this field is filled with a > series of integer values (beginning with zero), to > align the Pad Length and Payload Type fields at the > end of an eight octet boundary (counted from the > beginning of the Payload Data). > > After decryption, it is examined for a valid series > of integer values. > > This field is opaque. That is, the value is set > prior to encryption, and is examined only after > decryption. > Please read this in the context of the whole paper. See also: 2.2. Decryption ... The Pad Length is removed and examined. If pad checking is config- ured, and the padding octets are not the correct values for the Pad Length, then the payload is discarded, and the "Decryption Failed" error is indicated [RFC-xxxx]. ... Operational Considerations ... Pad Check Some earlier implementations used random pad values. Default: Off. ... The default is off because of interoperability concerns. > In the "new" ESP draft (section 2.5) padding is defined as follows: > > The Padding bytes SHOULD be initialized with random data and they are > transmitted. The transmitter can add 0-255 bytes of padding. Padding > beyond that required for encryption algorithm blocksize alignment may > be used to conceal the actual length of the payload, in support of > traffic flow confidentiality. However, inclusion of such additional > padding has adverse bandwidth implications and thus its use should be > undertaken with care. The Padding field is optional, but all > implementations MUST support generation and consumption of padding. > The ESP draft is wrong. It has a scoping error. The description of padding is to be left to the individual transforms. See the previous notes to this list on the implementors' agreement. If this is not fixed in the next draft of ESP, I'm sure someone will suggest a more specific change in wording. > Lastly, RFC1829 states: > > Padding > > The size of this field is variable. > > Prior to encryption, it is filled with unspecified implementation > dependent (preferably random) values, to align the Pad Length and > Payload Type fields at an eight octet boundary. > > After decryption, it MUST be ignored. > > I don't understand how someone can write code to support the padding > requirements that conform to RFC1829 or the "new" ESP and find that it will > interoperate with code that is written to follow your new draft. An RFC1829 > programmer will send the "preferably random" values in for padding and the > implementor of your new draft will reject the incoming packet for lack of a > "valid series of integer values". While you don't say exactly what to do in > this case, it certainly leaves room for various interpretations (read that > as potential interoperability problems). > Hopefully, not everyone will read only the first part of a draft, and will actually follow and implement the draft in its entirety. The values were previously "implementation dependent", which was open to various interpretations. The "preferably random" values turned out to be cryptographically wrong. At the request of the persons explicitly named in the Acknowledgements, the "implementation dependent" values were changed to specified values. This is not open to various interpretations. I realize that you are new to the list, and may have missed the earlier debates. Remembering that you like to use the same technique in multiple venues, I'll point out that these values are used in PPP DES encryption. And that non-random values are also specified in RSA's PKCS. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 13:13:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02489 for ipsec-outgoing; Sat, 24 May 1997 13:11:43 -0400 (EDT) Date: Sat, 24 May 97 17:04:04 GMT From: "William Allen Simpson" Message-ID: <5956.wsimpson@greendragon.com> To: ipsec@tis.com Subject: CAST & RC5 Abstract correction Sender: owner-ipsec@ex.tis.com Precedence: bulk There are some substantive errors in language in both the CAST and RC5 drafts. In the Abstracts: > This draft describes the CAST-128 block cipher algorithm as to be > used with the IPSec Encapsulating Security Payload (ESP). > > This draft describes the RC5 block cipher algorithm as to be used > with the IPSec Encapsulating Security Payload (ESP). > This will not always be a draft. "as to be used" is problematic phrasing. There is no IPSec protocol. ESP is called an IP protocol (IPv4) or IP payload (IPv6). I suggest: This document describes the block cipher interface elements used with the IP Encapsulating Security Payload (ESP). WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 14:01:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02700 for ipsec-outgoing; Sat, 24 May 1997 14:01:12 -0400 (EDT) Date: Sat, 24 May 97 17:56:26 GMT From: "William Allen Simpson" Message-ID: <5957.wsimpson@greendragon.com> To: ipsec@tis.com Subject: DES-CBC "interface" shim Sender: owner-ipsec@ex.tis.com Precedence: bulk Since Bellovin, Kent and Monsour have all requested a revision, for comparison purposes I have generated a shorter version without the protocol and implementation information. I ask other folks to please indicate your preferences. Network Working Group P Metzger Internet Draft [Piermont] W A Simpson [DayDreamer] expires in six months May 1997 The ESP DES-CBC Transform Interface draft-simpson-esp-des1-shim-00.txt (C) Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Abstract This document describes the DES-CBC block cipher interface elements used with the IP Encapsulating Security Payload (ESP). Metzger & Simpson expires in six months [Page i] DRAFT ESP DES-CBC May 1997 1. Introduction The Encapsulating Security Payload (ESP) [RFC-1827] provides confi- dentiality for IP datagrams by encrypting the payload data to be pro- tected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algo- rithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. All implementations that claim conformance or compliance with the Encapsulating Security Payload specification MUST implement this DES- CBC transform. This document assumes that the reader is familiar with the related document "Security Architecture for the Internet Protocol" [RFC-1825], that defines the overall security plan for IP, and pro- vides important background for this specification. In this document, the key words "MUST", "optional", "recommended", "required", and "SHOULD", are to be interpreted as described in [RFC-2119]. 2. Algorithm and Mode P1 P2 Pi | | | IV->->(X) +>->->->(X) +>->->->(X) v ^ v ^ v +-----+ | +-----+ | +-----+ k->| Ek | ^ k->| Ek | ^ k->| Ek | +-----+ | +-----+ | +-----+ | ^ | ^ | +>->->+ +>->->+ +>->-> | | | C1 C2 Ci In DES-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 octet) plaintext block (P1). The keyed DES encryption function (Ek) generates the ciphertext (C1) for the block. For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES encryption function (Ek) generates the ciphertext (Ci) for that block. The Cipher Block Chaining (CBC) method provides for re- synchronization when datagrams are lost. For more explanation and implementation information for DES, see [Schneier95]. Metzger & Simpson expires in six months [Page 1] DRAFT ESP DES-CBC May 1997 3. Keys The secret DES key shared between the communicating parties is 56-bits in length. The 56-bit key is stored as a 64-bit (8 octet) quantity, with the least significant bit of each octet used as a par- ity bit. 3.1. Weak Keys DES has 64 known weak keys, including so-called semi-weak keys and possibly weak keys [Schneier95, pp 280-282]. Implementations SHOULD take care not to select weak keys [CN94], although the odds of pick- ing one at random are low. When manually configured, these 64 keys SHOULD be be rejected. When dynamically configured via a key management protocol, any of these 64 keys MUST be rejected, and a replacement key requested. 3.2. Key Management When manually configured, 64-bits (8 octets) are configured. Keys with incorrect parity SHOULD be be rejected. When dynamically configured via a key management protocol, 64-bits (8 octets) are returned for each key. The least significant bit of each key octet is ignored (or set to parity when the implementation requires). 4. Initialization Vector This mode of DES requires an Initialization Vector (IV) that is 64-bits (8 octets) in length. Each datagram contains its own IV. This IV is intended to be unique for the lifetime of the secret DES session-key. When manually configured, the 64-bit IV is generated from the 32-bit Sequence Number field followed by (concatenated with) the bit-wise complement of the same 32-bit value. When dynamically configured via a key management protocol, the 64-bit IV is generated from the 32-bit SPI field followed by (concatenated with) the 32-bit Sequence Number field. The bit-wise complement of the 32-bit Sequence Number value is XOR'd with the first 32-bits Metzger & Simpson expires in six months [Page 2] DRAFT ESP DES-CBC May 1997 (SPI). Security Notes: Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. The manually configured variant is required for backward compati- bility. It is appropriate when the associated SPI is unchanging. However, in a dynamic environment, the same data stream might be sent with more than one SPI. Including the changed SPI in the IV generation prevents analysis based on common leading blocks. Using the Sequence Number provides an easy method for preventing IV repetition, and is sufficiently robust for practical use with the DES algorithm. But, when used alone, cryptanalysis might be aided by the rare serendipitous occurrence where a corresponding bit position in the first DES block increments in exactly the same fashion as the Sequence Number. No commonly used IP Protocol/Payloads exhibit this property. Never-the-less, inclusion of the bit-wise complement ensures that Sequence Number bit changes are reflected twice in the IV. 5. Block Size The DES algorithm operates on blocks of 64-bits (8 octets). This often requires padding after the end of the unencrypted Payload Data. Both input and output result in the same number of octets. This facilitates in-place encryption and decryption. 6. ESP Padding The Padding field may be zero or more octets in length. Prior to encryption, this field is filled with a series of integer values (beginning with zero), to align the Pad Length and Payload Type fields at the end of an eight octet boundary (counted from the beginning of the Payload Data). After decryption, it may be examined for a valid series of integer values. Metzger & Simpson expires in six months [Page 3] DRAFT ESP DES-CBC May 1997 7. ESP Authenticator This optional variable-length field contains an Integrity Check Value (ICV) computed over the ESP data after encryption, beginning with the SPI and ending with the Payload Type. The length of the field depends upon the authentication function selected. DES-CBC does not provide integrity. When the ESP data is not other- wise verified (externally using AH or internally by the payload itself), it is recommended (but not required) that an ICV be provided here. The details of such functions are outside the scope of this document. 8. Performance Phil Karn has tuned DES software to achieve 10.45 Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES speed estimates may be found at [Schneier95, page 279]. Operational Considerations When used with manual keying, the specification provides only a few configurable parameters. SPI Configured SPIs are in the range 1 to 255. SPI LifeTime (SPILT) Manually configured LifeTimes are generally measured in days, while dynamic LifeTimes are specified in seconds. Default: 2,764,800 seconds (32 days). Maximum: implementation dependent. Pad Check Some earlier implementations used random pad values. Default: Off. Key The 56-bit key is configured as a 64-bit quantity, with appropri- ate parity included. Metzger & Simpson expires in six months [Page 4] DRAFT ESP DES-CBC May 1997 Each party configures a list of known SPIs and symmetric secret-keys. In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular SPI. For example, a party might allow FTP, but prohibit Telnet. Such consid- erations are outside the scope of this document. Security Considerations Users need to understand that the quality of the security provided by this specification depends completely on the strength of the DES algorithm, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implemen- tations in all of the participating nodes. The cut and paste splicing attack described by [Bell95, Bell96] exploits the nature of all Cipher Block Chaining algorithms. When a block is damaged in transmission, on decryption both it and the fol- lowing block will be garbled by the decryption process, but all sub- sequent blocks will be decrypted correctly. If an attacker has legitimate access to the same key, this feature can be used to insert or replay previously encrypted data of other users of the same engine, revealing the plaintext. The usual (ICMP, TCP, UDP) trans- port checksum can detect this attack, but on its own is not consid- ered cryptographically strong. In this situation, user or connection oriented integrity checking is needed [RFC-1826]. The padding bytes have a predictable value. They provide a small measure of tamper detection on their own block and the previous block in CBC mode. This makes it somewhat harder to perform splicing attacks, and avoids a possible covert channel. This small amount of known plaintext does not create any problems for modern ciphers. At the time of writing of this document, [BS93] demonstrated a dif- ferential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear cryptanalysis based known-plaintext attack requiring only 2^43 plain- text-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account. More disturbingly, [Weiner94] has shown the design of a DES cracking machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack. One or two blocks of known plaintext suffice to recover a DES key. Because IP datagrams typically begin with a block of known and/or Metzger & Simpson expires in six months [Page 5] DRAFT ESP DES-CBC May 1997 guessable header text, frequent key changes will not protect against this attack. It is suggested that DES is not a good encryption algorithm for the protection of even moderate value information in the face of such equipment. Triple DES is probably a better choice for such purposes. However, despite these potential risks, the level of privacy provided by use of ESP DES-CBC in the Internet environment is far greater than sending the datagram as cleartext. Change History Changes from RFC-1829: Additional explanation of IV calculation. Inclusion of SPI in IV calculation improves IV uniqueness over multiple sessions. Updated performance estimates. IV field renamed to Sequence. Only one size is supported. Padding is a known series of integers, and is checked upon receipt. Added authentication section. Removed protocol implementation specification. Added operational parameters section. Updated references. Updated contacts. Minor editorial changes. Metzger & Simpson expires in six months [Page 6] DRAFT ESP DES-CBC May 1997 Acknowledgements The basic field naming and layout is based on "swIPe" [IBK93, IB93]. Participants in the IP Security Working Group modified this to a variable number of variable length fields. After a digression span- ning 4 years, actual implementors mandated a return to these fewer well-known fields. Some of the text of this specification was derived from work by Ran- dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. Phil Karn provided the original Encryption and Decryption text, and was the motivator and founding member of the IP Security Working Group. Perry Metzger provided the original Security Considerations text, some of which is distributed throughout the document. William Allen Simpson was responsible for the name and semantics of the SPI, the IV calculation technique(s), editing and formatting. The use of known padding values was suggested in various forms by Robert Baldwin, Phil Karn, and David Wagner. This specification uses Self-Describing-Padding [RFC-1570]. Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz, Dave Mihelcic and Jeffrey Schiller provided useful critiques of ear- lier versions of this draft. References [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Presentation at the 32nd Internet Engi- neering Task Force, Danvers Massachusetts, April 1995. [Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Security Symposium, July 1996. [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993. [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. Metzger & Simpson expires in six months [Page 7] DRAFT ESP DES-CBC May 1997 [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implement- ing and Using the Data Encryption Standard", Federal Infor- mation Processing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [IB93] Ioannidis, J., and Blaze, M., "The Architecture and Imple- mentation of Network-Layer Security Under Unix", Proceedings of the Fourth Usenix Security Symposium, Santa Clara Cali- fornia, October 1993. [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- Layer Security for IP", Presentation at the 26th Internet Engineering Task Force, Columbus Ohio, March 1993. [Matsui94] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994. [RFC-1570] Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1825] Atkinson, R., "Security Architecture for the Internet Proto- col", RFC-1825, Naval Research Laboratory, July 1995. [RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval Metzger & Simpson expires in six months [Page 8] DRAFT ESP DES-CBC May 1997 Research Laboratory, July 1995. [RFC-1827] Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC-1827, Naval Research Laboratory, July 1995. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Require- ment Levels", BCP 14, Harvard University, March 1997. [RFC-xxxx] Karn, P., and Simpson, W., "ICMP Security Failures Mes- sages", draft-simpson-icmp-ipsec-fail-02.txt, work in progress. [RFC-yyyy] Simpson, W., and Wagner, D., "Internet Security Transform Enhancements", draft-simpson-ipsec-enhancement-01.txt, work in progress. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. [Weiner94] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. Metzger & Simpson expires in six months [Page 9] DRAFT ESP DES-CBC May 1997 Contacts Comments about this document should be discussed on the ipsec@tis.com mailing list. Questions about this document can also be directed to: Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Metzger & Simpson expires in six months [Page 10] From owner-ipsec Mon May 26 11:38:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13525 for ipsec-outgoing; Mon, 26 May 1997 11:33:14 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Bob Monsour'" , "'William Allen Simpson'" Cc: "'ipsec@tis.com'" Subject: RE: definitions versus protocols Date: Mon, 26 May 1997 10:27:54 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I guess I should reply to this since I am that un-named shared author of both the RC5 and CAST128 ESP drafts. Bill, the layout and wording of the new style ESP algorithm documents came about from many months of discussions. As you know we have been moving towards Steve Kent's new template oriented ESP and moving away from 'transforms'. One of the major issues that I (and other people) wanted resolved was to not have any overlapping between the main ESP document and all other algorithm documents. After discussions in Memphis and several ANX bake-offs, I believed that we had enough information to produce a half-decent first draft of what an ESP algorithm document was suppose to look like. The result was the RC5 and CAST128 drafts. These two documents were co-written with their appropriate representatives (Baldwin and Carter) and were sent out to various implementers before officially submitting them to the IETF. Steve Kent also had some very good input to these documents. As one of the IPSec implementers, and as having written all of the code from scratch (i.e.. RFCs), I wanted to write a direct and to-the-point draft that a developer would be able to quickly retrieve the desired information and implement that cipher algorithm. Everything that isn't in these documents was already in the ESP draft. I think this line from the my drafts says it all; "Furthermore, this document is a companion to [Kent97] and MUST be read in its context." That being said, these two documents are first drafts and should be updated and are not "ready for prime time". Thus any constructive criticism and comments are appreciated. Roy Pereira TimeStep Corporation >---------- >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] >Sent: Saturday, May 24, 1997 11:02 AM >To: Bob Monsour >Cc: ipsec@tis.com >Subject: definitions versus protocols > >Thanks for the comments, especially from an implementor; but as a >long-time participant, I cannot agree that this was the intent of most of >the folks _I_ was talking to.... (a small group of folks reviewed the >documents before I sent them off to the drafts repository). > >So, it looks like we really need a "straw poll" as to whether these >should be merely "shims" or true protocols. Let's debate that in this >thread for a week (ending May 30th), and see if there's a broader >consensus one way or the other. > >As I mentioned, the CAST and RC5 (sharing an author) don't provide >enough information to write any code. They just shim between real >documents. That's my objection. > >I have a strong prejudice for working on code, and therefore have >principly limited my efforts to code-generating documents. > >If these are "algorithm/transform definitions, not protocols", then they >would not be able to be on the Standards Track. The IETF standardizes >protocols, upon demonstrated interoperability. > >A shim would be easier to produce, but would only be an Informational RFC. > > >> From: Bob Monsour >> In what is being refered >> to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd >> paragraph of section 3.2.3.2, Encryption Algorithms, states: >> >> At the time of writing, one mandatory-to-implement encryption >> algorithm and mode has been defined for ESP. It is based on the Data >> Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode >> [NIST80]. Details of use of this mode are contained in [need a new >> I-D with DES-CBC and implicit IV generation, but no overlap with this >> document]. >> >> The operative phrase is "but no overlap with this document". >... > >I do not treat the old "new" ESP draft as gospel. We've already agreed >that it oversteps its bounds, and have more clearly defined its scope. >My draft is based on the Memphis meeting. We await the "new" "new" ESP. > > >> Would it not have been simple to create a draft that really matched the >> goal of matching the intentions of the "new" ESP draft and the wg? That >> would have been a great service to the wg. >> >I did my best, within the limitation of my understanding of what was >desired by the broad group of implementors. > > >> At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: >> >I looked at those (CAST & RC5), and found them remarkably uninformative. >> >I cannot imagine a "protocol" description without packet formats. They >> >should put some packet formats in! >> >> I see these as algorithm/transform definitions, not protocols. They define >> how to take a set of data and transform it into another set of data. The >> context is, as stated simply and elegantly in the abstracts of the RC5 and >> CAST drafts (and these are the only words in the abstracts): >> >> This draft describes the CAST-128 block cipher algorithm as to be >> used with the IPSec Encapsulating Security Payload (ESP). >> >> This draft describes the RC5 block cipher algorithm as to be used >> with the IPSec Encapsulating Security Payload (ESP). >> >> (OK, so they share an author) >> >> >The only true change in "new" ESP is the >> >requirement of the sequence field in all transforms, and adding an >> >optional trailing Authenticator. That's all I've done here, update to >> >match the "new" ESP environment. >> >> Not so. The move to the "new" ESP environment involved a conscious document >> structure change, not just the protocol changes you mentioned. That >> structure change is intended to simplify the specifications by eliminating >> reduntant and potentially conflicting requirements (i.e., factoring out the >> common elements of the packet formats and leaving the transform docs to >> specify algorithmic details). >> >The decision by _Steve_ to do this was debated on the list, and I saw >dissent. We need a nice general ESP document, but I have always seen >the ESP document as the template and "applicability statement", and the >transform documents as the protocols. > >Clearly, you and I have a difference of vision. > > >> >I don't like _under_ specifying stuff. Each transform should stand on >> >its own! >> >> B relating the transform drafts back to the base ESP draft (as you do and >> the RC5/CAST drafts do), then they DO stand on their own as separable >> transforms that support the packet formats as defined in ESP. They MUST be >> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If >> you REALLY want them to stand on their own in the context of all the >> working groups, then I would go further to say that they should just >> describe the algorithms and not refer to any base packet formats. In that >> way they could be referenced by any base protocol spec such as TLS or ECP >> by way of IANA numbers. But in my relatively short IETF life, I wouldn't >> expect to see that happen at this stage and would be grateful to fulfill >> the intentions of the wg and the ESP draft (and for this purpose, we have >> the IPSec DOI). >> >A very different vision. > >I am not in favor of transforms so general that they could be used >without packet formats. That's what the algorithm documents (like CAST >just published as an RFC) should do. The transforms are specific >applications of the generic algorithms in concrete form. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > From owner-ipsec Mon May 26 12:21:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13818 for ipsec-outgoing; Mon, 26 May 1997 12:21:08 -0400 (EDT) Message-Id: X-Aliased: From schmidt@rutil.Informatik.Uni-Oldenburg.DE (Torge Schmidt) From: "Torge Schmidt" Subject: ISAKMP/Oakley implementation availability To: ipsec@ex.tis.com Date: Mon, 26 May 1997 18:28:37 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi! Are there any ISAKMP/Oakley implementations, freely available out of the US? The IPsec survey results didn't mention any. Thanks, Torge From owner-ipsec Mon May 26 17:48:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15275 for ipsec-outgoing; Mon, 26 May 1997 17:47:44 -0400 (EDT) Message-Id: <199705262155.RAA27212@codex.cis.upenn.edu> To: "Torge Schmidt" cc: ipsec@ex.tis.com Subject: Re: ISAKMP/Oakley implementation availability In-reply-to: Your message of "Mon, 26 May 1997 18:28:37 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15619.864683538.1@dsl.cis.upenn.edu> Date: Mon, 26 May 1997 17:52:19 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Torge Schmidt" writes: > >Are there any ISAKMP/Oakley implementations, freely available out of >the US? The IPsec survey results didn't mention any. > I'm writing an implementation of it at the moment, while enjoying the Greek beaches :-) A very rough, GPL'ed version of it will be available after the first week of June (after the AIAG interop). Someone will (hopefully) pick it up from there (i'm getting back to the US then, so i won't be able to work on it any more). As is usually the case with such matters, there will be an announcement in this list when the time comes (the stars are aligned, the Old Ones are coming back, the protocol is stable...umm, scratch that). Cheers, -Angelos From owner-ipsec Tue May 27 08:14:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20029 for ipsec-outgoing; Tue, 27 May 1997 08:11:26 -0400 (EDT) Message-Id: <3.0.32.19970525220315.00b1a400@earthlink.net> Date: Sun, 25 May 1997 22:03:22 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Re: definitions versus protocols 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:02 PM 5/24/97 GMT, William Allen Simpson wrote: [snip...] >As I mentioned, the CAST and RC5 (sharing an author) don't provide >enough information to write any code. They just shim between real >documents. That's my objection. > >I have a strong prejudice for working on code, and therefore have >principly limited my efforts to code-generating documents. > >If these are "algorithm/transform definitions, not protocols", then they >would not be able to be on the Standards Track. The IETF standardizes >protocols, upon demonstrated interoperability. > >A shim would be easier to produce, but would only be an Informational RFC. I disagree. According to RFC2026 (Internet Standards Process), these "shim" docs fall into the class of Technical Specifications (as opposed to Applicability Statements), the definition of which follows: A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement. They clearly don't have to be "protocols". Perhaps the "shim" specs fall into the "convention" class. The "shim" specs "incorporates material from other specs by reference to other documents". From Section 4.1.2 of that same document, the following definition of the term "interoperable" is provided: For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. As for writing code from the "shim" specs, with the following specs in hand, (1) base ESP draft, (2) RC5 (or CAST) "shim" spec, and (3) detailed RC5 algorithm spec, I can clearly imagine writing a software module with a calling sequence that looks something like this: ESP_RC5(key, IV, plaintext) that would return the value of the resulting ciphertext. To do that I would have to refer to the ESP draft for the padding spec for how to make it pad. I'd also have to refer to the RC5 spec to code the algorithm. And the "shim" spec would tell me how to use the key and IV. While no two implementors would produce the same code, it's clear what the inputs are and what the outputs need to be from the "shim" spec and thus I would argue that the to implementors could demonstrate interoperability. )However, I would suggest that the interoperability in this case would be in the context of a complete ESP implementation.) >From the above definitions and the description of Informational (from RFC2026), I see no reason why the "shim" specs could not be Standards Track documents. [snip...] >> B relating the transform drafts back to the base ESP draft (as you do and >> the RC5/CAST drafts do), then they DO stand on their own as separable >> transforms that support the packet formats as defined in ESP. They MUST be >> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If >> you REALLY want them to stand on their own in the context of all the >> working groups, then I would go further to say that they should just >> describe the algorithms and not refer to any base packet formats. In that >> way they could be referenced by any base protocol spec such as TLS or ECP >> by way of IANA numbers. But in my relatively short IETF life, I wouldn't >> expect to see that happen at this stage and would be grateful to fulfill >> the intentions of the wg and the ESP draft (and for this purpose, we have >> the IPSec DOI). >> >A very different vision. > >I am not in favor of transforms so general that they could be used >without packet formats. That's what the algorithm documents (like CAST >just published as an RFC) should do. The transforms are specific >applications of the generic algorithms in concrete form. I agree that I went further than was practical to make by point. However, I still believe that the amount of overlap between the "transform"/"shim" specs and the base ESP specs in your two drafts is excessive and potentially problematic for implementors and I don't see a problem with the "shim" approach. Thanks for your comprehensive responses to my comments. I hope that the debate on doc structure does not put yet another incremental drag on IPSec progress. We've certainly got enough of those. I strongly encourage/beg-for the wg co-chairs (or the AD if needed) to provide their guidance/leadership to get the group decision-focused wrt the littany of seemingly endless obstacles (small and large alike) in front of the group. -Bob From owner-ipsec Tue May 27 10:02:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21231 for ipsec-outgoing; Tue, 27 May 1997 10:01:10 -0400 (EDT) Date: Tue, 27 May 1997 10:06:46 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705271406.KAA18672@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: definitions versus protocols X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "William Allen Simpson" > > So, it looks like we really need a "straw poll" as to whether these > should be merely "shims" or true protocols. Let's debate that in this > thread for a week (ending May 30th), and see if there's a broader > consensus one way or the other. > > [...] > > I am not in favor of transforms so general that they could be used > without packet formats. That's what the algorithm documents (like CAST > just published as an RFC) should do. The transforms are specific > applications of the generic algorithms in concrete form. Since we are straw polling, I absolutely agree with Bob M. that the ESP document should be the protocol definition and that the transform documents should be orthogonal to the ESP specification. * This is good engineering practice - using the ESP document as a boilerplate template to derive standalone transforms is just begging for mistakes to creep in, both in the document editing stage and in the implementation stage. If you don't have redundant specifications, you can't have inconsistencies between the redundant copies. (You can still have mistakes, but you only have to fix them once.) * If all transform documents include copies of ESP, changes to the ESP protocol (bits-on-the-wire, or changes in interpretation of existing bits) would require reissuing *every* transform RFC, even if the ESP changes had no algorithm-specific component (example: change to the size of the AR counter). * Although IPSEC is the first consumer of the transform documents and IPSEC should be the focus of this working group's effort, I believe it is valuable to write the algorithm definitions in such a way that they could be referenced by other protocols (TLS, S/MIME, ...) if other working groups choose to do so. Including only algorithm-specific data in the transform documents facilitatates such reuse. * The IETF is not the ISO, where one must wade through endless chains of references, some of which may be difficult to obtain. RFCs are all available in one place, and implementors should find it no more difficult writing code from a single ESP specification and the algorithm-specific supplements than from standalone algorithm documents. In the case of multiple-algorithm implementations, I contend that the orthogonal approach makes the implementor's life easier. From owner-ipsec Tue May 27 14:09:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23233 for ipsec-outgoing; Tue, 27 May 1997 14:01:53 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5952.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 13:47:47 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: definitions versus protocols Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, We have other examples of RFCs that define just algorithms, so I don't agree with your observation that it is inappropriate to do the same for the algorithms we are using for AH and ESP. Also, note that the IETF does issue standards-track RFCs for things other than protocols, e.g., APIs, MIBs, ... Steve From owner-ipsec Tue May 27 16:41:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24538 for ipsec-outgoing; Tue, 27 May 1997 16:40:19 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5955.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 15:59:42 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: padding values Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I've looked at all the message traffic since the Memphis meeting, and I do not see any reference to padding being algorithm-specific, as you suggest. Putting random values in tbe padding field has the well-known advantage that it helps counter known plaintext attacks that might result from padding with a constant value, e.g., "0". However, putting in the integer values you cite seems to reintroduce this sort of problem, if anyone didn't believe that known plaintext didn't exist from the encapsulated payload (as Bellovin analyzed in the case of both tunneled and transport mode uses of ESP). I can imagine an integrity bebefit for inclusion of such padding, in a cipher that provides error propogation to the end of the block, but that is not the case for CBC. It would seem that the major benefit for the padding you describe is the ability to detect mods to the last block (only) if no integrity service is elected, which seems a rather slim rationale for this approach to padding. Still, the issue you raise is a good one, i.e., do we want to leave definition of the contents of the padding field to the algorithm, or standardize it in the ESP spec. While I have cited one example of why algorithm-specific padding might be useful, I'm not sure that there are others. Also, note that this makes the interface to the decryption module slightly more complex, i.e., if one is to take advantage of the checking done on t his field, one must be prepared to receive an error indication of a sort that otherwise would be generated only by the authentication/integrity portion of ESP processing. With arbitrary padding, the decryption module merely decrypts the buffer and returns the purported plaintext, without trying to check for integrity (which is, arguably, not a function for a decryption routine). Steve From owner-ipsec Tue May 27 22:01:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26214 for ipsec-outgoing; Tue, 27 May 1997 21:59:55 -0400 (EDT) Date: Wed, 28 May 97 01:13:18 GMT From: "William Allen Simpson" Message-ID: <5970.wsimpson@greendragon.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: padding values Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > I've looked at all the message traffic since the Memphis meeting, > and I do not see any reference to padding being algorithm-specific, as you > suggest. Steve, I'd say you didn't look very hard. Paging backwards through the text of my May archive, the most recent I saw was: Date: Thu, 22 May 97 11:27:27 EST From: "Whelan, Bill" Message-Id: <9704228643.AA864325641@netx.nei.com> ... ESP may define restrictions on the length (e.g. a multiple of eight bytes) of the Opaque Payload Data, but otherwise not define content. Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Optional - Payload Data - Mandatory - Padding - Optional - Next Header - Mandatory I'm pretty sure we had a discussion last month, too, along with padding the IV to 32 or 64 bit boundaries. I'll find and summarize the rationale for integer padding in a separate message, as those messages by Wagner, Karn, and Baldwin (and the other discussants) are about a year and a half old.... The integer pad values have long been represented in the draft-simpson-esp-des3-x-00.txt that was out there for over a year, and many folks have implemented. > Still, the issue you raise is a good one, i.e., do we want to leave > definition of the contents of the padding field to the algorithm, or > standardize it in the ESP spec. ... More important, to me anyway, is that we cannot know of there is some other padding feature that will be required by some future transform. The need for padding (and the block size) is intimately tied to the algorithm, not the ESP headers. We need to know how long it is, but predicting contents for all future algorithms is beyond us. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue May 27 22:51:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26429 for ipsec-outgoing; Tue, 27 May 1997 22:50:54 -0400 (EDT) Date: Wed, 28 May 97 02:09:11 GMT From: "William Allen Simpson" Message-ID: <5971.wsimpson@greendragon.com> To: ipsec@tis.com Subject: padding values history Sender: owner-ipsec@ex.tis.com Precedence: bulk I've spent some time looking up some of the history. The original Karn proposal (circa 1992) specified padding with zeroes, and checking them upon receipt. In January 1995, various folks complained that checking values would slow down their implementations too much. So, the padding was changed to "unspecified implementation dependent values", and the checking was removed. In March 1995, some folks thought the values should be random to limit "known plaintext". There was some argument -- "(preferably random)" was added, but still left to the implementation. This was published. In February and March 1996, Wagner (with Bellovin) wrote up a "short message" attack, particularly useful for finding telnet passwords. The attack is aided by the lack of checking the trailing padding fields. In April 1996, RSA "purists" examined ESP. One of the issues raised by Baldwin was covert and subliminal channels. Although there are many in the IPSec transforms, using the 0,1,2,3,... self-describing padding was suggested as a way to minimize that problem in ESP. That's a reduction, not an elimination. There is still a small channel by specifying different padding multiples: 4, 12, 20 all give the same alignment, but the variation from packet to packet could pass a bit or two of covert data. Yes, this is getting esoteric. But the implementors at the time agreed to change to a known padding sequence, but make the checking optional, providing backward compatibility. This implementors' agreement was reflected in my drafts of that month. As to the complaint that this adds "known plaintext" for cryptanalysis, the PadLength can only be a few discrete values, and the PayloadType can only be a few discrete values, so there is already known text in that trailing block. Baldwin: "This small amount of known plaintext does not create any problems for modern ciphers." Bellovin: "... avoid use of weak ciphers." WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue May 27 23:20:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26566 for ipsec-outgoing; Tue, 27 May 1997 23:19:54 -0400 (EDT) Date: Tue, 27 May 97 20:23:05 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9705280323.AA27879@mentat.com> To: ipsec@tis.com Subject: Re: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk I have an architectural and implementation concern which stems from the excerpted (below) section 3.1 text from the latest AH document. I'm concerned that additional text has crept into this latest AH document, which is either simply incorrect or is going to limit flexibility of implementations. On this: 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (Use of transport mode in "bump-in-the- stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, is not recommended as these implementations may receive outbound IP fragments from the attached host and thus be unable to process these packets according to this specification.) ... I completely disagree with the parenthetical comment which has been added to this newest version of AH unless we're now getting into the business of restricting vendors/implementers on how they can implement their products. And for what benefit? Also, I don't recall seeing any discussion (either on the list or at Memphis) that led to this additional note. Perhaps someone could supply the background if there's something I've overlooked in the following? I didn't see any reason in the architectural PMTU/DF note last month dated 4/22, in fact in that note the bump-in-the-stack (BITS) approach was marked as being both Transport and Tunnel mode capable, along with the fragmentation issues. Transport mode *can* be properly implemented by a BITS IPSEC implementation ("underneath" the native IP stack), allowing end-hosts to avoid the overheads of Tunnel mode and to be configurable identically to native/integrated IPSEC implementations. As a vendor I see it can be attractive to customers to bring their older systems to full IPSEC protocol compliance without having to upgrade their OS or native protocol stack or buy external boxes. The text above about "outbound IP fragments" doesn't give an adequate reason for supporting the recommendation that BITS IPSEC implementations can't/shouldn't do Transport mode. In the extreme case (not that I recommend any implementers do this) one could have the BITS code "catch" all fragments before passing outbound to the driver/wire, reassemble/move them into contiguous memory, perform AH *exactly* as specified in this spec, and then refragment and pass on the packet fragments down to the driver/wire. There would be no "on the wire" difference from a native/integrated IPSEC implementation. So, other than implementation work to minimize performance impacts (which can be very low anyway if the native IP stack implements PMTU discovery itself), there's no protocol or interoperability problem with a BITS approach implementing Transport mode "according to this specification". Let the vendors and customers make the upgrade/cost/feature/performance trade-offs, lets not specify beyond what "goes on the wire". Or, since we sometimes have to describe how "to process these packets" to ensure that secure procedures are followed *within* a node lets do so in a manner which doesn't make certain implementation approaches, such as BITS, seem non-compliant. My text change recommendations would be to delete the above parenthetical text, since I hope its now clear its not "the full story". The other BITS-related text change I see (if we don't just want a "BITS implementations must perform the same on the wire as a native IPSEC stack" catch all) would be to follow the first sentence in the 3.2.4 Fragmentation section with something like: "For Transport mode BITS implementations, outbound fragments from the native stack of a single packet must be effectively reassembled back into a single IP packet before AH processing." Don't specify any more than that, I don't think any more needs to be specified for interoperability. -- Marc -- From owner-ipsec Wed May 28 09:48:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29943 for ipsec-outgoing; Wed, 28 May 1997 09:45:30 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9705280323.AA27879@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 09:51:54 -0400 To: Marc Hasson From: Stephen Kent Subject: Re: IPSEC AH -- document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, The text I added re BITS/BITW implementations was intentional, but maybe too strongly worded. No, there was no mention of this on the list; it was something that occurred to me while preparing the last revision and so I added it in for review this time around. Both the AH and ESP specs have been silent about these sorts of implementations in the past and because such implementations are being developed, I thought it was important to highlight what I thought might be a problem. Note that this comment is not a prohibition, just a recommendation, re this mode of use. You are right that the PMTU/DF note did not make any mention of this, because it did not occur to me in that context, when the work was done several weeks ago. The reason for the additional text is exactly what it says, i.e., because of the need to deal with fragments transmitted by the host. Perhaps the wording was too strong, and should merely be a warning that these implementations must be aware of the requirement to apply AH (and ESP) only to complete datagrams. I note that fragments created by the host might exist via two different interfaces in a multi-homed host, so a BITW device or very low level BITS code might not be able to do reassembly, IPsec, and then refragmnent, in that instance. Such implementations would have a similar problems for incoming fragements that arrive on separate interfaces and would be reassembled in the native IP implementation. So, those worst case scenarios motivated my recommendation. Still, I'm happy to change the wording to merely refelct the requirement that special care must be taken in these implementations to ensure the ability to properly perform AH and ESP, on both outbound and inbound traffic. Would that be OK? Steve From owner-ipsec Wed May 28 11:27:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00744 for ipsec-outgoing; Wed, 28 May 1997 11:26:31 -0400 (EDT) Date: Wed, 28 May 1997 11:28:01 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Stephen Kent cc: Marc Hasson , ipsec@tis.com Subject: Re: IPSEC AH -- document In-Reply-To: Message-Id: <97May28.112331edt.11650@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 28 May 1997, Stephen Kent wrote: > The reason for the