From Paul_Lambert@poncho.phx.sectel.mot.com Tue Nov 24 03:36:04 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25926 (5.65c/IDA-1.4.4 for ); Tue, 24 Nov 1992 12:48:33 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA08762 (InterLock SMTP Gateway 1.1 for ); Tue, 24 Nov 1992 12:36:20 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA02035; Tue, 24 Nov 1992 11:36:46 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA28186; Tue, 24 Nov 1992 11:36:43 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA25955; Tue, 24 Nov 92 10:34:40 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA28966; Tue, 24 Nov 1992 10:42:32 MST Message-Id: <00112.2805446552.28966@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: ahoover@ans.net (Al Hoover) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 24 Nov 1992 10:36:04 MST Subject: Charter? Charter? Al, Has the draft charter been sent out on this mailing list yet? I seem to have only been added to the list and have not seen any traffic yet. Also, the ipsec archives only cover August of 92. Has there been any discussions since then? p.l. From ahoover@ans.net Wed Nov 25 11:21:43 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44450 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 16:18:38 -0500 Received: by interlock.ans.net id AA13750 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Wed, 25 Nov 1992 16:23:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Nov 1992 16:23:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Nov 1992 16:23:48 -0500 Date: Wed, 25 Nov 1992 16:21:43 -0500 From: Alton Hoover Message-Id: <199211252121.AA01285@hoovermac.ans.net> To: ipsec@ans.net Subject: Draft Charter IPSEC WG Readership: Attached is a copy of the draft charter of the IPSEC WG which was submitted to Steve Crocker, SAAG Chair 11-19-92. Thanks again to all attendees of the BOFs held on Tuesday and Thursday. Al Hoover DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT Internet Protocol Security (IPSEC) Protocol Working Group Working Group Charter Chair(s): Alton Hoover & Paul Lambert Security Area Director: Steve Crocker (SAAG) Mailing lists: General Discussion: ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net (retrieve ~pub/archive/ipsec) Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security protocol working group (IPSEC WG) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Subnet-to-subnet topologies will support recursive cryptographic encapsulation. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC - such as Kerberos) and manual distribution approaches. Goals and Milestones A standards track RFC for a cryptographic security protocol in the network layer will be developed. A standards track RFC for a cryptographic key management protocol in the application layer will be developed. Pilot implementations of network security integrated with key management will be developed and tested in the Internet. Milestone Dates 3/93 Draft specification of the network layer security protocol. Initial framework for Internet key management techniques 7/93 Working prototype of network layer security and key management for host-to-host security. Draft specification for Internet key management. 11/93 Enhanced specification for a security protocol in the network layer that includes subnet-to-subnet protection. 3/94 Enhanced specification for Internet key management that supports subnet-to-subnet security services. Working prototypes of subnet-to-subnet protection integrated with key management. 7/94 Full standards for a network layer security protocol and a Internet key management protocol based on public key techniques. From kent@BBN.COM Wed Nov 25 11:52:03 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38703 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 16:44:34 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA03940 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 16:51:45 -0500 Message-Id: <199211252151.AA03940@interlock.ans.net> To: Alton Hoover Cc: ipsec@ans.net, saag@tis.com Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Wed, 25 Nov 92 16:21:43 -0500. <199211252121.AA01285@hoovermac.ans.net> Date: Wed, 25 Nov 92 16:52:03 -0500 From: Steve Kent Given the ongoing work in CAT and PEM has significant key management aspects, I wonder if a separate WG might be a good place to develop a key management protocol that is already proposed to live in the application layer? I would hate to see the network layer focus of this WG cause a key management protocol to arise which might be too layer 3-centric. Of course close co-ordination would need to be maintained between two the WGs if a separate KM WG was formed, to ensure that the resulting protoco, adequately supports the requirements of a layer 3 security protocol. Steve From ahoover@ans.net Wed Nov 25 12:13:12 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12675 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 17:07:41 -0500 Received: by interlock.ans.net id AA22526 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Wed, 25 Nov 1992 17:15:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Nov 1992 17:15:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Nov 1992 17:15:15 -0500 Date: Wed, 25 Nov 1992 17:13:12 -0500 From: Alton Hoover Message-Id: <199211252213.AA01359@hoovermac.ans.net> To: kent@BBN.COM Subject: Re: Draft Charter IPSEC WG Cc: ipsec@ans.net Steve, You may very well have a point concerning a separate KM WG. It is certainly our intent/direction in the BOF discussions, to keep the key management in the applications layer. I personally advocate a standardized approach for applications level key management both for network layer security services as well as applications like PEM. The previous work within CAT and PEM must not be ignored, nor do we have the energy/cycles to waste re-inventing key management techniques. Al H. ); Wed, 25 Nov 1992 17:20:13 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA35673 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 17:27:53 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA15698 sendmail 5.65/QC-main-2.1 via SMTP Wed, 25 Nov 92 14:26:57 -0800 for ahoover@ans.net Received: by servo; id AA01399 sendmail 5.67/QC-subsidiary-2.1 Wed, 25 Nov 92 14:26:56 -0800 for saag@tis.com Date: Wed, 25 Nov 92 14:26:56 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9211252226.AA01399@servo> To: ahoover@ans.net, kent@BBN.COM Subject: Re: Draft Charter IPSEC WG Cc: ipsec@ans.net, saag@tis.com Steve, The key management protocol I envision for network-layer security would be interactive, something along the following lines: 1. The systems do a Diffie-Hellman key exchange and immediately begin using the resulting key for IP packet encryption (using symmetric cryptography) and/or authentication (using a keyed hash function). 2. The two systems immediately compute and transmit RSA signatures on the DH exchanges, also exchanging RSA public key certificates if necessary. If the signatures fail, or if they are not received after some timeout, the protocol resets to the unkeyed state and starts again. Once the signatures have been verified, other upper layer protocols and applications can be notified that secure communications are now available between that host pair. 3. Either host can reinitiate the keying process with a peer host at any time by destroying its current key for that host pair and returning to step 1. This protocol has some very nice properties for interactive communications, such as the fact that the host-pair "session" key is unrecoverable once it is destroyed, even if the entire exchange has been recorded and one or both hosts' private RSA keys are later compromised. And rekeying pairs of hosts on a regular basis (say, every 10 minutes) would limit the amount of data that could be compromised by compromising an active session key. The best an active eavesdropper could do is to trick the parties into revealing their public key certificates (by doing the middle-against-the-ends attack against the Diffie-Hellman step). However, the hosts would detect this as soon as they exchange RSA signatures and not use the key to authenticate or encrypt any user traffic. Unlike many application layer security protocols, this protocol assumes bidirectional communication. I don't know what you're planning for an application layer key exchange protocol, but it's possible that we may still several different protocols if yours must assume unidirectionality. Phil From kent@BBN.COM Wed Nov 25 13:37:23 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43893 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 18:29:45 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA30363 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 18:37:09 -0500 Message-Id: <199211252337.AA30363@interlock.ans.net> To: Phil Karn Cc: ahoover@ans.net, kent@BBN.COM, ipsec@ans.net, saag@tis.com, kent@BBN.COM Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Wed, 25 Nov 92 14:26:56 -0800. <9211252226.AA01399@servo> Date: Wed, 25 Nov 92 18:37:23 -0500 From: Steve Kent Phil, I was not indending to open debate on a key management protocol at this point, only suggest that a different WG to develop a key managent protocol might be appropriate. There are a variety of ways to achieve many of the features you stated as goals and which are available in the example you provided. Some do not require use of DH. There has been considerable work in this area by a number of folks for some time. Not just abstract discussions of what algorithms to use and what propereties they might have, but detailed work with specific formats, consideration of interactions with the security protocols being served, etc. Work is underway now in the IEEE 802.10 committee, for example. Anyway, this is just an indication of the scope of work that should be addressed under the key management protocol topic and why establishing a second WG may be in order. Steve From crocker@TIS.COM Wed Nov 25 13:54:36 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25226 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 18:46:43 -0500 Received: from TIS.COM by interlock.ans.net with SMTP id AA18645 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 18:54:39 -0500 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA02495; Wed, 25 Nov 92 18:54:49 EST Message-Id: <9211252354.AA02495@TIS.COM> To: Steve Kent Cc: Phil Karn , ahoover@ans.net, ipsec@ans.net, saag@TIS.COM Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Wed, 25 Nov 92 18:37:23 -0500. <199211252337.AA30363@interlock.ans.net> Date: Wed, 25 Nov 92 18:54:36 -0500 From: Stephen D Crocker Steve, et al., In my view, unless we have a protocol complete with fully specified key management, we don't have a usable result. The IPSEC WG should not invent anything it doesn't need to, but I would not be satisfied if it produces a specification for how to authenticate and/or encrypt packets and doesn't provide a usable means for setting up the keys. The result may be two different documents, as was done with the PEM specs. If the key management aspects are too complicated to do within the scope of this working group, then perhaps it's not yet time to initiate this work. However, if it's simply a matter of coordinating what's needed with other WGs, that's somethingt that can be done reasoanbly within the scope of this WG. Steve From karn@qualcomm.com Wed Nov 25 08:10:03 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38455 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 19:01:51 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA32523 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 19:09:46 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA21347 sendmail 5.65/QC-main-2.1 via SMTP Wed, 25 Nov 92 16:10:05 -0800 for ahoover@ans.net Received: by servo; id AA01688 sendmail 5.67/QC-subsidiary-2.1 Wed, 25 Nov 92 16:10:03 -0800 for saag@tis.com Date: Wed, 25 Nov 92 16:10:03 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9211260010.AA01688@servo> To: karn@BBN.COM, kent@BBN.COM Subject: Re: Draft Charter IPSEC WG Cc: ahoover@ans.net, ipsec@ans.net, saag@tis.com Steve, Excellent. I have no real desire to reinvent the wheel - I am only pointing out that one single key management protocol may not be enough. There will probably need to be a variety of key management protocols, each designed for different environments. E.g., one for "slow" unidirectional communication, e.g., email, and a "better" one where "fast" bidirectional communications can be assumed, e.g., IP layer security. Nevertheless, I do believe that the way to actually accomplish something in this group is to start building and experimenting with prototypes ASAP. One can study the problem to death only for so long before the users revolt and start building their own ad-hoc solutions that themselves become the standard (witness PGP and even TCP/IP itself). Phil From karn@qualcomm.com Wed Nov 25 08:24:28 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14734 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 19:17:43 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA09519 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 19:24:17 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA22590 sendmail 5.65/QC-main-2.1 via SMTP Wed, 25 Nov 92 16:24:30 -0800 for ahoover@ans.net Received: by servo; id AA01730 sendmail 5.67/QC-subsidiary-2.1 Wed, 25 Nov 92 16:24:28 -0800 for saag@TIS.COM Date: Wed, 25 Nov 92 16:24:28 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9211260024.AA01730@servo> To: crocker@TIS.COM, kent@bbn.com Subject: Re: Draft Charter IPSEC WG Cc: ahoover@ans.net, ipsec@ans.net, karn@TIS.COM, saag@TIS.COM Steve (Crocker), Although I agree that fully specified key management is important, I don't agree that an IP security protocol would be "unusable" without it. I can think of some immediate and valuable applications for IP level security around here even if it only supported manually installed DES keys for the time being. For example, when combined with IP encapsulation one only need implement IP security in a few "security gateways" to provide an interim "pseudo link level" security feature between trusting communities of hosts separated by untrusted networks. For example, consider a multi-site company who wants to replace their dedicated intersite leased lines with public Internet connections. Eventually, as more hosts implement the security protocol, and as the general key management protocols become available, the hosts could begin to take responsibility for their own security. If someday all the hosts support the IP security protocol, then the encapsulating security gateways could be retired. I think the IP security work factors very nicely into two parallel tasks: the IP security protocol itself (authentication and encryption of IP datagrams assuming the existence of a shared key for each host pair using the protocol), and the protocol mechanisms for establishing those keys. I see no reason to delay work on the former until the latter is done. Phil From crocker@TIS.COM Wed Nov 25 14:35:47 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25112 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 19:27:49 -0500 Received: from TIS.COM by interlock.ans.net with SMTP id AA33852 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 19:35:50 -0500 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03345; Wed, 25 Nov 92 19:36:00 EST Message-Id: <9211260036.AA03345@TIS.COM> To: karn@qualcomm.com (Phil Karn) Cc: ipsec@ans.net, saag@TIS.COM Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Wed, 25 Nov 92 16:24:28 -0800. <9211260024.AA01730@servo> Date: Wed, 25 Nov 92 19:35:47 -0500 From: Stephen D Crocker Phil, We're not in fundamental disagreement. I have two concerns. My lesser concern is that without some form of usable key management, only ad hoc use of the network authentication/encryption protocol will exist. My greater concern is that work on the key management will get bogged down and never emerge. Otherwise, I agree there are two parallel paths and we can design this from the inside out -- or bottom up -- and gain experience. Incidentally, we are jiggering our TIS/PEM implementation to cough up a DES key, so there's an instant scheme for distributing DES keys securely to sites which run PEM. (By "jiggering" I mean the following. Whenever a user sends an encrypted message in PEM, the sender software creates a DES key and uses it to encrypt the message. The DES key is then encrypted under each receiver's public key and included in the message. Each receiver finds his copy of the encrypted DES key, decrypts it, and then uses the DES key to recover the message. The jiggering consists of optionally including the DES key with the decrypted message. Thus, the sender does not have to generate a separate key or include it in the message in some ad hoc fashion; all of that is automatic. All that's needed is for each receiver to read the message, extract the DES key and insert it into the application. Thus, along the lines you describe, there's a ready-made scheme for privately distributing DES keys. Steve From karn@qualcomm.com Wed Nov 25 08:50:07 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31874 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 19:41:47 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA29028 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 19:49:43 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA24112 sendmail 5.65/QC-main-2.1 via SMTP Wed, 25 Nov 92 16:50:09 -0800 for ipsec@ans.net Received: by servo; id AA01964 sendmail 5.67/QC-subsidiary-2.1 Wed, 25 Nov 92 16:50:07 -0800 for saag@TIS.COM Date: Wed, 25 Nov 92 16:50:07 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9211260050.AA01964@servo> To: crocker@TIS.COM Subject: Re: Draft Charter IPSEC WG Cc: ipsec@ans.net, karn@qualcomm.com, saag@TIS.COM Steve, That's an excellent idea about "jiggering" the DES keys. Of course, if you need more than 56 key bits (e.g., if you use IDEA instead of DES) then you'll have to send several messages. :-) Phil PS. Your mailer doesn't seem to be qualifying my name in your To: headers. When I reply my mailer appends @tis.com, which then bounces. From smb@research.att.com Wed Nov 25 16:02:22 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA53379 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 20:54:22 -0500 Received: from research.att.com by interlock.ans.net with SMTP id AA31263 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 21:02:18 -0500 Message-Id: <199211260202.AA31263@interlock.ans.net> From: smb@research.att.com Received: by bigbird; Wed Nov 25 21:02:25 EST 1992 To: crocker@tis.com, kent@bbn.com, karn@qualcomm.com, ipsec@ans.net, saag@tis.com Subject: Re: Draft Charter IPSEC WG Date: Wed, 25 Nov 92 21:02:22 EST The problem with setting up a key management working group now is that the requirements for it aren't clear. Just to pick an example out of a hat, electronic mail requires a very different protocol than does, say, SNMP, where a network management center will rarely try to control a random network element that they didn't install. Even if public key technology is needed in that case -- and I can imagine some circumstances where it might be useful, though not mandatory -- one certainly doesn't need the full-blown signature overhead. Let's figure out what types of keys IPSEC, or CAT, or PEM, or whatever need. Then we'll know what to ask of a key management protocol. --Steve Bellovin From ho@cs.arizona.edu Wed Nov 25 12:45:13 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA49410 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 21:36:41 -0500 Received: from optima.cs.arizona.edu by interlock.ans.net with SMTP id AA18545 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 21:44:52 -0500 Received: from umbra.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA06223; Wed, 25 Nov 1992 19:45:16 MST Date: Wed, 25 Nov 1992 19:45:13 MST From: "Hilarie Orman" Message-Id: <199211260245.AA28508@umbra.cs.arizona.edu> Received: by umbra.cs.arizona.edu; Wed, 25 Nov 1992 19:45:13 MST To: smb@research.att.com Cc: saag@tis.com, ipsec@ans.net, karn@qualcomm.com, kent@bbn.com, crocker@tis.com In-Reply-To: Your message <199211260202.AA31263@interlock.ans.net> Subject: Re: Draft Charter IPSEC WG It seems to make sense to sound the barbaric YAWG for KM, as long as the charter of the KMWG is not to force a once-size-fits all KM protocol, but to define the suite. After all, there's more than one dimension to the problem, but space isn't all that big. There is enough knowledge available to do this, and feedback from the particular layer WG's like IPSEC would ensure a good match to the needs. I support the idea of choice with respect to KM for the network layer. There are a variety of needs, and I doubt that bringing everyone under one umbrella can be forced. There are administrative and architectural issues that will intervene. (Is everyone getting enough copies of these messages?) From dcrocker@Mordor.Stanford.EDU Wed Nov 25 10:53:29 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19838 (5.65c/IDA-1.4.4 for ); Wed, 25 Nov 1992 21:44:54 -0500 Received: from Mordor.Stanford.EDU by interlock.ans.net with SMTP id AA29049 (InterLock SMTP Gateway 1.1 for ); Wed, 25 Nov 1992 21:53:05 -0500 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA00891; Wed, 25 Nov 92 18:53:29 -0800 Message-Id: <9211260253.AA00891@Mordor.Stanford.EDU> To: Stephen D Crocker Cc: saag@tis.com, iesg-tech@CNRI.Reston.VA.US, ipsec@ans.net Subject: Re: [Alton Hoover: Draft Charter IPSEC WG] Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 25 Nov 92 17:53:32 -0500. <9211252253.AA00832@TIS.COM> Date: Wed, 25 Nov 92 18:53:29 -0800 From: Dave Crocker X-Mts: smtp Alton, The proposed wg charter looks crisp and straightforward, with a relatively aggressive schedule. My guess is that the charter and schedule either are a) well-founded and pragmatic, or b) hopelessly naive. The latter possibility occurs to me primarily because of the history of difficulties with this topic. The former alternative seems more likely, since I doubt the Security area director would have let this one past easily. Simple question: Do you and others believe that you have the gist of the 2 solutions (net-layer protocol and key protocol) already fleshed out or do you expect substantial haggling about basic approaches? If the former applies, then I believe your schedule. If the latter applies, then you have a heck of a challenge ahead. (Hmmm. I suspose you have _that_ no matter what.) Dave From shirey@mitre.org Fri Nov 27 04:26:01 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15439 (5.65c/IDA-1.4.4 for ); Fri, 27 Nov 1992 09:23:25 -0500 Received: from mwunix.mitre.org by interlock.ans.net with SMTP id AA18969 (InterLock SMTP Gateway 1.1 for ); Fri, 27 Nov 1992 09:24:10 -0500 Return-Path: Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA15872; Fri, 27 Nov 92 09:24:36 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA00116; Fri, 27 Nov 92 09:24:24 EST Message-Id: <9211271424.AA00116@smiley.mitre.org.sit> Date: Fri, 27 Nov 1992 09:26:01 -0500 To: crocker@TIS.COM From: shirey@mitre.org Sender: shirey@smiley.mitre.org Subject: Re: Draft Charter IPSEC WG Cc: ipsec@ans.net, saag@TIS.COM At the ipsec meeting, I spoke in favor of having a separate WG for key management. Steve Crocker then offered his objection as outlined in his e-mail message: that layer 3 e3 protocol without fully specified key management is worthless. I think Phil Karns has now answered Crocker's objection. I believe it necessary to split off key management in order to get anything done in either group. The key mgmt group will discuss a very different set of issues than ipsec will. The ipsec group probably also will get dragged into the ROAD issues, since there is no other group to address security question for a new IP. These wgs need to be separate to achieve focus and move forward. I think that the last year of PEM delays shows the disadvantage of tolerating a forced linkage between technical areas. Everything is linked in the Internet! One might as well argue that IP and TCP should always be in the same wg since we mostly use one with the other. Regards, -Rob- Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Dr., McLean, Virginia 22102-3481 USA shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397 From shirey@mitre.org Fri Nov 27 08:17:59 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13405 (5.65c/IDA-1.4.4 for ); Fri, 27 Nov 1992 13:14:45 -0500 Received: from mwunix.mitre.org by interlock.ans.net with SMTP id AA13825 (InterLock SMTP Gateway 1.1 for ); Fri, 27 Nov 1992 13:16:05 -0500 Return-Path: Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA22950; Fri, 27 Nov 92 13:16:31 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA01730; Fri, 27 Nov 92 13:16:21 EST Message-Id: <9211271816.AA01730@smiley.mitre.org.sit> Date: Fri, 27 Nov 1992 13:17:59 -0500 To: Stephen D Crocker From: shirey@mitre.org Sender: shirey@smiley.mitre.org (Unverified) Subject: Jiggering Cc: ipsec@ans.net, saag@TIS.COM WARNING! Potential disaster. Suggest you should consult key management expertise. From crocker@TIS.COM Sat Nov 28 09:38:48 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15798 (5.65c/IDA-1.4.4 for ); Sun, 29 Nov 1992 03:29:06 -0500 Received: from TIS.COM by interlock.ans.net with SMTP id AA13683 (InterLock SMTP Gateway 1.1 for ); Sun, 29 Nov 1992 03:36:40 -0500 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03973; Sat, 28 Nov 92 14:39:18 EST Message-Id: <9211281939.AA03973@TIS.COM> To: ipsec@ans.net, saag@TIS.COM Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Fri, 27 Nov 92 09:26:01 -0500. <9211271424.AA00116@smiley.mitre.org.sit> Date: Sat, 28 Nov 92 14:38:48 -0500 From: Stephen D Crocker Rob Shirey, Hilarie Orman, Dave Crocker, Phil Karn, et al. all responded to my call for having the IPSEC WG design both the network layer security protocol and a key management protocol to accompany it. As with many situations, our perceptions are formed by prior bad experiences. In this case, I think there are two relevant negative examples. In the case of PEM, the focus on a specific key management protocol and accompanying policy added considerable time to the development of the protocol. I agree we want to avoid a similar delay in the IPSEC WG. Over in the OIS arena, it's my impression that SP3, SP4, NLSP and TLSP have been bouncing around for a few years without culminating in a usable protocol. I'm under the impression that one missing ingredient is the lack of key management protocol to accompany the network or transport layer protocol. In my prior note, I had this example in mind. The goal for the IPSEC WG is to define a network layer security protocol usable in the near future as part of the IP suite. Splitting off the key management part of the problem is fine as long as it gets done. I suppose we can punt and use manual key distribution techniques in the short run or roll our own ad hoc techniques. The main thing is to get the network layer defined and to have a reasonable path for getting the key management defined and deployed, one way or the other. Steve From nmh@thumper.bellcore.com Fri Nov 27 04:58:24 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA47797 (5.65c/IDA-1.4.4 for ); Sun, 29 Nov 1992 03:34:32 -0500 Received: from thumper.bellcore.com by interlock.ans.net with SMTP id AA44217 (InterLock SMTP Gateway 1.1 for ); Sun, 29 Nov 1992 03:42:12 -0500 Received: from winter.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ipsec@ans.net; Fri, 27 Nov 92 09:58:03 EST Received: by winter.bellcore.com (4.12/4.7) id AA00691; Fri, 27 Nov 92 09:58:24 est Date: Fri, 27 Nov 92 09:58:24 est From: nmh@thumper.bellcore.com (Neil Haller) Message-Id: <9211271458.AA00691@winter.bellcore.com> To: ipsec@ans.net Subject: IPSEC & ROAD Bob Shirey wrote: The ipsec group probably also will get dragged into the ROAD issues, since there is no other group to address security question for a new IP. I agree agree with Bob, and I feel that it is appropriate that IPSEC consider security issues for the new IP. The important thing is that we not get bogged down. I propose that we consider security for the current IP, and security for IPv7 as disjoint issues. Neil Haller Bellcore nmh@thumper.bellcore.com 201 829-4478 From karn@qualcomm.com Wed Nov 28 18:08:11 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31281 (5.65c/IDA-1.4.4 for ); Sun, 29 Nov 1992 05:00:04 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA22248 (InterLock SMTP Gateway 1.1 for ); Sun, 29 Nov 1992 05:07:52 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA27154 sendmail 5.65/QC-main-2.1 via SMTP Sun, 29 Nov 92 02:08:12 -0800 for ipsec@ans.net Received: by servo; id AA16692 sendmail 5.67/QC-subsidiary-2.1 Sun, 29 Nov 92 02:08:11 -0800 for nmh@thumper.bellcore.com Date: Sun, 29 Nov 92 02:08:11 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9211291008.AA16692@servo> To: ipsec@ans.net, nmh@thumper.bellcore.com Subject: Re: IPSEC & ROAD I think IP version issues are probably orthogonal to the IP security design I had in mind. An "IP security protocol" should be just that - a modular "protocol" that rides above IP. The Protocol field in the IP header would contain a (newly assigned) value meaning "security protocol". The original Protocol value (e.g., corresponding to TCP or UDP) would move into a field inside the (encrypted) security protocol header. On the wire, the packet might look something like this Link header, type = IP|IP header, PID=security|security header, PID=6|TCP|data |<- clear ->|<- encrypted ->| This makes the security protocol a modular component that could ride on top of any IP-like protocol, regardless of address size or format, and under any transport protocol. And when practicality (i.e., lack of universal implementation) dictates that you use the IP security protocol in a "security gateway" instead of in the hosts being protected, you use a separate mechanism (e.g., protocol 94, IP-IP) to carry the "inner" IP datagram on top of the security protocol: Link |"outer" IP hdr|security hdr, PID=94 | "inner" IP hdr, PID=6 | TCP|data |<- clear ->|<- encrypted ->| If the security protocol follows this general design, then it ought to be independent of IP version, so long as protocol fields remain 8 bits wide. And as long as IP remains connectionless (if it doesn't, I quit! :-). Phil From teb@saturn.sys.acc.com Mon Nov 30 04:15:02 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA58890 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 09:15:17 -0500 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA13585 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 09:16:03 -0500 Received: from saturn.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA00544; Mon, 30 Nov 92 06:12:51 EST Received: by saturn.sys.acc.com (5.51/5.17) id AA22497; Mon, 30 Nov 92 09:15:02 EST Date: Mon, 30 Nov 92 09:15:02 EST From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9211301415.AA22497@saturn.sys.acc.com> To: ipsec@ans.net Subject: Re: Draft Charter IPSEC WG I'm curious why the initial thrust is on host-host support, followed by subnet-subnet. In the real world, it will certainly take a long time for widespread support for this protocol in hosts. Is the real focus on getting something ready for firewall/gateway systems? Maybe this is just to allow us to experiment more easily? Tom Benkart ACC Systems From tardo@tardo.lkg.dec.com Mon Nov 30 05:03:19 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09302 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 10:06:17 -0500 Received: from mts-gw.pa.dec.com by interlock.ans.net with SMTP id AA12522 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 10:05:37 -0500 Received: by mts-gw.pa.dec.com; id AA11778; Mon, 30 Nov 92 07:03:46 -0800 Received: by tardo.lkg.dec.com (5.57/Ultrix3.0-C) id AA05342; Mon, 30 Nov 92 10:03:20 -0500 Message-Id: <9211301503.AA05342@tardo.lkg.dec.com> To: Stephen D Crocker Cc: ipsec@ans.net, saag@tis.com, tardo@tardo.lkg.dec.com Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of "Sat, 28 Nov 92 14:38:48 EST." <9211281939.AA03973@TIS.COM> Date: Mon, 30 Nov 92 10:03:19 -0500 From: tardo@tardo.lkg.dec.com X-Mts: smtp I'm a little concerned that the wheel is going to be reinvented here yet again. Not that it shouldn't, just that it might. The main reasons [SP{2,3,4}|{N,T}LSP] efforts have not "culminated in a usable protocol" are threefold, as I can see: 1. an unfortunate choice of securing a stack that nobody uses 2. delays and overdesign caused by unproductive religious bickering over layer issues 3. the fact that not enough people actually feel they want it I can do something about the first two, like compromise my own sometimes too dug-in positions, but I have been at wits end to deal with the third. I have been as guilty as this group seems to be of the "it we build it, they will come" mentality. We built it, and they didn't come. Others built it, too, and a few potential users came by and sniffed, but rarely did anyone buy except under duress. I'd feel better if there were some actual quantification of need, expressed in a public forum, with potential users (not "the government and the banks") actually identified. Sorry to be so negative, it's based on years of fun. Now some more constructive comments, on Alton Hoover and Paul Lambert's Draft charter. 1. What do you mean by "access control"? Do you mean labelling? Packet filtering? This should probably not be an early requirement. 2. Sprinkle "algorithm independence" in somewhere. 3. What do you mean by "integrity" for a datagram service? This is a snake pit if you are worried about replay. 4. "Subnet-to-subnet ... recursive ... encapsulation" is a bit too specific for terms of reference. 5. Key management - let's be realistic. I suggest the "minimalist" (KISS) approach to start: manual keying via SNMP (: duck :) with a nice little MIB. Next should come a peer-peer exchange in the layer ("Key Exchange Control Protocol"), something akin to what Phil Karn (others before him) have suggested, but as lightweight as possible. Later on (much later) should come the all-singing-all-dancing-802.10-KMAE- X9.17-compatible-Holy-Grail ultimate one-size-fits-all key exchange application, if ever. 6. Finally, is it integrated in IP or a sublayer? In other words, is this limited to "externally observable" interworking issues or are you going to delve into end-system interface issues? This starts to get into the "assurance" question... The schedule looks ok for an encapsulating frame, no replay integrity hacks, SP3-D-based protocol with MIB keying, end-system-to-end-system, no assurance, no access control or authentication beyond "yup, key works!". I think the schedule is a bit optimistic for resolution on gateway-to-gateway or key management layer debates, but why not try? -- Joe From kasten@ftp.com Mon Nov 30 08:25:53 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21289 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 13:24:38 -0500 Received: from ftp.com (babyoil.ftp.com) by interlock.ans.net with SMTP id AA26600 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 13:25:22 -0500 Received: by ftp.com id AA04646; Mon, 30 Nov 92 13:25:53 -0500 Date: Mon, 30 Nov 92 13:25:53 -0500 Message-Id: <9211301825.AA04646@ftp.com> To: ahoover@ans.net Subject: Re: Draft Charter IPSEC WG From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipsec@ans.net Al, I skimmed through your IPSEC WG charter. One thing that might be missing. For IPv7 we are currently going through a long process of figuring out what exactly should be in IPv7 and so on. Security is one of the things we want. The sooner the IPv7 protocol designers can get some feeling from the security people as to what is needed from the IP layer, the easier it will be to integrate security into IPv7 when that happens. -- Frank Kastenholz From crocker@TIS.COM Mon Nov 30 08:54:23 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07586 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 13:55:23 -0500 Received: from TIS.COM by interlock.ans.net with SMTP id AA13707 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 13:55:33 -0500 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA00165; Mon, 30 Nov 92 13:54:39 EST Message-Id: <9211301854.AA00165@TIS.COM> To: kasten@ftp.com Cc: ipsec@ans.net Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Mon, 30 Nov 92 13:25:53 -0500. <9211301825.AA04646@ftp.com> Date: Mon, 30 Nov 92 13:54:23 -0500 From: Stephen D Crocker Frank, In both the IPSEC BOF and the SAAG we did discuss the security needs of IPv7. It's not at all clear what those needs are, but it is clear that we should make sure this issue is discussed. From a formal chartering viewpoint, the focus of the IPSEC WG ought to be the creation of a security protocol at the IP layer, and the charter should mention that the IP layer is undergoing change. But that presents the matter only from the point of view of preparing the IPSEC effort for whatever changes might be coming. For the other side of the issue, viz providing the IP community with advice, I think the right thing at the moment is to make sure the relevant folks are coupled into the discussion. "Relevant" to me inlcudes the IESG, the IAB, SAAG, the PSRG and the IPSEC WG. (The order of this list reflects no value judgment, and I may have left out one or more relevant groups.) Steve From solo@BBN.COM Mon Nov 30 03:48:27 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19751 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 14:43:48 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA06409 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 14:51:25 -0500 Message-Id: <199211301951.AA06409@interlock.ans.net> To: Stephen D Crocker Cc: ipsec@ans.net, saag@tis.com, solo@BBN.COM Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Sat, 28 Nov 92 14:38:48 -0500. <9211281939.AA03973@TIS.COM> Date: Mon, 30 Nov 92 08:48:27 -0500 From: solo@BBN.COM Steve, My thoughts regarding the IPSEC WG were that, at a minimum, we would have to identify the KM services required by the target protocol we were describing. This is essentially the approach taken with some of the protocols you list for the network layer. It is also the approach being taken in other ongoing NLSP profiling activities. Once the requirements exist, then the question of whether we select/recommend/ develop an approach is a secondary issue. I certainly hope/expect that we will be able to adopt one of the current emerging standards. A particular concern I have is the distinction between key management in its simplest form (get the key to all the people (but only them) that need it) and security association management. For the candidate class of security protocol we are describing, distribution of the key is just one of the services required. For all but the simplest cases, it is necessary to negotiate service parameters as well as identification and access control information. Beyond addressing conventions, the specification of these association parameters (and how to authenticate them, if necessary) may be the largest open issue the WG has to deal with. Dave From dee@ranger.enet.dec.com Mon Nov 30 05:32:55 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA59050 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 16:25:03 -0500 Received: from enet-gw.pa.dec.com by interlock.ans.net with SMTP id AA16559 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 16:32:35 -0500 Received: by enet-gw.pa.dec.com; id AA23656; Mon, 30 Nov 92 13:32:51 -0800 Message-Id: <9211302132.AA23656@enet-gw.pa.dec.com> Received: from ranger.enet; by decwrl.enet; Mon, 30 Nov 92 13:32:55 PST Date: Mon, 30 Nov 92 13:32:55 PST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 30-Nov-1992 1632" To: karn@qualcomm.com Cc: dee@ranger.enet.dec.com, ipsec@ans.net Apparently-To: ipsec@ans.net, karn@qualcomm.com Subject: RE: Re: IPSEC & ROAD I have a different view. I think that a good part of any "IP Security Protocol" needs to be an IP Option. This is particularly true of authentication. Here are some reasons: (1) You would like to authenicate ICMP messages (redirects, quenches, etc.), DNS responses (even if the query isn't authenticated), etc. This requires some way to sign the datagram, perhaps with an RSA signed digest like thing. However, you don't want to have to negotiate this with the destination and would like things to "work" even if the destination is ignorant of the security protocol. After you have converted your local routers to produce authenticated redirects, you don't want to have to make all your hosts understand this or even have to keep a table of which do and don't. (There was some joking at the IETF about using a forged redirect to 127.0.0.1 as a particularly effective form of source quench...) Similarly, there is little reason to secure queries to the DNS, or any similar public database, but it would be nice to have authenticated responses always generated where the destination of the answer could be authentication aware or not. An unknown option is supposed to be ignored so a security option, when used in authentication mode, should have the desired effects. You could also protect against replay with a time field. (2) You would like to be able to send "secure" datagrams through various filters that look at the protocol field and perhaps port. For authentication only, they can look as deep into other layers as they want. If you want confidentiality and to still be able to get through such filters, you would need some kludge like a field that says where encryption starts in the "data", so you could leave the TCP header, say, clear if you wanted. I'm not sure just how much this variable encryption start byte would be worth but it does not seem all that hard. I think you would only want to use an encapsulating protocol in cases where you want confidentiality for the underlying protocol type or for one or more end-to- end IP options. Donald PS: To get stuff like that in item 1 above to work, you probably have to store public keys in the DNS and have the DNS servers be some of the first to be secured. -------------- From: US1RMC::"karn@qualcomm.com" "Phil Karn" 29-NOV-1992 05:12 To: ipsec@ans.net, nmh@thumper.bellcore.com Subj: Re: IPSEC & ROAD I think IP version issues are probably orthogonal to the IP security design I had in mind. An "IP security protocol" should be just that - a modular "protocol" that rides above IP. The Protocol field in the IP header would contain a (newly assigned) value meaning "security protocol". The original Protocol value (e.g., corresponding to TCP or UDP) would move into a field inside the (encrypted) security protocol header. On the wire, the packet might look something like this Link header, type = IP|IP header, PID=security|security header, PID=6|TCP|data |<- clear ->|<- encrypted ->| This makes the security protocol a modular component that could ride on top of any IP-like protocol, regardless of address size or format, and under any transport protocol. And when practicality (i.e., lack of universal implementation) dictates that you use the IP security protocol in a "security gateway" instead of in the hosts being protected, you use a separate mechanism (e.g., protocol 94, IP-IP) to carry the "inner" IP datagram on top of the security protocol: Link |"outer" IP hdr|security hdr, PID=94 | "inner" IP hdr, PID=6 | TCP|data |<- clear ->|<- encrypted ->| If the security protocol follows this general design, then it ought to be independent of IP version, so long as protocol fields remain 8 bits wide. And as long as IP remains connectionless (if it doesn't, I quit! :-). Phil From kent@BBN.COM Mon Nov 30 17:39:26 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28272 (5.65c/IDA-1.4.4 for ); Mon, 30 Nov 1992 22:31:57 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA25395 (InterLock SMTP Gateway 1.1 for ); Mon, 30 Nov 1992 22:39:11 -0500 Message-Id: <199212010339.AA25395@interlock.ans.net> To: Stephen D Crocker Cc: ipsec@ans.net Subject: Re: Draft Charter IPSEC WG In-Reply-To: Your message of Sat, 28 Nov 92 14:38:48 -0500. <9211281939.AA03973@TIS.COM> Date: Mon, 30 Nov 92 22:39:26 -0500 From: Steve Kent Steve, Ypu misunderstand the progress (or lack thereof ) re SP3/4, NLSP, etc. There is a key management protocol for use with SP3/4 and there is at least one product sold which makes use of this protocol. The delays in NLSP have a lot to d with the efforts of some folks to shoehorn in connection-oriented protoco, support, after SP3 was desogned for a connectionless environment. So, I think some of the conclusions you are reaching re the importance of closely tied development of key management protocol may be based on inaccurate perceptions of what has happened with regard to the protocols you cited. On the other hand, I do believe that it is important to have the net layer security protocol work done in close concert with a key management effort. My only concern, as stated in my initial message, is that we not get so focused that the resulting key management protocol becomes usable ONLY for layer 3. The key management infrastructure developed for PEM is usable for the network layer, in an interactive context, but the way certificates are used would be different 9to accommodate tye real time exchange). Alternatively, one could develop an approach based on the DH and subsequent RSA exchange Phil described. This needs to be explored in a context larger than just the network layer if we are to get maximum benefit from the resulting effort. Steve P.S. And yes, there has been substantial work in this area.