Received: from relay.tis.com by neptune.TIS.COM id aa21976; 1 Jul 96 9:49 EDT Received: by relay.tis.com; id JAA04191; Mon, 1 Jul 1996 09:51:03 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004178; Mon, 1 Jul 96 09:50:39 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15666; Mon, 1 Jul 96 09:50:39 EDT Received: by relay.tis.com; id JAA04165; Mon, 1 Jul 1996 09:50:35 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma004151; Mon, 1 Jul 96 09:50:20 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id JAA03828; Mon, 1 Jul 1996 09:55:25 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id JAA04896; Mon, 1 Jul 1996 09:55:13 -0400 Date: Mon, 1 Jul 1996 09:55:13 -0400 From: Hilarie Orman Message-Id: <199607011355.JAA04896@earth.hpc.org> To: smb@research.att.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199607010217.TAA20630@baskerville.CS.Arizona.EDU> Subject: Re: deriving keying material from the shared secret Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is an important idea, and the OAKLEY draft makes the assumption that the transforms can take a variable precision integer and do these things. A separate RFC sounds like a good thing, though it should be careful to make the hashing function generic, so that one isn't requried to use MD5 to get the key for a SHA transform. There are some delicate issues about making sure the raw keying material has enough bits for the transform's use that might be addressed in such an RFC. Received: from relay.tis.com by neptune.TIS.COM id aa23878; 1 Jul 96 11:37 EDT Received: by relay.tis.com; id LAA07004; Mon, 1 Jul 1996 11:39:04 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006999; Mon, 1 Jul 96 11:38:36 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26718; Mon, 1 Jul 96 11:38:37 EDT Received: by relay.tis.com; id LAA06993; Mon, 1 Jul 1996 11:38:34 -0400 Received: from wizard.pn.com(204.96.36.2) by relay.tis.com via smap (V3.1.1) id xma006989; Mon, 1 Jul 96 11:38:30 -0400 Received: from massey (massey.ftp.com [128.127.128.152]) by wizard.pn.com (8.6.12) with SMTP id LAA27037; Mon, 1 Jul 1996 11:41:09 -0400 Message-Id: <199607011541.LAA27037@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 01 Jul 1996 11:40:35 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: mailing list archive location? Cc: rodney@sabletech.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk I thought the mailing list archive was ftp://ftp.tis.com/pub/archive/ipsec (which is what it says in http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html, for you compulsive cut-and-pasters out there) However, there is no archive directory there, and there is an archive at /pub/lists/ipsec. So I assume the list has moved and I'll poke the webmaster... Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" Received: from relay.tis.com by neptune.TIS.COM id aa23857; 1 Jul 96 11:36 EDT Received: by relay.tis.com; id LAA06976; Mon, 1 Jul 1996 11:38:04 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006968; Mon, 1 Jul 96 11:37:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26640; Mon, 1 Jul 96 11:37:38 EDT Received: by relay.tis.com; id LAA06965; Mon, 1 Jul 1996 11:37:34 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma006958; Mon, 1 Jul 96 11:37:06 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA18984; Mon, 1 Jul 1996 11:40:11 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id LAA21534; Mon, 1 Jul 1996 11:39:34 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA21226; Mon, 1 Jul 1996 11:45:26 -0400 Date: Mon, 1 Jul 1996 11:45:26 -0400 Message-Id: <9607011545.AA21226@secpwr.watson.ibm.com> To: ipsec@TIS.COM, smb@research.att.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: Re: deriving keying material from the shared secret Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: kflqhCoLK1Y7wfGJhmDu1w== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Yes, this is a good idea. I don't know, however, if we should specify a generic algorithm for all crypto algorithms; or each crypto (e.g., DES, HAMC-MD5, etc.) should specify its own transformation to transfer a n-bit keying material to a m-bit key ? Where n could be either greater than, equal to, or less than m. The advantage of per-algorithm transformation is that some algorithm may have special considerations. For example, DES may require special processing if the result of the transformation is a DES weak key (as suggested bt teh isakmp-oakley draft). Regards, Pau-Chen > From ipsec-request@neptune.tis.com Mon Jul 1 10:49:46 1996 > Message-Id: <199606302320.TAA00201@smb.research.att.com> > X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs > From: Steve Bellovin > Mmdf-Warning: Unable to confirm address in preceding line at neptune.TIS.COM > To: ipsec@TIS.COM > Subject: deriving keying material from the shared secret > Date: Sun, 30 Jun 1996 19:18:51 -0400 > Sender: ipsec-approval@neptune.tis.com > Precedence: bulk > Content-Length: 2145 > Status: RO > > The particular secrecy and authentication transforms we are considering > need varying amounts of keying material. For example, the current ESP > draft (draft-ietf-ipsec-esp-des-md5-02.txt) uses two 56-bit DES keys > (though it extracts 64-bit chunks), a single 64-bit IV (why one instead > of two?), and a 128-bit HMAC key. A mechanism for deriving these keys > from the shared secret is given in the text; it involves a 512-bit > pad field whose contents varies, and MD5. > > By contrast, the current MD5-HMAC draft (draft-ietf-ipsec-ah-hmac-md5-00.txt) > uses a variable-length key apparently taken directly from the shared > secret, crunching it through MD5 if needed to reduce it to 64 bytes if > needed. > > I suggest that we have one standard method of extracting keys from > the shared secret, probably spelled out in a separate RFC. It is > important, in my opinion, to make it extremely difficult to derive > one key given one of the others derived from the same shared secret. > For example, suppose one can determine the IV used for the ESP > transform as defined; we don't want to make it easy to determine > the session keys from the IV. > > The derivation mechanism used in the ESP draft is probably wrong, since > it uses MD5 run on the concatenation of a constant string (which differs > for each key) and the shared secret. Since the constant string is > 64 bytes long, the natural input block length of MD5, when the secret > is crunched in it is equivalent to running MD5' on just the secret, > where MD5 differs from MD5 only in the starting values of the state > registers A, B, C, D. If the shared secret is, say, 155 bits (and I > think that that will be common, if elliptic curves are used and if I'm > reading the Oakley spec correctly), then the attacker need only go after > one of the simpler cases for attacking MD5. (A forthcoming draft paper > will show why it may be relatively easier to get the key for one direction > than for the other. And given the key, the IV is trivial to recover.) > > Possibly, we should run HMAC on the padding string, using the shared > secret as the key. At the least, I suggest that MD5(key,constantstring) > would be more secure. > > Comments? Received: from relay.tis.com by neptune.TIS.COM id aa25716; 1 Jul 96 13:28 EDT Received: by relay.tis.com; id NAA10999; Mon, 1 Jul 1996 13:30:59 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010994; Mon, 1 Jul 96 13:30:33 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05329; Mon, 1 Jul 96 13:30:34 EDT Received: by relay.tis.com; id NAA10986; Mon, 1 Jul 1996 13:30:29 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma010978; Mon, 1 Jul 96 13:30:08 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id NAA13677 for ; Mon, 1 Jul 1996 13:33:13 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA22958; Mon, 1 Jul 1996 13:32:47 -0400 From: Uri Blumenthal Message-Id: <9607011732.AA22958@hawpub.watson.ibm.com> Subject: Re: deriving keying material from the shared secret To: pau@watson.ibm.com Date: Mon, 1 Jul 1996 13:32:47 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <9607011545.AA21226@secpwr.watson.ibm.com> from "pau@watson.ibm.com" at Jul 1, 96 11:45:26 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk pau@watson.ibm.com says: > Yes, this is a good idea. I don't know, however, if we should specify > a generic algorithm for all crypto algorithms; or each crypto > (e.g., DES, HAMC-MD5, etc.) should specify its own transformation > to transfer a n-bit keying material to a m-bit key ? Where n could be > either greater than, equal to, or less than m. I would prefer for each transform to have its own algorithm for deriving keys from keying material. [Of course, it would be nice, especially for those mildly paranoid like me (:-) to ensure that there is reliable "one-way valve" between the keying material and the derived keys, so that a weaker transform did not compromise stronger keys.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa26318; 1 Jul 96 13:59 EDT Received: by relay.tis.com; id OAA11818; Mon, 1 Jul 1996 14:01:30 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011811; Mon, 1 Jul 96 14:01:02 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07365; Mon, 1 Jul 96 14:01:03 EDT Received: by relay.tis.com; id OAA11804; Mon, 1 Jul 1996 14:01:00 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma011801; Mon, 1 Jul 96 14:00:39 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA096324191; Mon, 1 Jul 1996 11:03:11 -0700 Message-Id: <199607011803.AA096324191@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA198584190; Mon, 1 Jul 1996 14:03:10 -0400 To: Steve Bellovin MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM Subject: Re: deriving keying material from the shared secret In-Reply-To: smb's message of Sun, 30 Jun 1996 19:18:51 -0400. <199606302320.TAA00201@smb.research.att.com> Date: Mon, 01 Jul 1996 14:03:09 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk All transforms which provide authentication and encryption need to resist a known-plaintext key-recovery attack. Using the strongest cryptographic part of the transform itself with the shared secret as the *key* and some known plaintext as input might be a good way to generate one or more keys for use by a given transform. If you need multiple keys, use multiple different known plaintexts. In the event the transform can't deal with a variable-length key, do some not-necessarily-cryptographic transform of the shared secret to come up with the fixed-length key (like the kerberos string-to-key bitwise-fanfold-and-xor approach). Upside: the resulting key generation should be no weaker than the transform itself is, assuming the shared secret is big enough. For instance, for 3DES, you wouldn't weaken a 168-bit 3DES key to 160 or 128 bits by funnelling the key material through SHA or MD5. Downside: you probably don't want to do this for algorithms where key recovery might become practical (e.g., single-DES) because you'll leak bits out of the shared secret that way. - Bill Received: from relay.tis.com by neptune.TIS.COM id aa01403; 3 Jul 96 8:56 EDT Received: by relay.tis.com; id IAA14271; Wed, 3 Jul 1996 08:42:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014260; Wed, 3 Jul 96 08:42:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03413; Wed, 3 Jul 96 08:41:56 EDT Received: by relay.tis.com; id IAA14249; Wed, 3 Jul 1996 08:42:03 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma014217; Wed, 3 Jul 96 08:41:49 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id OAA21977; Wed, 3 Jul 1996 14:42:11 +0200 (MET DST) From: Germano Caronni Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id OAA10521; Wed, 3 Jul 1996 14:42:10 +0200 (MET DST) Message-Id: <199607031242.OAA10521@kom30.ethz.ch> Subject: Stream Cipher Transform -- revisited To: ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP Date: Wed, 3 Jul 1996 14:42:10 +0200 (MET DST) Cc: Burkhard Stiller , Bernhard Plattner X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hello everybody, during the last few weeks Marcel and I received some favorable and encouraging comments (among others ;-) ) concerning the stream-cipher draft, and its usability for real-world implementations. This motivated us to continue our work on it, and I would thus like to invite your technical feedback, comments, suggestions that will lead to a new revision of the draft. draft-esp-stream-00.txt is the base of discussion, as it can e.g. be found under http:///www.tik.ee.ethz.ch/~skip/esp-stream.txt Current list of changes: Make it possible to use 4-byte OR 8-byte counters for the stream offset. This might save 4 bytes of headers in protocols where quick change of packet keys is the norm. The point has been raised that the 'stream offset' of 64 bits maximal might be insufficent for certain algorithms. Comments on this? A section will be added that contains concrete parameters for RC4 and SEAL such that alogorithms can be assigned 'transform identifiers' and used in key management protocols. This should alleviate the problem of the draft being too generic. The drawback is that the draft would then actually specify the parameters for a group of ciphers and not only one of them... No authentication will be incorporated, as the goal of esp-stream is to provide as fast as possible privacy to e.g. encrypt realtime video. Should we add CFB mode (or perhaps even OFB) of DES or another wellknown algorithm such as BLOWFISH, RC5 or Safer-SK as a 'stream cipher' ? If yes, the structure of the individual IVs needs to be discussed. This might be a bad idea. And then it might not... It has been suggested that replay protection is more important than the 'optional' label would indicate. How do people feel about making it mandatory, or shold we just strengthen the wording in the advisory text? Please send feedback to me or skip@tik.ee.ethz.ch, and we will produce a new revision of the draft in the next few weeks. Friendly greetings, Germano Caronni p.s. I would like to thank the following persons (in no particular order) for their feedback and comments to esp-stream. I apologize to those people I missed in this list, some comments lost their name tags during the time... Roy Shamir, David Wagner, Ran Atkinson, Ashar Aziz, Tom Markson, Rich Skrenta, Derek Palma - -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBMdpqn7H8jId7euXhAQGh1gP/cVO/XUV08z4Q5bgiek8HnF6cwTn2urfz cE5eQ0O17fzpOwl2iOnNd0L3z44nW8jdAgpos0ihgPS/cnmDOssK/DI6yZ0FkHUz LVpvW/fuup5N62QgeFw40pil5s6ivvMcYmKMaYKJqV7bGh4u24yc+sgb1CydZJU+ jY4ag4N3LeQ= =Gvyk -----END PGP SIGNATURE----- Received: from relay.tis.com by neptune.TIS.COM id aa07554; 5 Jul 96 11:24 EDT Received: by relay.tis.com; id LAA05603; Fri, 5 Jul 1996 11:26:46 -0400 From: Steve_Rodney_at_HP7@rimail.interlan.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005597; Fri, 5 Jul 96 11:26:18 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24221; Fri, 5 Jul 96 11:26:10 EDT Received: by relay.tis.com; id LAA05588; Fri, 5 Jul 1996 11:26:16 -0400 Received: from interlan.interlan.com(130.204.8.1) by relay.tis.com via smap (V3.1.1) id xma005581; Fri, 5 Jul 96 11:25:51 -0400 Received: from rimail.InterLan.COM by interlan.interlan.com with SMTP (5.65/25-eef) id AA09976; Fri, 5 Jul 96 10:53:39 -0400 Received: from ccMail by rimail.interlan.com id AA836591343 Fri, 05 Jul 96 11:29:03 EST Date: Fri, 05 Jul 96 11:29:03 EST Encoding: 988 Text Message-Id: <9606058365.AA836591343@rimail.interlan.com> To: ipsec@TIS.COM Subject: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk The latest Security Architecture for IP draft (4 June 96) changes the role of ESP from confidentiality only to confidentiality + authentication. But, ESP in Transport Mode does not operate on the cleartext IP header. So I still need to apply AH after ESP to provide end-to-end authentication of IP headers. It is desirable to tweak the architecture so that authentication provided by ESP has the same security as authentication provided by AH. Then only a single security header is needed for end-to-end confidentiality + authentication. Steve ===================================================================== Steve Rodney E-mail: SRODNEY@FTL03.RACAL.COM Racal-Datacom 1601 N. Harrison Parkway Phone: 1-954-846-6836 Sunrise, Florida 33323-6836 Fax: 1-954-846-4942 ===================================================================== Received: from relay.tis.com by neptune.TIS.COM id aa08790; 5 Jul 96 12:54 EDT Received: by relay.tis.com; id MAA07644; Fri, 5 Jul 1996 12:56:18 -0400 From: Steve_Rodney_at_HP7@rimail.interlan.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007636; Fri, 5 Jul 96 12:55:49 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28878; Fri, 5 Jul 96 12:55:42 EDT Received: by relay.tis.com; id MAA07633; Fri, 5 Jul 1996 12:55:48 -0400 Received: from interlan.interlan.com(130.204.8.1) by relay.tis.com via smap (V3.1.1) id xma007630; Fri, 5 Jul 96 12:55:46 -0400 Received: from rimail.InterLan.COM by interlan.interlan.com with SMTP (5.65/25-eef) id AA11077; Fri, 5 Jul 96 12:23:35 -0400 Received: from ccMail by rimail.interlan.com id AA836596736 Fri, 05 Jul 96 12:58:56 EST Date: Fri, 05 Jul 96 12:58:56 EST Encoding: 1866 Text Message-Id: <9606058365.AA836596736@rimail.interlan.com> To: ipsec@TIS.COM Subject: Documentation Layering Structure Sender: ipsec-approval@neptune.tis.com Precedence: bulk In Montreal we decided to improve the IPSEC documentation structure to reduce redundancy in defining security transforms. A document structure is shown below. My main point is that Security Transforms should define what fields are required (such as SPIs, replay counters and IVs) and how to apply authentication and encryption algorithms. The Security Transform should be independent of the protocol being secured and the actual authentication and encryption algorithms. How a security transform is applied to IP should only be in the IP AH and IP ESP documents. Then it would be easy to reuse security transforms to secure other protocols and different layers in the protocol stack. --------------------------------------------------- | Security Architecture for the Internet Protocol | --------------------------------------------------- | | | --------- ---------- -------------------------------------- | IP AH | | IP ESP | | Approved Transforms and Algorithms | --------- ---------- | for IP AH and ESP | | | -------------------------------------- ----------------------- | Security Transforms | ... ----------------------- | ----------------------- | Algorithms | ... ----------------------- ===================================================================== Steve Rodney E-mail: SRODNEY@FTL03.RACAL.COM Racal-Datacom 1601 N. Harrison Parkway Phone: 1-954-846-6836 Sunrise, Florida 33323-6836 Fax: 1-954-846-4942 ===================================================================== Received: from relay.tis.com by neptune.TIS.COM id aa10593; 5 Jul 96 15:13 EDT Received: by relay.tis.com; id PAA11243; Fri, 5 Jul 1996 15:16:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011238; Fri, 5 Jul 96 15:15:36 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07407; Fri, 5 Jul 96 15:15:25 EDT Received: by relay.tis.com; id PAA11234; Fri, 5 Jul 1996 15:15:31 -0400 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1) id xma011219; Fri, 5 Jul 96 15:15:15 -0400 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/3.0) id PAA02949; Fri, 5 Jul 1996 15:18:05 -0400 Received: from milkyway.com (metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id PAA13330 for ; Fri, 5 Jul 1996 15:10:07 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id PAA22204; Fri, 5 Jul 1996 15:16:01 -0400 Message-Id: <199607051916.PAA22204@milkyway.com> X-Mailer: exmh version 1.6.4 10/10/95 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Fri, 05 Jul 1996 11:29:03 EST." <9606058365.AA836591343@rimail.interlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 1996 15:16:00 -0400 From: Michael Richardson Sender: ipsec-approval@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Fri, 05 Jul 1996 11:29:03 EST > end-to-end authentication of IP headers. It is desirable to tweak the > architecture so that authentication provided by ESP has the same > security as authentication provided by AH. Then only a single security > header is needed for end-to-end confidentiality + authentication. Except that tunnel mode will most often be used by security gateways, not the end-to-end contents. Received: from relay.tis.com by neptune.TIS.COM id aa10770; 5 Jul 96 15:24 EDT Received: by relay.tis.com; id PAA11595; Fri, 5 Jul 1996 15:26:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011569; Fri, 5 Jul 96 15:25:32 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07865; Fri, 5 Jul 96 15:25:25 EDT Received: by relay.tis.com; id PAA11565; Fri, 5 Jul 1996 15:25:31 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma011563; Fri, 5 Jul 96 15:25:17 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id PAA16278; Fri, 5 Jul 1996 15:31:43 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Jul 1996 15:29:04 +0100 To: Steve_Rodney_at_HP7@rimail.interlan.com From: Stephen Kent Subject: Re: Authentication using ESP in Transport Mode Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, AH still has a role in IPSEC, independent of ESP. ESP, as it's name indicates, encapsulates data to protect it. In that mode it can offer authentication and integrity (as well as confidentiality) for tunneled IP packets, but it cannot protect the IP header for a packet in which it is embedded. It is still appropriate to use a combination of AH and ESP if one wishes to protect the IP header for a packet and to bind that header to a payload protected with ESP. The change to AH that was approved at the meeting, was to remove all references to the mode of AH operation in which it did NOT apply to an IP header in which it was embedded. The motivation for redefining AH in this fashion arose because wel now have ESP transforms that provide authentication and integrity, and because this dual mode of AH use was unduly complex given the existance of such ESP transforms. Steve Received: from relay.tis.com by neptune.TIS.COM id aa21321; 8 Jul 96 13:31 EDT Received: by relay.tis.com; id NAA10044; Mon, 8 Jul 1996 13:33:48 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010026; Mon, 8 Jul 96 13:33:19 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13552; Mon, 8 Jul 96 13:33:07 EDT Received: by relay.tis.com; id NAA10017; Mon, 8 Jul 1996 13:33:16 -0400 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1.1) id xma010005; Mon, 8 Jul 96 13:33:07 -0400 Received: by interlock.ans.net id AA18863 (InterLock SMTP Gateway 3.0 for ipsec@ans.net); Mon, 8 Jul 1996 13:35:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 8 Jul 1996 13:35:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 8 Jul 1996 13:35:33 -0400 Date: Mon, 8 Jul 1996 10:35:24 -0700 From: Matt Bishop Message-Id: <9607081735.AA28861@nob> To: ipsec@ans.net Subject: [2nd Posting] CFP: Symposium on Network and Distributed System Security Sender: ipsec-approval@neptune.tis.com Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security February 10-11, 1997, San Diego Princess Resort, San Diego, California Submissions due: August 1, 1996 Notification to Authors: October 1, 1996 Camera-Ready Copy due: November 1, 1996 GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following: * Design and implementation of communication security services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Design and implementation of security mechanisms, services, and APIs to support communication security services, key management and certification infrastructures, audit, and intrusion detection. * Requirements and designs for securing network information resources and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS. * Requirements and designs for systems supporting electronic commerce -- payment services, fee-for-access, EDI, notary -- endorsement, licensing, bonding, and other forms of assurance. * Design and implementation of measures for controlling network communication -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integration of security services with system and application security facilities, and application protocols -- including but not limited to message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. GENERAL CHAIR: David Balenson, Trusted Information Systems PROGRAM CHAIRS: Clifford Neuman, University of Southern California 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, Bell Northern Research Richard Graveman, Bellcore Li Gong, SRI Burt Kaliski, RSA Laboratories Steve Kent, BBN Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, Sun Microsystems Hilarie Orman, DARPA Michael Roe, Cambridge University 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 LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 1 August 1996, and should be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 1 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Clifford Neuman, University of Southern California, Information Sciences Institute, 4676 Admiralty Way, Marina del Rey, California 90292-6695, Phone: +1 (310) 822-1511, FAX: +1 (310) 823-6714, Email: sndss97-submissions@isi.edu. Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/conferences/ndss97. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 1 October 1996. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 1 November 1996. Received: from relay.tis.com by neptune.TIS.COM id aa25051; 8 Jul 96 16:30 EDT Received: by relay.tis.com; id QAA15683; Mon, 8 Jul 1996 16:33:08 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015674; Mon, 8 Jul 96 16:32:42 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26983; Mon, 8 Jul 96 16:32:29 EDT Received: by relay.tis.com; id QAA15667; Mon, 8 Jul 1996 16:32:38 -0400 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma015658; Mon, 8 Jul 96 16:32:32 -0400 Received: from snail.rsa.com by RSA.COM with SMTP id AA15324; Mon, 8 Jul 96 13:30:47 PDT Received: from cc:Mail by snail.rsa.com id AA836858249; Mon, 08 Jul 96 13:33:17 PST Date: Mon, 08 Jul 96 13:33:17 PST From: kurt Message-Id: <9606088368.AA836858249@snail.rsa.com> To: pem-dev@TIS.COM, smime-dev@rsa.com, ipsec@TIS.COM, swan-dev@rsa.com, rsa-place@rsa.com, set-discuss@commerce.net, ietf-pkix@tandem.com, pgp-mime@purpletape.cs.uchicago.edu, CMGannon@aol.com, corman@cerf.net, firewall-interest@rsa.com, kkincaid@vnet.ibm.com, layne@lke.com, malr@ca.newbridge.com, marshall@verisign.com, Michael Cenko <72420.2723@compuserve.com>, perezchica.jerry@ssd.loral.com, rhdanck@delphi.com, rivest@theory.lcs.mit.edu, rotenberg@epic.org, SchnellST@aol.com, shamir@wisdom.weizmann.ac.il, susan@lke.com, whitfield.diffie@eng.sun.com, whmurray@dockmaster.ncsc.mil, RSA_at_rsapo@snail.rsa.com Subject: CALL FOR PAPERS: *** 1997 RSA Conference Sender: ipsec-approval@neptune.tis.com Precedence: bulk CALL FOR PAPERS & DEMONSTRATIONS SIXTH ANNUAL RSA DATA SECURITY CONFERENCE January 28-31, 1997 San Francisco, California ********************************************************* The 6th Annual RSA Data Security Conference will be held January 28-31, 1997, at various facilities atop Nob Hill in San Francisco, California. Selected cryptographers, analysts, developers, and partners will be given the opportunity to give presentations on their applications or research. You are encouraged to suggest/submit multiple talks. Please duplicate this form as necessary. The four days of the conference will consist of two days of general sessions (with an anticipated attendance of around 2000) and two more days of breakouts, divided into the following five tracks: * Cryptography (mathematics), * Standards (overviews of international crypo stds) * Development (tutorials & case studies for developers), * Analysts (Politics, Markets and Legal issues surrounding crypto), and * Products (Product Demonstrations and Announcements) Organization: ______________________________________________________________ Presenter's Name: ______________________________________________________________ Title: ______________________________________________________________ Address: ______________________________________________________________ Phone: ______________________________________________________________ Fax: ______________________________________________________________ E-mail: ______________________________________________________________ Web Site: ______________________________________________________________ Proposed Title of Your Talk: ______________________________________________________________ Suggested Track for Your Talk: _____ Cryptography _____ Standards _____ Development _____ Analysts _____ Products Please attach to this form: * 100 word abstract of your presentation * 25 word topic description * 50 word personal biography * 50 word company biography * personal photo (digital or hard copy) * company logo (digital or hard copy) Mail, fax, or e-mail all documents by August 5, 1996 to: 1997 RSA Data Security Conference c/o LKE Productions 1620 Montgomery Street, Suite 120 San Francisco, CA 94111 (415)544-9300 phone (415)544-9306 fax info@lke.com You will be notified in early September if your talk is selected. Please be prepared to submit a hard copy or diskette of your slides by October 30, 1996. Each speaking slot is 30 minutes long; please plan for a 20 minute presentation and a 10 minute Q & A. Thank you for your submission! ********************************************************* for more info, visit the RSA website at www.rsa.com ********************************************************* Received: from relay.tis.com by neptune.TIS.COM id aa01336; 9 Jul 96 0:57 EDT Received: by relay.tis.com; id AAA24390; Tue, 9 Jul 1996 00:59:40 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024387; Tue, 9 Jul 96 00:59:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10408; Tue, 9 Jul 96 00:59:00 EDT Received: by relay.tis.com; id AAA24384; Tue, 9 Jul 1996 00:59:10 -0400 Received: from unix.ka9q.ampr.org(129.46.90.35) by relay.tis.com via smap (V3.1.1) id xma024382; Tue, 9 Jul 96 00:58:42 -0400 Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id VAA14902; Mon, 8 Jul 1996 21:59:44 -0700 (PDT) Date: Mon, 8 Jul 1996 21:59:44 -0700 (PDT) Message-Id: <199607090459.VAA14902@unix.ka9q.ampr.org> From: Phil Karn To: ho@earth.hpc.org Cc: smb@research.att.com, ipsec@TIS.COM In-Reply-To: <199607011355.JAA04896@earth.hpc.org> (message from Hilarie Orman on Mon, 1 Jul 1996 09:55:13 -0400) Subject: Re: deriving keying material from the shared secret Reply-To: karn@qualcomm.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk How critical is the particular hash method used to produce the key from the shared secret? Too critical to just specify a particular hash method for fear that it might become compromised (e.g., MD5)? Phil Received: from relay.tis.com by neptune.TIS.COM id aa09132; 9 Jul 96 11:07 EDT Received: by relay.tis.com; id LAA03491; Tue, 9 Jul 1996 11:09:28 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma003468; Tue, 9 Jul 96 11:08:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01007; Tue, 9 Jul 96 11:08:43 EDT Received: by relay.tis.com; id LAA03456; Tue, 9 Jul 1996 11:08:53 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma003440; Tue, 9 Jul 96 11:08:34 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id LAA19706; Tue, 9 Jul 1996 11:11:26 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA42227; Tue, 9 Jul 1996 11:10:59 -0400 From: Uri Blumenthal Message-Id: <9607091510.AA42227@hawpub.watson.ibm.com> Subject: Re: deriving keying material from the shared secret To: karn@qualcomm.com Date: Tue, 9 Jul 1996 11:10:59 -0400 (EDT) Cc: ipsec@TIS.COM In-Reply-To: <199607090459.VAA14902@unix.ka9q.ampr.org> from "Phil Karn" at Jul 8, 96 09:59:44 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil Karn says: > How critical is the particular hash method used to produce the key > from the shared secret? Cannot answer this one - but hash should be stronger than the algorithm(s) that use the derived key, and hopefully enjoy the same level of trust... > Too critical to just specify a particular hash > method for fear that it might become compromised (e.g., MD5)? I'd say - yes... Plus, it seems to me that there's little benefit in narrowing the choices down to "one hash function for all"... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: from relay.tis.com by neptune.TIS.COM id aa10723; 9 Jul 96 12:13 EDT Received: by relay.tis.com; id MAA06100; Tue, 9 Jul 1996 12:15:39 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006098; Tue, 9 Jul 96 12:15:17 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06849; Tue, 9 Jul 96 12:15:00 EDT Received: by relay.tis.com; id MAA06093; Tue, 9 Jul 1996 12:15:09 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma006080; Tue, 9 Jul 96 12:14:45 -0400 Received: by pilotx.firewall.is.chrysler.com; id MAA20654; Tue, 9 Jul 1996 12:17:09 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma020643; Tue, 9 Jul 96 12:16:47 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id MAA10496; Tue, 9 Jul 1996 12:10:50 -0400 (EDT) Message-Id: <2.2.32.19960709160928.00aef9f8@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Jul 1996 12:09:28 -0400 To: Michael Richardson , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 03:16 PM 7/5/96 -0400, Michael Richardson wrote: >In a galaxy far, far away, : Fri, 05 Jul 1996 11:29:03 EST >> end-to-end authentication of IP headers. It is desirable to tweak the >> architecture so that authentication provided by ESP has the same >> security as authentication provided by AH. Then only a single security >> header is needed for end-to-end confidentiality + authentication. > > Except that tunnel mode will most often be used by security gateways, not >the end-to-end contents. Not quite. I THINK it will be used in end-to-gateway-to-end as well. Yes? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa13946; 9 Jul 96 14:40 EDT Received: by relay.tis.com; id OAA10891; Tue, 9 Jul 1996 14:42:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010865; Tue, 9 Jul 96 14:42:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16449; Tue, 9 Jul 96 14:41:55 EDT Received: by relay.tis.com; id OAA10857; Tue, 9 Jul 1996 14:42:03 -0400 Received: from wizard.pn.com(204.96.36.2) by relay.tis.com via smap (V3.1.1) id xma010844; Tue, 9 Jul 96 14:42:01 -0400 Received: from massey (massey.ftp.com [128.127.128.152]) by wizard.pn.com (8.6.12) with SMTP id OAA24131 for ; Tue, 9 Jul 1996 14:44:28 -0400 Message-Id: <199607091844.OAA24131@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Jul 1996 14:43:56 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: re... usage models Sender: ipsec-approval@neptune.tis.com Precedence: bulk An end node talking to a "tunnel head" is one model I am looking at. Think of a notebook PC communicating with a firewall at the edge of a corporate intranet. I have the (general vague) impression other people think this is a realistic model. >Date: Tue, 09 Jul 1996 12:09:28 -0400 >To: Michael Richardson , ipsec@TIS.COM >From: Robert Moskowitz > >At 03:16 PM 7/5/96 -0400, Michael Richardson wrote: >>In a galaxy far, far away, : Fri, 05 Jul 1996 11:29:03 EST >>> end-to-end authentication of IP headers. It is desirable to tweak the >>> architecture so that authentication provided by ESP has the same >>> security as authentication provided by AH. Then only a single security >>> header is needed for end-to-end confidentiality + authentication. >> >> Except that tunnel mode will most often be used by security gateways, not >>the end-to-end contents. > >Not quite. I THINK it will be used in end-to-gateway-to-end as well. Yes? > >Robert Moskowitz >Chrysler Corporation 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" Received: from relay.tis.com by neptune.TIS.COM id aa14273; 9 Jul 96 14:54 EDT Received: by relay.tis.com; id OAA11336; Tue, 9 Jul 1996 14:56:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011328; Tue, 9 Jul 96 14:56:12 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18654; Tue, 9 Jul 96 14:56:00 EDT Received: by relay.tis.com; id OAA11324; Tue, 9 Jul 1996 14:56:03 -0400 Received: from portal.visa.com(198.80.42.2) by relay.tis.com via smap (V3.1.1) id xma011307; Tue, 9 Jul 96 14:55:23 -0400 Received: by portal.visa.com id AA15404 (InterLock SMTP Gateway 3.0 for ipsec@TIS.COM); Tue, 9 Jul 1996 18:56:55 GMT Message-Id: <199607091856.AA15404@portal.visa.com> Received: by portal.visa.com (Protected-side Proxy Mail Agent-1); Tue, 9 Jul 1996 18:56:55 GMT From: "Smith, David" To: "ipsec@TIS.COM" , Michael Richardson , Robert Moskowitz Subject: RE: Authentication using ESP in Transport Mode Date: Tue, 9 Jul 1996 11:34:30 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 7 TEXT Sender: ipsec-approval@neptune.tis.com Precedence: bulk Sorry if I don't understand, but could anyone give an example of a configuration where you would see end-to-gateway-to-end use of tunnel mode--i.e., what is at the other "end". Cheers, David Smith Visa International Received: from relay.tis.com by neptune.TIS.COM id aa15669; 9 Jul 96 16:10 EDT Received: by relay.tis.com; id QAA14944; Tue, 9 Jul 1996 16:12:33 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014929; Tue, 9 Jul 96 16:12:05 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22909; Tue, 9 Jul 96 16:11:54 EDT Received: by relay.tis.com; id QAA14926; Tue, 9 Jul 1996 16:12:03 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma014921; Tue, 9 Jul 96 16:11:36 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Tue, 9 Jul 1996 16:12:11 -0400 Received: from localhost (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with SMTP id QAA00437; Tue, 9 Jul 1996 16:12:06 -0400 Message-Id: <199607092012.QAA00437@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: Host localhost didn't use HELO protocol To: "Smith, David" Cc: "ipsec@TIS.COM" , Michael Richardson , Robert Moskowitz Subject: Re: Authentication using ESP in Transport Mode In-Reply-To: david's message of Tue, 09 Jul 1996 11:34:30 -0700. <199607091856.AA15404@portal.visa.com> Date: Tue, 09 Jul 1996 16:11:51 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Sorry if I don't understand, but could anyone give an example of a > configuration where you would see end-to-gateway-to-end use of tunnel > mode--i.e., what is at the other "end". here's one possibility: end 1: wandering laptop gateway: firewall end 2: server behind firewall I think Bob Moskowitz wants to have end-to-end encryption from the laptop to the server, wants to use tunnel mode to get to/through the firewall, and also wants to avoid the overhead of double-encrypting traffic on the client. - Bill Received: from relay.tis.com by neptune.TIS.COM id aa17213; 9 Jul 96 17:18 EDT Received: by relay.tis.com; id RAA16388; Tue, 9 Jul 1996 17:20:34 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016382; Tue, 9 Jul 96 17:20:07 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25890; Tue, 9 Jul 96 17:19:55 EDT Received: by relay.tis.com; id RAA16373; Tue, 9 Jul 1996 17:20:04 -0400 Received: from fluffy.cisco.com(161.44.128.253) by relay.tis.com via smap (V3.1.1) id xma016368; Tue, 9 Jul 96 17:19:50 -0400 Received: from localhost (localhost [127.0.0.1]) by fluffy.cisco.com (8.7.5/8.7.3) with SMTP id OAA03084; Tue, 9 Jul 1996 14:22:06 -0700 (PDT) Message-Id: <199607092122.OAA03084@fluffy.cisco.com> To: "Smith, David" Cc: "ipsec@TIS.COM" , Michael Richardson , Robert Moskowitz Subject: Re: Authentication using ESP in Transport Mode In-Reply-To: Your message of "Tue, 09 Jul 1996 11:34:30 PDT." <199607091856.AA15404@portal.visa.com> Date: Tue, 09 Jul 1996 14:21:57 -0700 From: Derrell Piper Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Sorry if I don't understand, but could anyone give an example of a >configuration where you would see end-to-gateway-to-end use of tunnel >mode--i.e., what is at the other "end". Well, precisely that, really. Some people want a private tunnel back to the corporate firewall _and_ an encrypted tunnel to the ultimate endnode. Derrell Received: from relay.tis.com by neptune.TIS.COM id aa00405; 10 Jul 96 8:36 EDT Received: by relay.tis.com; id IAA25302; Wed, 10 Jul 1996 08:38:21 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025294; Wed, 10 Jul 96 08:37:58 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18074; Wed, 10 Jul 96 08:37:41 EDT Received: by relay.tis.com; id IAA25289; Wed, 10 Jul 1996 08:37:51 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via smap (V3.1.1) id xma025285; Wed, 10 Jul 96 08:37:50 -0400 Received: by pilot.firewall.is.chrysler.com; id IAA00716; Wed, 10 Jul 1996 08:40:19 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma000712; Wed, 10 Jul 96 08:40:07 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id IAA24930; Wed, 10 Jul 1996 08:34:09 -0400 (EDT) Message-Id: <2.2.32.19960710123236.00c0e3b8@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jul 1996 08:32:36 -0400 To: Rodney Thayer , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: re... usage models Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 02:43 PM 7/9/96 -0400, Rodney Thayer wrote: >An end node talking to a "tunnel head" is one model I am looking at. > >Think of a notebook PC communicating with a firewall at the edge of a >corporate intranet. > >I have the (general vague) impression other people think this is a realistic >model. This is the 'simple' problem set. And truth be known, maybe 80% of the implementation needs for the next year. BTW, it is such thinking that has produced PPTP. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa00425; 10 Jul 96 8:36 EDT Received: by relay.tis.com; id IAA25311; Wed, 10 Jul 1996 08:38:50 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025307; Wed, 10 Jul 96 08:38:22 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18138; Wed, 10 Jul 96 08:38:10 EDT Received: by relay.tis.com; id IAA25301; Wed, 10 Jul 1996 08:38:20 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via smap (V3.1.1) id xma025297; Wed, 10 Jul 96 08:38:04 -0400 Received: by pilot.firewall.is.chrysler.com; id IAA00715; Wed, 10 Jul 1996 08:40:19 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma000711; Wed, 10 Jul 96 08:40:06 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id IAA24928; Wed, 10 Jul 1996 08:34:08 -0400 (EDT) Message-Id: <2.2.32.19960710123236.00bc6270@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jul 1996 08:32:36 -0400 To: "Smith, David" , "ipsec@TIS.COM" , Michael Richardson From: Robert Moskowitz Subject: RE: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 11:34 AM 7/9/96 -0700, Smith, David wrote: >Sorry if I don't understand, but could anyone give an example of a >configuration where you would see end-to-gateway-to-end use of tunnel >mode--i.e., what is at the other "end". > HR person at an college employement fair needing a secure connection to the corporate HR server. Connection has to be secure from their connection to the University LAN back to the corporate firewall. Corporate requirements are for secure communication even within the corporate LAN. Design Engineer at Acme Design Studios working from home with connections back to his design server at Acme and to the OEM's design server. Since ACME has many contracts with competing companies they are contractually bound to secure communications by contract. The OEM secures communications internally on all design projects by policy (as opposed to engineering projects; designs are much more closely guarded). I REALLY got to do these today. Can you help? Oh and don't forget the DNS and routing (ie addressing) challenges along with the security ones. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa02670; 10 Jul 96 10:34 EDT Received: by relay.tis.com; id KAA28415; Wed, 10 Jul 1996 10:37:09 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028408; Wed, 10 Jul 96 10:36:41 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25653; Wed, 10 Jul 96 10:36:29 EDT Received: by relay.tis.com; id KAA28405; Wed, 10 Jul 1996 10:36:39 -0400 Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1.1) id xma028402; Wed, 10 Jul 96 10:36:27 -0400 Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA23114; Wed, 10 Jul 1996 10:38:44 -0400 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA00827; Wed, 10 Jul 1996 10:38:43 -0400 Message-Id: <9607101438.AA00827@wellspring.us.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jul 1996 10:38:10 -0400 To: ipsec@TIS.COM From: Rodney Thayer Subject: Re: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk As we all move closer to actually (gasp!) deploying working code this kind of question seems interesting. Hope I'm not belaboring an old point... I wonder if you mean you want this: 1. Packets travel from remote node to node within (e.g. corporate internal network) -and- 2. Packets are encrypted as they travel from remote node to tunnel endpoint at corporate Firewall -and- 3. packets are also encrypted so the remote node and the other end node have a secure pathway. So specifically do you mean you want to double encrypt packets at the remote node, so that one layer of encryption is stripped at the tunnel endpoint and the second layer of encryption is stripped at the other end node? The packets would be: IPv4 ...outer header as it travels the net AH ...is this needed? ESP ...for firewall/tunnel ESP ...for remote to internal node original TCP/UDP/etc. ...real data. If so, then I have a question: I believe the architecture supports this fine. Has anyone implemented this? Has anyone done interoperability testing? Are we really really sure any existing implementations correctly allow ESP inside ESP? This is an interoperability and operational question, as I understand it the technology is agreed upon and should work. >From: Derrell Piper > >>Sorry if I don't understand, but could anyone give an example of a >>configuration where you would see end-to-gateway-to-end use of tunnel >>mode--i.e., what is at the other "end". > >Well, precisely that, really. Some people want a private tunnel back to >the corporate firewall _and_ an encrypted tunnel to the ultimate endnode. 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" Received: from relay.tis.com by neptune.TIS.COM id aa05176; 10 Jul 96 12:42 EDT Received: by relay.tis.com; id MAA02210; Wed, 10 Jul 1996 12:44:27 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002208; Wed, 10 Jul 96 12:44:02 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02397; Wed, 10 Jul 96 12:43:47 EDT Received: by relay.tis.com; id MAA02205; Wed, 10 Jul 1996 12:43:57 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma002203; Wed, 10 Jul 96 12:43:43 -0400 Received: by pilotx.firewall.is.chrysler.com; id MAA08111; Wed, 10 Jul 1996 12:46:12 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma008098; Wed, 10 Jul 96 12:45:43 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id MAA00149; Wed, 10 Jul 1996 12:39:44 -0400 (EDT) Message-Id: <2.2.32.19960710163812.00c358ac@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jul 1996 12:38:12 -0400 To: Rodney Thayer , ipsec@TIS.COM From: Robert Moskowitz Subject: Re: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 10:38 AM 7/10/96 -0400, Rodney Thayer wrote: >As we all move closer to actually (gasp!) deploying working code this kind >of question seems interesting. Hope I'm not belaboring an old point... > >I wonder if you mean you want this: > Basically. > >So specifically do you mean you want to double encrypt packets at the remote >node, so that one layer of encryption is stripped at the tunnel endpoint and >the second layer of encryption is stripped at the other end node? Maybe not quite. >The packets would be: > > IPv4 ...outer header as it travels the net > AH ...is this needed? > ESP ...for firewall/tunnel > ESP ...for remote to internal node > original TCP/UDP/etc. ...real data. Would the outer ESP be needed for the end-to-end packets (only for the end-to-gateway authorization?). Thus there might be 2 classes of packets: IPv4 ...outer header as it travels the net ESP ...for firewall/tunnel original TCP/UDP/etc. ...tunnel authorization data IPv4 ...outer header as it travels the net AH ...is this needed? ESP ...for remote to internal node original TCP/UDP/etc. ...real data. Of course one thing you have left out here is the issue of routing to the internal host. It's IP address is different from the gateway, so perhaps you do need 2 ESPs as: IPv4 ...outer header as it travels the net AH ...is this needed? ESP ...for firewall/tunnel IPv4 ...inner header as it travels the intranet ESP ...for remote to internal node original TCP/UDP/etc. ...real data. And it gets worst when the workstation is inside yet another secure domain and has to go out of its domain, across the public, and then into the destination secure domain.... >This is an interoperability and operational question, as I understand it the >technology is agreed upon and should work. There will be DNS issues and addressing/routing issues as well that will surface as we try and 'net' this all out. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.tis.com by neptune.TIS.COM id aa09295; 10 Jul 96 16:03 EDT Received: by relay.tis.com; id QAA06776; Wed, 10 Jul 1996 16:05:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006764; Wed, 10 Jul 96 16:05:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11096; Wed, 10 Jul 96 16:04:56 EDT Received: by relay.tis.com; id QAA06761; Wed, 10 Jul 1996 16:05:07 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma006759; Wed, 10 Jul 96 16:05:00 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id NAA12840; Wed, 10 Jul 1996 13:07:31 -0700 Date: Wed, 10 Jul 1996 13:07:31 -0700 Message-Id: <199607102007.NAA12840@puli.cisco.com> From: Ran Atkinson To: ipsec@TIS.COM Subject: Re: Authentication using ESP in Transport Mode Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <9607101438.AA00827@wellspring.us.dg.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk Someone wrote: >The packets would be: > > IPv4 ...outer header as it travels the net > AH ...is this needed? > ESP ...for firewall/tunnel > ESP ...for remote to internal node > original TCP/UDP/etc. ...real data. I don't think so. I was thinking more like: IP (source=outside firewall, dest=firewall) ESP with combined transform IP (source=outside firewall, dest=inner destination) AH alone OR ESP with combined transform inner IP/TCP, IP/UDP, TCP, UDP, etc. >Has anyone implemented this? My description above is implemented by the NRL source code if one configures a "secure IPv4 tunnel" for the outer path and also the user requests ESP tunnel-mode on the original packet. >Are we really really sure any existing implementations correctly allow ESP >inside ESP? Gee, I hope not. ESP directly inside ESP is bogus. Ran rja@inet.org Received: from relay.tis.com by neptune.TIS.COM id aa27249; 11 Jul 96 14:06 EDT Received: by relay.tis.com; id OAA00890; Thu, 11 Jul 1996 14:08:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000858; Thu, 11 Jul 96 14:08:06 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02142; Thu, 11 Jul 96 14:07:53 EDT Received: by relay.tis.com; id OAA00843; Thu, 11 Jul 1996 14:08:04 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma000830; Thu, 11 Jul 96 14:07:51 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id LAA28305; Thu, 11 Jul 1996 11:10:18 -0700 Message-Id: <199607111810.LAA28305@puli.cisco.com> From: Ran Atkinson Date: Thu, 11 Jul 1996 11:10:18 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: jis@mit.edu Subject: US Patent 5,511,122 Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk To: Jeff Schiller, Security Area Director, IETF, From: Randall Atkinson, Subject: Notification of patent I have just been officially notified that US Patent 5, 511, 122 on "Intermediate Network Authentication" was issued to me on 23 April 1996 with all rights assigned to The United States of America as represented by the Secretary of the Navy. The filing date on this patent is 3 June 1994 and the work was begun in 1991. The funded project work behind this patent was unrelated to IPsec and primarily related to a need for intermediate network authentication of datagrams in a network that performed intermediate fragmentation of datagrams. I am not a lawyer and I am not making any kind of legal representation, but I believe that this patent DOES NOT create any issues with respect to current IPsec RFCs or any current IPsec draft that I am aware of or any other IETF standard that I'm aware of. The patent might affect a (hypothetical) AH transform proposal that used cryptographic digital signatures based on asymmetric cryptography (e.g. an RSA digital signature), as distinguished from all current standards-track documents and online proposals (which I believe all use keyed one-way cryptographic hash functions). -- Received: from relay.tis.com by neptune.TIS.COM id aa16893; 12 Jul 96 12:41 EDT Received: by relay.tis.com; id MAA20414; Fri, 12 Jul 1996 12:43:50 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020408; Fri, 12 Jul 96 12:43:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02354; Fri, 12 Jul 96 12:43:09 EDT Received: by relay.tis.com; id MAA20404; Fri, 12 Jul 1996 12:43:20 -0400 Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.tis.com via smap (V3.1.1) id xma020394; Fri, 12 Jul 96 12:43:18 -0400 Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1) id AA17005; Fri, 12 Jul 96 12:45:49 EDT Date: Fri, 12 Jul 96 12:45:49 EDT From: "Michael J. Oehler" Message-Id: <9607121645.AA17005@tarius.tycho.ncsc.mil> To: ipsec@TIS.COM Subject: IPSEC Implementation Availability Announcement Sender: ipsec-approval@neptune.tis.com Precedence: bulk The NIST/NSA IPSEC implementation is now available for distribution. The software is distributed on an "AS IS" basis. There is no implied warranty on part of the US Government. If you would like to obtain a copy, please notify me. I will fax our release form. An appropriate representative from your company must sign it, and return it to me. The form states that the software was developed as a research project and is given to you "AS IS". Thus, the software is not considered Government-Furnished Equipment (GFE) or cannot be used as justification for a cost extension to any US Government contract. You may re-distributed the software so long as the ackownledgement and the software's notice appears. The prototype contains DES CBC, MD5, and SHA source code. Department of Commerce and State Department export control laws apply and hence the prototype may only be distributed within the US. Developer's Profile: Name of Implementation: NIST/NSA IPSEC Prototype Security Protocols: ESP (RFC1827), AH (RFC1826) Security Transforms: ESP-DES (RFC1829), AH-MD5 (RFC1828), AH-HMAC-MD5, AH-HMAC-SHA Key Management: Manual and (soon) automated via PF_SADB interface Platforms: BSD/OS, NetBSD, FreeBSD, DTOS Notes: Prototype development on-going Host Keying only Lineage of Code: Developed by NIST and NSA. Location of Source Code: Contact Michael Oehler (see below). Point of Contact: Rob Glenn, Rob.Glenn@nist.gov, Michael Oehler, mjo@tycho.ncsc.mil Michael Oehler Atn: R23 INFOSEC Research and Development 9800 Savage Road Fort George Meade, Maryland 20755-6534 V: (301) 688-0849 F: (301) 688-0255 Received: from relay.tis.com by neptune.TIS.COM id aa17296; 12 Jul 96 12:58 EDT Received: by relay.tis.com; id NAA20934; Fri, 12 Jul 1996 13:00:20 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020913; Fri, 12 Jul 96 12:59:54 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06040; Fri, 12 Jul 96 12:59:39 EDT Received: by relay.tis.com; id MAA20902; Fri, 12 Jul 1996 12:59:50 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma020890; Fri, 12 Jul 96 12:59:22 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id KAA28197 for ipsec@tis.com; Fri, 12 Jul 1996 10:01:52 -0700 Date: Fri, 12 Jul 1996 10:01:52 -0700 From: Ran Atkinson Message-Id: <199607121701.KAA28197@puli.cisco.com> To: ipsec@TIS.COM Subject: July/96 IPsec Implementation Status Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, Appended below is the current IPsec Implementation Status summary as best I am aware of it. I suspect that there might be additional implementations or updated interoperability information out there that isn't yet reflected in this summary. So I'd like to ask that implementers check their entry and send me any updated information. I expect to reissue this summary with revised/updated data early next week (week of July 15th). Thanks, Ran rja@cisco.com Co-Chair, IPsec WG ---------------------------------------------------------------------- This is the IETF IPsec WG Implementation Status as of 12 July 1996. There are 8 known freely distributable implementations (listed first) and 10 known commercial/proprietary implementations (listed afterwards). Some of the listed implementations are "planned" or "in progress". Not all implementations include all of the IETF IPsec specifications and/or proposals. Claimed interoperability is also listed. Not all implementations have been tested against each other, so not listing interoperability might mean that the implementations were never tested against each other. Paul Lambert Randall Atkinson Co-Chairs of the IP Security WG Internet Engineering Task Force Here is the list of freely distributable IPsec implementations: _______________________________________________________________________ Name of Implementation: x-Kernel IPsec Organisation: Univ. of Arizona, Dept of CS IP versions: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual, Photuris (draft 8, Elliptical curves) Platforms: x-Kernel (U of AZ's research OS) Lineage of IPsec Code: University of Arizona Lineage of Key Mgmt Code: University of Arizona Location of Source Code: ftp://ftp.cs.arizona.edu/xkernel/ xkernel.v3.2.security.tar.Z Point of Contact: Hilarie Orman Claimed Interoperability: KA9Q NOS (AH MD5, ESP DES), JI (Photuris, AH MD5) _______________________________________________________________________ Name of Implementation: ENskip Organisation: ETH Zurich Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): Partial (SPI == 1 only) ESP (RFC-1825,1827): Partial (SPI == 1 only) AH MD5 (RFC-1828): YES, with 128, 64, & 32 bit keys ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES, ESP-IDEA, ESP-RC4 Key Management: SKIP (draft 6) Platforms: Solaris 2.4+, IRIX (version ??), NetBSD, Nextstep Lineage of IPsec Code: ETH Zurich Lineage of Key Mgmt Code: ETH Zurich Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip Point of Contact: Claimed Interoperability: Sun SKIP _______________________________________________________________________ Name of Implementation: ISAKMP with Oakley Extensions Key Mgmt Daemon Organisation: cisco Systems Which IP versions are supported: IPv4 and IPv6 Implemented Features: AH (RFC-1825,1826): Not applicable ESP (RFC-1825,1827): Not applicable AH MD5 (RFC-1828): Not applicable ESP DES (RFC-1829): Not applicable Other AH Transforms: Not applicable Other ESP Transforms: Not applicable Key Management: ISAKMP with Oakley Extensions Platforms: Any system with the NRL PF_KEY key management API Lineage of IPsec Code: not applicable Lineage of Key Mgmt Code: cisco Systems Location of Source Code: http://web.mit.edu/network/isakmp/ http://www.cisco.com/public/library/isakmp.html Note: Patent issues have been taken care of by cisco. Point of Contact: Dan Harkins Public Mailing List: Claimed Interoperability: (UK) DRA Malvern's ISAKMP as of ISAKMP draft 4. _______________________________________________________________________ Name of Implementation: ISI/USC Organisation: Information Sciences Institute, USC Which IP versions are supported: IPv4 AH (RFC-1825,1826): YES ESP (RFC-1825,1827): NO AH MD5 (RFC-1828): YES ESP DES (RFC-1829): NO Other AH Transforms: checksum, proprietary Other ESP Transforms: none Key Management: staticly configured Platforms: BSD Lineage of IPsec Code: Both NRL-derived and ISI-developed Lineage of Key Mgmt Code: not applicable Location of Source Code: (expected March 1996) Point of Contact: Joe Touch Claimed Interoperability: _______________________________________________________________________ Name of Implementation: JI's IPsec Organisation: John Ioannidis Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: HMAC MD5 in progress ??? Other ESP Transforms: none Key Management: manual, Photuris (which draft ?) in progress, PF_ENCAP keying interface, PF_ROUTE extensions Platforms: BSD/OS 2.0 Lineage of IPsec Code: JI Lineage of Key Mgmt Code: Angelos ?? Location of Source Code: (??) ftp://ftp.ripe.net/ Point of Contact: John Ioannidis Claimed Interoperability: _______________________________________________________________________ Name of Implementation: KA9Q NOS Organisation: Phil Karn Which IP versions are supported: IPv4 AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual Platforms: DOS with KA9Q NOS Lineage of IPsec Code: Phil Karn Lineage of Key Mgmt Code: not applicable Location of Source Code: (available soon) Point of Contact: Phil Karn Claimed Interoperability: _______________________________________________________________________ Name of Implementation: NIST/NSA IPSEC Prototype Organisation: NIST & NSA Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-SHA, AH-HMAC-MD5 Other ESP Transforms: Key Management: manual, PF_SADB interface Platforms: BSD/OS, NetBSD, FreeBSD, DTOS Lineage of IPsec Code: NIST & NSA Lineage of Key Mgmt Code: NIST & NSA Location of Source Code: (US-only expected March 1996) Point of Contact: Rob Glenn, Rob.Glenn@nist.gov, Michael Oehler, mjo@tycho.ncsc.mil, (301) 688-0849 Claimed Interoperability: TBD ________________________________________________________________________ Name of Implementation: NRL IPv6/IPsec Software Distribution Organisation: Naval Research Laboratory (NRL) Which IP versions are supported: IPv4 and IPv6 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-MD5, AH-HMAC-SHA Other ESP Transforms: DES-CBC-MD5-Replay is planned. Key Management: manual, PF_KEY Key Management API, includes cisco's ISAKMP+Oakley daemon. Platforms: any 4.4-Lite BSDish system, NetBSD, BSDI, 4.4 BSD Lineage of IPsec Code: NRL, with some AH transforms contributed by NIST Lineage of Key Mgmt Code: cisco Systems Location of Source Code: US: ftp://ftp.c2.org (see file "pub/README.US-only") US: http://web.mit.edu/network/isakmp US/Canada: http://www.cisco.com/public/library/ipsec.html Europe: ftp://ftp.ripe.net/ipv6/nrl/ Point of Contact: Claimed Interoperability: (all are for ESP DES, AH MD5) Ascend, V-One, TIS, IBM, KA9Q, & NRL-derived implementations _______________________________________________________________________ Name of Implementation: Sun SKIP Organisation: Sun Microsystems' Internet Commerce Group (Sun ICG) Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): in progress ESP (RFC-1825,1827): in progress AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: SKIP Platforms: SunOS 4.1.x Lineage of IPsec Code: Sun ICG Lineage of Key Mgmt Code: Sun ICG Location of Source Code: http://skip.incog.com Point of Contact: Tom Markson Claimed Interoperability: ETH Zurich's EnSKIP, Elvis SKIP Here is the list of commercial/proprietary IETF IPsec implementations: ________________________________________________________________________ Name of Implementation: AccessSecure Organisation: Ascend Communications Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES, with variable length keys ESP DES (RFC-1829): YES, 32-bit or 64-bit IV Other AH Transforms: none Other ESP Transforms: none Key Management: manual Platforms: Ascend Pipeline and Max routers Lineage of IPsec Code: Ascend (was MorningStar) Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Karl Fox Claimed Interoperability: NRL, Checkpoint, IBM, NIST, Raptor, Secure Computing, SOS, TimeStep, TIS, Gemini, KA9Q NOS _______________________________________________________________________ Name of Implementation: ERP IPSEC Organisation: Bellcore Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES, with 128, 64, & 32 bit keys ESP DES (RFC-1829): YES Other implemented AH transforms: none Other implemented ESP transforms: none Key Management: manual Platforms: ??? Lineage of IPsec Code: ??? Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Antonio Fernandez Claimed Interoperability: _______________________________________________________________________ Name of Implementation: cisco IOS (TM) Organisation: cisco Systems Which IP versions are supported: IPv4 & IPv6 in progress Implemented Features: AH (RFC-1825,1826): In Progress ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): In Progress ESP DES (RFC-1829): In Progress Other implemented AH transforms: AH-HMAC-MD5 & AH-HMAC-SHA in progress. Other implemented ESP transforms: ESP-DES-MD5-Replay in progress, proprietary DES transform. Key Management: proprietary now; ISAKMP+Oakley 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 Claimed Interoperability: TBA ________________________________________________________________________ Name of Implementation: OnNet Organisation: ftp Software Which IP versions are supported: IPv4 now, IPv6 planned Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: none Key Management: manual now; ISAKMP+Oakley is planned. Platforms: Windows95, Windows 3.11 Lineage of IPsec Code: FTP Software; referenced but didn't port the NRL software. Lineage of Key Mgmt Code: FTP Software; referenced but didn't port the NRL software. Plan to port cisco's ISAKMP+Oakley code. Location of Source Code: proprietary Point of Contact: Naganand Doraswamy Claimed Interoperability: Raptor, SCC, IBM, & TIS now; testing with NRL is in progress. _______________________________________________________________________ Name of Implementation: Trusted Security Firewall-Guard (GTFW-GD) Organisation: Gemini Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-SHA, proprietary Other ESP Transforms: none Key Management: manual, proprietary Platforms: Gemini Trusted Firewall-Guard Lineage of IPsec Code: Gemini Lineage of Key Mgmt Code: Gemini Location of Source Code: Proprietary Point of Contact: Dr. Tien F. Tao Claimed Interoperability: IBM SNG, MorningStar, NIST, Raptor Systems, SCC, SOS, TIS _______________________________________________________________________ Name of Implementation: IBM SNG Organisation: IBM Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES, both 32-bit & 64-bit IV Other AH Transforms: HMAC MD5 Other ESP Transforms: none Key Management: manual, proprietary Platforms: IBM AIX Lineage of IPsec Code: IBM Lineage of Key Mgmt Code: IBM Location of Source Code: proprietary Point of Contact: Claimed Interoperability: For ESP-DES & AH-MD5: NRL, JI, KA9Q, NIST, TIS, Checkpoint, SOS, Gemini, MorningStar, Raptor, SCC, TimeStep For ESP-DES & HMAC MD5: NIST, Raptor _______________________________________________________________________ Name of Implementation: SafeNet Organisation: Information Resources Engineering, Inc. Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): Planned ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): Planned ESP DES (RFC-1829): In Progress Other AH Transforms: none Other ESP Transforms: DES-Counter-ANSI-X9.9 Key Management: SKIP in progress; various ANSI in progress Platforms: V.34 modem, IP over PPP, Ethernet Lineage of IPsec Code: Information Resources Engineering Lineage of Key Mgmt Code: Information Resources Engineering Location of Source Code: proprietary Point of Contact: Claimed Interoperability: TBA _______________________________________________________________________ Name of Implementation: BorderGuard and Security Router Organisation: Network Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): TBD ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): TBD ESP DES (RFC-1829): TBD Other AH Transforms: none Other ESP Transforms: ESP-DES-MD5-Replay in progress Key Management: manual, proprietary D-H are done now. ISAKMP+Oakley is in progress. Platforms: Network Systems routers Lineage of IPsec Code: Network Systems Lineage of Key Mgmt Code: Network Systems Location of Source Code: proprietary Point of Contact: Ted Doty Claimed Interoperability: TBD _______________________________________________________________________ Name of Implementation: Eagle Organisation: Raptor Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-MD5 Other ESP Transforms: DES-CBC-MD5-Replay is planned Key Management: manual, proprietary Platforms: Raptor Eagle Firewall Lineage of IPsec Code: Raptor Lineage of Key Mgmt Code: proprietary Location of Source Code: proprietary Point of Contact: Jeff Kraemer Claimed Interoperability: FTP Software, IBM SNG, MorningStar, NIST, Secure Computing, SOS, TimeStep, TIS, Gemini ______________________________________________________________________ Name of Implementation: Sidewinder Firewall Organisation: Secure Computing Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: none Key Management: manual Platforms: Sidewinder Firewall Lineage of IPsec Code: ??? Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Troy de Jongh (dejongh@sctc.com) Claimed Interoperability: _______________________________________________________________________ Name of Implementation: PERMIT Organisation: TimeStep Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: none Key Management: manual, proprietary Platforms: TimeStep Lineage of IPsec Code: ??? Lineage of Key Mgmt Code: TimeStep ??? Location of Source Code: proprietary Point of Contact: Stephane Lacelle Claimed Interoperability: _______________________________________________________________________ Name of Implementation: TIS Gauntlet Organisation: Trusted Information Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual, proprietary Platforms: TIS Gauntlet Lineage of IPsec Code: NRL-derived Lineage of Key Mgmt Code: TIS ??? Location of Source Code: proprietary Point of Contact: Rick Murphy, rick@tis.com Claimed Interoperability: NRL _______________________________________________________________________ Name of Implementation: V-ONE SmartWall Organisation: V-One Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES, RC4, stream DES Key Management: manual, proprietary Platforms: V-ONE SmartWall Lineage of IPsec Code: NRL-derived Lineage of Key Mgmt Code: V-One ??? Location of Source Code: proprietary Point of Contact: Jason Wang Claimed Interoperability: NRL ______________________________________________________________________ Received: from relay.tis.com by neptune.TIS.COM id aa27065; 15 Jul 96 9:23 EDT Received: by relay.tis.com; id JAA18822; Mon, 15 Jul 1996 09:26:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018811; Mon, 15 Jul 96 09:25:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01360; Mon, 15 Jul 96 09:25:08 EDT Received: by relay.tis.com; id JAA18784; Mon, 15 Jul 1996 09:25:00 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1.1) id xma018774; Mon, 15 Jul 96 09:24:41 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10915; 15 Jul 96 9:22 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-01.txt Date: Mon, 15 Jul 96 09:22:25 -0400 Message-Id: <9607150922.aa10915@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC-SHA IP Authentication with Replay Prevention Author(s) : S. Chang, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-sha-01.txt Pages : 7 Date : 07/12/1996 This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. 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-sha-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960712170030.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-sha-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960712170030.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa27064; 15 Jul 96 9:23 EDT Received: by relay.tis.com; id JAA18820; Mon, 15 Jul 1996 09:26:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018810; Mon, 15 Jul 96 09:25:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01364; Mon, 15 Jul 96 09:25:03 EDT Received: by relay.tis.com; id JAA18785; Mon, 15 Jul 1996 09:25:01 -0400 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1.1) id xma018773; Mon, 15 Jul 96 09:24:41 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10976; 15 Jul 96 9:22 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-01.txt Date: Mon, 15 Jul 96 09:22:43 -0400 Message-Id: <9607150922.aa10976@IETF.CNRI.Reston.VA.US> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC-MD5 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-01.txt Pages : 7 Date : 07/12/1996 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 [HMAC-MD5]. An option is also specified to guard against replay attacks. 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960712170309.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960712170309.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa05837; 17 Jul 96 1:23 EDT Received: by relay.tis.com; id BAA11975; Wed, 17 Jul 1996 01:26:03 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011973; Wed, 17 Jul 96 01:25:34 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08282; Wed, 17 Jul 96 01:25:17 EDT Received: by relay.tis.com; id BAA11970; Wed, 17 Jul 1996 01:25:33 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma011968; Wed, 17 Jul 96 01:25:09 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id WAA28532; Tue, 16 Jul 1996 22:26:31 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA07071; Tue, 16 Jul 1996 22:14:46 -0700 Message-Id: <9607170514.AA07071@maildig1.us.oracle.com> Date: Tue, 16 Jul 1996 22:14:46 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: Authentication using ESP in Transport Mode X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 10-Jul-96 13:07 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-22345810-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-22345810-0-0 >Gee, I hope not. ESP directly inside ESP is bogus. > >Ran Hummm ... no, ESP inside ESP should be a fairly common case when two workstations with ESP communicate through two encrypting firewalls using ESP. I assume that you were thinking of ESP inside ESP with no intermedate encrypting systems as a bogus example... Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --Boundary-22345810-0-0 Content-Type: message/rfc822 Date: 10 Jul 96 13:07:31 From:"Ran Atkinson " To: ipsec@tis.com Subject: Re: Authentication using ESP in Transport Mode X-Orcl-Application: Newsgroups: cisco.external.ietf.ipsec X-Orcl-Application: In-Reply-To: <9607101438.AA00827@wellspring.us.dg.com> X-Orcl-Application: Organization: cisco Systems, Inc., Menlo Park, Ca. X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk Someone wrote: >The packets would be: > > IPv4 ...outer header as it travels the net > AH ...is this needed? > ESP ...for firewall/tunnel > ESP ...for remote to internal node > original TCP/UDP/etc. ...real data. I don't think so. I was thinking more like: IP (source=outside firewall, dest=firewall) ESP with combined transform IP (source=outside firewall, dest=inner destination) AH alone OR ESP with combined transform inner IP/TCP, IP/UDP, TCP, UDP, etc. >Has anyone implemented this? My description above is implemented by the NRL source code if one configures a "secure IPv4 tunnel" for the outer path and also the user requests ESP tunnel-mode on the original packet. >Are we really really sure any existing implementations correctly allow ESP >inside ESP? Gee, I hope not. ESP directly inside ESP is bogus. Ran rja@inet.org --Boundary-22345810-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa12662; 17 Jul 96 9:35 EDT Received: by relay.tis.com; id JAA18557; Wed, 17 Jul 1996 09:38:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018540; Wed, 17 Jul 96 09:38:07 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20506; Wed, 17 Jul 96 09:37:40 EDT Received: by relay.tis.com; id JAA18532; Wed, 17 Jul 1996 09:37:55 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma018512; Wed, 17 Jul 96 09:37:26 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id JAA10082; Wed, 17 Jul 1996 09:42:19 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id JAA29879; Wed, 17 Jul 1996 09:41:35 -0400 Date: Wed, 17 Jul 1996 09:41:35 -0400 From: Hilarie Orman Message-Id: <199607171341.JAA29879@earth.hpc.org> To: PALAMBER@us.oracle.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <9607170514.AA07071@maildig1.us.oracle.com> Subject: Re: Authentication using ESP in Transport Mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk > >Gee, I hope not. ESP directly inside ESP is bogus. > > > >Ran > Hummm ... no, ESP inside ESP should be a fairly common case when two > workstations with ESP communicate through two encrypting firewalls using ESP. > I assume that you were thinking of ESP inside ESP with no intermedate > encrypting systems as a bogus example... ESP followed by ESP is non-bogus wrt the architecture and ESP docs. I've always thought this was deliberate and a good idea because it allowed ESP to be used to define orthogonal services. And while double encryption might be inefficient (as in the firewall case), surely no one would want to prohibit it (firewall would discard outgoing ESP packets?!). Received: from relay.tis.com by neptune.TIS.COM id aa15909; 17 Jul 96 11:43 EDT Received: by relay.tis.com; id LAA22589; Wed, 17 Jul 1996 11:45:58 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022576; Wed, 17 Jul 96 11:45:33 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01045; Wed, 17 Jul 96 11:45:14 EDT Received: by relay.tis.com; id LAA22570; Wed, 17 Jul 1996 11:45:29 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma022565; Wed, 17 Jul 96 11:45:27 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id IAA02481; Wed, 17 Jul 1996 08:47:55 -0700 Date: Wed, 17 Jul 1996 08:47:55 -0700 From: Ran Atkinson Message-Id: <199607171547.IAA02481@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: Authentication using ESP in Transport Mode In-Reply-To: <9607170514.AA07071@maildig1.us.oracle.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk Earlier, Ran wrote: >>Gee, I hope not. ESP directly inside ESP is bogus. >> >>Ran In article <9607170514.AA07071@maildig1.us.oracle.com> Paul wrote: > >Hummm ... no, ESP inside ESP should be a fairly common case when two >workstations with ESP communicate through two encrypting firewalls using ESP. > >I assume that you were thinking of ESP inside ESP with no intermedate >encrypting systems as a bogus example... > > >Paul Paul, I believe there was a communication gap, rather than a substantive technical difference between what you mention and what I said. Referring back to the original set of notes below, please examine the area I've marked at the left margin with "*" first to make clear what my comment quoted above was referring to. It is bogus for a packet to be of the form: [IP, s->d][ESP][ESP][ULP or IP] The case you mention (End-to-End encryption while traversing an encrypted tunnel between two intermediate systems (e.g. routers or firewalls)) will have tunnel-mode ESP packets of the form: [IP, fw1->fw2][ESP][IP, s->d][ESP][ULP or IP] where: fw1,fw2 are addresses of the intermediate encryptors and the arrow separates the source from the destination. s,d are the ultimate source and destination workstations that are also ESP-capable. ULP == upper-layer protocol (e.g. TCP, UDP, ICMP) Regards, Ran rja@cisco.com >--Boundary-22345810-0-0 >Content-Type: message/rfc822 > >Date: 10 Jul 96 13:07:31 >From:"Ran Atkinson " >To: ipsec@tis.com >Subject: Re: Authentication using ESP in Transport Mode >X-Orcl-Application: Newsgroups: cisco.external.ietf.ipsec >X-Orcl-Application: In-Reply-To: <9607101438.AA00827@wellspring.us.dg.com> >X-Orcl-Application: Organization: cisco Systems, Inc., Menlo Park, Ca. >X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com >X-Orcl-Application: Precedence: bulk > > >Someone wrote: >>The packets would be: >> * IPv4 ...outer header as it travels the net * AH ...is this needed? * ESP ...for firewall/tunnel * ESP ...for remote to internal node * original TCP/UDP/etc. ...real data. > >I don't think so. I was thinking more like: > > IP (source=outside firewall, dest=firewall) > ESP with combined transform > IP (source=outside firewall, dest=inner destination) > AH alone OR ESP with combined transform > inner IP/TCP, IP/UDP, TCP, UDP, etc. > >>Has anyone implemented this? > >My description above is implemented by the NRL source code if one configures a >"secure IPv4 tunnel" for the outer path and also the user requests ESP >tunnel-mode on the original packet. > >>Are we really really sure any existing implementations correctly allow ESP >>inside ESP? > >Gee, I hope not. ESP directly inside ESP is bogus. > >Ran >rja@inet.org > > > >--Boundary-22345810-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa28696; 17 Jul 96 22:08 EDT Received: by relay.tis.com; id WAA07494; Wed, 17 Jul 1996 22:10:55 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007492; Wed, 17 Jul 96 22:10:28 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10186; Wed, 17 Jul 96 22:10:09 EDT Received: by relay.tis.com; id WAA07489; Wed, 17 Jul 1996 22:10:25 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma007487; Wed, 17 Jul 96 22:10:14 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id TAA21495; Wed, 17 Jul 1996 19:12:41 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA06796; Wed, 17 Jul 1996 19:03:56 -0700 Message-Id: <9607180203.AA06796@maildig1.us.oracle.com> Date: Wed, 17 Jul 1996 19:03:56 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: US Patent 5,511,122 X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 11-Jul-96 11:10 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-22397859-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-22397859-0-0 >The patent might affect a (hypothetical) AH >transform proposal that used cryptographic digital >signatures based on asymmetric cryptography (e.g. an >RSA digital signature), as distinguished from >all current standards-track documents and online >proposals (which I believe all use keyed one-way >cryptographic hash functions). There were e-mail and verbal proposals for asymmetric signatures on and off in the working roup from the begining. Hilarie has broght up this topic at many meetings ... So Ran, are you saying that you patented the use of asymmetric algorithms as IPsec security transforms (AH or ESP)? Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Now hiring, send resumes to: rwessman@us.oracle.com !!! -------------------------------------------------------------- --Boundary-22397859-0-0 Content-Type: message/rfc822 Date: 11 Jul 96 11:10:18 From:"Ran Atkinson " To: jis@mit.edu Subject: US Patent 5,511,122 Cc: ipsec@tis.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com X-Orcl-Application: Precedence: bulk To: Jeff Schiller, Security Area Director, IETF, From: Randall Atkinson, Subject: Notification of patent I have just been officially notified that US Patent 5, 511, 122 on "Intermediate Network Authentication" was issued to me on 23 April 1996 with all rights assigned to The United States of America as represented by the Secretary of the Navy. The filing date on this patent is 3 June 1994 and the work was begun in 1991. The funded project work behind this patent was unrelated to IPsec and primarily related to a need for intermediate network authentication of datagrams in a network that performed intermediate fragmentation of datagrams. I am not a lawyer and I am not making any kind of legal representation, but I believe that this patent DOES NOT create any issues with respect to current IPsec RFCs or any current IPsec draft that I am aware of or any other IETF standard that I'm aware of. The patent might affect a (hypothetical) AH transform proposal that used cryptographic digital signatures based on asymmetric cryptography (e.g. an RSA digital signature), as distinguished from all current standards-track documents and online proposals (which I believe all use keyed one-way cryptographic hash functions). -- --Boundary-22397859-0-0-- Received: from relay.tis.com by neptune.TIS.COM id aa00175; 17 Jul 96 23:48 EDT Received: by relay.tis.com; id XAA08277; Wed, 17 Jul 1996 23:51:26 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008275; Wed, 17 Jul 96 23:50:57 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11984; Wed, 17 Jul 96 23:50:39 EDT Received: by relay.tis.com; id XAA08272; Wed, 17 Jul 1996 23:50:56 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma008270; Wed, 17 Jul 96 23:50:36 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id UAA19753; Wed, 17 Jul 1996 20:53:03 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id UAA16798; Wed, 17 Jul 1996 20:56:26 -0700 Message-Id: <199607180356.UAA16798@mailsun2.us.oracle.com> Date: 17 Jul 96 20:50:08 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: Re: Authentication using ESP in Transport Mode X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 17-Jul-96 08:47 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.0.35) Content-Type: multipart/mixed; boundary="=_ORCL_5921400_0_11919607172157270" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_5921400_0_11919607172157270 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Ran, >Paul, > > I believe there was a communication gap, >.... There was no communication gap, I was disagreeing with your statement: > It is bogus for a packet to be of the form: > [IP, s->d][ESP][ESP][ULP or IP] There was a head space gap. Thanks for leaving me a possible out... but I'm wrong. ESP over ESP is not totally bogus, but the example of two hosts going through two firewalls is most easily handled by: [IP, fw1->fw2][ESP][IP, s->d][ESP][ULP] ... as you pointed out. You can get tricky at firewalls and could get rid of the inner IP. This has not been discussed much on the IPsec list and requires red-side reassembly of packet fragments. This also requires the use of the inner SPI to map incoming packets to a source / destination address pair. This would need to be a Firewall "enhancement" that would require special negotiations or SPI conventions to establish. So, it is much easier to just use the ESP-IP-ESP sandwich for the dual firewall example. ESP over ESP still should be allowed... we should not limit the creative use of multiple layers of security encapsulation. Regards, Paul PS - also thanks Steve K. for keeping me honest on this :-) -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_5921400_0_11919607172157270 Content-Type:message/rfc822 Date: 17 Jul 96 08:47:55 From:"Ran Atkinson " To:ipsec@tis.com Subject:Re: Authentication using ESP in Transport Mode X-Orcl-Application:In-Reply-To: <9607170514.AA07071@maildig1.us.oracle.com> X-Orcl-Application:Organization: cisco Systems, Inc., Menlo Park, Ca. X-Orcl-Application:Sender: ipsec-approval@neptune.tis.com X-Orcl-Application:Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Earlier, Ran wrote: >>Gee, I hope not. ESP directly inside ESP is bogus. >> >>Ran In article <9607170514.AA07071@maildig1.us.oracle.com> Paul wrote: > >Hummm ... no, ESP inside ESP should be a fairly common case when two >workstations with ESP communicate through two encrypting firewalls using ESP. > >I assume that you were thinking of ESP inside ESP with no intermedate >encrypting systems as a bogus example... > > >Paul Paul, I believe there was a communication gap, rather than a substantive technical difference between what you mention and what I said. Referring back to the original set of notes below, please examine the area I've marked at the left margin with "*" first to make clear what my comment quoted above was referring to. It is bogus for a packet to be of the form: [IP, s->d][ESP][ESP][ULP or IP] The case you mention (End-to-End encryption while traversing an encrypted tunnel between two intermediate systems (e.g. routers or firewalls)) will have tunnel-mode ESP packets of the form: [IP, fw1->fw2][ESP][IP, s->d][ESP][ULP or IP] where: fw1,fw2 are addresses of the intermediate encryptors and the arrow separates the source from the destination. s,d are the ultimate source and destination workstations that are also ESP-capable. ULP == upper-layer protocol (e.g. TCP, UDP, ICMP) Regards, Ran rja@cisco.com >--Boundary-22345810-0-0 >Content-Type: message/rfc822 > >Date: 10 Jul 96 13:07:31 >From:"Ran Atkinson " >To: ipsec@tis.com >Subject: Re: Authentication using ESP in Transport Mode >X-Orcl-Application: Newsgroups: cisco.external.ietf.ipsec >X-Orcl-Application: In-Reply-To: <9607101438.AA00827@wellspring.us.dg.com> >X-Orcl-Application: Organization: cisco Systems, Inc., Menlo Park, Ca. >X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com >X-Orcl-Application: Precedence: bulk > > >Someone wrote: >>The packets would be: >> * IPv4 ...outer header as it travels the net * AH ...is this needed? * ESP ...for firewall/tunnel * ESP ...for remote to internal node * original TCP/UDP/etc. ...real data. > >I don't think so. I was thinking more like: > > IP (source=outside firewall, dest=firewall) > ESP with combined transform > IP (source=outside firewall, dest=inner destination) > AH alone OR ESP with combined transform > inner IP/TCP, IP/UDP, TCP, UDP, etc. > >>Has anyone implemented this? > >My description above is implemented by the NRL source code if one configures a >"secure IPv4 tunnel" for the outer path and also the user requests ESP >tunnel-mode on the original packet. > >>Are we really really sure any existing implementations correctly allow ESP >>inside ESP? > >Gee, I hope not. ESP directly inside ESP is bogus. > >Ran >rja@inet.org > > > >--Boundary-22345810-0-0-- --=_ORCL_5921400_0_11919607172157270-- Received: from relay.tis.com by neptune.TIS.COM id aa23098; 17 Jul 96 16:08 EDT Received: by relay.tis.com; id QAA01608; Wed, 17 Jul 1996 16:10:35 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001601; Wed, 17 Jul 96 16:10:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27810; Wed, 17 Jul 96 16:09:51 EDT Received: by relay.tis.com; id QAA01598; Wed, 17 Jul 1996 16:10:05 -0400 Received: from winnie.fit.edu(163.118.5.1) by relay.tis.com via smap (V3.1.1) id xma001590; Wed, 17 Jul 96 16:09:44 -0400 Received: from [163.118.110.8] (krist.sci-ed.fit.edu [163.118.110.8]) by Message-ID: <9607180753.aa06797@neptune.TIS.COM> winnie.fit.edu (8.7.5/8.6.11) with SMTP id QAA23069 for ; Wed, 17 Jul 1996 16:19:41 -0400 (EDT) Date: Wed, 17 Jul 1996 16:19:41 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@TIS.COM From: Steve Nordmark Subject: Removal from List Sender: ipsec-approval@neptune.tis.com Precedence: bulk I realize this is not the appropriate format for this request, but I wish to discontinue my participation in this list. I would appreciate receiving the proper address to submit my unsubscribe request. Thank you for your indulgence, Steven G. Nordmark (snordmar@fit.edu) Research Assistant/Mathematics Education Florida Institute of Technology 150 W. University Blvd. Melbourne, FL 32901 Received: from relay.tis.com by neptune.TIS.COM id aa13314; 18 Jul 96 13:57 EDT Received: by relay.tis.com; id NAA23078; Thu, 18 Jul 1996 13:59:36 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023071; Thu, 18 Jul 96 13:59:09 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13672; Thu, 18 Jul 96 13:58:50 EDT Received: by relay.tis.com; id NAA23066; Thu, 18 Jul 1996 13:59:06 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma023057; Thu, 18 Jul 96 13:58:55 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id LAA27178; Thu, 18 Jul 1996 11:01:22 -0700 Date: Thu, 18 Jul 1996 11:01:22 -0700 From: Ran Atkinson Message-Id: <199607181801.LAA27178@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: US Patent 5,511,122 In-Reply-To: <9607180203.AA06796@maildig1.us.oracle.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9607180203.AA06796@maildig1.us.oracle.com> Paul wrote: >So Ran, are you saying that you patented the use of asymmetric algorithms as >IPsec security transforms (AH or ESP)? I did not say that. Please don't put words into my mouth. The work patented predates the existence of the IPsec WG and even predates the very first IPsec BOF held in Cambridge adjacent to MIT in 1992. It does not mention or cite IPsec at all. I mentioned it only for completeness. I don't have it in electronic form that I can grep through to be sure, but I don't think it mentions the word 'encryption' either. As the title implies, its a patent on a particular technique for "Intermediate Network Authentication", with the particular focus being how to authenticate - at an intermediate node - datagrams that.might be fragmented during transit in a datagram network having dynamic packet routing. Ran rja@cisco.com Received: from relay.tis.com by neptune.TIS.COM id aa28918; 19 Jul 96 9:04 EDT Received: by relay.tis.com; id JAA09879; Fri, 19 Jul 1996 09:06:20 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009857; Fri, 19 Jul 96 09:05:52 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24633; Fri, 19 Jul 96 09:05:32 EDT Received: by relay.tis.com; id JAA09850; Fri, 19 Jul 1996 09:05:50 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma009830; Fri, 19 Jul 96 09:05:20 -0400 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for ns.tis.com [192.94.214.100]) with SMTP; 19 Jul 1996 13:07:43 UT Received: from midwest.raptor.com (foghorn.raptor.com [204.7.242.8]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id JAA06357 for ; Fri, 19 Jul 1996 09:07:10 -0400 (EDT) Message-Id: <2.2.32.19960718094448.0069533c@raptor1> X-Sender: jtardo@raptor1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jul 1996 05:44:48 -0400 To: ipsec@TIS.COM From: Joe Tardo Subject: Key Management, anyone? Sender: ipsec-approval@neptune.tis.com Precedence: bulk What's going on with key management? Are there key management mailing lists, perhaps? Let me stimulate some discussion. Looking at the ISAKMP drafts, there are a number of inconsistencies in interpretation, not just what the fields are supposed to mean, but whether or not you have to even send them. Example: Auxiliary SPI's (interpretation depends on DOI, message in sequence, whether it's a leap year, phase of moon, what else?). The whole use of DOI's per SA is kind of confusing. What are the "mix-and-match" rules? Envelopes? Sound convenient, but then, if I want to communicate an SPI under negotiation, I have to use one. But, maybe not (cisco draft), if the SPI value is 0 anyway. The three flavors of Internet DOI (annex A, Oakley, cisco) clearly aren't interoperable yet. Authentication is also kind of messed up. Why does every CA need a registered number even though all x.509 certificates are self- describing as to CA and even algorithms? Why does Oakley think that DNSSEC is ever going to take off? Making something so tentative mandatory is a shot in the foot. Besides, DNSSEC doesn't solve the problem (who's going to administer it? what about dhcp or PPP dynamic addressing?) How does one introduce other certificate formats, like SPKI, without issuing a new rfc? All of this is fixable, of course. Where are these issues being discussed? Thanks, Joe Received: from relay.tis.com by neptune.TIS.COM id aa01163; 19 Jul 96 11:08 EDT Received: by relay.tis.com; id LAA14689; Fri, 19 Jul 1996 11:10:31 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014681; Fri, 19 Jul 96 11:10:04 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01574; Fri, 19 Jul 96 11:09:44 EDT Received: by relay.tis.com; id LAA14672; Fri, 19 Jul 1996 11:10:01 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma014657; Fri, 19 Jul 96 11:09:39 -0400 Received: from research.research.att.com by ns; Fri Jul 19 11:09:28 EDT 1996 Received: from raptor.research.att.com by research; Fri Jul 19 11:06:07 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id LAA10734; Fri, 19 Jul 1996 11:06:07 -0400 (EDT) Message-Id: <199607191506.LAA10734@raptor.research.att.com> To: Joe Tardo Cc: ipsec@TIS.COM Subject: Re: Key Management, anyone? Date: Fri, 19 Jul 1996 11:06:07 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Why does Oakley think that DNSSEC is ever going to take off? Making something so tentative mandatory is a shot in the foot. Besides, DNSSEC doesn't solve the problem (who's going to administer it? what about dhcp or PPP dynamic addressing?) These are very valid points. Unfortunately, in my opinion DNSSEC is utterly mandatory for *any* type of key management for IPSEC. Suppose I want to establish a secure connection to plugh.com. My application -- say, telnet -- will ask the DNS for the IP address, and then do the socket() and the connect() operations. Deep in the bowels of the kernel, something in the protocol stack will realize that (a) the connection must be secure, and (b) it doesn't have a key. So it asks the key management daemon to negotiate a session key -- but the parameter passed via the PF_KEY interface *must* be the IP address, since that's all the kernel knows. You see where I'm heading. Without DNSSEC, there's an unauthenticated, security-critical step. I'll end up with a secure connection to an unknown party. Sure, the certificate for that party will identify them as bearhands.com, not plugh.com -- but I as a user will never see that certificate. There's more to be said on this general topic; those of you who were in Montreal heard me speak on it. I've been meaning to write a longer message to this list, outlining the crucial work areas for this group; maybe I'll get to it next week.... --Steve Bellovin Received: from relay.tis.com by neptune.TIS.COM id aa02107; 19 Jul 96 11:54 EDT Received: by relay.tis.com; id LAA16498; Fri, 19 Jul 1996 11:57:06 -0400 From: pcalhoun@usr.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016496; Fri, 19 Jul 96 11:56:38 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05369; Fri, 19 Jul 96 11:56:17 EDT Received: by relay.tis.com; id LAA16491; Fri, 19 Jul 1996 11:56:36 -0400 Received: from mailgate.usr.com(149.112.20.2) by relay.tis.com via smap (V3.1.1) id xma016487; Fri, 19 Jul 96 11:56:31 -0400 Received: from robogate2.usr.com by usr.com (8.7.3/3.1.090690-US Robotics) id KAA22295; Fri, 19 Jul 1996 10:54:00 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.01 Enterprise) id 1EFAFD90; Fri, 19 Jul 96 10:55:05 -0500 Mime-Version: 1.0 Date: Fri, 19 Jul 1996 10:35:07 -0500 Message-Id: <1EFAFD90.@usr.com> Subject: Question regarding mandatory CBC-DESSupport To: ipsec@TIS.COM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipsec-approval@neptune.tis.com Precedence: bulk The IPSEC spec defines that all implementations MUST support CBC-DES. I have a question regarding the export laws which are associated with it. My understanding is that if I make the key 40 bits, then there is no export problem. However, the KDC system that we have implemented generates 128 bit session keys, and these keys are short lived (meaning that they are one time keys). I believe that DES has restricted key length of 64 bits, so I suppose I must truncate the session key to that length. Has anyone ever tried to export a product which would do this?? It seems that the Government would not allow me to do so. One method, I suppose would be to only use the first 40 bits of the session key but this considerably weakens the protocol's security. I would appreciate any help, Pat R. Calhoun e-mail: pcalhoun@usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. Received: from relay.tis.com by neptune.TIS.COM id aa02195; 19 Jul 96 11:58 EDT Received: by relay.tis.com; id MAA16571; Fri, 19 Jul 1996 12:01:06 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016569; Fri, 19 Jul 96 12:00:37 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05545; Fri, 19 Jul 96 12:00:17 EDT Received: by relay.tis.com; id MAA16566; Fri, 19 Jul 1996 12:00:36 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma016560; Fri, 19 Jul 96 12:00:06 -0400 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for ns.tis.com [192.94.214.100]) with SMTP; 19 Jul 1996 16:02:32 UT Received: from midwest.raptor.com (foghorn.raptor.com [204.7.242.8]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id MAA27111; Fri, 19 Jul 1996 12:01:58 -0400 (EDT) Message-Id: <2.2.32.19960718123936.006a27a0@raptor1> X-Sender: jtardo@raptor1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jul 1996 08:39:36 -0400 To: Steven Bellovin From: Joe Tardo Subject: Re: Key Management, anyone? Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 11:06 AM 7/19/96 -0400, Steven Bellovin wrote: >You see where I'm heading. Without DNSSEC, there's an unauthenticated, >security-critical step. I'll end up with a secure connection to an >unknown party. Sure, the certificate for that party will identify >them as bearhands.com, not plugh.com -- but I as a user will never see >that certificate. Steve: I eagerly await your writeup. I don't disagree, by the way, that there is a big problem here. My concern is that the DNSSEC solution may be impractical except maybe for "intranets". I am *really* concerned if root DNS key servers will be adminstered by Network Solutions. I also don't understand how dynamic assigned ISP addresses will work. For example, UUNET gives me a *real* ip address that you can look up some really ugly name for, but they're not going to give me the private key for that name, nor have they volunteered to put my public key in for the duration of my login, never mind the certification issues. And they adminster the DNS servers. Besides, best case would be your secure connection to an unknown party! I can, however, authenticate based on my user certificate, which I can pass on the ISAKMP id exchange. Setting up the policy for this is going to be interesting, but seems more likely to happen. Besides, it lets me "start small" and not rely on infrastructure. Thanks, Joe Received: from relay.tis.com by neptune.TIS.COM id aa03464; 19 Jul 96 13:10 EDT Received: by relay.tis.com; id NAA19177; Fri, 19 Jul 1996 13:13:18 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019171; Fri, 19 Jul 96 13:13:03 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01853; Fri, 19 Jul 96 13:12:14 EDT Received: by relay.tis.com; id NAA19110; Fri, 19 Jul 1996 13:12:22 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma019069; Fri, 19 Jul 96 13:11:38 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA23677 for ; Fri, 19 Jul 1996 13:14:08 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma023675; Fri Jul 19 13:13:48 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA21480 for ; Fri, 19 Jul 1996 13:10:22 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA14693; Fri, 19 Jul 1996 13:13:39 -0400 Date: Fri, 19 Jul 1996 13:13:39 -0400 From: "David P. Kemp" Message-Id: <199607191713.NAA14693@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: Key Management, anyone? X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Steven Bellovin > > These are very valid points. Unfortunately, in my opinion DNSSEC > is utterly mandatory for *any* type of key management for IPSEC. > > Suppose I want to establish a secure connection to plugh.com. My > application -- say, telnet -- will ask the DNS for the IP address, > and then do the socket() and the connect() operations. Deep in the > bowels of the kernel, something in the protocol stack will realize > that (a) the connection must be secure, and (b) it doesn't have a key. > So it asks the key management daemon to negotiate a session key -- but > the parameter passed via the PF_KEY interface *must* be the IP address, > since that's all the kernel knows. > > You see where I'm heading. Without DNSSEC, there's an unauthenticated, > security-critical step. I'll end up with a secure connection to an > unknown party. Sure, the certificate for that party will identify > them as bearhands.com, not plugh.com -- but I as a user will never see > that certificate. Are you saying that, despite the seesaws on user keying from mandatory to recommended and now back to mandatory, you believe there is *no hope of ever doing user-specific keying in IPSEC* ??? In other words, network stacks are not to be allowed to propogate user context down to whatever layer the transform engine communicates with the key management daemon, and key management daemons are not to be allowed to contact the user or consult configuration files or caches or directory servers other than DNSSEC to verify certificate names? This is a critical point, because a community of users (such as the DoD) can establish a certificate structure that it trusts to be correct, but may (will :-) not be willing to trust a DNS directory service administered by who knows whom. It would be much better if DNS could be regarded much like SMTP - it usually works as a transport mechanism to get bits from here to there, especially if there is no benefit to attacking it. If users want email security, they use MSP/PGP/SMIME/MOSS over SMTP and there's a good chance, but no guarantee, that the message will get to its destination. If users want connection security, they should be able to rely on DNS to give them a shot at connecting to the desired destination machine, but it's up to the key management daemons and ESP/AH transforms to ensure that the connection is indeed secure, and that multiple users on one machine and multiple servers on another can be cryptographically isolated. If this isn't the direction IPSEC is heading, we'll have to abandon any thought of using it, and stick with GSS-API or TLS mechanisms to achieve the required connection security. Received: from relay.tis.com by neptune.TIS.COM id aa09269; 19 Jul 96 18:49 EDT Received: by relay.tis.com; id SAA05806; Fri, 19 Jul 1996 18:50:47 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005800; Fri, 19 Jul 96 18:50:18 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20984; Fri, 19 Jul 96 18:49:59 EDT Received: by relay.tis.com; id SAA05797; Fri, 19 Jul 1996 18:50:17 -0400 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma005795; Fri, 19 Jul 96 18:50:08 -0400 Received: from snail.rsa.com by RSA.COM with SMTP id AA10893; Fri, 19 Jul 96 15:45:01 PDT Received: from cc:Mail by snail.rsa.com id AA837816703; Fri, 19 Jul 96 15:51:22 PST Date: Fri, 19 Jul 96 15:51:22 PST From: baldwin Message-Id: <9606198378.AA837816703@snail.rsa.com> To: pcalhoun@usr.com, ipsec@TIS.COM Subject: Re: Question regarding mandatory CBC-DESSupport Sender: ipsec-approval@neptune.tis.com Precedence: bulk Pat, One trick that may help you implement both DES-CBC and comply with a 40 bit key length for general export is to create a key management system that uses the subset of DES keys that are used by DES-CDMF (an IBM invention). Normal DES keys are chosen from a 56 bit space, and CDMF defines a 40 bit subset of that space that is uniformly distributed across the normal DES key space. The basic idea is to pick a 40 bit number, encrypt it with a well known des key to get a 64 bit number, which is then parity adjusted to be a proper 56 bit des key stored in eight bytes. The standard DES-CBC algorithm is used with this key. --Bob ______________________________ Reply Separator _________________________________ Subject: Question regarding mandatory CBC-DES Support Author: pcalhoun@usr.com at INTERNET Date: 7/19/96 10:27 AM The IPSEC spec defines that all implementations MUST support CBC-DES. I have a question regarding the export laws which are associated with it. My understanding is that if I make the key 40 bits, then there is no export problem. However, the KDC system that we have implemented generates 128 bit session keys, and these keys are short lived (meaning that they are one time keys). I believe that DES has restricted key length of 64 bits, so I suppose I must truncate the session key to that length. Has anyone ever tried to export a product which would do this?? It seems that the Government would not allow me to do so. One method, I suppose would be to only use the first 40 bits of the session key but this considerably weakens the protocol's security. I would appreciate any help, Pat R. Calhoun e-mail: pcalhoun@usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. Received: from relay.tis.com by neptune.TIS.COM id aa10541; 19 Jul 96 20:26 EDT Received: by relay.tis.com; id UAA07110; Fri, 19 Jul 1996 20:28:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007108; Fri, 19 Jul 96 20:28:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26542; Fri, 19 Jul 96 20:28:06 EDT Received: by relay.tis.com; id UAA07105; Fri, 19 Jul 1996 20:28:23 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma007103; Fri, 19 Jul 96 20:28:13 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id UAA05384; Fri, 19 Jul 1996 20:30:30 -0400 (EDT) Message-Id: <199607200030.UAA05384@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: baldwin MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: pcalhoun@usr.com, ipsec@TIS.COM Subject: Re: Question regarding mandatory CBC-DESSupport In-Reply-To: Your message of "Fri, 19 Jul 1996 15:51:22 PST." <9606198378.AA837816703@snail.rsa.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 19 Jul 1996 20:30:29 -0400 From: "Perry E. Metzger" Sender: ipsec-approval@neptune.tis.com Precedence: bulk baldwin writes: > One trick that may help you implement both DES-CBC and > comply with a 40 bit key length for general export is to create > a key management system that uses the subset of DES keys that > are used by DES-CDMF (an IBM invention). The specs for IPSEC require the support of manual keying, which presumably means that full 56 bit key support must be present. .pm Received: from relay.tis.com by neptune.TIS.COM id aa10868; 19 Jul 96 20:55 EDT Received: by relay.tis.com; id UAA07425; Fri, 19 Jul 1996 20:58:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007421; Fri, 19 Jul 96 20:57:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27834; Fri, 19 Jul 96 20:57:37 EDT Received: by relay.tis.com; id UAA07416; Fri, 19 Jul 1996 20:57:54 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma007412; Fri, 19 Jul 96 20:57:35 -0400 Received: from research.research.att.com by ns; Fri Jul 19 20:59:06 EDT 1996 Received: from raptor.research.att.com by research; Fri Jul 19 20:58:19 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id UAA02657; Fri, 19 Jul 1996 20:58:18 -0400 (EDT) Message-Id: <199607200058.UAA02657@raptor.research.att.com> To: baldwin MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: pcalhoun@usr.com, ipsec@TIS.COM Subject: Re: Question regarding mandatory CBC-DESSupport Date: Fri, 19 Jul 1996 20:58:18 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Pat, One trick that may help you implement both DES-CBC and comply with a 40 bit key length for general export is to create a key management system that uses the subset of DES keys that are used by DES-CDMF (an IBM invention). Normal DES keys are chosen from a 56 bit space, and CDMF defines a 40 bit subset of that space that is uniformly distributed across the normal DES key space. The basic idea is to pick a 40 bit number, encrypt it with a well known des key to get a 64 bit number, which is then parity adjusted to be a proper 56 bit des key stored in eight bytes. The standard DES-CBC algorithm is used with this key. Note that CDMF is patented by IBM. Received: from relay.tis.com by neptune.TIS.COM id aa11822; 19 Jul 96 22:14 EDT Received: by relay.tis.com; id TAA06162; Fri, 19 Jul 1996 19:10:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006155; Fri, 19 Jul 96 19:10:24 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22213; Fri, 19 Jul 96 19:10:06 EDT Received: by relay.tis.com; id TAA06152; Fri, 19 Jul 1996 19:10:23 -0400 Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1.1) id xma006138; Fri, 19 Jul 96 19:09:55 -0400 Received: from snail.rsa.com by RSA.COM with SMTP id AA11053; Fri, 19 Jul 96 16:07:31 PDT Received: from cc:Mail by snail.rsa.com id AA837818052; Fri, 19 Jul 96 16:13:37 PST Date: Fri, 19 Jul 96 16:13:37 PST From: baldwin Message-Id: <9606198378.AA837818052@snail.rsa.com> To: ipsec@TIS.COM Subject: Exporting an IPSec implementation Sender: ipsec-approval@neptune.tis.com Precedence: bulk As a reminder, if you need to build an ipsec implementation that is exportable, you can use the RC5 transforms that we described in two internet drafts published on the IETF sites and on rsa.com's site. RC5 has both a 128 bit and a 40 bit variant. We have received basic approval for the 40 bit variant to be used with IPsec implementations (you still need to do the export paperwork, but it should go fast and we can help with it). Within the USA, RC5 should be licensed from RSA Data Security, outside the USA anyone can implement it. The internet drafts provide enough detail, sample code and test vectors to ensure that independent implementations of RC5-CBC and the ESP transform will interoperate. By the way, if you have a restricted target market like IPSec for an international bank, then you should attempt to get an export license for a full strength 56 bit DES. Similar situations have worked successfully for our customers. --Bob Baldwin Disclaimer: To legally claim that a product implements "IPSec", the product MUST implement 56 bit DES-CBC which of course is not exportable for general applications. So, if your product only performs a 40 bit RC5, which would allow you to post it on the web and give it away for free throughout the world, then your legal claims should indicate that it is a demonstration version not a true implementation of IPSec. Received: from relay.tis.com by neptune.TIS.COM id aa12606; 19 Jul 96 23:03 EDT Received: by relay.tis.com; id XAA08837; Fri, 19 Jul 1996 23:05:54 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008835; Fri, 19 Jul 96 23:05:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29630; Fri, 19 Jul 96 23:05:07 EDT Received: by relay.tis.com; id XAA08830; Fri, 19 Jul 1996 23:05:24 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma008826; Fri, 19 Jul 96 23:05:22 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id UAA08198; Fri, 19 Jul 1996 20:07:49 -0700 (PDT) Message-Id: <199607200307.UAA08198@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Key Management and DNSSEC In-Reply-To: <2.2.32.19960718094448.0069533c@raptor1> Date: Fri, 19 Jul 1996 20:07:48 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > What's going on with key management? Are there key management > mailing lists, perhaps? Jeff Schiller made an executive decision at the last IETF, after straw-polling the attendees on design criteria. A small subgroup of people are currently working on a combined key management proposal, including designers from SKIP, Oakley, ISAKMP, and Photuris camps. They have until September 1 to produce a draft acceptable to the working group. At that point people could start coding for interoperability testing. Jeff says he's prepared to decide among the current set of candidates if he has to, but he'd prefer an approach that resolves everyone's issues in a more coherent fashion. I haven't heard anything from the subgroup since the day after it was formed, but they're supposed to not be having their elbows joggled by the working group anyway. > Why does Oakley think > that DNSSEC is ever going to take off? Making something so tentative > mandatory is a shot in the foot. I firmly believe that DNSSEC will take off. I'm putting a lot of effort to make it take off this summer; it's my job. I've contributed code to BIND, which will be out in an alpha release in a week or two, which stores and retrieves SIG and KEY records. It does not affect the export status of BIND because it contains no cryptography; it's just data storage and retrieval. This will allow us to bootstrap into DNSSEC soon, with a bit of auxiliary cryptographic code for generating the keys and signatures offline (which is where they're supposed to be generated anyway). For experimental early deployment of IPSEC, there's no need to check the signatures on keys; we are still protected against passive attacks such as packet-sniffing. When full-blown DNSSEC code is merged and deployed, we'll be protected against active attacks as well. I'm also working closely with Trusted Information Systems, which has been funded by DARPA to build a prototype full-blown DNSSEC implementation. I've been working out legal and copyright issues with them, and hope to soon start helping Paul Vixie merge their code into BIND. I'm also on the hook to provide a DNSSEC implementation in the resolver library, which would check the signatures on DNS RR's; the TIS code only checks signatures in named, not in the resolver. I've started DNSSEC deployment discussions with the IANA, which owns the root domain, and with the various NICs around the world. So far everyone has indicated a willingness to generate keys and sign peoples' records, as soon as the code shows up to implement it. There is an issue about Network Solutions and its ownership potentially wanting to undermine Internet security. It's been pointed out to me (and I should have known better), that if they wanted to undermine the DNS, they could provide the wrong RR's as well as the wrong (or no) signatures. DNSSEC doesn't prove that everything is trustable; it proves that records are coming from the organization who has been delegated the authority for that part of the name space. If we delegate part of the name space to someone we don't trust, all the DNSSEC in the world won't help us. NSI can make microsoft.com's IP traffic all go to dockmaster.ncsc.mil any time they want to, and nothing short of the IANA taking away their delegation of .com will stop that. And whoever took over authority for .com would then be in the same position. Crypto can't create trust. It merely automates the trust that already exists for other reasons. > Besides, DNSSEC doesn't solve > the problem (who's going to administer it? what about dhcp or > PPP dynamic addressing?) The beauty of DNSSEC is that it is administered by the same people who administer DNS today. It's a distributed workload that exactly matches the current DNS zone delegation hierarchy. DNS is actually quite an unrecognized heroic feat: a global distributed replicated cached dynamic database. It works so well that we just *assume* that our host names will "of course" map to IP addresses and back. As for PPP dynamic addressing and DHCP, indeed there is a short-term problem. I'm content to start deploying DNSSEC and IPSEC among hosts who have fixed addresses, while we implement what's needed to support dynamic addresses; we have to start somewhere. Paul Vixie has been working hard on Dynamic DNS Update, for which there is an Internet-Draft and an implmentation contributed by IBM. The draft has not advanced in the standards process because it didn't include security mechanisms; the ability to update DNS records remotely without working out the details of authentication could undermine rather than improve Internet security. DNSSEC offers perfectly good security for Dynamic DNS though; as we deploy DNSSEC and get it operational, we can use DNSSEC SIG records to validate requests for updates (e.g. from dhcp daemons who have just handed out an address). In summary, DNSSEC is moving fast. Very early adopters in the US can play with it now (see ftp://ftp.tis.com/pub/DNSSEC/README). In a few months you'll see scattered operational deployment including a couple of high-level zones. By the end of the year I expect most countries' NICs, and many companies, to be signing their records. John Gilmore Received: from relay.tis.com by neptune.TIS.COM id aa13176; 19 Jul 96 23:52 EDT Received: by relay.tis.com; id XAA09356; Fri, 19 Jul 1996 23:55:24 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009354; Fri, 19 Jul 96 23:54:55 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00474; Fri, 19 Jul 96 23:54:37 EDT Received: by relay.tis.com; id XAA09351; Fri, 19 Jul 1996 23:54:54 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma009341; Fri, 19 Jul 96 23:54:27 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id UAA09217; Fri, 19 Jul 1996 20:56:51 -0700 (PDT) Message-Id: <199607200356.UAA09217@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "David P. Kemp" Cc: ipsec@TIS.COM, gnu@toad.com Subject: Re: Key Management, anyone? In-Reply-To: <199607191713.NAA14693@argon.ncsc.mil> Date: Fri, 19 Jul 1996 20:56:50 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Flame off, please. > Are you saying that, despite the seesaws on user keying from > mandatory to recommended and now back to mandatory, you believe there is > *no hope of ever doing user-specific keying in IPSEC* ??? It will be hard to do user-specific keying in IPSEC firewalls, which are certainly a large part of the IPSEC market. I think ten or twelve commercial firewall vendors have interoperated (http://www.rsa.com/rsa/SWAN/), while no commercially available end-systems like Unix or Windows boxes have yet done so. For IPSEC firewalls to work, DNSSEC or something very much like it will need to work. As for what is implemented in end-user systems that run IPSEC, that's up to the system implementer. Certainly the information is available to do user-specific keying, if the market demand exists. I expect that if a user provides key material, and the system at the other end of the connection accepts it, it can be used; if not, a default host key will be used if one can be found. > In other words, network stacks are not to be allowed to propogate user > context down to whatever layer the transform engine communicates with > the key management daemon, and key management daemons are not to be allowed > to contact the user or consult configuration files or caches or directory > servers other than DNSSEC to verify certificate names? This sounds like a vast overstatement. Let's not bash too much on this particular strawman. Key management daemons will be "allowed" to do whatever falls within the documented end-to-end protocols. If they want to pop up a window to the user, examine config files, or talk to a user-specific smart card, they can do that. I think Steve was talking about what we expect to be the most common case, which will have to be invisible to users and very easy to administer (no config files required) so that it will be easy to deploy. We're interested in operational security, not theoretical security so complex that nobody uses it. > This is a critical point, because a community of users (such as the > DoD) can establish a certificate structure that it trusts to be correct, > but may (will :-) not be willing to trust a DNS directory service > administered by who knows whom. The DoD can certainly put in the effort to configure their systems to trust or mistrust any particular keying method or set of sites. If DoD doesn't trust the DNS to communicate keys among DoD-trusted sites, it can write its own hardened DNS implementation, or can tell the public community what isn't trustworthy about the DNS so that we can all fix it together. Secure DNS only requires the use of a specific algorithm for general interoperability; the algorithm in use is identified in each signature. If DoD doesn't trust the RSA algorithm, I'm sure IANA would assign DoD an algorithm identifier for a classified signature algorithm and certificate format. It could use that algorithm to interoperate among its own hosts. Please explain how using DNSSEC packet formats to communicate these signatures and keys would somehow render them untrustworthy. If the problem is not with DNS or RSA security per se, but that DNS doesn't provide the features that DoD needs, it should define its own unique key management protocols and key communications methods. I understand that there's a need to use key-escrowed and/or classified algorithms in the DoD community; these needs are not shared by the rest of the world. Bending the protocols used to secure general-purpose traffic, so that they can accomodate unique and intrusive requirements, is probably not the best use of the working group's energy. John Gilmore Received: from relay.tis.com by neptune.TIS.COM id aa13508; 20 Jul 96 0:20 EDT Received: by relay.tis.com; id AAA09550; Sat, 20 Jul 1996 00:22:54 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009546; Sat, 20 Jul 96 00:22:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00931; Sat, 20 Jul 96 00:22:07 EDT Received: by relay.tis.com; id AAA09543; Sat, 20 Jul 1996 00:22:24 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma009541; Sat, 20 Jul 96 00:22:14 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id VAA09853; Fri, 19 Jul 1996 21:24:39 -0700 (PDT) Message-Id: <199607200424.VAA09853@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: pcalhoun@usr.com Cc: ipsec@TIS.COM, gnu@toad.com Subject: Re: Question regarding mandatory CBC-DES support In-Reply-To: <1EFAFD90.@usr.com> Date: Fri, 19 Jul 1996 21:24:37 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > The IPSEC spec defines that all implementations MUST support CBC-DES. > I have a question regarding the export laws which are associated with > it. The government has approved many general exports of products with more than 40-bit keys. 40 is the published minimum, not the real rule. You will get more if you negotiate for it. This is the evil of "secret law" in action, in which the real rules are not public knowledge. I encourage companies to publish their export paperwork (see the bottom of ftp://ftp.cygnus.com/pub/export/ export.html) so that we can collectively attempt to infer what the real rules are. They like to keep us ignorant for divide-and-conquer; together we are stronger. But more importantly, the security of the IPSEC protocols rests on the integrity of the implementations in choosing keys. If your product claims to be generating a 56-bit key but actually always uses an identical key with everyone, it won't provide real security, but will mislead your customers. (Until the cypherpunks or your competition looks more closely at your product.) If sites want to provide minimal (e.g. 40-bit) security, they should advertise a 40-bit algorithm in their key negotiations, so that sites which want better security can refuse to communicate using that algorithm. The intent of the Internet Architecture Board in specifying that the IPSEC protocols should be designed without regard to the peculiarities of export controls of particular countries is clear. The security of the world Internet cannot and should not depend on the whims of one national government. If you make a 40-bit implementation, it won't be compatible with the real IPSEC CBC-DES transform. Build a real IPSEC implementation in a free country, negotiate harder with the State Department, lobby the government to get real, support the lawsuit to overturn the export controls, and/or only ship your product domestically. You have lots of options. The standard key management protocol should provide that both sides contribute bits to the common key, so that both sides are required to support all possible bit combinations as the final agreed-on key, and neither side can force the key to be from a smaller space without help from the other side. I believe that an IPSEC implementation that deliberately restricts the key space to be smaller than the documented key space should not qualify as being compatible with the IPSEC standards. This might require some specific wording in the final standards, if the working group agrees. John Gilmore Received: from relay.tis.com by neptune.TIS.COM id aa15258; 20 Jul 96 2:21 EDT Received: by relay.tis.com; id CAA10339; Sat, 20 Jul 1996 02:23:55 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010336; Sat, 20 Jul 96 02:23:26 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02518; Sat, 20 Jul 96 02:23:07 EDT Received: by relay.tis.com; id CAA10333; Sat, 20 Jul 1996 02:23:25 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1) id xma010330; Sat, 20 Jul 96 02:23:10 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id XAA05167; Fri, 19 Jul 1996 23:25:28 -0700 (PDT) Date: Fri, 19 Jul 1996 23:25:28 -0700 (PDT) From: Phil Karn MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199607200625.XAA05167@servo.qualcomm.com> To: baldwin@rsa.com Cc: ipsec@TIS.COM In-Reply-To: <9606198378.AA837818052@snail.rsa.com> (message from baldwin on Fri, 19 Jul 96 16:13:37 PST) Subject: Re: Exporting an IPSec implementation Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bob, Does the DoS 40-bit export policy apply to source, or only to object? And if it's limited to object code only, how does the use of 40-bit RC5 help us, given the standard IETF practice of distributing reference source implementations? Phil Received: from relay.tis.com by neptune.TIS.COM id aa29114; 21 Jul 96 0:25 EDT Received: by relay.hq.tis.com; id AAA07691; Sun, 21 Jul 1996 00:28:03 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007689; Sun, 21 Jul 96 00:27:34 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18987; Sun, 21 Jul 96 00:27:16 EDT Received: by relay.hq.tis.com; id AAA07686; Sun, 21 Jul 1996 00:27:33 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma007684; Sun, 21 Jul 96 00:27:28 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id VAA22591; Sat, 20 Jul 1996 21:29:31 -0700 Date: Sat, 20 Jul 1996 21:29:31 -0700 Message-Id: <199607210429.VAA22591@puli.cisco.com> To: baldwin@rsa.com From: Ran Atkinson Subject: Re: Exporting an IPSec implementation In-Reply-To: <9606198378.AA837818052@snail.rsa.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9606198378.AA837818052@snail.rsa.com> Bob Baldwin wrote: >Disclaimer: To legally claim that a product implements "IPSec", >the product MUST implement 56 bit DES-CBC which of course is >not exportable for general applications. Yes, though the specific mandatory-to-implement transform will probably vary through time. >So, if your product only >performs a 40 bit RC5, which would allow you to post it on >the web and give it away for free throughout the world, then >your legal claims should indicate that it is a demonstration >version not a true implementation of IPSec. Please do not use the term "IPsec demonstration version" to describe something that doesn't really implement IPsec per the standards-track RFCs. That would be at least misleading and perhaps would be illegal in some localities. If it does not implement IPsec per the current-at-the-time Internet standards-track RFCs, then it should not claim to implement IPsec. Ran rja@inet.org only speaking for myself as an individual... Received: from relay.hq.tis.com by neptune.TIS.COM id aa21827; 22 Jul 96 11:22 EDT Received: by relay.hq.tis.com; id LAA01913; Mon, 22 Jul 1996 11:25:15 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001903; Mon, 22 Jul 96 11:24:47 -0400 Received: from la.tis.com ([192.5.49.8]) by tis.com (4.1/SUN-5.64) id AA04799; Mon, 22 Jul 96 11:24:09 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA18655; Mon, 22 Jul 96 08:26:23 PDT Received: by relay.la.tis.com; id IAA05736; Mon, 22 Jul 1996 08:22:05 -0700 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.la.tis.com via smap (V3.1.1) id xma005734; Mon, 22 Jul 96 08:21:57 -0700 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA28607 for ; Mon, 22 Jul 1996 11:25:21 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma028603; Mon Jul 22 11:25:07 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA27788 for ; Mon, 22 Jul 1996 11:21:41 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA16126; Mon, 22 Jul 1996 11:24:57 -0400 Date: Mon, 22 Jul 1996 11:24:57 -0400 From: "David P. Kemp" Message-Id: <199607221524.LAA16126@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: Key Management, anyone? X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: John Gilmore > Flame off, please. I hope the tone of my message was not perceived to be antagonistic; it wasn't intended to be. Incredulous is more like it. > It will be hard to do user-specific keying in IPSEC firewalls > ... > For IPSEC firewalls to work, DNSSEC or something very much like it > will need to work. Bellovin's second of three firewall properties is: "Only authorized traffic, as defined by the local security policy, will be allowed to pass." (C&B, page 9.) If the definition of authorized traffic is "anything that can be tunnelled between IPSEC firewalls is allowed", then relying on the security of DNS to provide unspoofable name-to-IP translation may be useful. But some local security policies require firewalls to authenticate users before traffic is allowed to pass. Since users don't have IP addresses, DNSSEC is irrelevant except to the extent that it serves as a convenient, but not necessarily trusted, transport mechanism for keying material that may have been certified elsewhere. In that sense, requiring the "Security" part of DNSSEC is a misnomer, because all that is required is a generalized Resource Record format that can accommodate the distribution (not the certification) of keys. > I think Steve was talking about what we > expect to be the most common case, which will have to be invisible to > users and very easy to administer (no config files required) so that > it will be easy to deploy. We're interested in operational security, > not theoretical security so complex that nobody uses it. That may be what Steve meant, but it didn't appear to be what he said. It appeared that he was claiming that a single-rooted key certification heirarchy explicitly tied to the DNS heirarchy should be *required* in order to use IPSEC, or equivalently, that IPSEC is useless without DNSSEC. It's interesting that some of those who have strenuously objected to single-rooted key heirarchies in the past are now finding that they have some operational advantages. > If DoD doesn't trust the DNS to communicate keys among DoD-trusted > sites, it can write its own hardened DNS implementation, or can tell the > public community what isn't trustworthy about the DNS so that we can > all fix it together. That's the whole point - we don't need a hardened DNS*. Regular old DNS, with new record types to allow it to distribute certificates, would be fine. Perhaps it would be clearer to separate the roles of DNS as a key certification heirarchy and as a directory service. There is no question that DNS is pre-emininently qualified for the latter role. It may also be convenient for some people with low-end security requirements (not a pejorative term - the data to be protected may be of low value) to use DNSSEC in the former role, but there should be no implication that DNS-certified keys are required in order to use IPSEC - we as a working group should not be that narrowly-focused. -- *Hardened DNS (DNS-certified keys for the purpose of improving the reliability of name-to-address mapping) is quite useful for it's own sake. It's just seductively misleading to extend the use of "DNS keys created to secure DNS data" into the domain of "keys to secure IPSEC traffic". Received: from relay.hq.tis.com by neptune.TIS.COM id aa28245; 22 Jul 96 15:54 EDT Received: by relay.hq.tis.com; id PAA15474; Mon, 22 Jul 1996 15:56:36 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015463; Mon, 22 Jul 96 15:56:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21331; Mon, 22 Jul 96 15:55:47 EDT Received: by relay.hq.tis.com; id PAA15460; Mon, 22 Jul 1996 15:56:06 -0400 Received: from mail.intranet.ca(206.51.251.53) by relay.tis.com via smap (V3.1.1) id xma015441; Mon, 22 Jul 96 15:55:37 -0400 Received: from -ford1 ([206.51.250.164]) by hal.intranet.on.ca (8.6.11/8.6.9) with SMTP id PAA04365; Mon, 22 Jul 1996 15:59:09 -0400 Message-Id: <2.2.32.19960722194503.006b7018@mail.intranet.ca> X-Sender: wford@mail.intranet.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 15:45:03 -0400 To: ietf-pkix@tandem.com, ipsec@TIS.COM From: Warwick Ford Subject: Document for Information Sender: ipsec-approval@neptune.tis.com Precedence: bulk Members of PKIX and IPSEC may be interested in the document "Architecture for Public-Key Infrastructure" prepared by the APKI Working Group of the Open Group (OSF): "This document describes an Architecture for Public-Key Infrastructure components, identifies which elements of the architecture should (in the opinion of the authors) be standardized, and identifies candidate interface and protocol specifications which might serve as base documents for the standardization efforts." The document (currently available only in .ps form) is at: http://www.osf.org/~melman/pki/apki-7-18.ps. I am told that an ASCII version is in preparation. Warwick ------------------------------------------------------------------- Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 ------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa04185; 22 Jul 96 22:16 EDT Received: by relay.hq.tis.com; id WAA24850; Mon, 22 Jul 1996 22:19:22 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024848; Mon, 22 Jul 96 22:18:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01669; Mon, 22 Jul 96 22:18:33 EDT Received: by relay.hq.tis.com; id WAA24842; Mon, 22 Jul 1996 22:18:52 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma024836; Mon, 22 Jul 96 22:18:33 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id TAA03902; Mon, 22 Jul 1996 19:20:54 -0700 (PDT) Message-Id: <199607230220.TAA03902@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Key Management, anyone? In-Reply-To: <199607221524.LAA16126@argon.ncsc.mil> Date: Mon, 22 Jul 1996 19:20:50 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > That's the whole point - we don't need a hardened DNS*. Regular old > DNS, with new record types to allow it to distribute certificates, would > be fine. The Internet-Draft that defines those record types is from the DNSSEC working group (draft-ietf-dnssec-sexext-01.txt). The new record types are KEY and SIG. There's also a new NXT record, which is not relevant to what you are looking for. You can use these new record types whether or not your resolver actually checks the signatures on records (what you called hardened DNS). Code that implements the KEY and SIG record types should appear under ftp://ftp.vix.com/pub/bind/testing/ within a week or two. Note that DNSSEC doesn't have the concept of a "certificate". Keys are carried in one RR and signatures are carried in another. The combination of a signed key is what most people think of as a certificate. But in DNSSEC, you can sign other record types, and can publish keys that aren't signed. I'd guess that when algorithm-ID's are assigned for e.g. X.509 certs or PGP keys, the entire certificate (including the key and the non-DNS-related sigs) would appear in the KEY record. > It may also be convenient for some people . . . to use DNSSEC > [as a key certification hierarchy], but there should be no implication that > DNS-certified keys are required in order to use IPSEC - we as a working > group should not be that narrowly-focused. It depends on whether we are trying to build a tightly integrated, easily understood, easily deployed system -- or another PEM. We require the use of DNS to run IP (see RFC 1123, Host Requirements, section 6.1). Why should we not require the use of DNS to run IPSEC? > *Hardened DNS (DNS-certified keys for the purpose of improving > the reliability of name-to-address mapping) is quite useful for it's > own sake. It's just seductively misleading to extend the use of > "DNS keys created to secure DNS data" into the domain of "keys to > secure IPSEC traffic". If you know of a security problem with using the DNS protocols and/or the RSA/MD5 algorithms to distribute public keys which could be used to secure IPSEC traffic, then I propose that you announce it. Your last two messages have cast aspersions, without making specific what your perceived problem is. Personally I see an MD5/RSA-secured DNS as an excellent way to publish and locate keys for IPSEC use. It has most of the attributes we'd like in such a system, including good use of existing protocols and code and human knowledge, redundancy, cacheing, local control of keying material, proven scalability, and a well-distributed workload for both humans and computers. > It's interesting that some of those who have strenuously objected to > single-rooted key heirarchies in the past are now finding that they have > some operational advantages. We always knew there were operational advantages. The question is one of risk for society by centralizing that much power. If distributed systems can be workably built, they will provide more protection for the openness of society, making it hard for any single faction (including the government) to control society or to suppress opposing points of view. PGP is a successful but not pervasive attempt at such a system. DNSSEC is an obvious candidate for publishing IPSEC keys. The up-and-coming alternative is a system with much more centralized power. The FBI and NSA are busy designing a certification hierarchy that requires you to hand your PRIVATE key to a government agent before your public key can be published. Given that choice, deploying a self-publishing system that has a root, but with much less power at the root, is preferable. DNSSEC is such a system. For me, one factor seems to be that I personally trust Jon Postel to do the right thing with the root key. I have a lot more trust in him than in the FBI, NIST, the "good side" of the NSA, or the President. My guess is that this view is pretty pervasive on the Internet. John Gilmore Received: from relay.hq.tis.com by neptune.TIS.COM id aa05461; 22 Jul 96 23:54 EDT Received: by relay.hq.tis.com; id XAA25409; Mon, 22 Jul 1996 23:57:23 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025407; Mon, 22 Jul 96 23:56:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03210; Mon, 22 Jul 96 23:56:33 EDT Received: by relay.hq.tis.com; id XAA25404; Mon, 22 Jul 1996 23:56:53 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma025402; Mon, 22 Jul 96 23:56:22 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id UAA20330; Mon, 22 Jul 1996 20:58:50 -0700 Date: Mon, 22 Jul 1996 20:58:50 -0700 From: Ran Atkinson Message-Id: <199607230358.UAA20330@puli.cisco.com> To: ipsec@TIS.COM Subject: Re: Key Management, anyone? In-Reply-To: <199607230220.TAA03902@toad.com> References: <199607221524.LAA16126@argon.ncsc.mil> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-approval@neptune.tis.com Precedence: bulk >We require the use of DNS to run IP (see RFC 1123, Host Requirements, >section 6.1). Why should we not require the use of DNS to run IPSEC? Hmm. Perhaps permit me to narrow those statements a bit to try to clarify something (mandating implementation support vs. mandating use) that periodically causes confusion within the IPsec WG. The IETF requires that _implementations_ of IP also _implement_ support for DNS. The IETF does NOT require that users actually _USE_ DNS. Now most users DO use DNS because it is widely implemented and it is often easier to use than typing an IP number. However, on occasion users (e.g. me) don't use DNS and instead just type an IP number on the command line (e.g. "telnet 1.2.3.4") and this isn't violating any IETF requirement. Similarly, the IPsec WG would be wrong to try to mandate that "users MUST use DNS to obtain IPsec keys", while it might be very legitimate for the IPsec WG to mandate that "IPsec implementations SHOULD/MUST also implement support for DNSsec" if that is what the IPsec WG were to decide to do. [1] It is NOT the usual IETF practice to impose mandates on users. It is often the IETF practice to impose implementation mandates on implementers. >> *Hardened DNS (DNS-certified keys for the purpose of improving >> the reliability of name-to-address mapping) is quite useful for it's >> own sake. It's just seductively misleading to extend the use of >> "DNS keys created to secure DNS data" into the domain of "keys to >> secure IPSEC traffic". > >If you know of a security problem with using the DNS protocols and/or >the RSA/MD5 algorithms to distribute public keys which could be used to >secure IPSEC traffic, then I propose that you announce it. Your last >two messages have cast aspersions, without making specific what your >perceived problem is. I think you are misreading his intent. I haven't seen any aspersion so far. I have seen an evident desire to decouple the policy questions (which algorithms does one use and which key heirarchy does one use) from the technical questions (what are the standard mechanisms are available for use). Different user communities should be able to select for themselves which algorithms they wish to use. Similarly, different user communities should be able to select which key heirarchy (if any, after all PGP is not a strict heirarchy :-) they use. It is the IETF way to only specify mechanisms and let the various user communities decide the policy questions for themselves. Please lets all keep the list discussions on the technical matter of what the specifications say. Other lists are more appropriate places for various folks to debate policies. Personally, I believe that different user communities (e.g. Academia vs. Auto Industry) will have different security needs, different security models, and different policy choices. My personal goal is to ensure that the right set of security mechanisms is available, not to mandate any particular policy on any particular set of users. Regards, Ran rja@cisco.com NOTE 1: IETF rules prohibit a standards-track RFC at level N in the standards process from back referencing a standards-track RFC at a level less than N. At present, IPsec is a Proposed Standard and DNSsec is not a standards-track RFC. This winter, IPsec will probably move to Draft Standard, but DNSsec is required to remain at Proposed Standard until (1) at least 6 months have passed since publication as a Proposed Standard RFC and (2) interoperability of multiple independent implementations is demonstrated. Hence, if the IPsec RFCs mandate implementation of DNSsec, then the progress of the IPsec RFCs is likely to be delayed accordingly. It is up to the WG as a whole to develop consensus on whether such an explicit standards-dependence is desirable. Received: from relay.hq.tis.com by neptune.TIS.COM id aa05751; 23 Jul 96 0:14 EDT Received: by relay.hq.tis.com; id AAA25544; Tue, 23 Jul 1996 00:17:23 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025542; Tue, 23 Jul 96 00:16:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03601; Tue, 23 Jul 96 00:16:33 EDT Received: by relay.hq.tis.com; id AAA25539; Tue, 23 Jul 1996 00:16:53 -0400 Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (V3.1.1) id xma025537; Tue, 23 Jul 96 00:16:25 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA15529; Tue, 23 Jul 96 00:18:46 EDT Received: by dcl.MIT.EDU (5.x/4.7) id AA07507; Tue, 23 Jul 1996 00:18:45 -0400 Date: Tue, 23 Jul 1996 00:18:45 -0400 Message-Id: <9607230418.AA07507@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: John Gilmore Cc: ipsec@TIS.COM, gnu@toad.com In-Reply-To: John Gilmore's message of Mon, 22 Jul 1996 19:20:50 -0700, <199607230220.TAA03902@toad.com> Subject: Re: Key Management, anyone? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 22 Jul 1996 19:20:50 -0700 From: John Gilmore For me, one factor seems to be that I personally trust Jon Postel to do the right thing with the root key. I have a lot more trust in him than in the FBI, NIST, the "good side" of the NSA, or the President. Note that a very simple enhancement to DNSSEC would allow sub-hierarchies to not even need to trust Jon Postel, by using what the "up certificates". This is where the ENTERPRISE.NAVY.MIL signs NAVY.MIL's key, and NAVY.MIL signs MIL's key, and TIGERS.ARMY.MIL signs ARMY.MIL's key, and ARMY.MIL signs MIL's key, and so on. In this configuration, if ENTERPRISE.NAVY.MIL and SARATOGA.NAVY.MIL need to communicate, they only have to trust NAVY.MIL; if ENTERPRISE.NAVY.MIL and TIGERS.ARMY.MIL need to communicate, they only have to trust NAVY.MIL, MIL, and ARMY.MIL. This allows you to only need to trust the minimum number of nodes, and as long as all of the communications are within the .MIL hierarchy, you don't even need to trust anyone at the IANA or at the InterNIC. If two companies start doing a bilateral deal, they can set up cross certificates --- FORD.COM and TOYOTA.COM could sign each others' keys. It wouldn't be that hard to set up the secure DNS at FORD.COM to check to see if the local zone has signed any bilateral keys before commenceing up the tree looking for "up certificates" to find an appropriate certificate chain. - Ted Received: from relay.hq.tis.com by neptune.TIS.COM id aa06213; 23 Jul 96 0:37 EDT Received: by relay.hq.tis.com; id AAA25809; Tue, 23 Jul 1996 00:40:28 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025804; Tue, 23 Jul 96 00:39:59 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04048; Tue, 23 Jul 96 00:39:39 EDT Received: by relay.hq.tis.com; id AAA25798; Tue, 23 Jul 1996 00:39:58 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma025794; Tue, 23 Jul 96 00:39:35 -0400 Received: from research.research.att.com by ns; Tue Jul 23 00:41:07 EDT 1996 Received: from smb.research.att.com by research; Tue Jul 23 00:39:36 EDT 1996 Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.6.12/8.6.10) with ESMTP id AAA10935 for ; Tue, 23 Jul 1996 00:39:34 -0400 Message-Id: <199607230439.AAA10935@smb.research.att.com> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs From: Steve Bellovin To: ipsec@TIS.COM Subject: challenges for the IPSEC group Date: Tue, 23 Jul 1996 00:39:32 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk At the Montreal IETF, I posed several open issues for the IPSEC group. I regard these as very important, since I don't think we can achieve operational deployment of IPSEC until they're solved (or, in some cases, until we find a suitable rug to sweep them under). Conspicuous by its absence is DNSSEC. Apart from the fact that I consider it to be a solved problem for IPSEC's purposes, that issue is being discussed in another thread. The first big issue is name formats. I hate naming discussions, since they're worse than religious arguments -- not only does everyone think they're right, they *are* right, because their postulates -- and environment -- differ. But we have to decide how to name the endpoints we want to protect, because if we don't have a name, we can't find the right certificate. An obvious choice is the DNS name, or perhaps the reversed IP address. These schemes have the advantage that we can use the DNS to distribute the certificates. (This is, of course, independent of whether or not we should use the DNSSEC structure to sign the certificates.) But DNS-like names may not fit into some existing certificate hierarchies. Also, in an era of DHCP and PPP, the owner of an address is transient. If we use DNS-like names, we may want to extend the syntax and/or mechanism to permit user@domain.name, or maybe user.domain.name. (But my laptop is smb.research.att.com; does it have a separate key from me?) A syntax with user names is necessary for user-oriented keying. For the server side, we may need something like portnum.TCP@ip.address; this would let us give each service a separate certificate if we wished. But we still need a way to have a default key for a host or even a zone. Using X.509 certificates has some obvious advantages. But the disadvantages are even more obvious, at least in the IETF... If we do adopt X.509, though, we need to munge its name structure so that we can name the sorts of objects described above. (I've contemplated trying to register country=cyberspace or some such.) The second big issue is certificate discovery. How does a host find the certificate it needs? The DNS is one answer, of course; if we use X.509 certificates, we could use ``the'' directory service, if only we had such a beast deployed. SKIP's Certificate Discovery Protocol, unbundled, is another option, though we'd still need to define and implement a distributed database so that you could get a certificate for someone you've never talked to before. Regardless of syntax, we need a way to find the certificate for the *real* firewall router for a domain. Even assuming that the encryption structure precisely matches the DNS name space -- and if firewall encryptors are used, that is indeed an assumption -- there are some difficult problems. For example, suppose that there is a firewall router for gue.com, with the appropriate certificate, but that host flood-control-dam.gue.com has its own certificate because it has special security needs. A query for flood-control-dam.gue.com's key should return that certificate, but an enemy might substitute the *.gue.com certificate record instead. DNSSEC won't help; private keys are offline with DNSSEC, so the query/response pair can't be signed. Possible, the *.gue.com record could have an exception list, but I fear that that would be unwieldy. We do need to pick a certificate format -- and that won't be easy, especially given the feelings on that subject. (The IETF has two different working groups on the topic.) If the certificates can have multiple signatures, we need some way to turn this signature graph into an authorization list. For example, I may wish to allow John Gilmore access to my system. But I'd should, perhaps, be a mite suspicious if what purported to be his certificate were signed by Louis Freeh. But what if it's also signed by Jeff Schiller, using a key I know to be valid? Or what if there are three levels of unknown and circular indirection in there? How do I build an ACL that captures the proper policy? As has been noted, a simple tree has operational advantages, but it's not at all clear that we can or should restrict ourselves to such a structure. Our final challenge is to build something that can be used for other purposes. It would be nice if SNMPvN could use the same key structure, for example. Similarly, if we have many PGP keys (and even a few PEM keys) floating around; it would be pleasant if we could dispense with the current ad hoc key servers. --Steve Bellovin Received: from relay.hq.tis.com by neptune.TIS.COM id aa06214; 23 Jul 96 0:37 EDT Received: by relay.hq.tis.com; id AAA25808; Tue, 23 Jul 1996 00:40:28 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025805; Tue, 23 Jul 96 00:39:59 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04049; Tue, 23 Jul 96 00:39:39 EDT Received: by relay.hq.tis.com; id AAA25799; Tue, 23 Jul 1996 00:39:58 -0400 Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1.1) id xma025795; Tue, 23 Jul 96 00:39:35 -0400 Received: from research.research.att.com by ns; Tue Jul 23 00:41:07 EDT 1996 Received: from raptor.research.att.com by research; Tue Jul 23 00:39:57 EDT 1996 Received: from research.att.com (localhost.research.att.com [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id AAA23748; Tue, 23 Jul 1996 00:39:56 -0400 (EDT) Message-Id: <199607230439.AAA23748@raptor.research.att.com> To: "David P. Kemp" Cc: rja@cisco.com, wdm@tycho.ncsc.mil, mjo@tycho.ncsc.mil, ipsec@TIS.COM Subject: Re: Key Management, anyone? Date: Tue, 23 Jul 1996 00:39:56 -0400 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk What smb said (not what you think he said, or what you think he should have said) was that "without DNSSEC, there's an unauthenticated step." I disagree. PGP provides some level of authentication, without DNSSEC, using plain DNS (plus PGP cert resource records) as a directory service. I confess that my mind is boggled by the thought of people arguing over what I did or didn't say or mean. Makes me feel like some sort of mystic oracle (but please don't offer me any goat entrails, even as a MIME attachment...). Anyway -- I stand by my statement, though I can and will expand on it a bit, and add a few qualifiers. The problem we have is the name-to-address mapping. Without DNSSEC -- or some local mechanism -- this step is completely unauthenticated, from the perspective of more-or-less vanilla applications that just call gethostbyname() or equivalent. The certificate for plugh.com may be signed by the director of NSA, the head of the (former) KGB, and John Gilmore -- and it's quite useless if an enemy can slip in a bogus IP address, since the firewall-based encryptor knows nothing but the IP address. To be sure, the DNSSEC tree does have what is (for some purposes) an inappropriate root. That can be dealt with by using manually configured certificates for subtrees of interest. It may not be a great solution -- and it's certainly not pretty -- but it permits local control and policies over an important step. (One could even use a PGP-like web of trust to distribute sets of zone keys.) To be sure, this only works if the implementations of DNSSEC permit local override keys -- but I think that it does. If not, it can be changed to do so, without affecting the over-the-wire protocol. What are the alternatives, assuming a smart application? If I want to talk to plugh.com, I can retrieve its certificate from my own trusted certificate hierarchy. I still need its IP address, though, which implies that I need DNS. If an enemy can spoof that, through lack of DNSSEC, we'd have a denial of service situation -- which is still better than information leakage, but far from ideal. What we still lack, though, is some standard way to tell a firewall encryptor, or even a bump-in-the-cord encryptor, which certificate to use. There's no reason we can't design such a protocol, of course, but we don't have one yet, and we'd have to confront the issue of identifying the proper outbound encryptor(s). Would that scheme work? Sure. The problem is that it doesn't scale well on the Internet, if our goal is ubiquitous cryptographic security. We'd need a separate tree, parallel to the DNS, with operational characteristics very similar to the DNS, but without a decade or so of operational experience in the implemenation. Outbound certificates are much less of a problem, since the local host or firewall can be told what certificate to use. My laptop may use its Fortezza card (well, your laptop might; I don't have a Fortezza card), a multiuser host might look up the user's certificate or use a per-host certificate, the firewall can check the source IP address (and if you can't trust that locally, you have no business using firewall-based encryption), etc. In a separate message, I list several important challenge areas for the IPSEC group. By challenges, I mean ``problems we have to solve in order to use IPSEC''. DNSSEC isn't on the list, since I consider that to be a solved problem for our purposes. --Steve Bellovin Received: from relay.hq.tis.com by neptune.TIS.COM id aa15452; 23 Jul 96 9:55 EDT Received: by relay.hq.tis.com; id JAA02186; Tue, 23 Jul 1996 09:57:32 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002150; Tue, 23 Jul 96 09:57:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA17731; Tue, 23 Jul 96 09:56:42 EDT Received: by relay.hq.tis.com; id JAA02147; Tue, 23 Jul 1996 09:57:02 -0400 Received: from unknown(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma002141; Tue, 23 Jul 96 09:56:59 -0400 Received: by pilotx.firewall.is.chrysler.com; id JAA22510; Tue, 23 Jul 1996 09:58:59 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma022506; Tue, 23 Jul 96 09:58:40 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id JAA10832; Tue, 23 Jul 1996 09:52:07 -0400 (EDT) Message-Id: <2.2.32.19960723135825.00ba15cc@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jul 1996 09:58:25 -0400 To: "Theodore Y. Ts'o" , John Gilmore From: Robert Moskowitz Subject: Re: Key Management, anyone? Cc: ipsec@TIS.COM, gnu@toad.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:18 AM 7/23/96 -0400, Theodore Y. Ts'o wrote: > >If two companies start doing a bilateral deal, they can set up cross >certificates --- FORD.COM and TOYOTA.COM could sign each others' keys. >It wouldn't be that hard to set up the secure DNS at FORD.COM to check >to see if the local zone has signed any bilateral keys before >commenceing up the tree looking for "up certificates" to find an >appropriate certificate chain. Yah, I am planning to do this :) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa16597; 23 Jul 96 10:31 EDT Received: by relay.hq.tis.com; id KAA03981; Tue, 23 Jul 1996 10:33:10 -0400 From: bmanning@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma003973; Tue, 23 Jul 96 10:32:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20741; Tue, 23 Jul 96 10:32:21 EDT Received: by relay.hq.tis.com; id KAA03968; Tue, 23 Jul 1996 10:32:40 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma003961; Tue, 23 Jul 96 10:32:37 -0400 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 23 Jul 1996 07:35:04 -0700 Posted-Date: Tue, 23 Jul 1996 07:33:58 -0700 (PDT) Message-Id: <199607231433.AA00968@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 23 Jul 1996 07:33:58 -0700 Subject: Re: challenges for the IPSEC group To: Steve Bellovin Date: Tue, 23 Jul 1996 07:33:58 -0700 (PDT) Cc: ipsec@TIS.COM In-Reply-To: <199607230439.AAA10935@smb.research.att.com> from "Steve Bellovin" at Jul 23, 96 00:39:32 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1200 Sender: ipsec-approval@neptune.tis.com Precedence: bulk > We do need to pick a certificate format -- and that won't be easy, > especially given the feelings on that subject. (The IETF has two > different working groups on the topic.) If the certificates can > have multiple signatures, we need some way to turn this signature > graph into an authorization list. For example, I may wish to allow > John Gilmore access to my system. But I'd should, perhaps, be a mite > suspicious if what purported to be his certificate were signed by > Louis Freeh. But what if it's also signed by Jeff Schiller, using > a key I know to be valid? Or what if there are three levels of > unknown and circular indirection in there? How do I build an ACL > that captures the proper policy? As has been noted, a simple tree > has operational advantages, but it's not at all clear that we can > or should restrict ourselves to such a structure. I noted in one mtg or other that perhaps one method would be to co-opt some of the work being done in the RPS wg. They are developing a policy description language with the inital target being routing. I expect that with a couple of twists, it could be made applicable here as an authorization policy language. --bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa18803; 23 Jul 96 11:39 EDT Received: by relay.hq.tis.com; id LAA06428; Tue, 23 Jul 1996 11:42:13 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006419; Tue, 23 Jul 96 11:41:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25989; Tue, 23 Jul 96 11:41:23 EDT Received: by relay.hq.tis.com; id LAA06416; Tue, 23 Jul 1996 11:41:43 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma006403; Tue, 23 Jul 96 11:41:22 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id LAA26791 for ; Tue, 23 Jul 1996 11:46:34 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id LAA22041; Tue, 23 Jul 1996 11:45:24 -0400 Date: Tue, 23 Jul 1996 11:45:24 -0400 From: Hilarie Orman Message-Id: <199607231545.LAA22041@earth.hpc.org> To: ipsec@TIS.COM In-Reply-To: Yourmessage <199607230358.UAA20330@puli.cisco.com> Subject: Re: Key Management, anyone? Sender: ipsec-approval@neptune.tis.com Precedence: bulk How about requiring that each host have a DNSSEC key record? This would provide a minimum interoperable basis for authentication. Received: from relay.hq.tis.com by neptune.TIS.COM id aa23070; 23 Jul 96 13:59 EDT Received: by relay.hq.tis.com; id OAA11328; Tue, 23 Jul 1996 14:02:10 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011326; Tue, 23 Jul 96 14:02:04 -0400 Received: from london.eu.tis.com by tis.com (4.1/SUN-5.64) id AA04852; Tue, 23 Jul 96 14:01:38 EDT Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id TAA07262 for ; Tue, 23 Jul 1996 19:01:22 +0100 (BST) Received: by relay.eu.tis.com; id OAA11303; Tue, 23 Jul 1996 14:56:46 +0100 (BST) Received: from puli.cisco.com(171.69.1.174) by relay.eu.tis.com via smap (V3.1.1) id xma011301; Tue, 23 Jul 96 14:56:29 +0100 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id LAA14931 for ipsec@tis.com; Tue, 23 Jul 1996 11:02:48 -0700 Message-Id: <199607231802.LAA14931@puli.cisco.com> From: Ran Atkinson Date: Tue, 23 Jul 1996 11:02:48 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: IPsec Implementation Summary (7/23/96) Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is the IETF IPsec WG Implementation Status as of 23 July 1996. There are 8 known freely distributable implementations (listed first) and 10 known commercial/proprietary implementations (listed afterwards). Some of the listed implementations are "planned" or "in progress". Not all implementations include all of the IETF IPsec specifications and/or proposals. Claimed interoperability is also listed. Not all implementations have been tested against each other, so not listing interoperability might mean that the implementations were never tested against each other. Paul Lambert Randall Atkinson Co-Chairs of the IP Security WG Internet Engineering Task Force Here is the list of freely distributable IPsec implementations: _______________________________________________________________________ Name of Implementation: x-Kernel IPsec Organisation: Univ. of Arizona, Dept of CS IP versions: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual, Photuris (draft 8, Elliptical curves) Platforms: x-Kernel (U of AZ's research OS) Lineage of IPsec Code: University of Arizona Lineage of Key Mgmt Code: University of Arizona Location of Source Code: ftp://ftp.cs.arizona.edu/xkernel/ xkernel.v3.2.security.tar.Z Point of Contact: Hilarie Orman Claimed Interoperability: KA9Q NOS (AH MD5, ESP DES), JI (Photuris, AH MD5) _______________________________________________________________________ Name of Implementation: ENskip Organisation: ETH Zurich Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): Partial (SPI == 1 only) ESP (RFC-1825,1827): Partial (SPI == 1 only) AH MD5 (RFC-1828): YES, with 128, 64, & 32 bit keys ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES, ESP-IDEA, ESP-RC4 Key Management: SKIP (draft 6) Platforms: Solaris 2.4+, IRIX (version ??), NetBSD, Nextstep Lineage of IPsec Code: ETH Zurich Lineage of Key Mgmt Code: ETH Zurich Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip Point of Contact: Claimed Interoperability: Sun SKIP _______________________________________________________________________ Name of Implementation: ISAKMP with Oakley Extensions Key Mgmt Daemon Organisation: cisco Systems Which IP versions are supported: IPv4 and IPv6 Implemented Features: AH (RFC-1825,1826): Not applicable ESP (RFC-1825,1827): Not applicable AH MD5 (RFC-1828): Not applicable ESP DES (RFC-1829): Not applicable Other AH Transforms: Not applicable Other ESP Transforms: Not applicable Key Management: ISAKMP with Oakley Extensions Platforms: Any system with the NRL PF_KEY key management API Lineage of IPsec Code: not applicable Lineage of Key Mgmt Code: cisco Systems Location of Source Code: http://web.mit.edu/network/isakmp/ http://www.cisco.com/public/library/isakmp.html Note: Patent issues have been taken care of by cisco. Point of Contact: Dan Harkins Public Mailing List: Claimed Interoperability: (UK) DRA Malvern's ISAKMP as of ISAKMP draft 4. _______________________________________________________________________ Name of Implementation: ISI/USC Organisation: Information Sciences Institute, USC Which IP versions are supported: IPv4 AH (RFC-1825,1826): YES ESP (RFC-1825,1827): NO AH MD5 (RFC-1828): YES ESP DES (RFC-1829): NO Other AH Transforms: checksum, proprietary Other ESP Transforms: none Key Management: staticly configured Platforms: BSD Lineage of IPsec Code: Both NRL-derived and ISI-developed Lineage of Key Mgmt Code: not applicable Location of Source Code: (expected March 1996) Point of Contact: Joe Touch Claimed Interoperability: _______________________________________________________________________ Name of Implementation: JI's IPsec Organisation: John Ioannidis Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: HMAC MD5 in progress ??? Other ESP Transforms: none Key Management: manual, Photuris (which draft ?) in progress, PF_ENCAP keying interface, PF_ROUTE extensions Platforms: BSD/OS 2.0 Lineage of IPsec Code: JI Lineage of Key Mgmt Code: Angelos D, Keromytis Location of Source Code: TBD Point of Contact: John Ioannidis Claimed Interoperability: _______________________________________________________________________ Name of Implementation: KA9Q NOS Organisation: Phil Karn Which IP versions are supported: IPv4 AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual Platforms: DOS with KA9Q NOS Lineage of IPsec Code: Phil Karn Lineage of Key Mgmt Code: not applicable Location of Source Code: (available soon) Point of Contact: Phil Karn Claimed Interoperability: _______________________________________________________________________ Name of Implementation: NIST/NSA IPSEC Prototype Organisation: NIST & NSA Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-SHA, AH-HMAC-MD5 Other ESP Transforms: Key Management: manual, PF_SADB interface Platforms: BSD/OS, NetBSD, FreeBSD, DTOS Lineage of IPsec Code: NIST & NSA Lineage of Key Mgmt Code: NIST & NSA Location of Source Code: Code available, contact Mike Oehler. Point of Contact: Rob Glenn, Rob.Glenn@nist.gov, Michael Oehler, mjo@tycho.ncsc.mil, (301) 688-0849 Claimed Interoperability: NRL, Gemini, Ftp Software, IBM, Morningstar, Raptor, Secure Computing, SOS, and TIS ________________________________________________________________________ Name of Implementation: NRL IPv6/IPsec Software Distribution Organisation: Naval Research Laboratory (NRL) Which IP versions are supported: IPv4 and IPv6 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-MD5, AH-HMAC-SHA Other ESP Transforms: DES-CBC-MD5-Replay is planned. Key Management: manual, PF_KEY Key Management API, includes cisco's ISAKMP+Oakley daemon. Platforms: any 4.4-Lite BSDish system, NetBSD, BSDI, 4.4 BSD Lineage of IPsec Code: NRL, with some AH transforms contributed by NIST Lineage of Key Mgmt Code: cisco Systems Location of Source Code: US: http://web.mit.edu/network/isakmp US/Canada: http://www.cisco.com/public/library/ipsec.html Europe: ftp://ftp.ripe.net/ipv6/nrl/ Point of Contact: Claimed Interoperability: (all are for ESP DES, AH MD5) Ascend, V-One, TIS, IBM, KA9Q, & NRL-derived implementations _______________________________________________________________________ Name of Implementation: Sun SKIP Organisation: Sun Microsystems' Internet Commerce Group (Sun ICG) Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: SKIP Platforms: SunOS 4.1.x, FreeBSD 2.1.0 Lineage of IPsec Code: Sun ICG Lineage of Key Mgmt Code: Sun ICG Location of Source Code: http://skip.incog.com Point of Contact: Tom Markson Claimed Interoperability: ETH Zurich's EnSKIP, Elvis SKIP, Checkpoint Firewall-1 Here is the list of commercial/proprietary IETF IPsec implementations: ________________________________________________________________________ Name of Implementation: AccessSecure Organisation: Ascend Communications Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES, with variable length keys ESP DES (RFC-1829): YES, 32-bit or 64-bit IV Other AH Transforms: none Other ESP Transforms: none Key Management: manual Platforms: Ascend Pipeline and Max routers Lineage of IPsec Code: Ascend (was MorningStar) Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Karl Fox Claimed Interoperability: NRL, Checkpoint, IBM, NIST, Raptor, Secure Computing, SOS, TimeStep, TIS, Gemini, KA9Q NOS _______________________________________________________________________ Name of Implementation: ERP IPSEC Organisation: Bellcore Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES, with 128, 64, & 32 bit keys ESP DES (RFC-1829): YES Other implemented AH transforms: none Other implemented ESP transforms: none Key Management: manual Platforms: ??? Lineage of IPsec Code: ??? Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Antonio Fernandez Claimed Interoperability: _______________________________________________________________________ Name of Implementation: cisco IOS (TM) Organisation: cisco Systems Which IP versions are supported: IPv4 & IPv6 in progress Implemented Features: AH (RFC-1825,1826): In Progress ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): In Progress ESP DES (RFC-1829): In Progress Other implemented AH transforms: AH-HMAC-MD5 & AH-HMAC-SHA in progress. Other implemented ESP transforms: DES-CBC-MD5-Replay in progress, proprietary DES transform. Key Management: proprietary now; ISAKMP+Oakley 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 Claimed Interoperability: TBA _____________________________________________________________________ Name of Implementation: MultiNet for Windows (Cisco TCP/IP Suite 100) Organisation: Cisco/TGV Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES (w/ latest Internet Drafts) ESP (RFC-1825,1827): YES (w/ latest Internet Drafts) AH MD5 (RFC-1828): NO ESP DES (RFC-1829): NO Other AH Transforms: AH-HMAC-MD5, AH-HMAC-SHA Other ESP Transforms: DES-CBC-MD5-Replay Key Management: manual keying, has PF_KEY API ISAKMP/Oakley in progress Platforms: Windows 95 Lineage of IPsec Code: TGV and cisco, referenced the NRL software Lineage of Key Mgmt Code: TGV and cisco Location of Source Code: proprietary Point of Contact: Derrell Piper Claimed Interoperability: TBD _______________________________________________ Name of Implementation: OnNet Organisation: ftp Software Which IP versions are supported: IPv4 now, IPv6 planned Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: none Key Management: manual now; ISAKMP+Oakley is planned. Platforms: Windows95, Windows 3.11 Lineage of IPsec Code: FTP Software; referenced but didn't port the NRL software. Lineage of Key Mgmt Code: FTP Software; referenced but didn't port the NRL software. Plan to port cisco's ISAKMP+Oakley code. Location of Source Code: proprietary Point of Contact: Naganand Doraswamy Claimed Interoperability: Raptor, SCC, IBM, & TIS now; testing with NRL is in progress. _______________________________________________________________________ Name of Implementation: Trusted Security Firewall-Guard (GTFW-GD) Organisation: Gemini Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-SHA, proprietary Other ESP Transforms: none Key Management: manual, proprietary Platforms: Gemini Trusted Firewall-Guard Lineage of IPsec Code: Gemini Lineage of Key Mgmt Code: Gemini Location of Source Code: Proprietary Point of Contact: Dr. Tien F. Tao Claimed Interoperability: IBM SNG, MorningStar, NIST, Raptor Systems, SCC, SOS, TIS _______________________________________________________________________ Name of Implementation: IBM SNG Organisation: IBM Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES, both 32-bit & 64-bit IV Other AH Transforms: HMAC MD5 Other ESP Transforms: none Key Management: manual, proprietary Platforms: IBM AIX Lineage of IPsec Code: IBM Lineage of Key Mgmt Code: IBM Location of Source Code: proprietary Point of Contact: Claimed Interoperability: For ESP-DES & AH-MD5: NRL, JI, KA9Q, NIST, TIS, Checkpoint, SOS, Gemini, MorningStar, Raptor, SCC, TimeStep For ESP-DES & HMAC MD5: NIST, Raptor _______________________________________________________________________ Name of Implementation: SafeNet Organisation: Information Resources Engineering, Inc. Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): Planned ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): Planned ESP DES (RFC-1829): In Progress Other AH Transforms: none Other ESP Transforms: DES-Counter-ANSI-X9.9 Key Management: SKIP in progress; various ANSI in progress Platforms: V.34 modem, IP over PPP, Ethernet Lineage of IPsec Code: Information Resources Engineering Lineage of Key Mgmt Code: Information Resources Engineering Location of Source Code: proprietary Point of Contact: Claimed Interoperability: TBA _______________________________________________________________________ Name of Implementation: BorderGuard and Security Router Organisation: Network Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): TBD ESP (RFC-1825,1827): In Progress AH MD5 (RFC-1828): TBD ESP DES (RFC-1829): TBD Other AH Transforms: none Other ESP Transforms: DES-CBC-MD5-Replay in progress Key Management: manual, proprietary D-H are done now. ISAKMP+Oakley is in progress. Platforms: Network Systems routers Lineage of IPsec Code: Network Systems Lineage of Key Mgmt Code: Network Systems Location of Source Code: proprietary Point of Contact: Ted Doty Claimed Interoperability: TBD _______________________________________________________________________ Name of Implementation: CryptoWall (TM) Organisation: RADGUARD, Ltd. IP versions: IPv4 Implemented Features: AH (RFC-1825,1826): In progress ESP (RFC-1825,1827): In progress AH MD5 (RFC-1828): In progress ESP DES (RFC-1829): In progress Other AH Transforms: none Other ESP Transforms: DES-CBC+DES-MAC in progress Key Management: In progress Platforms: CryptoWall Lineage of IPsec Code: RADGUARD Lineage of Key Mgmt Code: RADGUARD Location of Source Code: proprietary Point of Contact: Dan Frommer Claimed Interoperability: TBD _______________________________________________________________________ Name of Implementation: Eagle Organisation: Raptor Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: AH-HMAC-MD5 Other ESP Transforms: DES-CBC-MD5-Replay is planned Key Management: manual, proprietary Platforms: Raptor Eagle Firewall Lineage of IPsec Code: Raptor Lineage of Key Mgmt Code: proprietary Location of Source Code: proprietary Point of Contact: Jeff Kraemer Claimed Interoperability: FTP Software, IBM SNG, MorningStar, NIST, Secure Computing, SOS, TimeStep, TIS, Gemini ______________________________________________________________________ Name of Implementation: Sidewinder Firewall Organisation: Secure Computing Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: none Key Management: manual Platforms: Sidewinder Firewall Lineage of IPsec Code: ??? Lineage of Key Mgmt Code: not applicable Location of Source Code: proprietary Point of Contact: Claimed Interoperability: _______________________________________________________________________ Name of Implementation: PERMIT Organisation: TimeStep Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: HMAC-MD5 and HMAC-SHA are both in progress Other ESP Transforms: RCx in progress Key Management: manual, proprietary, ISAKMP+Oakley in progress Platforms: Windows 3.11, Windows95, WindowsNT in progress Lineage of IPsec Code: Timestep Lineage of Key Mgmt Code: TimeStep Location of Source Code: proprietary Point of Contact: Stephane Lacelle Claimed Interoperability: IBM, Raptor, Checkpoint, TIS, Morningstar _______________________________________________________________________ Name of Implementation: TIS Gauntlet Organisation: Trusted Information Systems Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES Key Management: manual, proprietary Platforms: TIS Gauntlet Lineage of IPsec Code: NRL-derived Lineage of Key Mgmt Code: TIS ??? Location of Source Code: proprietary Point of Contact: Rick Murphy, rick@tis.com Claimed Interoperability: NRL _______________________________________________________________________ Name of Implementation: V-ONE SmartWall Organisation: V-One Which IP versions are supported: IPv4 Implemented Features: AH (RFC-1825,1826): YES ESP (RFC-1825,1827): YES AH MD5 (RFC-1828): YES ESP DES (RFC-1829): YES Other AH Transforms: none Other ESP Transforms: ESP-3DES, RC4, stream DES Key Management: manual, proprietary Platforms: V-ONE SmartWall Lineage of IPsec Code: NRL-derived Lineage of Key Mgmt Code: V-One ??? Location of Source Code: proprietary Point of Contact: Jason Wang Claimed Interoperability: NRL ______________________________________________________________________ -- Received: from relay.hq.tis.com by neptune.TIS.COM id aa02746; 23 Jul 96 22:52 EDT Received: by relay.hq.tis.com; id WAA23003; Tue, 23 Jul 1996 22:55:21 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022999; Tue, 23 Jul 96 22:54:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24901; Tue, 23 Jul 96 22:54:31 EDT Received: by relay.hq.tis.com; id WAA22993; Tue, 23 Jul 1996 22:54:51 -0400 Received: from btw.aa.net(204.157.220.237) by relay.tis.com via smap (V3.1.1) id xma022989; Tue, 23 Jul 96 22:54:42 -0400 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 25jan96) with ESMTP id TAA14278 for ; Tue, 23 Jul 1996 19:57:02 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id TAA25654 for ipsec@TIS.COM; Tue, 23 Jul 1996 19:57:00 -0700 (PDT) Message-Id: <199607240257.TAA25654@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Tue, 23 Jul 96 19:56:57 -0700 To: ipsec@TIS.COM Subject: DNSSEC for IPSEC? Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have some questions I am asking myself with regard to using DNS to aid IPSEC. Are they valid? I dunno, but here they are. What do you think? * I am not confident of the security of the root servers. What is the effect of root server key compromise or the server itself? * I believe that, for DNS records to be trustworthy, all zones from the source zone to the root be verifiable. What is the likelihood that will happen anytime soon? What is "soon"? Also, the InterNIC does not impress me as a body that reacts quickly. I am not confident of receiving quick response should I want to change my zone key as a result of compromise. -dpg Received: from relay.hq.tis.com by neptune.TIS.COM id aa13881; 24 Jul 96 10:20 EDT Received: by relay.hq.tis.com; id KAA11535; Wed, 24 Jul 1996 10:23:01 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011531; Wed, 24 Jul 96 10:22:33 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15819; Wed, 24 Jul 96 10:22:11 EDT Received: by relay.hq.tis.com; id KAA11521; Wed, 24 Jul 1996 10:22:31 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma011491; Wed, 24 Jul 96 10:22:07 -0400 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for relay.hq.tis.com [192.94.214.100]) with SMTP; 24 Jul 1996 14:24:22 UT Received: from Joe_Tardo.raptor.com (pool019.Max4.San-Francisco.CA.DYNIP.ALTER.NET [153.37.101.19]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id KAA02140; Wed, 24 Jul 1996 10:22:55 -0400 (EDT) Message-Id: <2.2.32.19960724142314.006d77e0@204.7.242.10> X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 07:23:14 -0700 To: Robert Moskowitz From: Joe Tardo Subject: Re: Key Management, anyone? Cc: "Theodore Y. Ts'o" , John Gilmore , ipsec@TIS.COM, gnu@toad.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 09:58 AM 7/23/96 -0400, Robert Moskowitz wrote: >Yah, I am planning to do this :) Does DNSSEC have the RR's and stuff that make it easy? Last time I looked, you would have to do something like cross certification yourself. = ========================================================= = Joe Tardo Voice: 415-843-0991 Raptor Systems, Inc. 777 San Antonio Ave. Suite 92 Fax: 408-524-2988 Palo Alto, CA. 94303 = ========================================================= = Received: from relay.hq.tis.com by neptune.TIS.COM id aa14286; 24 Jul 96 10:39 EDT Received: by relay.hq.tis.com; id KAA11993; Wed, 24 Jul 1996 10:42:31 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011990; Wed, 24 Jul 96 10:42:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16775; Wed, 24 Jul 96 10:41:42 EDT Received: by relay.hq.tis.com; id KAA11987; Wed, 24 Jul 1996 10:42:01 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma011985; Wed, 24 Jul 96 10:41:58 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Wed, 24 Jul 1996 10:44:17 -0400 Received: from localhost (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with SMTP id KAA02491; Wed, 24 Jul 1996 10:43:48 -0400 Message-Id: <199607241443.KAA02491@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: Host localhost didn't use HELO protocol To: Joe Tardo Cc: Robert Moskowitz , "Theodore Y. Ts'o" , John Gilmore , ipsec@TIS.COM Subject: Re: Key Management, anyone? In-Reply-To: tardo's message of Wed, 24 Jul 1996 07:23:14 -0700. <2.2.32.19960724142314.006d77e0@204.7.242.10> Date: Wed, 24 Jul 1996 10:43:45 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Does DNSSEC have the RR's and stuff that make it easy? Last > time I looked, you would have to do something like cross > certification yourself. There was supposed to be a subgroup of DNSSEC getting together to work on the trust issues. I volunteered to participate, but nobody got back to me so I assume that nothing has happened yet.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa17546; 24 Jul 96 12:53 EDT Received: by relay.hq.tis.com; id MAA14934; Wed, 24 Jul 1996 12:56:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014922; Wed, 24 Jul 96 12:56:04 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23869; Wed, 24 Jul 96 12:55:42 EDT Received: by relay.hq.tis.com; id MAA14912; Wed, 24 Jul 1996 12:56:02 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma014907; Wed, 24 Jul 96 12:55:57 -0400 Received: by pilotx.firewall.is.chrysler.com; id MAA11121; Wed, 24 Jul 1996 12:58:24 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma011103; Wed, 24 Jul 96 12:58:19 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id MAA05892; Wed, 24 Jul 1996 12:51:47 -0400 (EDT) Message-Id: <2.2.32.19960724165753.00c17f20@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 12:57:53 -0400 To: Joe Tardo From: Robert Moskowitz Subject: Re: Key Management, anyone? Cc: "Theodore Y. Ts'o" , John Gilmore , ipsec@TIS.COM, gnu@toad.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:23 AM 7/24/96 -0700, Joe Tardo wrote: >At 09:58 AM 7/23/96 -0400, Robert Moskowitz wrote: >>Yah, I am planning to do this :) > >Does DNSSEC have the RR's and stuff that make it easy? Last >time I looked, you would have to do something like cross >certification yourself. Let's say that the AIAG will be the CA for this. The main OEMs (there are 17 of us, only the 3 main US ones need to do it, the others will run in then) could certify the AIAG to do it. Of course, the AIAG would be certifying each of our keys. But the multiple to one back to multiple trust model should work. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa18528; 24 Jul 96 13:36 EDT Received: by relay.hq.tis.com; id NAA16323; Wed, 24 Jul 1996 13:38:44 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016292; Wed, 24 Jul 96 13:38:20 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26067; Wed, 24 Jul 96 13:37:58 EDT Received: by relay.hq.tis.com; id NAA16276; Wed, 24 Jul 1996 13:38:14 -0400 Received: from unknown(132.197.8.9) by relay.tis.com via smap (V3.1.1) id xma016260; Wed, 24 Jul 96 13:37:52 -0400 Received: from rcmppc2 by ns.gte.com (8.7.5/) Message-Id: <2.2.32.19960724173704.002d8798@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 13:37:04 -0400 To: Bill Sommerfeld From: Stuart Jacobs Subject: Re: Key Management, anyone? Cc: Joe Tardo , Robert Moskowitz , "Theodore Y. Ts'o" , John Gilmore , ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I would like to participate also should a subgroup be formed. I am working on strong authentication for route optimized mobile IP based on using public/private key digital signatures. This approach will require an efficient means for home/foreign agents and mobile hosts to obtain public keys for digital signature checking. At 10:43 AM 7/24/96 -0400, Bill Sommerfeld wrote: >> Does DNSSEC have the RR's and stuff that make it easy? Last >> time I looked, you would have to do something like cross >> certification yourself. > >There was supposed to be a subgroup of DNSSEC getting together to work >on the trust issues. I volunteered to participate, but nobody got >back to me so I assume that nothing has happened yet.. > > - Bill > > ========================== Stuart Jacobs Secure Systems Department GTE Labs, Room 3-198 40 Sylvan Road Waltham, MA 02254 (617)466-3076 ========================== Received: from relay.hq.tis.com by neptune.TIS.COM id aa10535; 25 Jul 96 4:28 EDT Received: by relay.hq.tis.com; id EAA02177; Thu, 25 Jul 1996 04:30:42 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002173; Thu, 25 Jul 96 04:30:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22041; Thu, 25 Jul 96 04:29:51 EDT Received: by relay.hq.tis.com; id EAA02170; Thu, 25 Jul 1996 04:30:11 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma002165; Thu, 25 Jul 96 04:29:56 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id BAA22290; Thu, 25 Jul 1996 01:30:50 -0700 (PDT) Message-Id: <199607250830.BAA22290@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ipsec@TIS.COM, gnu@toad.com Subject: Re: DNSSEC for IPSEC? In-Reply-To: <199607240257.TAA25654@imo.plaintalk.bellevue.wa.us> Date: Thu, 25 Jul 1996 01:30:49 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I have some questions I am asking myself with regard to > using DNS to aid IPSEC. Are they valid? I dunno, but here > they are. What do you think? We should probably limit this form of traffic on the list. People with specific questions of the "I don't know but..." variety should send them directly to me. People with issues or questions of the "I've read the spec and thought about it and..." variety should send them to the whole list. > * I am not confident of the security of the root servers. > What is the effect of root server key compromise or > the server itself? Signing of DNS records is designed to be performed offline. The input to signing is an ASCII zone file and a private key; the signing results in a new ASCII zone file, which includes the original DNS records, plus SIG records interspersed throughout. If one of the root zone's servers (there are half a dozen) is compromised, there is no issue. It will not be able to present authenticated bogus information, since the root zone's private key is held offline. If the root zone's key becomes known, those who have it can authentically create new top-level domains, or authentically sign new keys for existing top-level domains such as COM. However, the attackers would not have COM's private key. They could only make a new one up, and sign that. They could not authenticate a new key for e.g. SUN.COM, without faking up an entire new COM domain, with new signatures on every entry. This would likely lead to detection. There is a trickiness possible here; if the DNSSEC validation algorithm permits the use of a key for e.g. SUN.COM that is signed directly by the root, despite the existence of a level of delegation in the middle (COM), a root key compromise allows for more mischief. The holder of the root key could sign new bogus keys or other records at any level of the hierarchy. I expect that as a result the algorithm will disallow such "shortcut" validation. > * I believe that, for DNS records to be trustworthy, all > zones from the source zone to the root be verifiable. What > is the likelihood that will happen anytime soon? What is > "soon"? There are two parts of the answer. First, within organizations, verification need not go all the way to the root, just to the common ancestor of the communicating parties. yyy.tokyo.sun.com need not trust the root or COM when checking keys for zzz.scotland.sun.com, if it has been configured to know sun.com's public key in a config file. This will be useful in intra-nets and in bootstrapping the Internet. The use of "upward key signatures" can also make this easier to administer. I have spoken with representatives of most of the major NICs at IETF, as well as with Jon Postel who runs the root zone. They all indicated a willingness to sign records for their customers as soon as the software to do so was available. They, too, are interested in securing the infrastructure that they are paid to maintain :-). I believe that most high level zones will have keys and offer signatures before the end of this year. John Gilmore Received: from relay.hq.tis.com by neptune.TIS.COM id aa19386; 25 Jul 96 12:50 EDT Received: by relay.hq.tis.com; id MAA13966; Thu, 25 Jul 1996 12:51:46 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013927; Thu, 25 Jul 96 12:51:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11044; Thu, 25 Jul 96 12:50:55 EDT Received: by relay.hq.tis.com; id MAA13924; Thu, 25 Jul 1996 12:51:16 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma013885; Thu, 25 Jul 96 12:50:46 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 25 Jul 1996 12:53:07 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA03817; Thu, 25 Jul 1996 12:53:06 -0400 Message-Id: <199607251653.MAA03817@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Phil Karn Cc: baldwin@rsa.com, ipsec@TIS.COM Subject: Re: Exporting an IPSec implementation In-Reply-To: karn's message of Fri, 19 Jul 1996 23:25:28 -0700. <199607200625.XAA05167@servo.qualcomm.com> Date: Thu, 25 Jul 1996 12:53:00 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Does the DoS 40-bit export policy apply to source, or only to > object? My experience with the export control people is that they don't like source exports at all (and they have difficulty understanding the concept of free software); they consider code which *calls* a cryptographic API (because it would necessarily have a (possibly trivial) key management component) to be the "ancillary equipment" (in the "cryptographic hardware and ancillary equipment") of the ITAR. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa19838; 25 Jul 96 13:09 EDT Received: by relay.hq.tis.com; id MAA13824; Thu, 25 Jul 1996 12:49:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013799; Thu, 25 Jul 96 12:48:49 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA10849; Thu, 25 Jul 96 12:48:25 EDT Received: by relay.hq.tis.com; id MAA13792; Thu, 25 Jul 1996 12:48:46 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma013784; Thu, 25 Jul 96 12:48:18 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 25 Jul 1996 12:50:42 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA03803; Thu, 25 Jul 1996 12:50:41 -0400 Message-Id: <199607251650.MAA03803@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: John Gilmore Cc: dennis.glatting@plaintalk.bellevue.wa.us, ipsec@TIS.COM Subject: Re: DNSSEC for IPSEC? In-Reply-To: gnu's message of Thu, 25 Jul 1996 01:30:49 -0700. <199607250830.BAA22290@toad.com> Date: Thu, 25 Jul 1996 12:50:30 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk With respect to validation policies, I think there's also need for some more advanced policies, allowing for a domain-to-domain web of trust/cross certification, where the trust graph doesn't match the domain hierarchy. E.g., to use Bob Moskowitz's auto industry model, Chrysler and its big subcontractors may well "trust" the root domain to not screw up on a day-to-day basis, but because they have long-term business relationship involving the exchange of hundreds of millions of dollars a year, and they only each send $50/year to the Internic, they might be happier if there was a direct trust path between their zones not involving any organization which wasn't as committed as they were to their business relationship. One way to do this would be to configure the trusted key for chrysler.com into all resolvers in the subcontractor.com domain, but that would be a management nightmare; an alternative would be to set up some sort of "trusted shadow" of the root inside chrysler.com (e.g., a peers.chrysler.com zone signed by the chrysler key containing KEY rr's off of `subcontractor.com.peers.chrysler.com'); the validation model (which is admittedly an extension of the current DNSsec model) would trust zone keys inside the shadow subtree before you trust keys certified through the root.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa25726; 25 Jul 96 17:34 EDT Received: by relay.hq.tis.com; id RAA26019; Thu, 25 Jul 1996 17:36:51 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026010; Thu, 25 Jul 96 17:36:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02046; Thu, 25 Jul 96 17:35:59 EDT Received: by relay.hq.tis.com; id RAA26005; Thu, 25 Jul 1996 17:36:21 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1) id xma026001; Thu, 25 Jul 96 17:36:13 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA02034; Thu, 25 Jul 1996 14:38:33 -0700 (PDT) Date: Thu, 25 Jul 1996 14:38:33 -0700 (PDT) From: Phil Karn Message-Id: <199607252138.OAA02034@servo.qualcomm.com> To: sommerfeld@apollo.hp.com Cc: baldwin@rsa.com, ipsec@TIS.COM In-Reply-To: <199607251653.MAA03817@thunk.orchard.medford.ma.us> (message from Bill Sommerfeld on Thu, 25 Jul 1996 12:53:00 -0400) Subject: Re: Exporting an IPSec implementation Sender: ipsec-approval@neptune.tis.com Precedence: bulk >My experience with the export control people is that they don't like >source exports at all (and they have difficulty understanding the >concept of free software); they consider code which *calls* a >cryptographic API (because it would necessarily have a (possibly >trivial) key management component) to be the "ancillary equipment" (in >the "cryptographic hardware and ancillary equipment") of the ITAR. Exactly what I expected to hear. Which means the 40-bit rule isn't much use to us, given the IETF tradition of releasing free reference source implementations, is it? Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa29202; 25 Jul 96 21:22 EDT Received: by relay.hq.tis.com; id VAA01407; Thu, 25 Jul 1996 21:25:24 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001404; Thu, 25 Jul 96 21:25:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08117; Thu, 25 Jul 96 21:24:34 EDT Received: by relay.hq.tis.com; id VAA01398; Thu, 25 Jul 1996 21:24:54 -0400 Received: from hp.com(15.255.152.4) by relay.tis.com via smap (V3.1.1) id xma001394; Thu, 25 Jul 96 21:24:31 -0400 Received: from hpindlm.cup.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA154914417; Thu, 25 Jul 1996 18:26:57 -0700 Received: by hpindlm.cup.hp.com (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA27432; Thu, 25 Jul 1996 18:26:56 -0700 Date: Thu, 25 Jul 1996 18:26:56 -0700 From: Wan-Yen Hsu Message-Id: <9607260126.AA27432@hpindlm.cup.hp.com> To: ipsec@TIS.COM Subject: Any key mgmt proto comparison info available? Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, Has any one done comparison between SKIP and ISAKMP? Where can I find the information? Thanks for your help. wh Received: from relay.hq.tis.com by neptune.TIS.COM id aa03086; 26 Jul 96 2:40 EDT Received: by relay.hq.tis.com; id CAA04598; Fri, 26 Jul 1996 02:43:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004595; Fri, 26 Jul 96 02:42:57 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13811; Fri, 26 Jul 96 02:42:25 EDT Received: by relay.hq.tis.com; id CAA04591; Fri, 26 Jul 1996 02:42:47 -0400 Received: from btw.aa.net(204.157.220.237) by relay.tis.com via smap (V3.1.1) id xma004589; Fri, 26 Jul 96 02:42:40 -0400 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 25jan96) with ESMTP id XAA00460; Thu, 25 Jul 1996 23:45:04 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id XAA00284; Thu, 25 Jul 1996 23:45:02 -0700 (PDT) Message-Id: <199607260645.XAA00284@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Thu, 25 Jul 96 23:45:00 -0700 To: John Gilmore Subject: Re: DNSSEC for IPSEC? Cc: ipsec@TIS.COM Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199607250830.BAA22290@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Subject: Re: DNSSEC for IPSEC? Date: Thu, 25 Jul 1996 01:30:49 -0700 > > * I am not confident of the security of the root servers. > > What is the effect of root server key compromise or > > the server itself? > > Signing of DNS records is designed to be performed > offline. The input to signing is an ASCII zone file and a > private key; the signing results in a new ASCII zone file, > which includes the original DNS records, plus SIG > records interspersed throughout. > > If one of the root zone's servers (there are half a dozen) > is compromised, there is no issue. It will not be able to > present authenticated bogus information, since the > root zone's private key is held offline. > There is an issue. Storing the private key off-line is not a deterrent: the mischievous person simply generates a new key pair and re-signs the zone. [ stuff deleted ] > > * I believe that, for DNS records to be trustworthy, all > > zones from the source zone to the root be verifiable. What > > is the likelihood that will happen anytime soon? What is > > "soon"? > > There are two parts of the answer. First, within > organizations, verification need not go all the way to > the root, just to the common ancestor of the > communicating parties. yyy.tokyo.sun.com need not > trust the root or COM when checking keys for > zzz.scotland.sun.com, if it has been configured to know > sun.com's public key in a config file. This will be useful > in intra-nets and in bootstrapping the Internet. The use > of "upward key signatures" can also make this easier to > administer. > > I have spoken with representatives of most of the major > NICs at IETF, as well as with Jon Postel who runs the root > zone. They all indicated a willingness to sign records > for their customers as soon as the software to do so was > available. They, too, are interested in securing the > infrastructure that they are paid to maintain :-). > > I believe that most high level zones will have keys and > offer signatures before the end of this year. > The value of DNS-SEC is if everyone uses it. Until that time, which may be a decade or more down the road, resolvers are going to have to trust any response, thereby reducing DNS-SEC's value to a simple checksum. There is little sign current DNS problems are going to be resolved any time too. For example, there are many DNS servers issuing lame responses. Recently, Paul Vixie enabled validation code in a beta release of BIND. There was much complaint and the code deactivated. I question the value of using DNS-SEC to aid IPSEC. Coupled with the issues I noted, and more I have not noted, there is an open validation issue and little, if any, operational experience. I am not convinced DNS-SEC will offer much value for many years. -dpg Received: from relay.hq.tis.com by neptune.TIS.COM id aa05150; 26 Jul 96 5:13 EDT Received: by relay.hq.tis.com; id FAA05317; Fri, 26 Jul 1996 05:16:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005313; Fri, 26 Jul 96 05:15:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16067; Fri, 26 Jul 96 05:15:25 EDT Received: by relay.hq.tis.com; id FAA05310; Fri, 26 Jul 1996 05:15:47 -0400 Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1) id xma005308; Fri, 26 Jul 96 05:15:39 -0400 From: Masataka Ohta Message-Id: <199607260918.SAA16348@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA16348; Fri, 26 Jul 1996 18:17:57 +0859 Subject: Re: DNSSEC for IPSEC? To: ipsec@TIS.COM Date: Fri, 26 Jul 96 18:17:57 JST X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk DNS is a database. Secure DNS make the database secure, as long as the managers of the database is reliable. That is, ownership of DNS name space and IP address space may be considered to be secure. Nothing more than that. So, secure DNS as is can offer only the abstract security over a DNS tree having nothing to do with the real world. For real world applications, we need some social and/or network mechanism for the anchoring with some API. For example, an authentication chain on election must be rooted by the governments. On the other hand, an economically meaningful authentication chain may be rooted by reliable banks, credit card companies or issuers of prepaid cards, which may, then, be secured by some physically written contract. To make matters worse, which entities are reliable varies currency by currency, person by person and by the amount of the transaction. Finally, if there is a reliable anchor into DNS tree, secure DNS is a mechanism to offer a secure authentication chain from it mostly along the structure of DNS tree. But, as people's identity is maintained by goverment hierarchy unrelated to DNS tree, I'm not sure whether secure DNS is useful in the real world except for the management of ownership of DNS name space and IP address space. Masataka Ohta Received: from relay.hq.tis.com by neptune.TIS.COM id aa11782; 26 Jul 96 10:16 EDT Received: by relay.hq.tis.com; id KAA11034; Fri, 26 Jul 1996 10:19:35 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011032; Fri, 26 Jul 96 10:19:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26808; Fri, 26 Jul 96 10:18:43 EDT Received: by relay.hq.tis.com; id KAA11025; Fri, 26 Jul 1996 10:19:05 -0400 Received: from soscorp.soscorp.com(204.52.248.130) by relay.tis.com via smap (V3.1.1) id xma011021; Fri, 26 Jul 96 10:18:41 -0400 Received: from fearless.soscorp.com (fearless.soscorp.com [204.52.249.130]) by brimstone.soscorp.com ($Revision: 2.30 $/8.6.12/8.6.4.287) with BSMTP id BS0008084/KAA08092; Fri, 26 Jul 1996 10:21:02 -0400 Received: from fearless.soscorp.com (aggelos@localhost) by fearless.soscorp.com (8.6.12/8.6.4.287) with ESMTP id KAA20363; Fri, 26 Jul 1996 10:20:14 -0400 Message-Id: <199607261420.KAA20363@fearless.soscorp.com> To: dennis.glatting@plaintalk.bellevue.wa.us Cc: John Gilmore , ipsec@TIS.COM Subject: Re: DNSSEC for IPSEC? In-Reply-To: Your message of "Thu, 25 Jul 1996 23:45:00 PDT." <199607260645.XAA00284@imo.plaintalk.bellevue.wa.us> Date: Fri, 26 Jul 1996 10:20:13 -0400 From: "Angelos D. Keromytis" Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199607260645.XAA00284@imo.plaintalk.bellevue.wa.us>, Dennis Glattin g writes: > >There is an issue. Storing the private key off-line is not >a deterrent: the mischievous person simply generates a >new key pair and re-signs the zone. Which would generate a million alarms as the signature created by this new key does not verify under the old public key (the legitimate one). There is this small issue of key distribution/revocation you see. So one would have to break/acquire/bribe to get the key pairs of the entities that would sign the root's public key (i assume there will be such safety precautions). >The value of DNS-SEC is if everyone uses it. Until that >time, which may be a decade or more down the road, >resolvers are going to have to trust any response, >thereby reducing DNS-SEC's value to a simple checksum. > This is partly true; while IPSEC cannot depend on DNSSEC at this point, it makes sense (very much so) to have full support for it and "complain" whenever it is not available (logs, popup windows, your pick). >I question the value of using DNS-SEC to aid IPSEC. >Coupled with the issues I noted, and more I have not noted, >there is an open validation issue and little, if any, >operational experience. I am not convinced DNS-SEC will >offer much value for many years. > I would be interested in hearing the not noted issues, as would most in this list i believe. Regards, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMfjUGL0pBjh2h1kFAQEAUwP9EWoHMJ3y8KsS9qyDtIcts35ngSZeKaMf GNBdmypfw2a2nThesXtXa2YkZfLNdpG21qUesvSOMNMMglFYn1AO6Yx5kf0gASM4 wAR42xfHWxZo2u099bL1nViP4L3zPxJFupz6Vo+kaDJbOxzpckX/ho1ecFFTn0BS 7gqOjxojkXw= =7Ezz -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa17027; 26 Jul 96 15:05 EDT Received: by relay.hq.tis.com; id PAA19603; Fri, 26 Jul 1996 15:07:42 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019599; Fri, 26 Jul 96 15:07:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13649; Fri, 26 Jul 96 15:06:50 EDT Received: by relay.hq.tis.com; id PAA19590; Fri, 26 Jul 1996 15:07:12 -0400 Received: from toxicwaste.mit.edu(18.85.0.40) by relay.tis.com via smap (V3.1.1) id xma019574; Fri, 26 Jul 96 15:06:42 -0400 Received: (from warlord@localhost) by toxicwaste.media.mit.edu (8.6.10/8.6.10) id PAA24684; Fri, 26 Jul 1996 15:08:47 -0400 Message-Id: <199607261908.PAA24684@toxicwaste.media.mit.edu> To: dennis.glatting@plaintalk.bellevue.wa.us Cc: John Gilmore , ipsec@TIS.COM Subject: Re: DNSSEC for IPSEC? In-Reply-To: Your message of "Thu, 25 Jul 1996 23:45:00 PDT." <199607260645.XAA00284@imo.plaintalk.bellevue.wa.us> Date: Fri, 26 Jul 1996 15:08:46 EDT From: Derek Atkins Sender: ipsec-approval@neptune.tis.com Precedence: bulk > There is an issue. Storing the private key off-line is not > a deterrent: the mischievous person simply generates a > new key pair and re-signs the zone. Actually, this doesn't work. The problem is that the parent zone needs to have signed the zone's key. So, I couldn't go and forge a zone key for MIT.EDU, because the MIT.EDU key needs to be signed by the EDU key, which in turn needs to be signed by the root key. So, you can't forge a key without forging the whole hierarchy. -derek Received: from relay.hq.tis.com by neptune.TIS.COM id aa20445; 26 Jul 96 18:39 EDT Received: by relay.hq.tis.com; id SAA24450; Fri, 26 Jul 1996 18:41:53 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024447; Fri, 26 Jul 96 18:41:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25502; Fri, 26 Jul 96 18:41:01 EDT Received: by relay.hq.tis.com; id SAA24444; Fri, 26 Jul 1996 18:41:23 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma024442; Fri, 26 Jul 96 18:41:22 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id SAA21879; Fri, 26 Jul 1996 18:48:15 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Jul 1996 18:44:18 -0400 To: Steve Bellovin From: Stephen Kent Subject: Re: challenges for the IPSEC group Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steve, Just a note that the X.509m v3 certificates no longer require the use of distinguished names, at all. There is explicit support for both IP addresses and for DNS names (as well as RFC 822 email addresses, for individual user names). So, one could use this certificate format to represent the various name forms that you have pointed out are appropriate, in different contexts, for use with IPSEC. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa02540; 27 Jul 96 15:45 EDT Received: by relay.hq.tis.com; id PAA00575; Sat, 27 Jul 1996 15:48:26 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000573; Sat, 27 Jul 96 15:47:58 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13912; Sat, 27 Jul 96 15:47:33 EDT Received: by relay.hq.tis.com; id PAA00570; Sat, 27 Jul 1996 15:47:56 -0400 Received: from btw.aa.net(204.157.220.237) by relay.tis.com via smap (V3.1.1) id xma000568; Sat, 27 Jul 96 15:47:47 -0400 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 25jan96) with ESMTP id MAA02013; Sat, 27 Jul 1996 12:50:03 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id MAA00914; Sat, 27 Jul 1996 12:50:01 -0700 (PDT) Message-Id: <199607271950.MAA00914@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Sat, 27 Jul 96 12:49:58 -0700 To: "Angelos D. Keromytis" Subject: Re: DNSSEC for IPSEC? -- or, how to exploit DNSSEC Cc: John Gilmore , ipsec@TIS.COM Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199607261420.KAA20363@fearless.soscorp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk There are several problems with DNSSEC that make it ripe for exploitation. I have included some of my thoughts in this message and are the basis of why I feel it is not a good idea to mandate connectivity between DNSSEC and IPSEC -- at least for the near future. The holes in DNSSEC are not confined to the extensions themselves rather they include practicality of DNS management and operation. The DNSSEC extensions document little addresses the issue of key roll-over. Consequently, it is difficult to differentiate between an alarm be sounded as a result of a root server compromise and the attacker replacing its key pair and one sounded in response to legitimate key roll-over. The document mentions the issue of cross signatures but does not indicate their role. I have not found a document that addresses these issues. The DNSSEC extensions document recommends a procedure for server private key management. That is all it is: a recommendation. Is that how the entities managing the root servers will manage them? Moreover, how are the root servers themselves secured? How will the weakest link, the people, be managed? Administrators tend to aggregate service classes to "ease administration". The same set of procedures and functions applied to one service are applied to all members of the aggregate. Therefore, it is highly probable that a technique used to penetrate one root server is a successful avenue to another. Consequently, it is possible to create a believable web of trust across compromised servers. When a parent zone changes its key, all its siblings will have to be updated (hmm, what is the number of zones under COM?). How will the administrators of those zones get the new key? How can they trust what they are getting? Suppose for a moment that a root server is compromised. Oh what chaos one can create. * A compromised server could redirect the address of the trusted key repository, resulting in a schizophrenic Internet. * If bogus responses are believable, the cache of tens of thousands of servers will quickly be polluted. To clean them, those servers will have to be rebooted. The result is something close to rebooting the Internet. * The root server can reduce TTL values to their minimum, resulting in other servers often reloading the RRs and recomputing SIGs -- watch their CPU load jump! * How about increasing key sizes too. Morris did nothing compared to the damage possible with DNSSEC. Glue data is not signed. Therefore, a server could redirect requests for nsa.gov, cia.gov, and whitehouse.gov to eff.org. If eff.org is not secure I suspect many recipients will believe the responses, i.e., until they get there. Why? Because for many years DNSSEC aware resolvers are going to have to live within the current, DNSSEC unaware, Internet. It is easy for a DNSSEC aware resolver to believe a response from a DNSSEC aware source; however, in a combined DNSSEC aware and unaware Internet, what is a resolver going to do when it gets a response from a DNSSEC unaware source? Ignore it? To do so would limit resolution breadth. (Bear in mind that no body has the authority to impose DNSSEC across the Internet. Therefore, the issue of DNSSEC aware resolvers having to figure out what to do with responses from DNSSEC unaware sources will not go away.) What kind of chaos can be created if the server's code is replaced? One thought is to always clear the AD bit in responses. Does DNSSEC add value to IPSEC? Maybe. I believe that for the next several years its value is limited. -dpg Received: from relay.hq.tis.com by neptune.TIS.COM id aa03648; 27 Jul 96 17:37 EDT Received: by relay.hq.tis.com; id RAA01217; Sat, 27 Jul 1996 17:40:26 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001211; Sat, 27 Jul 96 17:40:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15634; Sat, 27 Jul 96 17:39:33 EDT Received: by relay.hq.tis.com; id RAA01203; Sat, 27 Jul 1996 17:39:57 -0400 Received: from btw.aa.net(204.157.220.237) by relay.tis.com via smap (V3.1.1) id xma001187; Sat, 27 Jul 96 17:39:36 -0400 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 25jan96) with ESMTP id OAA02092; Sat, 27 Jul 1996 14:41:54 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id OAA00960; Sat, 27 Jul 1996 14:41:52 -0700 (PDT) Message-Id: <199607272141.OAA00960@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Sat, 27 Jul 96 14:41:48 -0700 To: Derek Atkins Subject: Re: DNSSEC for IPSEC? Cc: ipsec@TIS.COM Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199607261908.PAA24684@toxicwaste.media.mit.edu> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Fri, 26 Jul 1996 15:08:46 EDT From: Derek Atkins > > There is an issue. Storing the private key off-line is not > > a deterrent: the mischievous person simply generates a > > new key pair and re-signs the zone. > > Actually, this doesn't work. The problem is that the > parent zone needs to have signed the zone's key. So, I > couldn't go and forge a zone key for MIT.EDU, because the > MIT.EDU key needs to be signed by the EDU key, which in turn > needs to be signed by the root key. > > So, you can't forge a key without forging the whole > hierarchy. > The servers that serve . also serve EDU -- the disconnect between them is a logical one, not a physical one. A compromise of either is a compromise of both (as well as COM). The EDU zone could sign a key for the MIT.EDU subzone and return glue data that isn't addressed to MIT.EDU but to an impostor. If the resolver knew MIT's key then the impostor would have a problem; however, I suspect resolvers will commonly trust the key from the super zone. Once an impostor is introduced into the path, duplicating a hierarchy is just work. Detecting a compromised server is more easy if the server applied its craft to all of its responses. However, if the server itself (named) is replaced with one that targets specific data, its detection will be more difficult -- and more effective. -dpg Received: from relay.hq.tis.com by neptune.TIS.COM id aa04611; 27 Jul 96 19:20 EDT Received: by relay.hq.tis.com; id TAA02376; Sat, 27 Jul 1996 19:23:11 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002374; Sat, 27 Jul 96 19:22:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16920; Sat, 27 Jul 96 19:22:17 EDT Received: by relay.hq.tis.com; id TAA02371; Sat, 27 Jul 1996 19:22:41 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma002369; Sat, 27 Jul 96 19:22:36 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id QAA00737; Sat, 27 Jul 1996 16:24:54 -0700 (PDT) Message-Id: <199607272324.QAA00737@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Securing 5% of the Internet against Wiretapping by Christmas Date: Sat, 27 Jul 1996 16:24:52 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I've been working on a project in secret for a few months, and now am talking about it with everyone so that we can all help it along. Want all the Internet traffic between you and every other privacy-conscious site on the net, worldwide, to automatically be encrypted using Triple-DES, RSA, and Diffie-Hellman? Without changing your hardware or software, except to stick a Linux PC on your network, or install a new version of Linux on your laptop? Want it all by Christmas? Then check out http://www.cygnus.com/~gnu/swan.html [The two main differences in focus between my effort and the general IPSEC effort are: * Do opportunistic encryption to get the "fax effect", reduce the network administration workload, and raise the general level of privacy on the Internet (rather than just in virtual private networks). * Do it AND DEPLOY IT this year. Governments are rushing to outlaw it. Louis Freeh said as much in his Congressional testimony last week. We need a user base who'll object to having it taken away. It's also a lot easier to do the design work in the open, rather than as a hunted criminal or expatriate. Making it happen in the real network, now, will be a powerful force for making the right thing happen in the political realm. -- John Gilmore An equal opportunistic encryptor] Received: from relay.hq.tis.com by neptune.TIS.COM id aa17892; 28 Jul 96 21:48 EDT Received: by relay.hq.tis.com; id VAA09986; Sun, 28 Jul 1996 21:51:03 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009984; Sun, 28 Jul 96 21:50:35 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05737; Sun, 28 Jul 96 21:50:09 EDT Received: by relay.hq.tis.com; id VAA09979; Sun, 28 Jul 1996 21:50:34 -0400 Received: from in-touch.ihtfp.org(204.107.200.19) by relay.tis.com via smap (V3.1.1) id xma009975; Sun, 28 Jul 96 21:50:26 -0400 Received: (from warlord@localhost) by in-touch.ihtfp.org (8.6.12/DAA950726) id VAA01066; Sun, 28 Jul 1996 21:52:10 -0400 Message-Id: <199607290152.VAA01066@in-touch.ihtfp.org> To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ipsec@TIS.COM From: Derek Atkins Subject: Re: DNSSEC for IPSEC? In-Reply-To: Your message of "Sat, 27 Jul 1996 14:41:48 PDT." <199607272141.OAA00960@imo.plaintalk.bellevue.wa.us> Date: Sun, 28 Jul 1996 21:52:10 EDT Sender: ipsec-approval@neptune.tis.com Precedence: bulk Dennis, > The servers that serve . also serve EDU -- the disconnect > between them is a logical one, not a physical one. A > compromise of either is a compromise of both (as well as > COM). But this doesn't change what I said. To forge MIT.EDU you need to either fool EDU or forge EDU. To forge EDU you need to either fool or forge ".". The fact that "." and EDU are physically the same just makes an attack against one an attack against them all. > The EDU zone could sign a key for the MIT.EDU subzone > and return glue data that isn't addressed to MIT.EDU but > to an impostor. If the resolver knew MIT's key then the > impostor would have a problem; however, I suspect > resolvers will commonly trust the key from the > super zone. Once an impostor is introduced into the > path, duplicating a hierarchy is just work. Let's assume that EDU wasn't broken, so it signed the real MIT.EDU subzone key. Even if the glue points off to an imposter, the imposter can't sign the data in the DNS since it doesn't have the MIT.EDU key. So a client knows that it was sent to an imposter. Now, if the imposter signs its data, the key used to sign the data won't match the key signed by EDU. Again, a client knows that it is an imposter. The only way for a client to believe the DNS data from the imposter is if the imposter's key is signed by EDU, which requires a break of EDU's key. A break of EDU's key, in turn requires a break of the root key, which is supposedly hard-coded into the client already. Sure, "." and EDU are on the same machine, but you have to break into the machine that holds the key in order to exploit it. In that case, the assumptions upon which DNSSEC was built are no longer valid. The assumption is that you cannot break the root key, and that each subdomain key is kept "secure". Fine, you can go factor the RSA key and start signing things. But that isn't an interesting attack against the protocol. Sure, you can break into the server and steal the key, but again that isn't an interesting attack against the protocol. -derek Received: from relay.hq.tis.com by neptune.TIS.COM id aa27358; 29 Jul 96 9:36 EDT Received: by relay.hq.tis.com; id JAA15186; Mon, 29 Jul 1996 09:39:19 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015175; Mon, 29 Jul 96 09:38:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18086; Mon, 29 Jul 96 09:38:25 EDT Received: by relay.hq.tis.com; id JAA15168; Mon, 29 Jul 1996 09:38:49 -0400 Received: from henson.rutgers.edu(128.6.75.66) by relay.tis.com via smap (V3.1.1) id xma015165; Mon, 29 Jul 96 09:38:44 -0400 Received: (from wli@localhost) by henson.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA22671; Mon, 29 Jul 1996 09:40:53 -0400 Date: Mon, 29 Jul 1996 09:40:53 -0400 From: Wanglai Li Message-Id: <199607291340.JAA22671@henson.rutgers.edu> To: dns-security@TIS.COM, ietf-pkix@tandem.com, ietf-tls@w3.org, ipsec@TIS.COM, set-discuss@commerce.net Subject: DIMACS Workshop on Trust Management in Networks Cc: jf@research.att.com, wli@dimacs.rutgers.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk -------------------------------------------------------------------------- | DIMACS: Center for Discrete Mathematics & Theoretical Computer Science | | A National Science Foundation Science and Technology Center | -------------------------------------------------------------------------- DIMACS Workshop on Trust Management in Networks Dates: Sept. 30 - Oct. 2, 1996 Location: CORE Bldg., Rutgers University Busch Campus, Piscataway NJ Co-Chairs: Ernie Brickell, Bankers Trust, brickell@btec.com Joan Feigenbaum, AT&T Research, jf@research.att.com Dave Maher, AT&T Research, dpm@research.att.com Theme: The use of public-key cryptography on a mass-market scale requires sophisticated mechanisms for managing trust. For example, any application that receives a signed request for action is forced to answer the central question ``Is the key used to sign this request authorized to take this action?'' In certain applications, this question reduces to ``Does this key belong to this person?'' In others, the authorization question is considerably more complicated, and resolving it requires techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. This workshop covers all aspects of the trust management problem. Relevant topics include but are not limited to: General approaches to trust management Languages, systems, and tools Certificates and public-key infrastructure Formal models and analysis Trust management in specific application domains, including but not limited to: Banking E-mail Internet commerce Licensing Medical information systems Mobile programs and ``code signing'' Revocation of cryptographic keys Confirmed speakers include: Butler Lampson, Microsoft Matt Blaze, AT&T Research Steve Kent, BBN Carl Ellison, Cybercash Contributed talks: If you would like to attend and give a talk, please email a one-page abstract (NOT A FULL PAPER) in ascii format to Joan Feigenbaum at jf@research.att.com by September 1, 1996. The Trust Management workshop will be informal, and there are currently no plans to publish proceedings. For more information: If you would like to attend but not give a talk, contact Joan Feigenbaum at jf@research.att.com any time before the beginning of the workshop. There is a small amount of support available for people who do not have other sources of travel funds. Information about local arrangements, travel, lodging and registration can be found at http://dimacs.rutgers.edu/Workshops/Management. Those without WWW access can contact Pat Pravato at 908-445-5929 or pravato@dimacs.rutgers.edu. This workshop is part of DIMACS Special Year on Networks. Information about the Special Year on Networks can be found at DIMACS WWW site: http://dimacs.rutgers.edu or by contacting the center. --------------------------------------------------------------------- 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 90 DIMACS is a partnership of Rutgers University, Princeton University, AT&T Research, Bellcore, and Lucent - Bell Laboratories. Received: from relay.hq.tis.com by neptune.TIS.COM id aa01264; 29 Jul 96 12:13 EDT Received: by relay.hq.tis.com; id MAA19858; Mon, 29 Jul 1996 12:15:54 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019844; Mon, 29 Jul 96 12:15:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27579; Mon, 29 Jul 96 12:14:59 EDT Received: by relay.hq.tis.com; id MAA19839; Mon, 29 Jul 1996 12:15:24 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma019824; Mon, 29 Jul 96 12:15:18 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA25625; Mon, 29 Jul 1996 12:17:34 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma025593; Mon Jul 29 12:17:27 1996 Received: from magnus2 ([138.120.141.33]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id MAA22654; Mon, 29 Jul 1996 12:17:20 -0400 Date: Mon, 29 Jul 1996 12:16:46 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ipsec@TIS.COM Subject: Re: DNSSEC for IPSEC? In-Reply-To: <199607260645.XAA00284@imo.plaintalk.bellevue.wa.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Thu, 25 Jul 1996, Dennis Glatting wrote: > The value of DNS-SEC is if everyone uses it. Until that > time, which may be a decade or more down the road, > resolvers are going to have to trust any response, > thereby reducing DNS-SEC's value to a simple checksum. This seems overly pessimistic. Not so long ago a small number of important public sites added policy enforcing valid PTR records before access was granted and a most sloppy practice tightened up remarkably in less than a year. I don't see why that pattern couldn't be repeated. > I question the value of using DNS-SEC to aid IPSEC. And what limited value can we get from IPSEC without DNS-SEC? -- Ian Duncan Access Products Development Newbridge Networks Corp. Received: from relay.hq.tis.com by neptune.TIS.COM id aa29984; 30 Jul 96 20:21 EDT Received: by relay.hq.tis.com; id UAA00802; Tue, 30 Jul 1996 20:24:24 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000796; Tue, 30 Jul 96 20:23:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05709; Tue, 30 Jul 96 20:23:27 EDT Received: by relay.hq.tis.com; id UAA00793; Tue, 30 Jul 1996 20:23:54 -0400 Received: from atc.boeing.com(130.42.28.80) by relay.tis.com via smap (V3.1.1) id xma000791; Tue, 30 Jul 96 20:23:31 -0400 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA26679; Tue, 30 Jul 1996 17:09:10 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA258358450; Tue, 30 Jul 1996 07:54:10 -0700 Received: by commanche.ca.boeing.com (AIX 4.1/UCB 5.64/4.03) id AA21468; Tue, 30 Jul 1996 07:55:10 -0700 Message-Id: <9607301455.AA21468@commanche.ca.boeing.com> To: Germano Caronni Cc: ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP , Burkhard Stiller , Bernhard Plattner Subject: Re: Stream Cipher Transform -- revisited In-Reply-To: (Your message of Wed, 03 Jul 96 14:42:10 +0200.) <199607031242.OAA10521@kom30.ethz.ch> Date: Tue, 30 Jul 96 07:55:09 -0700 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Germano Apologies, I have been intending to reply but summer kept getting in the way. Anyway a couple comments and thoughts on including support for stream ciphers in IPSEC as I believe there is a strong security and business case for their use. 1) In general most of us have substantial numbers of legacy systems or over-subscribed systems which have minimal amounts of un-used cycles. It is very difficult to justify, and often to operationally implement, a high-overhead encryption mechanism which results in the capacity of 100 user production server being reduced to 60 or 70. 2) In many cases absolute security of the data may not be justified but prevention of re-play attacks or session-hijacks is essential, especially in light of on-going work on "single sign-on functions". It would seem that light weight ciphers might be ideal here. 3) For now, regardless of our personal views, exportability of a solution is very important. It seems likely that ciphers may be more generally exportable and having more exportable options would appear to be win. 4) As you note, protection of "content" from alteration during delivery is also key, whether you are working with "web data", realtime video, or voice. Again the low-overhead of ciphers looks attractive for this type of use. I encourage your group to continue the work as I believe that support of low-overhead encryption techniques will considerably broaden the usability of IPSEC. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | 206-957-5325 | tld5032@atc.boeing.com. | --------------- Tuesday July 30,1996 07:27 AM PDT ------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa03983; 31 Jul 96 1:29 EDT Received: by relay.hq.tis.com; id BAA04492; Wed, 31 Jul 1996 01:32:41 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004488; Wed, 31 Jul 96 01:32:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12070; Wed, 31 Jul 96 01:31:45 EDT Received: by relay.hq.tis.com; id BAA04482; Wed, 31 Jul 1996 01:32:11 -0400 Received: from interlock.ans.net(147.225.5.5) by relay.tis.com via smap (V3.1.1) id xma004478; Wed, 31 Jul 96 01:31:45 -0400 Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for ipsec@tis.com); Wed, 31 Jul 1996 01:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 31 Jul 1996 01:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 31 Jul 1996 01:34:07 -0400 Date: Wed, 31 Jul 1996 00:28:05 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 5th International conference on telecommunication Systems To: list2: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <01I7PBTXEL6Q8XFSXJ@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"list2" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: ipsec-approval@neptune.tis.com Precedence: bulk TSM97CFP C A L L for P A P E R S 5th International Conference on Telecommunication Systems Modelling and Analysis March 20-23, 1997 Nashville, TN Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modelling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Owen Graduate School of Management The 5th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville on March 20-23, 1997. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. The Program Committee has been divided along geographical regions with a separate Program Subcommittee assigned to each region. Abstracts and papers should be submitted directly to the Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1997 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tenessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Union Station hotel (see description at the end of the message). Lead Speakers and Keynote speakers include: Erol Gelenbe, Andrew Viterbi, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology 723 Swanston Street Carlton, Victoria Australia, 3001 Phone : 61 3 9282 2450 (CATT), 61 3 9660 2457 (RMIT) Fax : 61 3 9282 2490 (CATT), 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au ---Europe: (except Scandinavia and Baltic states) Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr ---Europe: (Scandinavia and Baltic states) Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se ---North America: Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : jpark@scout-po.biz.uiowa.edu ---North East Asia: Prof. Yutaka Takahashi Nara Institute of Science and Technology Takayama-cho 8916-5, Ikoma-shi, Nara, 630-01 JAPAN Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : ytanaka@mn.waseda.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl ---Chairman of the Economics track: Prof. William W. Sharkey Federal Communications Commission 1919 M Street Washington, DC 20554 USA Phone : 202-418-2743 Fax : 202-418-1413 E-Mail : wsharkey@fcc.gov ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its Impact on Commerce -- Internet and Intranet -- Standards -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Group Decision Support Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is whenever possible, to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, enabling participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early conference and hotel registration is recommended. The Union Station Hotel is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1996, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the forms at the end of this message to preregister for the conference and the hotal. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1996, which abstract/s have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1997, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fifth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Dates: March 20, 1997 (afternoon) to March 23, 1997 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applica- Academic Industry Corporate ble Date Rate Rate Rate --------------- -------- -------- -------- 1. Preregistration Until Dec. 9, 1996 $ 400 $ 500 $1,300 2. Registration Until Jan. 15, 1997 $ 500 $ 600 $1,300 3. On Site Registration After Jan. 15, 1997 $ 600 $ 750 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association" . Please mark an X in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I don't wish to become an ATSMA member. Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be endorsed to: ATSMA, Inc. Refund Policy: Half refund, for requests received by February 1, 1997. No refund after February 1, 1997. ----------------------------------------------------------------------------- If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. Hotel Reservation A block of rooms has been reserved at Union Station Hotel for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the Telecommunication Systems Conference to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference blocks on February 15, 1997, so please be sure and reserve your rooms before February 15th. Union Station Hotel 1001 Broadway Nashville, TN 37203 Phone: 615-726-1001 or 1-800-331-2123 Fax: 615-742-3084 $99.00 Single or Double Occupancy Room $109.00 Triple or Quad Occupancy Room - Rates are subject to state and local tax, which is now 12.25 percent. ------------------------------------------------------------------------- Union Station Hotel Reservation Request Form Name of Conference: Telecommunication Systems Conference Arrival Date _________________ Departure Date __________________ Guest Name:__________________________________________________ Address :__________________________________________________ :__________________________________________________ Phone No. :__________________________________________________ A one night deposit should be enclosed to guarantee the reservation Payment Method: Check Check No.______________ Amount____________ Credit Card Type______________ No.____________________ Expiration Date____________ Type of Room: King or 2 Double Beds Smoking or Nonsmoking -------------------------------------------------------------------------- Union Station Hotel Description A Grand Heritage Hotel Features and Amenities In the heart of "Music City" stands a hotel with the personality of an intimate friend...Union Station Hotel. The heartbeat of Nashville has always been strongest at the Union Station. >From the grand opening in 1890 until the decline of rail travel in the 50s no other building in the city has been the site of more commercial activity and human drama. Nearly a century later, the Union Station Hotel, a National Historic Landmark, is again an integral part of life in Music City 124 guest rooms including 13 suites on seven levels are architecturally distinctive and capture the historic elegance of a bygone era. Stained glass, glittering gold leaf and newly silvered mirrors scatter reflections of an era which has endured for nearly a century. 4 conference rooms with over 10,000 square feet of flexible meeting and banquet space to accommodate groups of 5 to 200. * Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel Holiday Award. * Broadway Bistro - casual dining open for lunch and dinner. Selected in the 1996 Zagat Survey as the city's best overall and best dining hotel. Heritage Executive Level with enhanced amenities ideal for the business and leisure traveler including concierge service, continental breakfast and evening cocktails Monday through Friday. * Valet parking. * Complimentary limo service in downtown Nashville. * Complimentary newspaper. * Blocks from downtown area, famed Music Row, Vanderbilt University and Convention Center. Recommended Airport: Nashville Metro Airport, 7 miles to the East. Transportation: Grayline Shuttle to the hotel. $8.00 one way, $14.00 round trip. Complimentary shuttle service within three mile radius of hotel for conference guests. ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa05791; 31 Jul 96 3:33 EDT Received: by relay.hq.tis.com; id DAA06568; Wed, 31 Jul 1996 03:35:51 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006566; Wed, 31 Jul 96 03:35:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14000; Wed, 31 Jul 96 03:34:55 EDT Received: by relay.hq.tis.com; id DAA06561; Wed, 31 Jul 1996 03:35:21 -0400 Received: from ssh.fi(194.100.44.97) by relay.tis.com via smap (V3.1.1) id xma006548; Wed, 31 Jul 96 03:35:04 -0400 Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id KAA20361; Wed, 31 Jul 1996 10:36:55 +0300 (EET DST) Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id KAA18037; Wed, 31 Jul 1996 10:36:52 +0300 (EET DST) Date: Wed, 31 Jul 1996 10:36:52 +0300 (EET DST) Message-Id: <199607310736.KAA18037@pilari.ssh.fi> From: Tatu Ylonen To: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Cc: Germano Caronni , ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP , Burkhard Stiller , Bernhard Plattner Subject: Re: Stream Cipher Transform -- revisited In-Reply-To: <9607301455.AA21468@commanche.ca.boeing.com> References: <199607031242.OAA10521@kom30.ethz.ch> <9607301455.AA21468@commanche.ca.boeing.com> Organization: SSH Communications Security, Finland Sender: ipsec-approval@neptune.tis.com Precedence: bulk > 3) For now, regardless of our personal views, exportability of a > solution is very important. It seems likely that ciphers may be more > generally exportable and having more exportable options would appear > to be win. The United States does not allow exporting anything that a determined college kid could not break. This level of (in)security is not acceptable. In some cases, the United States allows export if the effort to break the encryption is not greater for themselves than what a determined college kid could break. While this may provide somewhat more protection against non-USG attackers, this is not acceptable for the rest of the world. Tatu Received: from relay.hq.tis.com by neptune.TIS.COM id aa07109; 31 Jul 96 5:09 EDT Received: by relay.hq.tis.com; id FAA07394; Wed, 31 Jul 1996 05:12:39 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007392; Wed, 31 Jul 96 05:12:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15453; Wed, 31 Jul 96 05:11:43 EDT Received: by relay.hq.tis.com; id FAA07389; Wed, 31 Jul 1996 05:12:09 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma007387; Wed, 31 Jul 96 05:11:42 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id CAA23906; Wed, 31 Jul 1996 02:13:41 -0700 (PDT) Message-Id: <199607310913.CAA23906@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Terry L. Davis, Boeing Information & Support Services, Bellevue,\ WA" Cc: Germano Caronni , ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP , Burkhard Stiller , Bernhard Plattner , gnu@toad.com Subject: Re: Stream Cipher Transform -- revisited In-Reply-To: <9607301455.AA21468@commanche.ca.boeing.com> Date: Wed, 31 Jul 1996 02:13:40 -0700 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk I advise against making *any* design decision that trades off security or privacy for MIPS (beyond hitting the sweet spot in the market: running broadly useful data rates on cheap up-to-the-minute hardware). It's absolutely clear that the short-term, medium-term and long-term trends all tell us we will have plenty more MIPS whenever we want them. But we won't have plenty of security or privacy; both are up for grabs and there's no predictable outcome. Why give up something scarce to get something plentiful? Particularly when designing an architecture that will last for a decade or more. It's hard for people to think about the consequences of exponential factors like chip feature sizes. People told Richard Stallman he was crazy to build a compiler that needed more than a megabyte to run, or a text editor that kept the whole file in memory. He was right, they were wrong. "Eight Megabytes And Constantly Swapping" EMACS is pretty tame stuff on a 48-meg Pentium laptop, which has to do full-screen video to work up a sweat. Legacy systems that support a hundred users without encryption can't always have their speed doubled as easily as last year's clone. But an external encrypting gateway, built cheaply with this year's technology, can burn all the new MIPS, and hand the same old stuff to the legacy system. Exportability of solutions from the US is *NOT* very important this year. Last year, last decade, sure. We played that game and it was a losing game. We can keep losing or we can play a different game. RSA has noticed this; that's why they're making global alliances to build strong crypto worldwide. The IAB and IESG have noticed this. I hope the IPSEC working group knows it solidly, too. Note that by playing the new game well, the old game resolves itself (the gov't gives up), which could never happen while we continued to play by their rules. John Gilmore (An equal opportunistic encryptor.) Received: from relay.hq.tis.com by neptune.TIS.COM id aa12788; 31 Jul 96 10:47 EDT Received: by relay.hq.tis.com; id KAA14794; Wed, 31 Jul 1996 10:50:15 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014737; Wed, 31 Jul 96 10:49:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27557; Wed, 31 Jul 96 10:48:56 EDT Received: by relay.hq.tis.com; id KAA14703; Wed, 31 Jul 1996 10:49:19 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma014677; Wed, 31 Jul 96 10:49:00 -0400 Received: by janus.border.com id <18436-2>; Wed, 31 Jul 1996 10:50:21 -0400 Message-Id: <96Jul31.105021edt.18436-2@janus.border.com> To: John Gilmore Cc: Germano Caronni , ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP , Burkhard Stiller , Bernhard Plattner Subject: Re: Stream Cipher Transform -- revisited References: <199607310913.CAA23906@toad.com> In-Reply-To: gnu's message of "Wed, 31 Jul 1996 05:13:40 -0400". <199607310913.CAA23906@toad.com> From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Wed, 31 Jul 1996 10:51:15 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199607310913.CAA23906@toad.com>, John Gilmore writes: > I advise against making *any* design decision that trades off security > or privacy for MIPS Agreed, with an explanation. :-) There are two points on the performance curve worth considering; slow hardware is one, but high-speed/high-volume data streams are another. Take a real-time, broadcast-quality, full-motion M-JPEG stream, for example... I fully support continuing development for supporting stream ciphers within IPsec. However, to agree somewhat with John, these should be *optional* transforms. -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.hq.tis.com by neptune.TIS.COM id aa15507; 31 Jul 96 12:57 EDT Received: by relay.hq.tis.com; id NAA19179; Wed, 31 Jul 1996 13:00:38 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019111; Wed, 31 Jul 96 13:00:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07574; Wed, 31 Jul 96 12:59:12 EDT Received: by relay.hq.tis.com; id MAA19099; Wed, 31 Jul 1996 12:59:33 -0400 Received: from unknown(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma019047; Wed, 31 Jul 96 12:59:20 -0400 Received: from ftp.com by ftp.com ; Wed, 31 Jul 1996 13:00:37 -0400 Received: from athena.ftp.com by ftp.com ; Wed, 31 Jul 1996 13:00:37 -0400 Message-Id: <2.2.32.19960731170531.00ae3200@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, 31 Jul 1996 13:05:31 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy Subject: Question on TCP MSS with repsect to IPSEC Cc: solensky@ftp.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk When we adverstise MSS for TCP connections, am I right in saying that the MSS value should take into account the ESP and AH header and data. For example if the MTU is 576, and the AH header+data is 24 bytes and ESP header +data 20 bytes (assuming 8 bytes padding), then the MSS I announce should be (576 - 40 - 24 - 20). Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa17025; 31 Jul 96 14:10 EDT Received: by relay.hq.tis.com; id OAA22157; Wed, 31 Jul 1996 14:13:04 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022125; Wed, 31 Jul 96 14:12:36 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11140; Wed, 31 Jul 96 14:12:08 EDT Received: by relay.hq.tis.com; id OAA22119; Wed, 31 Jul 1996 14:12:35 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma022113; Wed, 31 Jul 96 14:12:29 -0400 Received: from wool.bbn.com (WOOL.BBN.COM [128.89.13.126]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id OAA07237 for ; Wed, 31 Jul 1996 14:19:32 -0400 (EDT) Message-Id: <2.2.32.19960731192328.00710434@po1.bbn.com> X-Sender: jzao@po1.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 1996 14:23:28 -0500 To: ipsec@TIS.COM From: John K Zao Subject: PF_KEY Key Management API Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello, folks. Where could I find a document that describes the "PF_KEY Key Management API"? The API is supported by the NRL IPSec implementation. In my course of designing a key management API for Mobile IP, I would like to learn from its design. Many thanks, John. Received: from relay.hq.tis.com by neptune.TIS.COM id aa17342; 31 Jul 96 14:26 EDT Received: by relay.hq.tis.com; id OAA23104; Wed, 31 Jul 1996 14:29:05 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023091; Wed, 31 Jul 96 14:28:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12067; Wed, 31 Jul 96 14:28:08 EDT Received: by relay.hq.tis.com; id OAA23085; Wed, 31 Jul 1996 14:28:35 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma023081; Wed, 31 Jul 96 14:28:25 -0400 Received: from munin.fnal.gov ("port 3161"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7Q37V3CQQ001GB6@FNAL.FNAL.GOV>; Wed, 31 Jul 1996 13:30:44 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id NAA29362; Wed, 31 Jul 1996 13:29:11 -0500 (CDT) Date: Wed, 31 Jul 1996 13:28:58 -0500 From: Matt Crawford Subject: Re: Question on TCP MSS with repsect to IPSEC In-Reply-To: "31 Jul 1996 13:05:31 EDT." <"2.2.32.19960731170531.00ae3200"@mailserv-H.ftp.com> To: Naganand Doraswamy Cc: ipsec@TIS.COM, solensky@ftp.com Message-Id: <199607311829.NAA29362@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ When we adverstise MSS for TCP connections, am I right in saying that the > MSS value should take into account the ESP and AH header and data. > > For example if the MTU is 576, and the AH header+data is 24 bytes and ESP > header +data 20 bytes (assuming 8 bytes padding), then the MSS I announce > should be (576 - 40 - 24 - 20). Received: from relay.hq.tis.com by neptune.TIS.COM id aa17406; 31 Jul 96 14:29 EDT Received: by relay.hq.tis.com; id OAA23213; Wed, 31 Jul 1996 14:32:05 -0400 From: touch@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023209; Wed, 31 Jul 96 14:31:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12195; Wed, 31 Jul 96 14:31:13 EDT Received: by relay.hq.tis.com; id OAA23199; Wed, 31 Jul 1996 14:31:35 -0400 Received: from zephyr.isi.edu(128.9.160.160) by relay.tis.com via smap (V3.1.1) id xma023185; Wed, 31 Jul 96 14:31:10 -0400 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 31 Jul 1996 11:33:25 -0700 Date: Wed, 31 Jul 1996 11:33:24 -0700 Posted-Date: Wed, 31 Jul 1996 11:33:24 -0700 Message-Id: <199607311833.AA14091@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Wed, 31 Jul 1996 11:33:24 -0700 To: ipsec@TIS.COM, naganand@ftp.com Subject: Re: Question on TCP MSS with repsect to IPSEC Cc: solensky@ftp.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: ipsec-approval@neptune.tis.com Precedence: bulk > When we adverstise MSS for TCP connections, am I right in saying that the > MSS value should take into account the ESP and AH header and data. > > For example if the MTU is 576, and the AH header+data is 24 bytes and ESP > header +data 20 bytes (assuming 8 bytes padding), then the MSS I announce > should be > (576 - 40 - 24 - 20). > > Thanks, > > --Naganand > ---------------------------------------------------------------- > naganand@ftp.com > Tel #: (508)684-6743 (O) Hmmm. The current BSD code uses the min of the MSS and 512, to optimize alignments, e.g., with pages, socket buffers, etc. Given that this leaves 492, a size of 256 seems small, but may have some benefit. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: from relay.hq.tis.com by neptune.TIS.COM id aa18880; 31 Jul 96 15:33 EDT Received: by relay.hq.tis.com; id PAA25864; Wed, 31 Jul 1996 15:36:16 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025852; Wed, 31 Jul 96 15:35:59 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15470; Wed, 31 Jul 96 15:35:24 EDT Received: by relay.hq.tis.com; id PAA25832; Wed, 31 Jul 1996 15:35:47 -0400 Received: from ns.gte.com(132.197.8.9) by relay.tis.com via smap (V3.1.1) id xma025823; Wed, 31 Jul 96 15:35:28 -0400 Received: from [132.197.64.22] by ns.gte.com (8.7.5/) X-Sender: tmc0@pophost.gte.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 1996 15:40:21 -0400 To: pem-dev@TIS.COM, ipsec@TIS.COM, ietf-pkix@tandem.com From: Tom Chen Subject: CFP: IEEE Network Mag. issue on network security Sender: ipsec-approval@neptune.tis.com Precedence: bulk IEEE NETWORK MAGAZINE Call for Papers Feature Issue on Network and Internet Security The May 1997 issue of IEEE Network will feature the topic of network and Internet security. Private and public organizations are increasingly dependent on distributed computer systems and computer networks such as the global Internet. However, the commercialization and escalating popularity of the Internet have been accompanied by a rising level of network-related security attacks despite firewalls, encryption, anti-virus programs, and other security measures. Today, security attacks can originate from a greater number of sources in more varied forms. New networking technologies (e.g., fiber optics, ATM) enable data to be moved at rates of gigabits/s, where security breaches and data transmissions can occur on timescales much faster than human intervention. In addition, computer technology is being used for increasingly sophisticated, automated tools that allow any non-expert to perpetrate serious security attacks. As the issue of security gains prominent attention in scientific, political, and commercial arenas, it poses a potential hindrance to the continued growth of the Internet and other computer networks. Contributions are invited to the feature issue of IEEE Network which will represent the current state of the art covering all aspects of network and internetwork security. Topics may include, but are not limited to: - cryptography and privacy; - viruses, worms, and intruding software; - Internet commerce; - firewalls and access control; - authentication and digital signatures; - key management and exchange; - certificates and certification authorities; - secure e-mail; - secure network management. Contributions should be submitted by November 1, 1996 to the guest editor: Thomas M. Chen GTE Laboratories, Inc. 40 Sylvan Road Waltham, MA 02254 USA tel: 617-466-2758 fax: 617-890-9320 email: tchen@gte.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa19060; 31 Jul 96 15:43 EDT Received: by relay.hq.tis.com; id PAA26217; Wed, 31 Jul 1996 15:46:16 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026215; Wed, 31 Jul 96 15:45:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16103; Wed, 31 Jul 96 15:45:24 EDT Received: by relay.hq.tis.com; id PAA26210; Wed, 31 Jul 1996 15:45:47 -0400 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1) id xma026204; Wed, 31 Jul 96 15:45:25 -0400 Received: by mercury.Sun.COM (Sun.COM) id MAA06308; Wed, 31 Jul 1996 12:47:47 -0700 Received: from pacific.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08315; Wed, 31 Jul 1996 12:47:45 -0700 Received: from kebe.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11626; Wed, 31 Jul 1996 12:47:44 -0700 Received: by kebe.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA20524; Wed, 31 Jul 1996 12:46:54 -0700 From: Dan McDonald Message-Id: <199607311946.MAA20524@kebe.eng.sun.com> Subject: Re: PF_KEY Key Management API To: jzao@zafu.bbn.com Date: Wed, 31 Jul 1996 12:46:54 -0800 (PDT) Cc: ipsec@TIS.COM In-Reply-To: <2.2.32.19960731192328.00710434@po1.bbn.com> from "John K Zao" at Jul 31, 96 02:23:28 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Hello, folks. Hi! > Where could I find a document that describes the "PF_KEY Key Management > API"? The API is supported by the NRL IPSec implementation. In my course of > designing a key management API for Mobile IP, I would like to learn from its > design. The man pages in the NRL distribution have a section for PF_KEY. And there's also source. :) A higher-level view is available in a recent paper that appeared in INET'96. It is entitled "A Socket-Based Key Management API" written by me, Ran Atkinson, and Bao Phan. It should be available RSN as PostScript at some web site, if you can't get the proceedings for INET'96. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + Received: from relay.hq.tis.com by neptune.TIS.COM id aa20878; 31 Jul 96 16:51 EDT Received: by relay.hq.tis.com; id QAA29174; Wed, 31 Jul 1996 16:54:08 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029168; Wed, 31 Jul 96 16:53:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21463; Wed, 31 Jul 96 16:53:14 EDT Received: by relay.hq.tis.com; id QAA29161; Wed, 31 Jul 1996 16:53:40 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma029157; Wed, 31 Jul 96 16:53:31 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id NAA11442; Wed, 31 Jul 1996 13:55:40 -0700 Date: Wed, 31 Jul 1996 13:55:40 -0700 From: Ran Atkinson Message-Id: <199607312055.NAA11442@puli.cisco.com> To: jzao@bbn.com Subject: Re: PF_KEY Key Management API In-Reply-To: <2.2.32.19960731192328.00710434@po1.bbn.com> Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <2.2.32.19960731192328.00710434@po1.bbn.com> John Zao wrote: >Where could I find a document that describes the "PF_KEY Key Management >API"? The API is supported by the NRL IPSec implementation. In my course of >designing a key management API for Mobile IP, I would like to learn from its >design. > >Many thanks, > >John. John, The PF_KEY API already has hooks to support Mobile IP, so you might just be able to reuse the freely distributable PF_KEY API and Key Engine code from the NRL IPv6+IPsec implementation. If you need minor API changes, the PF_KEY gang are happy to work with you to ensure that PF_KEY can meet the needs of Mobile IP. Send me unicast email if you want to persue this. An I-D describing PF_KEY version 2 exists and should be put online soon, but the INET'96 paper that Dan McD mentioned is a better introduction to PF_KEY anyway. All, This seems a good time to mention that the NRL July 1996 IPv6+IPsec (includes IPv6, IPsec for IPv4, IPsec for IPv6, PF_KEY, and the Key Engine for 4.4-Lite BSD/NetBSD/BSDI and tested with those on SPARC and x86 hardware) is available online now/soon. US: http://web.mit.edu/network/isakmp (coming very soon; was online there but they just suffered a disk crash) US & Canada: http://www.cisco.com/public/library/isakmp/ipsec.html Europe (Export version for July 96, but full versions for Jan96 & Sep 95): ftp://ftp.ripe.net/ipv6/nrl/ Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa20930; 31 Jul 96 16:52 EDT Received: by relay.hq.tis.com; id QAA29214; Wed, 31 Jul 1996 16:55:11 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029200; Wed, 31 Jul 96 16:54:41 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21494; Wed, 31 Jul 96 16:54:13 EDT Received: by relay.hq.tis.com; id QAA29193; Wed, 31 Jul 1996 16:54:40 -0400 Received: from hq.cisco.com(161.44.72.2) by relay.tis.com via smap (V3.1.1) id xma029179; Wed, 31 Jul 96 16:54:25 -0400 Received: from North-Bridge.cisco.com ([161.44.128.141]) by HQ.CISCO.COM via INTERNET ; Wed, 31 Jul 1996 13:56:27 PDT From: Rob Adams Message-Id: <19960731140101adams@North-Bridge.cisco.com> Date: Wed Jul 31 14:01:01 1996 X-Priority: Normal To: ipsec@TIS.COM Subject: Re: Question on TCP MSS with repsect to IPSEC Cc: naganand@ftp.com Content-Transfer-Encoding: 7bit X-Mailer: Pronto 96 3.0 Beta (0325) Mime-Version: 1.0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk I believe Mr. Crawford is correct. The sender's idea of the MTU for a particular route, moreso than the MSS, should be decremented by the amount of IPSEC header bytes needed. This also must be done on a per-association basis. This becomes an interesting problem though when you are speaking to a host with one association and then form another with different transforms. Optimally you would want to keep the number of bytes you can send as large as possible. So, if I have an association with a host that requires AH with MD5 and no replay, I would want to shave off 24 bytes. If I form another association with that host that requires AH with SHA and replay, then I want to shave off 32 bytes. Bookkeeping the fact that I've already shaved off 24 and only need to drop down an extra 8 is the interesting part. This becomes even more interesting if we want to keep per-association pad boundary data, not to mention tunnels. ============================================================================== Rob Adams 101 Cooper St. Cisco Systems Santa Cruz, CA 95060 adams@cisco.com > > This looks obviously correct, but consider RFC1122 section 4.2.2.6. > The sender of a TCP segment must subtract the length of the IP and > TCP options that it intends to send from the MSS advertised by the > remote node. (I caught one vendor in error this year on this point.) > In light of this, I think the opposite choice should be correct: The > sender of a packet with AH and/or ESP headers must subtract the sizes > of those headers from the remote node's MSS. > > Besides, I'm not convinced that the TCP on the other end will always > and everywhere be able to know in advance the size of the AH+ESP > headers which your end will use for each packet. > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A > Naganand Doraswamy: > > When we adverstise MSS for TCP connections, am I right in saying that the > > MSS value should take into account the ESP and AH header and data. > > > > For example if the MTU is 576, and the AH header+data is 24 bytes and ESP > > header +data 20 bytes (assuming 8 bytes padding), then the MSS I announce > > should be (576 - 40 - 24 - 20). > Received: from relay.hq.tis.com by neptune.TIS.COM id aa21659; 31 Jul 96 17:22 EDT Received: by relay.hq.tis.com; id RAA00121; Wed, 31 Jul 1996 17:25:10 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000115; Wed, 31 Jul 96 17:24:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22786; Wed, 31 Jul 96 17:24:13 EDT Received: by relay.hq.tis.com; id RAA00110; Wed, 31 Jul 1996 17:24:40 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma000105; Wed, 31 Jul 96 17:24:28 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA117758392; Wed, 31 Jul 1996 14:26:33 -0700 Message-Id: <199607312126.AA117758392@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA126258391; Wed, 31 Jul 1996 17:26:32 -0400 To: Rob Adams Cc: ipsec@TIS.COM, naganand@ftp.com Subject: Re: Question on TCP MSS with repsect to IPSEC In-Reply-To: adams's message of Wed, 31 Jul 1996 14:01:01. <19960731140101adams@North-Bridge.cisco.com> Date: Wed, 31 Jul 1996 17:26:31 -0400 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk I hope the result of this discussion winds up in an I-D somewhere... This becomes an interesting problem though when you are speaking to a host with one association and then form another with different transforms. If I form another association with that host that requires AH with SHA and replay, then I want to shave off 32 bytes. Bookkeeping the fact that I've already shaved off 24 and only need to drop down an extra 8 is the interesting part. Presumably, one needs to send both secured and unsecured traffic at the same time (key management is one case where you'd want to do this..). Wouldn't it be simpler to keep a "pre-security" MTU in the routing table (or wherever), and a "post-security" MTU (and/or MTU delta) in the security association data structures? - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa22694; 31 Jul 96 18:01 EDT Received: by relay.hq.tis.com; id SAA01060; Wed, 31 Jul 1996 18:04:10 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001053; Wed, 31 Jul 96 18:03:45 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26807; Wed, 31 Jul 96 18:03:15 EDT Received: by relay.hq.tis.com; id SAA01048; Wed, 31 Jul 1996 18:03:40 -0400 Received: from cs.pdx.edu(204.203.64.22) by relay.tis.com via smap (V3.1.1) id xma001037; Wed, 31 Jul 96 18:03:11 -0400 Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13]) by cs.pdx.edu (8.7.3/CATastrophe-2/10/96-P) with ESMTP id PAA29727; Wed, 31 Jul 1996 15:05:33 -0700 (PDT) for Received: from localhost (jrb@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.7.3/CATastrophe-9/18/94-C) with ESMTP id PAA22248; Wed, 31 Jul 1996 15:05:32 -0700 (PDT) Message-Id: <199607312205.PAA22248@sirius.cs.pdx.edu> To: John K Zao Cc: ipsec@TIS.COM, jrb@cs.pdx.edu Subject: Re: PF_KEY Key Management API In-Reply-To: Your message of "Wed, 31 Jul 1996 14:23:28 CDT." <2.2.32.19960731192328.00710434@po1.bbn.com> Date: Wed, 31 Jul 1996 15:05:31 -0700 From: Jim Binkley Sender: ipsec-approval@neptune.tis.com Precedence: bulk Your message <2.2.32.19960731192328.00710434@po1.bbn.com>: >Hello, folks. > >Where could I find a document that describes the "PF_KEY Key Management >API"? The API is supported by the NRL IPSec implementation. In my course of >designing a key management API for Mobile IP, I would like to learn from its >design. > >Many thanks, > >John. > John, Greetings from PSU. I believe we will be visiting you in Sept. I can't speak authoritatively on this subject, as I am one NRL implementation out of date (studied Jan. as opposed to June), but from what I understood, the api was simply that of a routing socket that was an addition to the socket types already spoke by BSD 4.4. The only documentation in the Jan. release were man pages, probably for key(4) (the socket, based on the route socket), key(5) (the format of the /etc/keys file), and key(8)( the "manual" key daemon that could take /etc/keys and stuff it down the key socket). If you don't get a better answer, bug me in about a week as I will be looking at the new NRL release at that point. regards, Jim Binkley jrb@cs.pdx.edu Received: from relay.hq.tis.com by neptune.TIS.COM id aa23765; 31 Jul 96 18:57 EDT Received: by relay.hq.tis.com; id TAA01709; Wed, 31 Jul 1996 19:00:10 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001701; Wed, 31 Jul 96 18:59:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28486; Wed, 31 Jul 96 18:59:13 EDT Received: by relay.hq.tis.com; id SAA01696; Wed, 31 Jul 1996 18:59:40 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma001690; Wed, 31 Jul 96 18:59:10 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id QAA09487; Wed, 31 Jul 1996 16:01:07 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA16100; Wed, 31 Jul 1996 16:01:04 -0700 Message-Id: <9607312301.AA16100@maildig1.us.oracle.com> Date: Wed, 31 Jul 1996 16:01:04 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@TIS.COM Subject: DNS? was Re: Key Management, anyone? X-Orcl-Application: In-Reply-To:UNX02.US.ORACLE.COM:ipsec-approval@neptune.hq.tis.com's message of 23-Jul-96 00:39 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-22986713-0-0 Sender: ipsec-approval@neptune.tis.com Precedence: bulk --Boundary-22986713-0-0 DNS security has been advocated as "the" answer for IPsec key management. >From: Steven Bellovin > >The problem we have is the name-to-address mapping. Even though security for DNS is a serious problem, it would be a bad architectural design to link IPsec strongly to DNS security. First, it violates some of the basic IETF guidelines for Internet architecture to link mechanisms together in a way that makes successful fielding require both systems to function. Second, name-to-address mapping does not matter for many applications of IPsec. It does not matter what authenticated address a computer has as long as it has the correct authenticated "name" (eg dynamic assignment of IP addresses). Given the above issues with DNS security, DNS certificates still are a viable mechanism for establishing trusted names for end systems. The use of DNS as a certificate distribution system seems less important given the architectural issues and the ability of peer systems to exchange certificate chains. While I have reservations on the use of DNS, the ongoing work to rapidly field DNS based solutions is exciting and will provide significant benefits. I hope that additional work will continue on solutions using other certificate formats. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --Boundary-22986713-0-0 Content-Type: message/rfc822 Date: 23 Jul 96 00:39:56 From:"Steven Bellovin " To: dpkemp@missi.ncsc.mil Subject: Re: Key Management, anyone? Cc: rja@cisco.com,wdm@tycho.ncsc.mil,mjo@tycho.ncsc.mil,ipsec@tis.com X-Orcl-Application: Sender: ipsec-approval@neptune.hq.tis.com X-Orcl-Application: Precedence: bulk What smb said (not what you think he said, or what you think he should have said) was that "without DNSSEC, there's an unauthenticated step." I disagree. PGP provides some level of authentication, without DNSSEC, using plain DNS (plus PGP cert resource records) as a directory service. I confess that my mind is boggled by the thought of people arguing over what I did or didn't say or mean. Makes me feel like some sort of mystic oracle (but please don't offer me any goat entrails, even as a MIME attachment...). Anyway -- I stand by my statement, though I can and will expand on it a bit, and add a few qualifiers. The problem we have is the name-to-address mapping. Without DNSSEC -- or some local mechanism -- this step is completely unauthenticated, from the perspective of more-or-less vanilla applications that just call gethostbyname() or equivalent. The certificate for plugh.com may be signed by the director of NSA, the head of the (former) KGB, and John Gilmore -- and it's quite useless if an enemy can slip in a bogus IP address, since the firewall-based encryptor knows nothing but the IP address. To be sure, the DNSSEC tree does have what is (for some purposes) an inappropriate root. That can be dealt with by using manually configured certificates for subtrees of interest. It may not be a great solution -- and it's certainly not pretty -- but it permits local control and policies over an important step. (One could even use a PGP-like web of trust to distribute sets of zone keys.) To be sure, this only works if the implementations of DNSSEC permit local override keys -- but I think that it does. If not, it can be changed to do so, without affecting the over-the-wire protocol. What are the alternatives, assuming a smart application? If I want to talk to plugh.com, I can retrieve its certificate from my own trusted certificate hierarchy. I still need its IP address, though, which implies that I need DNS. If an enemy can spoof that, through lack of DNSSEC, we'd have a denial of service situation -- which is still better than information leakage, but far from ideal. What we still lack, though, is some standard way to tell a firewall encryptor, or even a bump-in-the-cord encryptor, which certificate to use. There's no reason we can't design such a protocol, of course, but we don't have one yet, and we'd have to confront the issue of identifying the proper outbound encryptor(s). Would that scheme work? Sure. The problem is that it doesn't scale well on the Internet, if our goal is ubiquitous cryptographic security. We'd need a separate tree, parallel to the DNS, with operational characteristics very similar to the DNS, but without a decade or so of operational experience in the implemenation. Outbound certificates are much less of a problem, since the local host or firewall can be told what certificate to use. My laptop may use its Fortezza card (well, your laptop might; I don't have a Fortezza card), a multiuser host might look up the user's certificate or use a per-host certificate, the firewall can check the source IP address (and if you can't trust that locally, you have no business using firewall-based encryption), etc. In a separate message, I list several important challenge areas for the IPSEC group. By challenges, I mean ``problems we have to solve in order to use IPSEC''. DNSSEC isn't on the list, since I consider that to be a solved problem for our purposes. --Steve Bellovin --Boundary-22986713-0-0--