From ipsec-request@ans.net Fri Oct 8 06:03:28 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13517 (5.65c/IDA-1.4.4 for ); Fri, 8 Oct 1993 16:12:53 -0400 Received: by interlock.ans.net id AA08540 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 8 Oct 1993 16:02:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 8 Oct 1993 16:02:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 8 Oct 1993 16:02:31 -0400 Date: Fri, 8 Oct 1993 13:03:28 MST From: "Hilarie Orman" Message-Id: <199310082003.AA25206@umbra.cs.arizona.edu> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 8 Oct 1993 16:02:31 -0400 To: ipsec@ans.net Subject: Network security research project We are looking for candidates interested in the opportunity to be part of a research project in network security. This ARPA-funded 3 year project will develop an internet security archictecture through a highly modular representation of network security protocols. This approach will be used to secure existing protocols and to develop new ones. We are located in the Department of Computer Science at the University of Arizona, Tucson, Arizona. Familiarity with the principles of computer and network security, comfort with Unix and C, and experience working in a research environment are essential requirements. One fulltime position will be available. Tucson is located in the Sonoran desert, and is a city of 600K people and seven mountain ranges. In addition to the beauty of the environment, there are a multitude of excellent espresso bars. Contact: Hilarie Orman or Sean O'Malley ho@cs.arizona.edu 602-621-4891 sean@cs.arizona.edu 602-621-3498 Computer Science Department Gould-Simpson Building University of Arizona Tucson, AZ 85721 602-621-4246 (fax) From ipsec-request@ans.net Fri Oct 8 20:59:51 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07929 (5.65c/IDA-1.4.4 for ); Fri, 8 Oct 1993 17:02:06 -0400 Received: by interlock.ans.net id AA08458 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 8 Oct 1993 16:59:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 8 Oct 1993 16:59:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 8 Oct 1993 16:59:01 -0400 Message-Id: <199310082059.AA26458@vax.darpa.mil> To: "Hilarie Orman" Cc: ipsec@ans.net Reply-To: stjohns@ARPA.MIL Subject: Re: Network security research project In-Reply-To: Your message of Fri, 08 Oct 1993 13:03:28 -0700. <199310082003.AA25206@umbra.cs.arizona.edu> Date: Fri, 08 Oct 1993 16:59:51 -0400 From: Michael StJohns Guys - apologies - I'm funding this and I agree job recruiting is a no-no on IETF lists. *sigh* Mike From ipsec-request@ans.net Fri Oct 8 22:26:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17206 (5.65c/IDA-1.4.4 for ); Fri, 8 Oct 1993 18:30:51 -0400 Received: by interlock.ans.net id AA19126 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 8 Oct 1993 18:25:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 8 Oct 1993 18:25:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 8 Oct 1993 18:25:00 -0400 From: "Sean O'Malley" Message-Id: <199310082226.AA12692@mesquite.cs.arizona.edu> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 8 Oct 1993 18:25:00 -0400 Subject: sorry about the job posting To: ipsec@ans.net Date: Fri, 8 Oct 1993 15:26:20 -0700 (MST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 112 My appologies for the job posting. We did not know of the restrictions on IETF mailing lists. Sean O'Malley From ipsec-request@ans.net Tue Oct 12 03:19:57 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20627 (5.65c/IDA-1.4.4 for ); Tue, 12 Oct 1993 13:29:41 -0400 Received: by interlock.ans.net id AA16584 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 12 Oct 1993 13:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 12 Oct 1993 13:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 12 Oct 1993 13:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 12 Oct 1993 13:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 12 Oct 1993 13:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 12 Oct 1993 13:20:24 -0400 Message-Id: <00112.2833266370.49790@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 12 Oct 1993 10:19:57 MST Subject: IPSEC at the Twenty-Eighth Subject: IPSEC at the Twenty-Eighth IETF Message: There will be two IP Security (IPSEC) WG Meetings at the Twenty-Eighth IETF. They are scheduled as follows: Tuesday, November 2, 1993 (0930-1200) IPSEC - IP Security, network security protocol Wednesday, November 3, 1993 (0930-1200) IPSEC - Key Management for IP Security A complete agenda will be posted on October 15. Please send me a note if you would like to: - give a presentation - demonstrate a network security implementation - add a specific topic to the agenda Paul From ipsec-request@ans.net Wed Oct 13 05:25:17 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19387 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 09:32:22 -0400 Received: by interlock.ans.net id AA20840 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 09:23:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 09:23:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 09:23:29 -0400 Date: Wed, 13 Oct 93 09:25:17 EDT From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9310131325.AA04110@sloth.ncsl.nist.gov> To: Subject: Key Managment Query/Comments... Cc: Rob_Glenn, maughan@cs.umbc.edu, walters@sloth.ncsl.nist.gov Hello all: It seems to me that key managment has two major functional parts: 1) the managment and exchange of security association attributes in a secure fashion, and 2) a key distribution mechanism so keys can be securely exchanged and used as part of the security association attributes. Assuming all of this is true, there seems to be two possible architectural solutions (actually there are more, but these two in particular are more interesting). The first (and the one I've seen explored more often) would be to develop a simple managment and key distribution protocol specifically designed to use installed lower layer security mechanisms to provide a secure managment channel. Some very small amount of security might exist in this protocol, but most would be provided by already existing security (IPSP). The second model would be to use an existing managment protocol that contains robust security (SNMP-V2) to protect it's managed objects. Creating a MIB to manage security protocol objects shouldn't be that difficult. The only thing that seems to be missing from SNMP-V2 is a scalable key distribution protocol. An interim solution would be to start with a manual "master" key (one with a long lifetime). This key would have to be entered manually, but would be used to distribute future keys, (sort of an initial jump-start key), including future "master" keys. If the master key is ever comprimised, another would have to be entered manually. Like I said, this probably doesn't scale, but until a "better" key distribution protocol is added to network managment this *should* work. I know that there is a little hesitation to "add" additional purpose to the Great Network Managment Solution. Has anyone explored the "managment of security" solution vs. the "security managment" solution? If so what were the conclusions (if any)? Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Wed Oct 13 05:47:33 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19229 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 09:49:06 -0400 Received: by interlock.ans.net id AA17399 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 09:46:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 09:46:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 09:46:15 -0400 Date: Wed, 13 Oct 93 09:47:33 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9310131347.AA20531@itd.nrl.navy.mil> To: glenn@sloth.ncsl.nist.gov Subject: Re: Key Managment Query/Comments... Cc: ipsec@ans.net We have studied SNMPv2 security and do not like what we have found. The key management in SNMPv2 has undesirable characteristics (e.g. you use the old key to get and install its replacement rather than using KEK). If the old key had already been compromised, the new key is also compromised upon installation. Also, SNMPv2 does not have algorithm independence, so using it for key management implies that one trusts _for all time_ that DES is sufficient security for one's keys. IMHO, using SNMPv2 for key management is not appropriate and would not conform to the IPv4 security protocol's requirement for algorithm independence. NRL has much experience in the use of formal methods to analyse key management protocols. There are many cases where key management algorithms in the open literature have had serious flaws discovered long after initial publication. Local discussions have persuaded me that it is highly desirable to have a key management protocol/mechanism that is entirely separate from the IP security protocol. For example, I consider swIPe's so-called "out of band" data to be too tightly coupled to swIPe for it to be suitable for key mgmt. If one uses a completely independent key management protocol/mechanism and one needs to change the key management protocol/mechanism at some future date, one can do so without having to make major changes to the IP security protocol or any other Internet protocol. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Oct 13 14:16:13 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18963 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 10:19:18 -0400 Received: by interlock.ans.net id AA21463 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 10:14:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 10:14:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 10:14:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 10:14:59 -0400 Message-Id: <9310131416.AA25030@skidrow.lkg.dec.com> To: IP Secrity WG Subject: key distribution Date: Wed, 13 Oct 93 10:16:13 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp How about using a formatted piece of secure mail for key distribution? Donald ------------------------------------------------------------------------ Donald E. Eastlake, III 1-508-486-6577(w) PO Box N, MIT Branch PO dee@lkg.dec.com Cambridge, MA 02139 USA 1-508-287-4877(h) dee@ranger.enet.dec.com From ipsec-request@ans.net Wed Oct 13 06:50:42 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17360 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 11:02:11 -0400 Received: by interlock.ans.net id AA10287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 10:50:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 10:50:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 10:50:39 -0400 Date: Wed, 13 Oct 93 10:50:42 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9310131450.AA22624@itd.nrl.navy.mil> To: dee@skidrow.lkg.dec.com Subject: Re: key distribution Cc: ipsec@ans.net Donald's suggestion is worth considering and is intriguing in that it implicitly proposes reusing the key certificate technology used in PEM. I myself lean more towards using the DNS to store host key CERTIFICATES (emphasis added to avoid being flamed). I proposed this recently on the Namedroppers list and there was some discussion about it for a while. One person on that list indicated there might be an MTU problem with key certificates (for some key sizes) with the DNS approach. I'm recently told that the commercial world seems to be using key sizes in the 1K bits range [separate email messages from Steve Bellovin, Neil Haller, et. al.]. It seems likely that we will eventually wish to have larger key sizes. I have no idea over what time span that will occur, but we should avoid boxing ourselves in unduly. Presently, we will have a reasonable key certificate infrastructure, thanks entirely to the PEM folks. I would suggest that we consider reusing that infrastructure for host keys. Then some published session key mgmt protocol could use those host keys (from the host key certificates) to agree upon and distribute a suitable session key for use by the IP security protocol among the hosts participating in the session. I would suggest that the session key mgmt protocol have its own transport-level port number assigned to it and also that there be a 'version number' or 'key mgmt protocol identifier' assigned so that the session key mgmt protocol could be revised later if a flaw were found and also so that we could potentially support more than one session key mgmt protocol (e.g. one for multicast sessions and one for unicast sessions if a significant advance should be made in multicast key mgmt protocols in the published literature). I'm not sure that perhaps we are leaping ahead of ourselves here by doing key management before we have the encapsulating security protocol figured out somewhat, but I'll go along with whatever the list consensus is on which order to address topics. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Oct 13 07:39:15 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13340 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 11:49:17 -0400 Received: by interlock.ans.net id AA21763 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 11:37:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 11:37:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 11:37:31 -0400 Date: Wed, 13 Oct 93 11:39:15 EDT From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9310131539.AA04225@sloth.ncsl.nist.gov> To: atkinson@itd.nrl.navy.mil Subject: Re: Key Managment Query/Comments... Cc: ipsec@ans.net, glenn@sloth.ncsl.nist.gov, walters@osi.ncsl.nist.gov, west@osi.ncsl.nist.gov, maughan@cs.umbc.edu Ran, I agree that SNMPv2 lacks a good key distribution mechanism. Something better will hopefully come along (out of this group or the managment group). As for algorithm independence, SNMPv2 (in RFC 1446) does adhere to algorithm independence. For the sake of interoperability it "suggests" the use of DES, but DES is not required (just as MD5 is suggested but not required for integrity). I also agree that the security protocol(s) should have a completely independent key management protocol/mechanism. This would be greatly benefited by a standardized interface between the manament and security protocols. I'm curious... Is there, at this time, a compiled listing of requirements for the work being done by this group? If so, could someone post it? If not, can we get one generated? Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Wed Oct 13 15:46:47 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19054 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 12:00:41 -0400 Received: by interlock.ans.net id AA12884 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 11:48:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 13 Oct 1993 11:48:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 11:48:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 11:48:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 11:48:01 -0400 Message-Id: <9310131546.AA06479@snark.lehman.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: dee@skidrow.lkg.dec.com, ipsec@ans.net Subject: Re: key distribution In-Reply-To: Your message of "Wed, 13 Oct 1993 10:50:42 EDT." <9310131450.AA22624@itd.nrl.navy.mil> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 13 Oct 1993 11:46:47 -0400 From: "Perry E. Metzger" Ran Atkinson says: > I myself lean more towards using the DNS to store host key > CERTIFICATES (emphasis added to avoid being flamed). I proposed this > recently on the Namedroppers list and there was some discussion about > it for a while. One person on that list indicated there might be an > MTU problem with key certificates (for some key sizes) with the DNS > approach. I'm recently told that the commercial world seems to be > using key sizes in the 1K bits range [separate email messages from > Steve Bellovin, Neil Haller, et. al.]. It seems likely that we will > eventually wish to have larger key sizes. I have no idea over what > time span that will occur, but we should avoid boxing ourselves in > unduly. I agree that DNS feels like the right way to store these things. It would be nice if someone could convey to the people doing the next generation of DNS that setting the record size high enough that this could be done would be a big win. Presently, records can't be large enough to accomodate future key lengths. Perry From ipsec-request@ans.net Wed Oct 13 16:17:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13068 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 12:31:52 -0400 Received: by interlock.ans.net id AA13033 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 12:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 12:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 12:16:38 -0400 Date: Wed, 13 Oct 93 12:17:35 -0400 Message-Id: <9310131617.AA15335@ftp.com> To: glenn@sloth.ncsl.nist.gov Subject: Re: Key Managment Query/Comments... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, glenn@sloth.ncsl.nist.gov, walters@osi.ncsl.nist.gov, west@osi.ncsl.nist.gov, maughan@cs.umbc.edu SNMP has an overriding requirement that it rely on as few working elements of the network as possible. Basically, the only things that SNMP relies on is that packets can (probably) get from here to there. SNMP is to be as independent from other protocols -- especially the "infrastructure" protocols such as name services, key distribution, time services, and so on -- as possible. Therefore, SNMP does not now, and probably will not in the future, rely upon any "external" key-distribution protocol. The reason is simple. The purpose of the SNMP is to detect, diagnose, and fix network failures. If the key-distribution-protocol fails, how can SNMP be used to detect, diagnose, and fix the key-distribution protocol? Similarly, if the SNMP manager/agent can not reach a key-distribution server to, e.g., validate keys or tickets or whatever, then SNMP can not be used to fix other things as well. > I agree that SNMPv2 lacks a good key distribution mechanism. > Something better will hopefully come along (out of this group > or the managment group). > > As for algorithm independence, SNMPv2 (in RFC 1446) does adhere > to algorithm independence. For the sake of interoperability it > "suggests" the use of DES, but DES is not required (just as MD5 is > suggested but not required for integrity). > > I also agree that the security protocol(s) should have a completely > independent key management protocol/mechanism. This would be > greatly benefited by a standardized interface between the > manament and security protocols. > > I'm curious... Is there, at this time, a compiled listing of requirements > for the work being done by this group? If so, could someone post it? > If not, can we get one generated? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ipsec-request@ans.net Wed Oct 13 08:55:56 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21067 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 13:08:06 -0400 Received: by interlock.ans.net id AA21040 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 12:54:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 12:54:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 12:54:40 -0400 Date: Wed, 13 Oct 93 12:55:56 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9310131655.AA25680@itd.nrl.navy.mil> To: glenn@sloth.ncsl.nist.gov Subject: Re: Key Managment Query/Comments... Cc: ipsec@ans.net % As for algorithm independence, SNMPv2 (in RFC 1446) does adhere % to algorithm independence. For the sake of interoperability it % "suggests" the use of DES, but DES is not required (just as MD5 is % suggested but not required for integrity). It is not clear to me that this really is so. Could you please give an example where DES could be replaced by some arbitrary algorithm "FOO" throughout SNMPv2 and yet that implementation could be said to fully conform/comply with the SNMPv2 specs and not have extended the SNMP MIBs, administrative structure, (etc) or changed them in some manner ? That would greatly help. Thanks, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Oct 13 17:23:19 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20404 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 13:39:20 -0400 Received: by interlock.ans.net id AA14159 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 13:26:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 13 Oct 1993 13:26:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 13:26:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 13:26:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 13:26:09 -0400 Message-Id: <9310131723.AA06605@snark.lehman.com> To: ipsec@ans.net Subject: Re: Key Managment Query/Comments... In-Reply-To: Your message of "Wed, 13 Oct 1993 12:17:35 EDT." <9310131617.AA15335@ftp.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 13 Oct 1993 13:23:19 -0400 From: "Perry E. Metzger" Frank Kastenholz says: > The reason is simple. The purpose of the SNMP is to detect, diagnose, > and fix network failures. If the key-distribution-protocol fails, how > can SNMP be used to detect, diagnose, and fix the key-distribution > protocol? Similarly, if the SNMP manager/agent can not reach a > key-distribution server to, e.g., validate keys or tickets or whatever, > then SNMP can not be used to fix other things as well. It can't if it hasn't prefetched the public keys, but it can easily get them while the network is still functioning and hold on to them, thus providing it with the keys for those periods when it ceases to function. Most SNMP management systems tend to poll the same machines over and over again, so holding on to them is no big deal. In our network here at Lehman, we have about 3000 workstations and I'd guess no more than 4000 managed objects altogether. Assuming 1K per key, a cache of all the keys for the firm will fit in 4MB of space, which is fine. Assuming a firm with 100 times the number of managed objects and you still could fit in an really cheap disk, which will only get cheaper. Perry From ipsec-request@ans.net Wed Oct 13 18:29:36 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13217 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 14:43:56 -0400 Received: by interlock.ans.net id AA14088 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 14:28:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 14:28:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 14:28:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 14:28:19 -0400 Message-Id: <9310131829.AA21045@tardo.lkg.dec.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net, tardo@tardo.lkg.dec.com Subject: Re: Key Managment Query/Comments... In-Reply-To: Your message of "Wed, 13 Oct 93 09:47:33 EDT." <9310131347.AA20531@itd.nrl.navy.mil> Date: Wed, 13 Oct 93 14:29:36 -0400 From: tardo@tardo.lkg.dec.com X-Mts: smtp Ran: You make some excellent points. Let me just add: 1. SNMPvX is really not useful for negotiating session keys anyway, since it does not support 'actions' in any standard way. And, of course, you want to have the two ends negotiate keys directly. Having each propose their own Diffie-Hellman vectors (signed using a the public key algorithm) can protect against later overrun/replay attacks. For these reasons, a completely out of band key management 'daemon' makes a lot of sense. 2. SNMP might be useful for 'publishing' certificates in conjunction with some kind of in-line key exchange, but this gets kludgy for datagrams, where it seems better to negotiate a 'session' key for the appropriate algorithm. Separating key distribution from the actual protocol makes sense for the reasons you outline (but is somewhat offensive to some 'layer independence' architecture purists I know). But why would you need to use SNMP if you could contact a key management daemon who could just tell you its certificate? 3. DNS seems unnecessary for distributing host certificates since you can just get them from the target anyway. The only situation I can imagine is some kind of single-datagram scenario, in which case you are limited to an initiator- proposed key. I contend this is a rather degenerate case that represents an exception and not something you want to optimize around. -- Joe From ipsec-request@ans.net Wed Oct 13 18:41:25 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21182 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 14:51:17 -0400 Received: by interlock.ans.net id AA15738 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 14:40:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 14:40:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 14:40:12 -0400 Date: Wed, 13 Oct 93 14:41:25 -0400 Message-Id: <9310131841.AA23279@ftp.com> To: atkinson@itd.nrl.navy.mil Subject: Re: Key Managment Query/Comments... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: glenn@sloth.ncsl.nist.gov, ipsec@ans.net > % As for algorithm independence, SNMPv2 (in RFC 1446) does adhere > % to algorithm independence. For the sake of interoperability it > % "suggests" the use of DES, but DES is not required (just as MD5 is > % suggested but not required for integrity). > > It is not clear to me that this really is so. > > Could you please give an example where DES could be replaced by some > arbitrary algorithm "FOO" throughout SNMPv2 and yet that implementation > could be said to fully conform/comply with the SNMPv2 specs and not have > extended the SNMP MIBs, administrative structure, (etc) or changed them > in some manner ? > > That would greatly help. The encryption and authentication algorithms that are in use for a specific pair of SNMPv2 parties (basically, parties are the two sides of a particular SNMP communication) are identified in the configuration MIBs by ASN.1 Object Identifiers (OIDs), which are tree structured numbers that provide distributed assignmenty authority -- similar to domain names. So, FTP Software could develop its own special encryption algorithm and assign an OID out of our proprietary subtree to identify that algorithm. Then, presumably, our code -- both manager and agent -- would support that algorithm; as would anyone else's code IF they wish to do the development. So, nodes that support our special encryption algorithm could be configured, within the SNMP management framework, to use that algorithm. Finally, if someone attempts to configure some node that does not support our algorithm to use it, the node would give a well-known error message back to the manager station. In short, the use of any specific algorithm (other than NONE) is not mandated by the SNMPv2 protocols. The protocols define a standard method to define, identify, configure, and use (i.e. encode packets) any algorithm you wish. The standards DO pre-define one encryption and one authentication algorithm (DES and MD5). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ipsec-request@ans.net Wed Oct 13 18:41:36 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14055 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 14:57:49 -0400 Received: by interlock.ans.net id AA14532 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 14:46:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 14:46:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 14:46:21 -0400 Date: Wed, 13 Oct 93 14:41:36 -0400 Message-Id: <9310131841.AA23289@ftp.com> To: pmetzger@lehman.com Subject: Re: Key Managment Query/Comments... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipsec@ans.net > Frank Kastenholz says: > > The reason is simple. The purpose of the SNMP is to detect, diagnose, > > and fix network failures. If the key-distribution-protocol fails, how > > can SNMP be used to detect, diagnose, and fix the key-distribution > > protocol? Similarly, if the SNMP manager/agent can not reach a > > key-distribution server to, e.g., validate keys or tickets or whatever, > > then SNMP can not be used to fix other things as well. > > It can't if it hasn't prefetched the public keys, but it can easily > get them while the network is still functioning and hold on to them, > thus providing it with the keys for those periods when it ceases to > function. Most SNMP management systems tend to poll the same machines > over and over again, so holding on to them is no big deal. Assuming that the non-SNMP mechanism used to pre-fetch the keys is working. And, of course, what happens if a key "times out" during the problem period? Plus there is the cost issue -- if I run some key-distribution system then I need to set up and control another software package, perhaps on a machine that is different than the SNMP manager... I've discovered that commercial sites tend to prefer having as few vendors as possible -- makes it easier to track down and fix problems (i.e. it is harder to blame someone else if there are fewer someone-elses :-) And of course, what if I am not running in a TCP/IP environment? SNMP works over non-TCP/IP protocols (raw ethernet, novell, decnet, osi, sna -- i believe -- and so on). If I were to use something like Kerberos for key management/distribution, then I'd need to get Kerberos over the same thing as SNMP is running.... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ipsec-request@ans.net Wed Oct 13 19:13:44 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13354 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 15:36:39 -0400 Received: by interlock.ans.net id AA14437 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 15:24:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 13 Oct 1993 15:24:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 15:24:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 15:24:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 15:24:35 -0400 Message-Id: <9310131913.AA06835@snark.lehman.com> To: kasten@ftp.com Cc: pmetzger@lehman.com, ipsec@ans.net Subject: Re: Key Managment Query/Comments... In-Reply-To: Your message of "Wed, 13 Oct 1993 14:41:36 EDT." <9310131841.AA23289@ftp.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 13 Oct 1993 15:13:44 -0400 From: "Perry E. Metzger" Frank Kastenholz says: > Assuming that the non-SNMP mechanism used to pre-fetch the keys is > working. And, of course, what happens if a key "times out" during the > problem period? I remember once being in a meeting with A Big Network Hardware Vendor explaining to them that their network management tool was crap. They said "but its so user friendly", and I tried to explain to them that you can't enter in 4000 hosts in a GUI and you don't even want to, and that displaying networks of a hundred machines on a display in cute little icons is impractical. They didn't grok that we'd have administrative management databases and want to have them supply data to their tool directly -- never actually saw anyone manage a few thousand hosts, in other words. The fact is that most "experts" on these topics have never had to actually worry about real wide area networks. I speak as someone who's firm has to worry about a network on three continents in twenty cities with thousands of hosts and no administrators within a thousand miles of most of them. In the Real World, things are different from academia. In answer to your specific query, the non-SNMP method to prefetch the keys better be working at some point, because if it doesn't ever work something is so fucked up with your network that it has no useful function at all. When I say "prefetch", I mean load them and use them for the next six months if you feel like it. You could, of course, simply allow the use of old keys with a grace period if you felt like it, which would handle most timeouts -- which aren't a real problem anyway. If your network is so hosed for more than a few days that your keys start timing out, you don't need network management any more -- you need a hearse. Network management tools are for telling you that the wire to Tokyo has been cut -- but once its been cut the network management tool isn't going to go to the central office to repair the line. If you really have a prolonged outage, you no longer care about the network management tool -- its not going to help with that sort of problem. > Plus there is the cost issue -- if I run some key-distribution system > then I need to set up and control another software package, perhaps on a > machine that is different than the SNMP manager... You have to set up your key distribution system anyway because everything else is going to use it too. > I've discovered that commercial sites tend to prefer having as few > vendors as possible -- We are a commercial site. We write our own software and are perfectly capable of compiling sources from the network. We have to deal with hundreds of packages, and dealing with one more won't break us. > And of course, what if I am not running in a TCP/IP environment? > SNMP works over non-TCP/IP protocols And what if your grandmother is a schoolbus? Yeah, sure, SNMP runs over everything, but we still had to give our mainframe SNA folks IP addresses for all their network devices because their SNMP based monitoring systems run over TCP anyway. > If I were to use something like Kerberos for key > management/distribution, A bad idea... > then I'd need to get Kerberos over the same thing as SNMP is > running.... But not for that reason. Perry From ipsec-request@ans.net Wed Oct 13 20:13:19 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13441 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 16:22:53 -0400 Received: by interlock.ans.net id AA12582 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 16:12:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 16:12:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 16:12:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 16:12:07 -0400 Message-Id: <199310132013.AA05468@misc.glarp.com> To: pmetzger@lehman.com Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), dee@skidrow.lkg.dec.com, ipsec@ans.net Subject: Re: key distribution In-Reply-To: Your message of "Wed, 13 Oct 93 11:46:47 EDT." <9310131546.AA06479@snark.lehman.com> Date: Wed, 13 Oct 1993 14:13:19 -0600 From: Brad Huntting > I agree that DNS feels like the right way to store these things. It > would be nice if someone could convey to the people doing the next > generation of DNS that setting the record size high enough that this > could be done would be a big win. Presently, records can't be large > enough to accomodate future key lengths. Certificate chains for online resources should be stored with the hosts offering the resources. This includes IP certificates. Using DNS will only add yet another point of failure. Hosts supporting IPSP could easily support an ICMP or UDP based service which spits back the hosts certificate or certificate chain on request. DNS is useless for IPSP. brad From ipsec-request@ans.net Wed Oct 13 07:46:41 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12958 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 17:53:07 -0400 Received: by interlock.ans.net id AA11484 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 17:42:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 13 Oct 1993 17:42:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 13 Oct 1993 17:42:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 17:42:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 17:42:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 17:42:45 -0400 Message-Id: <00112.2833368498.50014@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: kasten@ftp.com (kasten) Cc: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 13 Oct 1993 14:46:41 MST Subject: Re: >Key Managment Query/Com Reply to: RE>>Key Managment Query/Comm Frank, You bring up some interesting issues with the interaction of SNMP with network layer security. > Frank Kastenholz says: > > The reason is simple. The purpose of the SNMP is to detect, diagnose, > > and fix network failures. If the key-distribution-protocol fails, how > > can SNMP be used to detect, diagnose, and fix the key-distribution > > protocol? Similarly, if the SNMP manager/agent can not reach a > > key-distribution server to, e.g., validate keys or tickets or whatever, > > then SNMP can not be used to fix other things as well. The insertion of IPSEC into a system will split management into two domains. There will be two profiles SNMP-over-IPSP and SNMP-no-IPSP. Most often an agent will be of one flavor or the other, but there will be scenarios where a host could contain both profiles. The diagnosis of a key distribution and IPSP system could be accomplished with SNMP-no-IPSP. Significant changes to the configuration of either key management or IPSP would warrant the use of SNMP-over-IPSP. Without drawing a few figures the scenarios above can be a little confusing. Network layer security can be installed in either a host or router configuration. SNMP operating through a router with IPSP may not be able to see any agents on the encrypted (Black) side of the security widget. The SNMP manager in this scenario will look locally like a vanilla SNMP-no-IPSP, but the profile through the secured router will be SNMP-over-IPSP. Is it worth adding an item on the Houston agenda for - IPSP interaction with SNMP? Paul A. Lambert Motorola (602)-441-3646 From ipsec-request@ans.net Wed Oct 13 13:56:29 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13095 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 18:06:42 -0400 Received: by interlock.ans.net id AA14903 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 17:56:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 17:56:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 17:56:26 -0400 Date: Wed, 13 Oct 93 17:56:29 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9310132156.AA05366@itd.nrl.navy.mil> To: huntting@glarp.com Subject: Re: key distribution Cc: ipsec@ans.net % Certificate chains for online resources should be stored with the % hosts offering the resources. This includes IP certificates. % % Using DNS will only add yet another point of failure. Hosts % supporting IPSP could easily support an ICMP or UDP based service % which spits back the hosts certificate or certificate chain on % request. % % DNS is useless for IPSP. I'm not really sure that "DNS is useless for IPSP". I'm also pretty sure that it would be nice if we could have a fairly generic key mgmt protocol that I might be able to re-use with future hypothetical security protocols (e.g. at the TCP layer). Clearly the host could store its own certificate and could implement a to-be-defined key certificate providing protocol and that would work. It implies defining a standard protocol to use to ask a remote host for its key certificate and to receive a response back and also getting that protocol implemented and the implementation deployed. However, consider that the originating host would normally make a DNS call to do name-->IP address translation anyway. The key certificate could be included in the same request/response and potentially eliminate a round-trip. (Assumes that one caches certificates just as we currently cache DNS responses; also assumes modern systems using DNS rather than the deprecated fixed host table file). In this case, one might just have an extension to an existing deployed service rather than an entirely new service. It might be easier to get folks to upgrade their bind(8) than to get/install an entirely new service. It might be easier to tweak DNS protocol than to design a new protocol. There are tradeoffs here and it isn't clear to me which of the two approaches is actually better; I think it merits further consideration of alternatives (including others that might be devised). Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Oct 13 09:54:10 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13246 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 20:01:42 -0400 Received: by interlock.ans.net id AA16779 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 13 Oct 1993 19:51:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 13 Oct 1993 19:51:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 13 Oct 1993 19:51:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 13 Oct 1993 19:51:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Oct 1993 19:51:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Oct 1993 19:51:39 -0400 Message-Id: <00112.2833376247.50044@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 13 Oct 1993 16:54:10 MST Subject: Re: key distribution From INTERNET RE>key distribution > I agree that DNS feels like the right way to store these things. It > would be nice if someone could convey to the people doing the next > generation of DNS that setting the record size high enough that this > could be done would be a big win. Presently, records can't be large > enough to accomodate future key lengths. DNS may seem attractive at first, but obtaining the destinations certificate is not the only requirement that we need to consider. Here are some ideas on a few requirements: - Multiple certificates may be supported by a single IPSEC Key Management Agent. - IPSP will support multiple algorithms. Determination of the algorithm (for integrity, confidentiality, etc.) could be provided by the same mechanism that establishes the cryptographic keying relationship. - The IPSEC Key Management (IP-KM) should provide Rpeer-entityS authentication. A real-time authentication is required to ensure that the keying relationship is established correctly. - The establishment of keying relationships for broadcast and multicast communications need to be supported by IP-KM. - A mapping of the destination address to the address of an intermediate IPSEC device must be supported. The address of the decrypting device may not be the same as the final destination. Using DNS to retrieve the destination certificate would allow a key to be created by sending only the initiators certificate to the destination. This one-step key certificate exchange may appear to be a useful hack, but it does not provide any way to support all of the requirements. As soon as you consider exchanging more than one PDU, you might as well allow for the destination to send its own certificate. There may also be some problems using DNS to distribute certificates for mobile hosts. The dynamics of a mobile-IP configuration would favor the use of key management mechanisms that are peer-to-peer. From ipsec-request@ans.net Fri Oct 15 03:57:19 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18630 (5.65c/IDA-1.4.4 for ); Fri, 15 Oct 1993 14:11:55 -0400 Received: by interlock.ans.net id AA15694 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 15 Oct 1993 13:57:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 15 Oct 1993 13:57:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 15 Oct 1993 13:57:10 -0400 X-Ns-Transport-Id: 08003700A33265253023 Date: Fri, 15 Oct 1993 10:57:19 PDT From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: Key Managment Query/Comments... In-Reply-To: <9310131829.AA21045@tardo.lkg.dec.com> To: tardo@tardo.lkg.dec.com Cc: ipsec@ans.net Message-Id: <"15-Oct-93 13:57:10".*.Russ_Housley.McLean_CSD@Xerox.com> Joe: >2. SNMP might be useful for 'publishing' certificates in > conjunction with some kind of in-line key exchange, but this > gets kludgy for datagrams, where it seems better to negotiate > a 'session' key for the appropriate algorithm. Separating > key distribution from the actual protocol makes sense for > the reasons you outline (but is somewhat offensive to some > 'layer independence' architecture purists I know). But why > would you need to use SNMP if you could contact a key management > daemon who could just tell you its certificate? By saying "this gets kludgy for datagrams" are you trying to say that the exchange of Diffie-Hellman vectors might require more space than a single datagram? When certificate-based key management is used, the exchange can certainly be larger than a single Ethernet frame. There are also sequencing concerns. I think that establishment of a security association is acomplished through two steps. First, the keying material is generated. This could be through the exchange certificates (perhaps oones that include Diffie-Hellman vectors) or through interaction with a key distribution center (perhaps a Kerberos server) or through manual distribution. Second, the attriutes for the security association are negotiated. This negotiation can be protected using the key generated in the first step. Also, by using the key to protect the negotiation, keys generated using Diffie-Hellman can be tested to ensure that both partied generated the same key. Russ From ipsec-request@ans.net Tue Oct 19 07:42:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03174 (5.65c/IDA-1.4.4 for ); Tue, 19 Oct 1993 11:50:55 -0400 Received: by interlock.ans.net id AA22593 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 19 Oct 1993 11:40:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 19 Oct 1993 11:40:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 19 Oct 1993 11:40:31 -0400 Date: Tue, 19 Oct 93 11:42:20 EDT From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9310191542.AA09221@sloth.ncsl.nist.gov> To: ipsec@ans.net Subject: NLSP goes IS FYI: For those that don't know, NLSP (ISO11577) has gone to IS (awaiting last minute editing). Some changes have been made to the document, but it will take me more time (conciderable) to determine how great the improvements are. Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Tue Oct 19 19:06:01 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17949 (5.65c/IDA-1.4.4 for ); Tue, 19 Oct 1993 15:11:37 -0400 Received: by interlock.ans.net id AA26749 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 19 Oct 1993 15:05:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 19 Oct 1993 15:05:11 -0400 Message-Id: <199310191905.AA25455@interlock.ans.net> To: "K. Robert Glenn" Cc: ipsec@ans.net, maughan@cs.umbc.edu, walters@sloth.ncsl.nist.gov Subject: Re: Key Managment Query/Comments... In-Reply-To: Your message of Wed, 13 Oct 93 09:25:17 -0400. <9310131325.AA04110@sloth.ncsl.nist.gov> Date: Tue, 19 Oct 93 15:06:01 -0400 From: Steve Kent Robert, SNMP-V2 does not have what I would call "robust security" in the sense required for generic key management. Moreover, because SNMP embodies a client/server model for interactions between managed objects and managers, it seems an unlikely basis for creating a key management protocol that would support secure communication between peers, especially when the peers are administratively autonomous. Steve From ipsec-request@ans.net Tue Oct 19 05:08:57 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07714 (5.65c/IDA-1.4.4 for ); Tue, 19 Oct 1993 15:13:50 -0400 Received: by interlock.ans.net id AA23781 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 19 Oct 1993 15:10:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 19 Oct 1993 15:10:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 19 Oct 1993 15:10:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 19 Oct 1993 15:10:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 19 Oct 1993 15:10:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 19 Oct 1993 15:10:17 -0400 Message-Id: <00112.2833877525.50635@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: crocker@TIS.COM (Stephen D Crocker), mwalnut@CNRI.Reston.VA.US (Megan Davies Walnut) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 19 Oct 1993 12:08:57 MST Subject: IPSEC Agenda Subject: IPSEC Agenda Message: If you have already received this, please excuse the double posting. --------------------- Agenda of the IP Security (IPSEC) WG - as of 10/15/93 at the Twenty-Eighth IETF (November 2,3, 1993) The IPSEC Working Group will meet two days at the Twenty-Eighth IETF: TUESDAY, November 2, 1993 0930-1200 SEC Internet Protocol Security Protocol WG (ipsec) IP Security Protocol (IPSP) WEDNESDAY, November 3, 1993 0930-1200 SEC Internet Protocol Security Protocol WG (ipsec) Key Management for IP Security Following are the detailed agendas for the two IPSEC WG meetings. IPSEC Agenda for Tuesday November 2, 1993 9:30 Introduction o Review and Approve Agenda o Minutes of Amsterdam (July 1993) Meeting 9:35 Review of Charter and Schedule 9:45 Liaisons 10:00 Requirements Review 10:30 Review of Experimental Implementations o swIPe o SP3 o NLSP o ANS o others 10:45 Demonstrations of prototype implementations (brief presentations only actual demonstrations will be located in another area) 11:30 Summarize Approaches and Recommendations o Features and Requirements (Host-to-Host, Host-to-Subnet, and Subnet-to-Subnet) o Clear Header Format o Security Transformation (encryption, MAC. etc.) o Protected Header o Labels o Peek-Through o Interaction with IP clients (including IP/IPSP/IP) o Fragmentation o Multicast / Broadcast o Interaction with SNMP o Others o Solicit Writing Assignments 11:50 Summary o Next Meeting o Review Action Items 12:00 Close IPSEC Agenda for Wednesday November 3, 1993 9:30 Introduction o Review and Approve Agenda 9:35 What is Key Management? 9:45 Existing Work o SDNS KMP o IEEE 802.10 o GULS o PEM o X.509 o X9.17 o others 10:30 Key Management Requirements Discussion o symmetric versus asymmetric algorithms o peer-entity authentication o option negotiation (support multiple algorithms) o Multicast / Broadcast Considerations o others 11:20 Existing Implementations Presentations o to be determined soon 11:45 Summary o Summarize Approaches and Recommendations o Next Meeting o Review Action Items 12:00 Close From ipsec-request@ans.net Fri Oct 29 01:48:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17899 (5.65c/IDA-1.4.4 for ); Thu, 28 Oct 1993 21:51:12 -0400 Received: by interlock.ans.net id AA22437 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 28 Oct 1993 21:47:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 28 Oct 1993 21:47:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 28 Oct 1993 21:47:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 28 Oct 1993 21:47:01 -0400 Date: Thu, 28 Oct 93 18:48:05 -0700 From: karn@qualcomm.com (Phil Karn) Message-Id: <9310290148.AA22785@servo> To: Paul_Lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net In-Reply-To: Paul Lambert's message of Tue, 19 Oct 1993 12:08:57 MST <00112.2833877525.50635@poncho.phx.sectel.mot.com> Subject: IPSEC Agenda Paul, I've been experimenting with a SWIPE-like IP security protocol within my own TCP/IP package (KA9Q NOS) for the past several weeks. Key management is currently manual, but it fully supports either end-to-end or "encryption gateway" style operations. You can configure it to either encrypt (with DES-CBC), authenticate (with keyed MD5), or both, individual datagrams on a per-host-pair basis. I'm currently using it to encrypt much of the traffic over my dialup slip link between home and work. I'd like to have a chance to talk about this as "work in progress" at the IPSEC meeting. The more I experiment with this, the more I'm convinced that the actual security packet header formats are not nearly as important as the many issues surrounding how to cleanly integrate an IP-level security protocol into the existing Internet architecture and into existing software implementations. Even though standards bodies are nominally not supposed to discuss implementation details, I think it useful to look at "case studies" in order to gain insights into broader issues that are definitely relevant to whatever standards we produce. Phil