From ipsec-request@ans.net Tue Feb 1 12:03:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15001 (5.65c/IDA-1.4.4 for ); Tue, 1 Feb 1994 17:07:22 -0500 Received: by interlock.ans.net id AA41379 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Feb 1994 17:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Feb 1994 17:03:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Feb 1994 17:03:32 -0500 Date: Tue, 1 Feb 94 17:03:22 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9402012203.AA21934@itd.nrl.navy.mil> To: ipsec@ans.net Subject: IPsec near term work I'd like to suggest that the most important work item for the group is not the IPv4 security protocol itself, but rather an Internet-standard key management protocol. Such a key management protocol is a critical missing piece. Security for a wide variety of existing and in-development protocols (e.g. BGP, OSPF, Mobile IP, SIPP, others) would be greatly facilitated by a standard key management protocol. Russ Housley has suggested using something derived from the IEEE 802.10 work, others have suggested using something derived from SDNS KMP. I think it would be most useful if people would write up short proposals and put them out as Internet Drafts now so that we could all have time to read them over and discuss them intelligently (:-) in Seattle. I really think that the details of the IPv4 security protocol syntax can be deferred until after a standard key management protocol is agreed to. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Feb 1 06:59:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17809 (5.65c/IDA-1.4.4 for ); Tue, 1 Feb 1994 18:12:10 -0500 Received: by interlock.ans.net id AA19941 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Feb 1994 17:59:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Feb 1994 17:59:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Feb 1994 17:59:57 -0500 Message-Id: Date: Tue, 1 Feb 94 14:59 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson) From: brian@lloyd.com (Brian Lloyd) Subject: Re: IPsec near term work Cc: ipsec@ans.net At 17:03 2/1/94 -0500, Ran Atkinson wrote: >I'd like to suggest that the most important work item for the group >is not the IPv4 security protocol itself, but rather an Internet-standard >key management protocol. I beg to differ. IPv4 security protocol is useful even without a key management tool; you just have to live with manual key management. Therefore IPv4 security protocol is useful by itself but the key management protocol is not. This is not to denegrate the need for a key managment protocol; one is badly needed for the general deployment of the IPv4 security protocol. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Tue Feb 1 11:29:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17782 (5.65c/IDA-1.4.4 for ); Tue, 1 Feb 1994 20:35:46 -0500 Received: by interlock.ans.net id AA23872 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Feb 1994 20:29:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Feb 1994 20:29:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Feb 1994 20:29:25 -0500 Date: Tue, 1 Feb 1994 18:29:20 MST From: "Hilarie Orman" Message-Id: <199402020129.AA20459@umbra.cs.arizona.edu> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Feb 1994 20:29:25 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Your message <9402012203.AA21934@itd.nrl.navy.mil> Subject: Re: IPsec near term work At one point I had thought that this group would define an interface to and requirements for key management protocols to act in concert with the IPv4 security protocol. Is it possible to proceed with this in order to allow the syntax definition to go forward? The other protocols could use the same interface, and several birds might begin plummeting. From ipsec-request@ans.net Tue Feb 1 16:45:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03197 (5.65c/IDA-1.4.4 for ); Tue, 1 Feb 1994 21:51:23 -0500 Received: by interlock.ans.net id AA10219 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Feb 1994 21:45:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Feb 1994 21:45:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Feb 1994 21:45:59 -0500 Date: Tue, 1 Feb 94 21:45:53 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9402020245.AA27062@itd.nrl.navy.mil> To: ipsec@ans.net Subject: Re: IPsec near term work In my opinion, there are too many pending security fixes that depend on having an actual Internet standards-track key management protocol for us to defer the details of that key management protocol. If we cannot exchange session keys interoperably, then none of these efforts will have much real long-term value. As an example, Mobile IP absolutely must have support from a standards-track key management protocol to get the kind of authentication that it really needs to have (mobile hosts are unable to predict ahead of time which relays they might need to use, so manual key mgmt just won't get the entire job done for Mobile IP). As far as an API goes, that seems out of the scope of the IPsec WG and within the scope of the Common Authentication Technology (CAT) WG anyway. CAT has already published an Application Programming Interface (API) which can be extended with key mgmt interfaces. However, having an API doesn't solve the problem of how to setup session keys. I've spent some time since Houston experimenting with IP-layer security implementations (including some work using KA9Q as a base and some using other IP implementations as a base). I really don't think that the syntax is the most important or the hardest problem in securing IP. Phil Karn made some persuasive comments along these lines in Houston. After some messing around on my own, I'm tending to agree with Phil on the matter of syntax. People who carefully read my draft on SIPP Encapsulating Security Payload will discover that I've put my typing where my mouth is. The syntax will probably vary slightly with different algorithm families and the efficient approach is probably to use a fixed syntax for each algorithm, with the syntax selected from a small set of possible syntaxes. Given that both sender and receiver have to know the algorithm and mode in use for each packet, they can adapt to slight syntactic differences on a packet by packet basis without much problem. [1] While algorithm independence is clearly required of the protocol, I suspect that, in practice, most implementations will only support one algorithm and mode (i.e. DES in CBC mode) anyway. I'm convinced that key management (as usual :-) is really the subtle and difficult problem here (not only technically but legally, sigh). If the IETF had more people working in the security area, then maybe I'd suggest splitting IPsec into an IPv4 Encapsulating Protocol WG and an Internet Key Mgmt Protocol WG. In practice, we don't have enough people to vigorously tackle both tasks in parallel and we should prioritise the work. IMHO, the key management piece should be tackled first. Private email responses to my earlier note indicate that I'm not alone in this view, though they are not numerous enough to indicate any sort of trend. Ran atkinson@itd.nrl.navy.mil [1] While I am not advocating reuse of the SIPP ESP syntax for IPv4, I do believe that it could be easily adapted for use with IPv4 and would not object if there were group consensus on doing that. :-) From ipsec-request@ans.net Wed Feb 2 08:26:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17862 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 03:30:33 -0500 Received: by interlock.ans.net id AA08229 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 03:26:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 03:26:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 03:26:53 -0500 Date: Wed, 2 Feb 1994 00:26:45 -0800 From: Phil Karn Message-Id: <199402020826.AAA06199@servo.qualcomm.com> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: <9402020245.AA27062@itd.nrl.navy.mil> (atkinson@itd.nrl.navy.mil) Subject: Re: IPsec near term work One of the reasons I've been putting off key management is a (sigh) familiar and thorny one to many of us: the public key patents and the politics surrounding them. I doubt I'm the only one. Everybody knows that the only truly practical way to do an IP key management protocol is with public key cryptography, but the sorry history of PEM isn't much cause for hope. Much of the Internet's success comes from its "let a thousand flowers bloom" philosophy, but so far those who control RSA haven't seen fit to legitimize this approach. Indeed, what is arguably now the best and most successful Internet implementation of RSA (PGP) was done in direct defiance of the patents and at considerable personal risk. A level of risk I would rather not assume myself, much less force others to assume. Will we have to wait until 1997 (when Diffie Hellman expires) or 2000 (when RSA expires) to do anything with IP security beyond manual single-key cryptography? Is anyone willing to tackle this issue? Phil From ipsec-request@ans.net Wed Feb 2 08:17:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18416 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 08:20:43 -0500 Received: by interlock.ans.net id AA21792 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 08:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 2 Feb 1994 08:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 08:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 08:18:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 08:18:41 -0500 Message-Id: <9402021317.AA19410@tis.com> To: Phil Karn Cc: ipsec@ans.net, crocker@tis.com Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 94 00:26:45 PST." <199402020826.AAA06199@servo.qualcomm.com> Date: Wed, 02 Feb 94 08:17:18 +0000 From: Stephen D Crocker -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,03 MIC-Info: RSA-MD5,RSA,QFfh6/f7DtjdgHI3Gn5DHW33MBNhXZOMkr0XAOd1rBa KzPthgefgmO2shPB2JRopFQ3k4lgDNMObxHJ1dOZnlwXzyJREWYNp7anoIUX4pqf UYqsAnPvyqPB9LQqM+Fb/ Phil, Discussions of the patents and license terms for the public key patents always seem to have a high emotional content, and it's with some trepidation that I attempt to respond to your message. I've now been directly involved in this matter for four years, and I think the situation is not as awkward as you suggest. I cannot speak for RSADSI, PKP or others, but here's my perception of the situation. o Licenses for public key technology are obtainable. RSADSI and PKP seem to consummate deals quite regularly, and quite a few major companies are listed as their licensees. I can't speak about the specific terms or practices for any other company, but we at TIS have seen nothing extreme or unreasonable in the terms in our license(s) from RSADSI. (RSADSI sells software; that software comes with the right to use the licensed technology. PKP sells the license only; its licensees build their own software or hardware.) o A substantial amount of the criticism in the community comes from people who believe that software ought not be patentable, that public key technology should not have been patented, or that the inventors or original patent holders (MIT, Stanford, etc.) acted unwisely or improperly in transferring those patents to PKP. In my view, those are not unreasonable matters for public debate, but I think it is most unlikely that such discussion will affect the present situation in the near future. As you say, the patents will expire in a handful of years. In my view, it's unlikely there'll be any changes in the legal foundation or government policy that would affect the situation in the next few years. o Over the last few years, RSADSI has opened up a path for development of new applications of public key cryptography by releasing its RSAREF package. RSAREF is available free of charge, in source form, for non-commercial user. RSADSI specifically encourages its use for new applications, experiments, etc. In those cases, in which the interfaces in RSAREF do not match the needs of the application, RSADSI entertains requests for modifications to the details of the license. We have had occasion to explore this avenue in our development of TIS/PEM, and we did not have any difficulty interacting with RSADSI. One might argue that providing RSAREF is merely a good marketing strategy. Sure, but it serves our community nonetheless. As I said above, all the evidence I have is that licenses for commercial applications are available in regular and businesslike way at prices that seem to work ok in the marketplace. (Discussion of prices is always controversial. Patents intentionally create monopolies, and monopolies obviously obey different -- not unconstrained, just different -- pricing rules than non-monopolies.) o PGP is a somewhat complicated case. I'll skip over the who did or didn't do what to whom at what time, and offer that, in my opinion, it's entirely possible to build applications that are as usable and popular as PGP and that also live within the current licensing rules. PEM is a different case. In my view, although some of the delay in bringing out the PEM specs may be attributable to license issues, another substantial component of the delay has been the ambition level of the design. PEM attempts to provide both the mechanism for protection of mail *and* a general solution to the naming and key management problem for the Internet. This latter problem is substantially harder than simply choosing algorithms and formats for protection of messages, and the solution chosen for PEM has the hard job of introducing X.500 style names and tools into an infrastructure built on the domain name system. The bottom line is that I agree with your assessment "that the only truly practical way to do an IP key management protocol is with public key cryptography," but I disagree with your assessment that the licensing requirements present a serious burden to us. Quite apart from the issue of patents and their licenses is the matter of export control and related government policies. You did not speak to those issues, but I believe those regulations have far more impact on us than the patent situation. I bring this up only to make sure the readers of our notes keep two separate markers in their minds, one related to patents and one related to government regulations. Letting the patents expire and/or using other unpatented cryptography won't change the regulatory environment. This is a topic for a different set of notes. I believe that if we should define whatever protocol meets our needs. If we choose standards which use public key cryptography, I anticipate it will be more or less ordinary to work out the licensing arrangements. And I hereby pledge to work with whomever is relevant to make this so. Steve Disclaimers, representations, etc: I am the IETF Security AD. I am also a vice president of Trusted Information Systems, Inc. and have been directly responsible the development of TIS' PEM implementation. I have written this primarily as Security AD, but I have drawn on our experience at TIS. TIS is a licensee of RSADSI. (TIS is not a licensee of PKP.) This note represents only my own opinion. It has not been coordinated with anyone at RSADSI, PKP, any other organization, nor even within TIS. This note is not a commitment by TIS, and except in so far as I'm obviously involved in the decision processes at TIS, this note does not necessarily represent TIS' business position. +-------------------------------------+-------------------------------+ | Steve Crocker | Voice: 301-854-6889 | | Trusted Information Systems | FAX: 301-854-5363 | | 3060 Washington Road (Route 97) |-------------------------------| | Glenwood, MD 21738 | Internet: crocker@tis.com | +-------------------------------------+-------------------------------+ > From: Phil Karn > To: atkinson@itd.nrl.navy.mil > cc: ipsec@ans.net > Date: Wed, 2 Feb 1994 00:26:45 -0800 > Subject: Re: IPsec near term work > > One of the reasons I've been putting off key management is a (sigh) > familiar and thorny one to many of us: the public key patents and the > politics surrounding them. I doubt I'm the only one. > > Everybody knows that the only truly practical way to do an IP key > management protocol is with public key cryptography, but the sorry > history of PEM isn't much cause for hope. Much of the Internet's > success comes from its "let a thousand flowers bloom" philosophy, but > so far those who control RSA haven't seen fit to legitimize this > approach. > > Indeed, what is arguably now the best and most successful Internet > implementation of RSA (PGP) was done in direct defiance of the patents > and at considerable personal risk. A level of risk I would rather not > assume myself, much less force others to assume. > > Will we have to wait until 1997 (when Diffie Hellman expires) or 2000 > (when RSA expires) to do anything with IP security beyond manual > single-key cryptography? Is anyone willing to tackle this issue? > > Phil > -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Tue Feb 1 22:41:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11901 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 09:45:20 -0500 Received: by interlock.ans.net id AA08677 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 09:42:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 09:42:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 09:42:53 -0500 X-Ns-Transport-Id: 08003700A35877273103 Date: Wed, 2 Feb 1994 06:41:46 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPsec near term work In-Reply-To: <199402020826.AAA06199@servo.qualcomm.com> To: karn@qualcomm.COM Cc: ipsec@ans.net Message-Id: <" 2-Feb-94 9:41:40".*.Russ_Housley.McLean_CSD@Xerox.com> Phil: The IEEE 802.10 Key Management allows three key management techniques to be used: certificate-based (which uses public key crypto), key distribution center (like Kerberos), and manual. In the cases of manual key distrinution, the protocol simply selects a key from a manually distributed cache. I recommend that the IETF work adopt a similar approach so that users who are willing to pay liscense fees to use the public key algorithms can do so and the users wo are unwilling to pa liscense fees are not left without a solution. Russ From ipsec-request@ans.net Wed Feb 2 02:24:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05198 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 13:28:38 -0500 Received: by interlock.ans.net id AA06530 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 13:24:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 13:24:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 13:24:52 -0500 Message-Id: Date: Wed, 2 Feb 94 10:24 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Russ_Housley.McLean_CSD@xerox.com From: brian@lloyd.com (Brian Lloyd) Subject: Re: IPsec near term work Cc: ipsec@ans.net At 6:41 2/2/94 -0800, Russ_Housley.McLean_CSD@xerox.com wrote: >I recommend that the IETF work adopt a similar approach so that users who are >willing to pay liscense fees to use the public key algorithms can do so and the >users wo are unwilling to pa liscense fees are not left without a solution. I second this approach. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Wed Feb 2 02:24:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16979 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 13:29:37 -0500 Received: by interlock.ans.net id AA21386 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 13:24:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 13:24:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 13:24:57 -0500 Message-Id: Date: Wed, 2 Feb 94 10:24 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Phil Karn , atkinson@itd.nrl.navy.mil From: brian@lloyd.com (Brian Lloyd) Subject: Re: IPsec near term work Cc: ipsec@ans.net At 0:26 2/2/94 -0800, Phil Karn wrote: >One of the reasons I've been putting off key management is a (sigh) >familiar and thorny one to many of us: the public key patents and the >politics surrounding them. I doubt I'm the only one. > >Everybody knows that the only truly practical way to do an IP key >management protocol is with public key cryptography, but the sorry >history of PEM isn't much cause for hope. Much of the Internet's >success comes from its "let a thousand flowers bloom" philosophy, but >so far those who control RSA haven't seen fit to legitimize this >approach. > >Indeed, what is arguably now the best and most successful Internet >implementation of RSA (PGP) was done in direct defiance of the patents >and at considerable personal risk. A level of risk I would rather not >assume myself, much less force others to assume. > >Will we have to wait until 1997 (when Diffie Hellman expires) or 2000 >(when RSA expires) to do anything with IP security beyond manual >single-key cryptography? Is anyone willing to tackle this issue? > >Phil We need an IP security protocol (encryption), period. We need one now even if it means that we do manual key managment. Frankly, key managment can be decoupled from the security protocol itself. We can at least move forward and begin experimentation in that area even as we decide what to do about key management. Re: key management. Sometimes you have to dance with the devil. RSA seems to have a headlock on the technology; their patents make that pretty indisputable. (I know: someone could challenge them in court but my company isn't going to carry that banner.) So we define a protocol that uses RSA public-key technology with a Diffie-Hellman key exchange. Later we can go on and define other methods. Sure this is suboptimal for everyone but it is a very straightforward solution. It is the technology of choice. Maybe we can get out from under the patents and patent royalties in a couple of years. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Wed Feb 2 20:29:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18379 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 15:35:15 -0500 Received: by interlock.ans.net id AA29794 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 15:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 15:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 15:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 15:29:48 -0500 Message-Id: <199402022029.AA01529@misc.glarp.com> To: Phil Karn Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 94 00:26:45 PST." <199402020826.AAA06199@servo.qualcomm.com> Date: Wed, 02 Feb 1994 13:29:31 -0700 From: Brad Huntting > Will we have to wait until 1997 (when Diffie Hellman expires) or 2000 > (when RSA expires) to do anything with IP security beyond manual > single-key cryptography? Is anyone willing to tackle this issue? If your implementation uses rsaref then there's a good chance it could be used by most north american companies. Unfortunately, this leaves out two very large sectors of the Internet. Namely (1) those outside north america, and (2) commercial interests. The first group could use an rsaref work alike as long as it was developed and maintained outside the US. The second group could use a shareware, licenced north american rsaref work alike if only it existed. RSADSI has blocked this approach by not selling a "comercial version" of the software they already give away. They see rsaref as a purly experimental library which has no place in the "real world". IMHO they are throwing away free money by not selling "comersial use licences" for rsaref to companies who want to use software built with it. brad From ipsec-request@ans.net Wed Feb 2 20:58:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18373 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 16:01:46 -0500 Received: by interlock.ans.net id AA19454 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 15:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 2 Feb 1994 15:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 15:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 15:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 15:59:32 -0500 Message-Id: <9402022058.AA17621@tis.com> To: Brad Huntting Cc: Phil Karn , atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 94 13:29:31 MST." <199402022029.AA01529@misc.glarp.com> Date: Wed, 02 Feb 94 15:58:04 -0500 From: Stephen D Crocker -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,03 MIC-Info: RSA-MD5,RSA,Kigr9NdAehfRZQUzKRPCB+aFbtF7tmXMYPJ1Ra7kxP2 lYZl308slFdYZyF1fIqVMVgF8bGExMah7Sar9SD2AeCfmfXY0OgcNJrLP/wtUC2Q jlMT1DHmhEml3XIUotpQc > The second group could use a shareware, licenced north american > rsaref work alike if only it existed. RSADSI has blocked this > approach by not selling a "comercial version" of the software they > already give away. > > They see rsaref as a purly experimental library which has no place > in the "real world". IMHO they are throwing away free money by > not selling "comersial use licences" for rsaref to companies who > want to use software built with it. I don't believe this description of the situation is completely accurate. I'm not sure what "shareware, licensed..." means precisely. However, I believe that if someone developed an application which uses RSAREF and then sought a commercial license for the application, a fairly strightforward business discussion would ensue. I don't speak for RSADSI, but I expect they would provide suitable commercial licenses whenever the situation arises. One can cast this as a pair of questions focused on test cases: - - Are there any known examples in which someone has built an application based on RSAREF, decided to commercialize it, approached RSADSI, and not been able to come to reasonable terms? I know of none, but perhaps others do. + Conversely, are there any known examples in which someone has built an application based on RSAREF, decided to commercialize it, approached RSADSI, and successfully obtained a license? I believe the answer is yes. All representations and disclaimers in my last note apply here too. Steve > From: Brad Huntting > To: Phil Karn > cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net > Date: Wed, 02 Feb 1994 13:29:31 -0700 > Subject: Re: IPsec near term work > > > > Will we have to wait until 1997 (when Diffie Hellman expires) or 2000 > > (when RSA expires) to do anything with IP security beyond manual > > single-key cryptography? Is anyone willing to tackle this issue? > > If your implementation uses rsaref then there's a good chance it > could be used by most north american companies. > > Unfortunately, this leaves out two very large sectors of the > Internet. Namely (1) those outside north america, and (2) commercial > interests. > > The first group could use an rsaref work alike as long as it was > developed and maintained outside the US. > > The second group could use a shareware, licenced north american > rsaref work alike if only it existed. RSADSI has blocked this > approach by not selling a "comercial version" of the software they > already give away. > > They see rsaref as a purly experimental library which has no place > in the "real world". IMHO they are throwing away free money by > not selling "comersial use licences" for rsaref to companies who > want to use software built with it. > > > brad -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Feb 2 21:39:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20251 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 16:41:41 -0500 Received: by interlock.ans.net id AA23421 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 16:39:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 16:39:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 16:39:14 -0500 Date: Wed, 2 Feb 1994 13:39:01 -0800 From: Phil Karn Message-Id: <199402022139.NAA07416@servo.qualcomm.com> To: crocker@tis.com Cc: ipsec@ans.net, karn@qualcomm.com In-Reply-To: <9402021317.AA19410@tis.com> (message from Stephen D Crocker on Wed, 02 Feb 94 08:17:18 +0000) Subject: Re: IPsec near term work Steve, It was also only with some trepidation that I sent my original message, as I didn't want to start a flame war. But this topic is, regrettably, inescapable. Believe me, I would like nothing better than to be proven wrong here -- that there are no significant obstacles to our using public key cryptography as we see fit to secure IP. But I fear that I am right. >o A substantial amount of the criticism in the community comes from > people who believe that software ought not be patentable, that True. I'll avoid this particular issue, except to make the obvious point that if public key cryptography were in the public domain, we wouldn't be having this discussion, and we would quite likely have fielded real systems by now. >o Licenses for public key technology are obtainable. RSADSI and PKP > seem to consummate deals quite regularly, and quite a few major Yes, but. The problem isn't so much that you have to pay and get a license to use public key cryptography, but that PKP puts so many conditions on it. Conditions that I feel unreasonably hamper our traditional freedom to explore multiple technical approaches in parallel, with experience and the marketplace choosing the eventual winner. Case in point: approaches to public key certification. I personally strongly prefer the PGP "mesh" model over PEM's strict hierarchy. It's much more elegant and easier to use than the PEM model, which it could even handle as a special case. It's also far more practical in a decentralized environment like the Internet. I would very much like to explore the use of the PGP certification structure as a base for IP security. You and others may disagree. Fine; reasonable people often do. There's no problem as long as we can all prototype our approaches, test them, and let the market decide the winner(s). It's happened many times before in the Internet, and it's a proven way to make progress. However, this assumes that we all play on a level field. Unfortunately, it's not. PKP blesses only the PEM model, and they have consistently refused to grant licenses, at any price, for the use of PGP and PGP-derived software, even for personal use. The only notable exception is ViaCrypt, which was apparently able to obtain a license only because PKP didn't know what they wanted it for. The popularity of PGP (3,106 registered keys on the keyservers as of my last look), despite PGP's "underground" legal status and the availability of "blessed" alternatives such as RIPEM, just underscores the appeal of PGP's approach to key management. PKP has also, to my understanding, denied repeated requests to allow modification of the RSAREF interfaces to accomodate PGP even for personal use. This makes RSAREF much less than useful to me, given that I would like to personally experiment with PGP-style IP security. In other words, I'm stuck -- either I pursue an approach that I consider to be technically inferior with PKP's blessing, or I "go underground" and pursue the approach that I really believe in. I'm not particularly enthusiastic about either alternative. Phil From ipsec-request@ans.net Wed Feb 2 17:45:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07849 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 17:49:00 -0500 Received: by interlock.ans.net id AA32144 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 17:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 2 Feb 1994 17:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 17:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 17:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 17:46:03 -0500 Message-Id: <9402022245.AA25123@tis.com> To: Phil Karn Cc: ipsec@ans.net, crocker@tis.com Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 94 13:39:01 PST." <199402022139.NAA07416@servo.qualcomm.com> Date: Wed, 02 Feb 94 17:45:27 +0000 From: Stephen D Crocker Phil, You wrote: > >o Licenses for public key technology are obtainable. RSADSI and PKP > > seem to consummate deals quite regularly, and quite a few major > > Yes, but. The problem isn't so much that you have to pay and get a > license to use public key cryptography, but that PKP puts so many > conditions on it. Conditions that I feel unreasonably hamper our > traditional freedom to explore multiple technical approaches in > parallel, with experience and the marketplace choosing the eventual > winner. > > Case in point: approaches to public key certification. I personally > strongly prefer the PGP "mesh" model over PEM's strict hierarchy. It's > much more elegant and easier to use than the PEM model, which it could > even handle as a special case. It's also far more practical in a > decentralized environment like the Internet. I would very much like to > explore the use of the PGP certification structure as a base for IP > security. See below for my view on the mesh model, etc. > You and others may disagree. Fine; reasonable people often do. Actually, I agree. > There's no problem as long as we can all prototype our approaches, > test them, and let the market decide the winner(s). It's happened many > times before in the Internet, and it's a proven way to make progress. I believe it's entirely plausible to prototype any approach you want. If there's trouble on this point, I would lend a hand to resolve whatever the trouble might be. > However, this assumes that we all play on a level field. > Unfortunately, it's not. PKP blesses only the PEM model, and they > have consistently refused to grant licenses, at any price, for the > use of PGP and PGP-derived software, even for personal use. PGP itself is a very special problem. I don't believe we'd have any trouble prototyping, or indeed building, a system that works like PGP. Attempting to use PGP directly combines a technical approach with some legal and business issues. The history here is unfortunate but not overly important. With respect to the particular certificate model we have in force for PEM, I'm afraid the blame for our choice of PEM design, hierarchy, etc. is squarely on our shoulders. The original design came from the PSRG. It was transitioned over to the PEM WG. The first PEM WG meeting under the IETF's auspices took place at the Atlanta IETF meeting a few years ago. The certificate hierarchy which had been designed by the PSRG was the focus of some intense criticism, and the situation changed rapidly thereafter. The certificate mechanism we have now is entirely our own responsibility. I have come to agree with you completely that the hierarchy we have is entirely too rigid. We should have built a more open system and evolved the more rigid hierarchy over a period of time if it turned out to be desired by some or all of the community. The certificate hierarchy is handled in the PEM WG. The relevant standard is 1422. It's in proposed standard status. Three possibilities exist. 1. Leave things as is. 2. Enter into the PEM WG and exert pressure according to your views. 3. Petition to organize a certificate or public key management WG which serves all applications, including PEM, IPSEC, etc. If the current design of the hierarchy does not meet our needs, we should do what the IETF is best at: fix it. I have spent considerable time and effort working toward opening up the certificate model. There are lots of competing forces. In our implementation of TIS/PEM, the user is able to designate a set of certificates which she wants to trust. A certificate is considered to be valid if there's a chain leading up to a designated certificate. If the only designated certificate is the IPRA's, this implements the official hierarchy. If all of the certificates are designated, this implements the simplest form of direct trust. Our implementation does not match PGP's web of trust completely. I'm not sure I understand all of the implications of a web of trust. But the general thrust of our work here is to attempt to deal with a larger range of models for precisely the same reasons you have in mind. Steve From ipsec-request@ans.net Wed Feb 2 13:11:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20451 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 18:18:32 -0500 Received: by interlock.ans.net id AA21404 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 18:11:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 18:11:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 18:11:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 18:11:32 -0500 Message-Id: <9402022311.AA17742@toxicwaste.media.mit.edu> To: Stephen D Crocker Cc: Phil Karn , ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Wed, 02 Feb 94 17:45:27 +0000. <9402022245.AA25123@tis.com> Date: Wed, 02 Feb 94 18:11:20 EST From: Derek Atkins > Our implementation does not match PGP's web of trust completely. I'm > not sure I understand all of the implications of a web of trust. But > the general thrust of our work here is to attempt to deal with a > larger range of models for precisely the same reasons you have in > mind. I've been trying to come to grips with this myself, Steve. I've sat down with a number of people and tried to explain how this works, each time beginning to understand it better myself. One of the major differences with the web is that a certificate can have any number of signatures on it, and also it means that *ANYONE* can become a certification authority. Since trust is not automatically transitive without setting individual trust parameters, it has, without any changes, become a cryptographic equivalent of TIS/PEM. However, if I understand TIS/PEM properly, when you trust a certificate, you don't sign it yourself -- rather, you just stick a bit in the database that says you trust it. (Please correct me, possibly in private email, if I am wrong here -- I haven't looked at the code myself). However, since you can have multiple signatures, this means that you can be signed by any number of "CA"'s, each of which may or may not trust one another, and it puts a cryptographic mark on the certificate to show to yourself and others that this trust exists. I realize that these aren't *all* the implications -- I'm sure that even Phil Zimmermann doesn't understand *all* the implications -- but I hope I've shed some light it a little. -derek From ipsec-request@ans.net Wed Feb 2 18:18:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07439 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 18:22:55 -0500 Received: by interlock.ans.net id AA06604 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 18:20:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 2 Feb 1994 18:20:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 18:20:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 18:20:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 18:20:13 -0500 Message-Id: <9402022318.AA26387@tis.com> To: Derek Atkins Cc: Phil Karn , ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 94 18:11:20 EST." <9402022311.AA17742@toxicwaste.media.mit.edu> Date: Wed, 02 Feb 94 18:18:46 +0000 From: Stephen D Crocker > > Our implementation does not match PGP's web of trust completely. I'm > > not sure I understand all of the implications of a web of trust. But > > the general thrust of our work here is to attempt to deal with a > > larger range of models for precisely the same reasons you have in > > mind. > > I've been trying to come to grips with this myself, Steve. I've sat > down with a number of people and tried to explain how this works, each > time beginning to understand it better myself. One of the major > differences with the web is that a certificate can have any number of > signatures on it, and also it means that *ANYONE* can become a > certification authority. Right. I don't believe that the limited extensions we've put in TIS/PEM match the entire set of capabilities in PGP. > Since trust is not automatically transitive without setting individual > trust parameters, it has, without any changes, become a cryptographic > equivalent of TIS/PEM. I assume you're speaking about PGP. Unfortunately, I'm not familiar with the detailed controls of PGP. > However, if I understand TIS/PEM properly, when you trust a > certificate, you don't sign it yourself -- rather, you just stick a > bit in the database that says you trust it. (Please correct me, > possibly in private email, if I am wrong here -- I haven't looked at > the code myself). That's right. > However, since you can have multiple signatures, this means that you > can be signed by any number of "CA"'s, each of which may or may not > trust one another, and it puts a cryptographic mark on the certificate > to show to yourself and others that this trust exists. Hmmm... I'm not sure how this relates to the previous text. One can have multiple signatures, but we don't have much experience with them. I believe the current implementation of TIS/PEM doesn't handle multiple certificates very well. > I realize that these aren't *all* the implications -- I'm sure that > even Phil Zimmermann doesn't understand *all* the implications -- but > I hope I've shed some light it a little. One of the criticisms of the web of trust model in PGP is that it's hard to characterize precisely what the properties are. Theorems, anyone? I'm not suggesting that lack of formal rigor invalidates it completely, but it's not unreasonable to worry about such things as we scale up our use of certificates. Steve From ipsec-request@ans.net Wed Feb 2 13:46:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07531 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 18:48:27 -0500 Received: by interlock.ans.net id AA21380 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 18:47:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 18:47:04 -0500 Message-Id: <199402022347.AA34176@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 18:47:04 -0500 To: Stephen D Crocker Cc: ipsec@ans.net Subject: Re: IPsec near term work Date: Wed, 02 Feb 94 18:46:26 EST > I realize that these aren't *all* the implications -- I'm sure that > even Phil Zimmermann doesn't understand *all* the implications -- but > I hope I've shed some light it a little. One of the criticisms of the web of trust model in PGP is that it's hard to characterize precisely what the properties are. Theorems, anyone? The web of trust is easily modeled as a directed graph, and probably as a directed acyclic graph. In fact, I think it's a lattice. Now, I'm not a graph theorist, but given all the work on lattices and Bell-Lapadula, I suspect that there are those in the security community who are. It might make for an interesting paper for the '95 Oakland conference.. From ipsec-request@ans.net Wed Feb 2 23:50:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15747 (5.65c/IDA-1.4.4 for ); Wed, 2 Feb 1994 18:52:30 -0500 Received: by interlock.ans.net id AA34188 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Feb 1994 18:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 2 Feb 1994 18:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 2 Feb 1994 18:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Feb 1994 18:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Feb 1994 18:51:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Feb 1994 18:51:06 -0500 Message-Id: <199402022350.SAA06339@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Stephen D Crocker Cc: Derek Atkins , Phil Karn , ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Wed, 02 Feb 1994 18:18:46 GMT." <9402022318.AA26387@tis.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 02 Feb 1994 18:50:51 -0500 From: "Perry E. Metzger" Stephen D Crocker says: > > I realize that these aren't *all* the implications -- I'm sure that > > even Phil Zimmermann doesn't understand *all* the implications -- but > > I hope I've shed some light it a little. > > One of the criticisms of the web of trust model in PGP is that it's > hard to characterize precisely what the properties are. Theorems, > anyone? Lets recall, of course, that the PEM model is a strict subset of the Web model. I could just build a strict heirarchy if I wanted. Unlike with PEM, however, with a Web, I can designate a sit or corporate signing authority or choose not to as my tastes go. I can designate a small set of other company's who's signing authorities I trust and set up a frustum of trust rather than a pyramid of trust, or I can set up a web with my friends, or I can do anything else I like. I agree that formally characterizing the properties of the model is hard. Of course, formally characterizing the failure modes of SMTP email is also hard, and yet people manage to trust that SMTP will deliver their mail most of the time just fine. It would be NICE to come up with formal characterizations, of course, but we would first need to very clearly understand what it was that we wanted to figure out about the security of the system. > I'm not suggesting that lack of formal rigor invalidates it > completely, but it's not unreasonable to worry about such things as we > scale up our use of certificates. Agreed. On another note, I'd like to point out that "Web" does not mean "everyone signs keys", it merely means "one may establish more than one root in the heirarchy of entities one chooses to trust". It will scale just fine if large organizations centralize WITHIN THEIR ORGANIZATION. This reminds me of the way that DNS forces local administrators to centralize their name management within their domain, but only some peripheral aspects of the namespace and some "starter" data get managed by DNS itself. Unlike DNS, however, the Web model allows you to operate entirely without a single root. Two companies or sites could choose to mutually trust signing authorities without having to involve anyone else in the decision. Overall, its really nice. Perry From ipsec-request@ans.net Wed Feb 2 22:37:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17813 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 07:40:06 -0500 Received: by interlock.ans.net id AA23457 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 07:34:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 3 Feb 1994 07:34:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 3 Feb 1994 07:34:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 07:34:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 07:34:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 07:34:27 -0500 Message-Id: <00112.2843098866.63886@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: crocker@TIS.COM (Stephen D Crocker), zmuda@mls1.hac.com (Jim Zmuda) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Feb 1994 5:37:33 MST Subject: IPSEC Charter - New Draft f IPSEC Charter - New Draft for Review IPSECers, Jim Zmuda has volunteered to serve as co-chair of our working group. He has been providing significant contributions to our effort and his help as co-chair will be greatly appreciated. Below is a slightly updated draft of the IPSEC charter for review. Regards, Paul ---------------------------------------------------------------- 2/3/93 Draft of IPSEC Charter ---------------------------------------------------------------- Internet Protocol Security Protocol (ipsec) Charter Chair(s): Paul Lambert Jim Zmuda Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. The IPSEC Working Group will develop a security protocol in the network layer to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Security Protocol (IPSP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. The working group will examine the relationship of network security the suite of IP protocols. This investigation will include the examination of IP as a client of IPSP running over IP. Recommendations documented in the IPSP specification will provide guidelines to protect the IP suite of protocols. The cryptographic encapsulation may hide information that is useful to network. This information may include security labels, addresses, and protocol identifiers. The working group will examine the mapping of encapsulated protocol information onto unprotected fields and guidelines for any required Rpeek-throughS of information. Protocol and cryptographic techniques will also be developed to support the key management requirements of the IPSP. 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: Mar 94 Post as an Internet-Draft a preliminary version of the IP Security Protocol. Mar 94 Review pilot experiments with cryptographic network security. Discuss, debate, and refine the framework for IPSP based on pilot experiments. Demonstrate interoperable implementations. Mar 94 Establish baseline design goals for Internet Key Management. Mar 94 Post preliminary text (as RFC) of Internet Key Management to include service primatives and basic assumtions. Jul 94 Update the IPSP Internet-Draft. Include preliminary text on labels, Rpeek-through,S and protection of IP suite. Jul 94 Update Key Management and release as Internet Draft Nov 94 Report on Pilot Implementations of the IP Security Protocol and Key Management Protocol, Update as needed. Mar 95 Submit the IP Security Protocol to the IESG for consideration as a Proposed Standard. Mar 95. Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. From ipsec-request@ans.net Thu Feb 3 04:33:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18228 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 09:39:37 -0500 Received: by interlock.ans.net id AA13842 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 09:33:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 09:33:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 09:33:59 -0500 Date: Thu, 3 Feb 94 09:33:50 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9402031433.AA11890@itd.nrl.navy.mil> To: Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: IPSEC Charter - New Draft for review Cc: ipsec@ans.net Paul, I would like to see a revised charter for the IP Security WG that put the Internet key mgmt protocol work more towards the top of the charter and put more emphasis upon it. I really think that because so many protocols (e.g. IP, Mobile IP, IPng, OSPF, BGP, etc) need a standard key mgmt protocol for security, the key management protocol work should be begun soonest by the IP Security WG. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Feb 3 14:45:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14953 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 09:57:17 -0500 Received: by interlock.ans.net id AA17536 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 09:51:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 09:51:28 -0500 Message-Id: <199402031451.AA24188@interlock.ans.net> To: smb@research.att.com Cc: Stephen D Crocker , ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Wed, 02 Feb 94 18:46:26 -0500. <199402022347.AA34176@interlock.ans.net> Date: Thu, 03 Feb 94 09:45:44 -0500 From: Steve Kent Steve B., There is a considerable body of work on lattice models of security, which is based on a formal model of a sensitivity or integrity policy plus rigorous labelling of sensitivity of information or of the integrity of information. Sensitivity labelling has been found to be quite useful in modelling real world security concerns in some contexts and thus we have systems today that embody that labelling and are used in these contexts. The integrity aspect of labelling has not been found to generally useful and we have few if any systems that make use of such facilities. The PGP web lacks a formal model that relates it to the real world. My personal view is that individuals have great difficulty codifying their model of trust and making it rigorous enough to fit this sort of model, especially since PGP calls for each individual to do this on a local basis. In contrast, the formal model for sensitivity is trivially intuitive (yet the formal rendition of it is hardly trivial). Superficially, one might argue that the integrity model is closer to the web of trust, but I think that too will not stand up to close scrutiny. So, by all means, have someone knowledgable about the long history of lattice model security look at the issues here and try to connect them, but my prediction is that this will not be fruitful. Steve From ipsec-request@ans.net Thu Feb 3 14:49:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18617 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 10:00:44 -0500 Received: by interlock.ans.net id AA24198 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 09:51:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 09:51:34 -0500 Message-Id: <199402031451.AA24194@interlock.ans.net> To: pmetzger@lehman.com Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Wed, 02 Feb 94 18:50:51 -0500. <199402022350.SAA06339@snark> Date: Thu, 03 Feb 94 09:49:16 -0500 From: Steve Kent Perry, Since the PGP web does not have notions of names comparable in structure to DNs, and no name subordinatin rule, it might be more accurate to say that a user could manually configure and manage his web to mimic the PEM hierarchy, but his software could not do this for him automatically because it lacks the features described above. Also, because PGP has no CL facility, the result also would not be comparable to the PEM system, so I think it potentially misleading to characterize the PEM model as a strict subset of the PGP model. Steve From ipsec-request@ans.net Thu Feb 3 01:07:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18462 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 10:15:42 -0500 Received: by interlock.ans.net id AA17632 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 10:03:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 3 Feb 1994 10:03:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 3 Feb 1994 10:03:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 10:03:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 10:03:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 10:03:07 -0500 Message-Id: <00112.2843107862.63903@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Feb 1994 8:07:27 MST Subject: Re: >IPSEC Charter - New Dra Reply to: RE>>IPSEC Charter - New Draf Ran, >I would like to see a revised charter for the IP Security WG that put the >Internet key mgmt protocol work more towards the top of the charter and Yes, the key management is important. Do you have some specific text changes to propose? >put more emphasis upon it. I really think that because so many protocols >(e.g. IP, Mobile IP, IPng, OSPF, BGP, etc) need a standard key mgmt protocol Humm ... why do these protocols need their own key management? They would all be protected by IPSP. Regards, Paul From ipsec-request@ans.net Thu Feb 3 15:29:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18462 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 10:35:25 -0500 Received: by interlock.ans.net id AA37891 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 10:30:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 3 Feb 1994 10:30:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 3 Feb 1994 10:30:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 10:30:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 10:30:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 10:30:05 -0500 Message-Id: <199402031529.KAA10884@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Thu, 03 Feb 1994 09:49:16 EST." <199402031451.JAA17828@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 03 Feb 1994 10:29:44 -0500 From: "Perry E. Metzger" Steve Kent says: > Perry, > > Since the PGP web does not have notions of names comparable in > structure to DNs, and no name subordinatin rule, it might be more > accurate to say that a user could manually configure and manage his > web to mimic the PEM hierarchy, but his software could not do this > for him automatically because it lacks the features described above. > Also, because PGP has no CL facility, the result also would not be > comparable to the PEM system, so I think it potentially misleading to > characterize the PEM model as a strict subset of the PGP model. Actually, I'm more refering to the "web of trust" model than to PGP's implementation of that model. PGP is just one possible way to implement this model, and it lacks support for large scale use of the model -- but that does not mean that the model could not be implemented in a scalable way, and indeed I suspect that it would scale if this was made an objective of the design. I see no reason why software couldn't be set up to mimic the PEM heirarchy automatically were this considered a desirable feature -- as a sanity check, lets all remember that at least in theory computers can do anything humans can. Perry From ipsec-request@ans.net Thu Feb 3 05:33:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16931 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 10:36:00 -0500 Received: by interlock.ans.net id AA33074 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 10:34:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 10:34:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 10:34:03 -0500 Date: Thu, 3 Feb 94 10:33:53 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9402031533.AA15035@itd.nrl.navy.mil> To: atkinson@itd.nrl.navy.mil, Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: >IPSEC Charter - New Dra Cc: ipsec@ans.net % >put more emphasis upon it. I really think that because so many protocols % >(e.g. IP, Mobile IP, IPng, OSPF, BGP, etc) need a standard key mgmt % protocol % % Humm ... why do these protocols need their own key management? They % would all be protected by IPSP. It isn't clear to me that they do need their own key management protocol and that is one reason why I'd like to have the key mgmt protocol done first. There are a number of good reasons why I might want to have authentication (etc) built into those protocols. Mobile IP in particular appears to need to have authentication built into the Mobile IP protocol because IPSP could not provide the right trust properties. I believe these others (IPng, OSPF, BGP) could also benefit from having authentication built into the protocols. There are groups/people already working on adding the hooks for such authentication (as well as some protocols which have the hooks but need a key mgmt protocol to transform those hooks into easily deployable authenticated protocols). Ran From ipsec-request@ans.net Thu Feb 3 15:33:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14903 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 10:38:00 -0500 Received: by interlock.ans.net id AA20006 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 10:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 3 Feb 1994 10:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 3 Feb 1994 10:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 10:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 10:33:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 10:33:42 -0500 Message-Id: <199402031533.KAA10898@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Thu, 03 Feb 1994 09:45:44 EST." <199402031451.AA24188@interlock.ans.net> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 03 Feb 1994 10:33:33 -0500 From: "Perry E. Metzger" Steve Kent says: > The PGP web lacks a formal model that relates it to the real > world. My personal view is that individuals have great difficulty > codifying their model of trust and making it rigorous enough to fit > this sort of model, especially since PGP calls for each individual to > do this on a local basis. Although this was not the focus of your message, I thought I ought to point out again at this juncture that although PGP itself operates on this basis, the Web-of-Trust model need not force individuals to operate this way. In particular, organizations might be free to set up default trust arangements for their users. This has the advantage that users and systems that should be more restrictive (or more generous) in their trust may be flexibly accomodated -- or not as the tastes of the organization go. Perry From ipsec-request@ans.net Thu Feb 3 11:27:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11991 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 11:33:43 -0500 Received: by interlock.ans.net id AA20188 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 11:28:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 3 Feb 1994 11:28:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 11:28:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 11:28:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 11:28:08 -0500 Message-Id: <9402031627.AA26016@tis.com> To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list) Subject: Emphasizing Key Mgmt In-Reply-To: Your message of "Thu, 03 Feb 94 08:07:27 MST." <00112.2843107862.63903@poncho.phx.sectel.mot.com> Date: Thu, 03 Feb 94 11:27:20 +0000 From: Stephen D Crocker Should we keep key management as a work item and goal within IPSEC or consider some other arrangement? I'm open to starting a separate group to work on this. However, it would obviously be a bit more complicated to have a distinct group working on key management. A third alternative (after leaving this as is or starting a fresh group) is to set up some sort of subgroup that's tied into IPSEC but organized to make progress in the near future. Comments? Steve From ipsec-request@ans.net Thu Feb 3 07:21:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20319 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 12:27:20 -0500 Received: by interlock.ans.net id AA35890 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 12:21:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 12:21:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 12:21:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 12:21:22 -0500 Date: Thu, 3 Feb 94 12:21:09 EST Message-Id: <9402031721.AA12153@tri-flow.ftp.com.ftp.com> To: crocker@tis.com Subject: Re: Emphasizing Key Mgmt From: kasten@tri-flow.ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net Content-Length: 1293 Steve, I'd suggest that you open a separate working group for key management. Experience has tended to show that as the number of items on a single working group's agenda increases, the probability of the group coming to closure on things decreases. If you have one group with two goals, the chair of the single group has to multiplex his time over both goals. With two groups, each with its own goal, each chair is free to concentrate on a single goal. An alternative would be to serialize the effort, finish the first task before addressing the second. Yes, there is the inter-group coordination problem but that is what the Area Director and the Area Directorates are for :-) > Should we keep key management as a work item and goal within IPSEC or > consider some other arrangement? > > I'm open to starting a separate group to work on this. However, it > would obviously be a bit more complicated to have a distinct group > working on key management. > > A third alternative (after leaving this as is or starting a fresh > group) is to set up some sort of subgroup that's tied into IPSEC but > organized to make progress in the near future. > > Comments? > > Steve > -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ipsec-request@ans.net Thu Feb 3 18:22:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18509 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 14:14:16 -0500 Received: by interlock.ans.net id AA22408 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 14:08:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 14:08:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 14:08:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 14:08:24 -0500 Message-Id: <9402031822.AA21020@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert), atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list), dns-security@tis.com Subject: Re: Emphasizing Key Mgmt In-Reply-To: Your message of "Thu, 03 Feb 94 11:27:20 GMT." <9402031627.AA26016@tis.com> Date: Thu, 03 Feb 94 13:22:55 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, I'm not sure what the right thing to do is but I expect to be posting a draft in connection with DNS security within a week which is quite relevant to some forms of key management. From: Stephen D Crocker To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list) In-Reply-To: Your message of "Thu, 03 Feb 94 08:07:27 MST." <00112.2843107862.63903@poncho.phx.sectel.mot.com> >Should we keep key management as a work item and goal within IPSEC or >consider some other arrangement? > >I'm open to starting a separate group to work on this. However, it >would obviously be a bit more complicated to have a distinct group >working on key management. I don't really see a need to multiply working groups yet. >A third alternative (after leaving this as is or starting a fresh >group) is to set up some sort of subgroup that's tied into IPSEC but >organized to make progress in the near future. > >Comments? > >Steve Donald From ipsec-request@ans.net Thu Feb 3 09:58:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20424 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 15:05:18 -0500 Received: by interlock.ans.net id AA33671 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 14:58:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 14:58:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 14:58:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 14:58:59 -0500 Message-Id: <9402031958.AA20276@toxicwaste.media.mit.edu> To: Steve Kent Cc: pmetzger@lehman.com, ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Thu, 03 Feb 94 09:49:16 -0500. <199402031451.AA24194@interlock.ans.net> Date: Thu, 03 Feb 94 14:58:33 EST From: Derek Atkins Steve: One of the ideas is that anonymity should be available. The fact that there is a name on an key doesn't mean anything unless you have a proper certification on that name... Also, in this case, the lack of a name subordination rule is a big win. I can think of a number of cases where this model wins highly over a strict CA hierarchy. If you want, I can explain one posibility, but I won't belabor the point unless people want to hear it. > Also, because PGP has no CL facility, the result also would not be > comparable to the PEM system, so I think it potentially misleading to > characterize the PEM model as a strict subset of the PGP model. Well, besides the fact that we are discussing the Web-of-trust, not "PGP" (PGP is a program that implements a cryptographic protocol and a web-of-trust certification model), I was wondering what you mean by "CL".. I couldn't find this term in any of the RFC's, and I don't know what you mean by this. Are you talking about a Revocation? Please expand the acronym "CL", if you don't mind. -derek From ipsec-request@ans.net Thu Feb 3 19:10:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19728 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 15:18:47 -0500 Received: by interlock.ans.net id AA33571 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Feb 1994 15:09:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Feb 1994 15:09:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Feb 1994 15:09:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Feb 1994 15:09:48 -0500 Message-Id: <9402031910.AA21589@skidrow.lkg.dec.com> To: kasten@ftp.com Cc: crocker@tis.com, Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net, dns-security@tis.com Subject: Re: Emphasizing Key Mgmt In-Reply-To: Your message of "Thu, 03 Feb 94 12:21:09 EST." <9402031721.AA12153@tri-flow.ftp.com.ftp.com> Date: Thu, 03 Feb 94 14:10:49 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Frank, From: kasten@tri-flow.ftp.com (Frank Kastenholz) To: crocker@tis.com Reply-To: kasten@ftp.com Cc: Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net >Steve, > >I'd suggest that you open a separate working group for key >management. Experience has tended to show that as the number of >items on a single working group's agenda increases, the probability >of the group coming to closure on things decreases. If you have one >group with two goals, the chair of the single group has to multiplex >his time over both goals. With two groups, each with its own goal, >each chair is free to concentrate on a single goal. An alternative >would be to serialize the effort, finish the first task before >addressing the second. If there are three groups going at once in ipsec, dns-security, and key management, I believe that many mail messages will be relevant to more than one group. I don't suppose they could have a common mailing list? >Yes, there is the inter-group coordination problem but that is what >the Area Director and the Area Directorates are for :-) >-- >Frank Kastenholz >FTP Software >2 High Street >North Andover, Mass. USA 01845 >(508)685-4000 Donald From ipsec-request@ans.net Thu Feb 3 22:10:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07904 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 09:12:35 -0500 Received: by interlock.ans.net id AA08405 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 09:10:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 09:10:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 09:10:52 -0500 X-Ns-Transport-Id: 08003700A35877DB3103 Date: Fri, 4 Feb 1994 06:10:23 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: Emphasizing Key Mgmt In-Reply-To: <9402031721.AA12153@tri-flow.ftp.com.ftp.com> To: ipsec@ans.net Message-Id: <" 4-Feb-94 9:10:16".*.Russ_Housley.McLean_CSD@Xerox.com> Steve: I strongly encourage you to leave IPSEC whole. The present charter says that the IPSP will eb done first, then the Key Management work will be done. This meets the "serialized: concern reaised by Frank Kastenholz. As I have stated many times on this list, key management has four phases: 1. Generate key 2. Negotiate attributes /* We call a key bound with its attributes a security association */ 3. Use the security association 4. Delete the security association Step 2 cannot be described is sufficient detail for implementation until you know ehich attributes are needed by IPSP. Russ From ipsec-request@ans.net Fri Feb 4 14:19:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14955 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 09:24:57 -0500 Received: by interlock.ans.net id AA29785 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 09:23:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 09:23:54 -0500 Message-Id: <199402041423.AA19285@interlock.ans.net> To: pmetzger@lehman.com Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Thu, 03 Feb 94 10:29:44 -0500. <199402031529.KAA10884@snark> Date: Fri, 04 Feb 94 09:19:16 -0500 From: Steve Kent Perry, I understood your comments about a web of trust to be in the context of PGP because I belive you explicitly cited PGP in your message. Without a concrete set of rules, e.g., as provided in PGP, the term "web of trust" is rather ambiguous. Following up on your analogy, although a Turing machine can model computation in general, in practical terms most users would find a Turning machine user's manual not very helpful (compared to the manual than comes with their computer). I feel that a generic web of trust is much like a Turing machine description; it can be made to encompass everything, but it is too primitive and too general to be of practical use in that form. Steve From ipsec-request@ans.net Fri Feb 4 14:25:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20354 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 09:30:26 -0500 Received: by interlock.ans.net id AA38022 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 09:30:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 09:30:07 -0500 Message-Id: <199402041430.AA21378@interlock.ans.net> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of Thu, 03 Feb 94 10:33:53 -0500. <9402031533.AA15035@itd.nrl.navy.mil> Date: Fri, 04 Feb 94 09:25:21 -0500 From: Steve Kent Ran, I have given some though to mobile IP security and I am not convinced that the key management protocol for IPSP will be just right for mobile IP. For example, in the mobile IP case the host may need to be able to assert his right to use a specific IP address to a router, which, in turn, may need to establish to other autonomous systems that this net is currently serving this IP address. This need to assert these identity claims is potentially very different from a need to establish a shared key for end-to-end communication security. The form of the signed objects exchanged, for example, may be quite different. Steve From ipsec-request@ans.net Fri Feb 4 14:42:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14872 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 09:49:30 -0500 Received: by interlock.ans.net id AA14332 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 09:48:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 09:48:36 -0500 Message-Id: <199402041448.AA06648@interlock.ans.net> To: Derek Atkins Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Thu, 03 Feb 94 14:58:33 -0500. <9402031958.AA20276@toxicwaste.media.mit.edu> Date: Fri, 04 Feb 94 09:42:26 -0500 From: Steve Kent Derek, Anonymity is an improtant feature, which is why PEM makes explicit provision for PERSONA certificates. The problem with anonimity effected by certification rules that don't strive to preclude use of non-unique names is that it leads to ambiguity even when anonymity is not a goal. Your later comment suggestions there was a typo in my message. I was referring to CRLs: certificate revocation lists. Steve From ipsec-request@ans.net Fri Feb 4 16:10:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15055 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 11:12:29 -0500 Received: by interlock.ans.net id AA21470 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 11:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 4 Feb 1994 11:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 4 Feb 1994 11:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Feb 1994 11:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 11:10:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 11:10:55 -0500 Message-Id: <199402041610.LAA17974@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Fri, 04 Feb 1994 09:19:16 EST." <199402041424.JAA28233@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 04 Feb 1994 11:10:47 -0500 From: "Perry E. Metzger" Steve Kent says: > Perry, > > I understood your comments about a web of trust to be in the > context of PGP because I belive you explicitly cited PGP in your > message. Without a concrete set of rules, e.g., as provided in PGP, > the term "web of trust" is rather ambiguous. The term refers (approximately) to the model that keys may possess multiple certifications, that any key may sign a certification for any other key, and that the set of keys to trust is configured rather than specified by the model itself. Perry From ipsec-request@ans.net Fri Feb 4 16:14:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19931 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 11:16:30 -0500 Received: by interlock.ans.net id AA19718 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 11:14:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 4 Feb 1994 11:14:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 4 Feb 1994 11:14:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Feb 1994 11:14:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 11:14:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 11:14:43 -0500 Message-Id: <199402041614.LAA17988@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of "Fri, 04 Feb 1994 09:25:21 EST." <199402041430.AA21378@interlock.ans.net> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 04 Feb 1994 11:14:28 -0500 From: "Perry E. Metzger" Steve Kent says: > Ran, > > I have given some though to mobile IP security and I am not > convinced that the key management protocol for IPSP will be just right > for mobile IP. Why don't you ask John Ioannidis about this? He developed one of the first functioning Mobile IP implementations, and also is the co-developer of swIPe. From conversations with him (I work with him), I get more than just a slight impression that he thinks of the IPSP as being an important component of any useful mobile IP system. > For example, in the mobile IP case the host may need > to be able to assert his right to use a specific IP address to a > router, which, in turn, may need to establish to other autonomous > systems that this net is currently serving this IP address. This need > to assert these identity claims is potentially very different from a > need to establish a shared key for end-to-end communication security. I don't see how. You are just communicating via a protocol to the router -- this is no different from any other communication you might have with any other entity. > The form of the signed objects exchanged, for example, may be quite > different. Again, I don't see how, or why, this should be so. Perry From ipsec-request@ans.net Fri Feb 4 16:26:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19719 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 11:50:48 -0500 Received: by interlock.ans.net id AA21994 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 11:47:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Feb 1994 11:47:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 11:47:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 11:47:35 -0500 Message-Id: <9402041626.AA28280@skidrow.lkg.dec.com> To: Steve Kent Cc: Ran Atkinson , ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of "Fri, 04 Feb 94 09:25:21 EST." <199402041430.AA21378@interlock.ans.net> Date: Fri, 04 Feb 94 11:26:42 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp You know, I really gotta get out the DNS security draft I'm working on.... Maybe I can post it Monday... Donald From: Steve Kent To: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: Your message of Thu, 03 Feb 94 10:33:53 -0500. <9402031533.AA15035@itd.nrl.navy.mil> >Ran, > > I have given some though to mobile IP security and I am not >convinced that the key management protocol for IPSP will be just right >for mobile IP. For example, in the mobile IP case the host may need >to be able to assert his right to use a specific IP address to a >router, which, in turn, may need to establish to other autonomous >systems that this net is currently serving this IP address. This need >to assert these identity claims is potentially very different from a >need to establish a shared key for end-to-end communication security. >The form of the signed objects exchanged, for example, may be quite >different. > >Steve From ipsec-request@ans.net Fri Feb 4 02:37:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20352 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 13:40:02 -0500 Received: by interlock.ans.net id AA38737 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 13:37:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 13:37:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 13:37:38 -0500 X-Ns-Transport-Id: 08003700A35878073103 Date: Fri, 4 Feb 1994 10:37:02 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPsec near term work In-Reply-To: <199402022350.SAA06339@snark> To: pmetzger@lehman.com Cc: ipsec@ans.net Message-Id: <" 4-Feb-94 13:37:00".*.Russ_Housley.McLean_CSD@Xerox.com> Perry: You said: > I agree that formally characterizing the properties of the model is > hard. Of course, formally characterizing the failure modes of SMTP > email is also hard, and yet people manage to trust that SMTP will > deliver their mail most of the time just fine. Authentication that can be trusted most of the time to be correct is not acceptable! I am not willing to call it authentication if I can trust it most of the time, but not always. In my opinion, PEM authentication must be able to tell me one of the following: . The message is unmodified and came from the person claimed, or . The message has been modified or the message originator cannot be confirmed. Russ From ipsec-request@ans.net Fri Feb 4 09:12:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20395 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 14:13:56 -0500 Received: by interlock.ans.net id AA37825 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 14:12:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Feb 1994 14:12:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 14:12:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 14:12:54 -0500 Message-Id: <9402041912.AA26055@toxicwaste.media.mit.edu> To: Steve Kent Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Fri, 04 Feb 94 09:42:26 -0500. <9402041448.AA04393@MIT.EDU> Date: Fri, 04 Feb 94 14:12:43 EST From: Derek Atkins > Your later comment suggestions there was a typo in my message. > I was referring to CRLs: certificate revocation lists. Ok, I thought that's what you meant. And I'm sorry to say, but you are mis-informed. You can have revocations in a web-of-trust model. There are two kinds. A person can revoke his own key, which is a key revocation certificate, or an entity can revoke its signature on a key, a signature revocation certificate. (There are also userID revocations as well). There is no reason that this can't exist. Steve, I realize you do not like PGP, but you seem to have this mindset that web-of-trust == PGP. This is not the case. As I said in an earlier message, PGP is an program that implements a web-of-trust. If you really want to know, while the current PGP implementation only has key revocation certificates, the data structures allow for both signature and userID revocations. The idea behind them is that a user should be able to revoke his own key, and any userIDs on his key, and any signatures he makes. I'm sorry, but what were you saying about CRLs? I don't remember your original statement. -derek From ipsec-request@ans.net Fri Feb 4 20:24:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05312 (5.65c/IDA-1.4.4 for ); Fri, 4 Feb 1994 15:29:29 -0500 Received: by interlock.ans.net id AA37753 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Feb 1994 15:24:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 4 Feb 1994 15:24:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 4 Feb 1994 15:24:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Feb 1994 15:24:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Feb 1994 15:24:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Feb 1994 15:24:41 -0500 Message-Id: <199402042024.PAA18560@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Fri, 04 Feb 1994 10:37:02 PST." <" 4-Feb-94 13:37:00".*.Russ_Housley.McLean_CSD@Xerox.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 04 Feb 1994 15:24:31 -0500 From: "Perry E. Metzger" Russ_Housley.McLean_CSD@xerox.com says: > Perry: > > You said: > > I agree that formally characterizing the properties of the model is > > hard. Of course, formally characterizing the failure modes of SMTP > > email is also hard, and yet people manage to trust that SMTP will > > deliver their mail most of the time just fine. > > Authentication that can be trusted most of the time to be correct is not > acceptable! I am not willing to call it authentication if I can trust it most > of the time, but not always. Anyone who can produce a proven correct *implementation* of any security protocol that is longer than 1000 lines of code in length is invited to reply. Otherwise, the notion of proving a protocol correct (when we can't even properly characterize all the threats) and then using a non-provably correct implementation is inane. I am also reminded of a project I worked at at Bellcore. We had a PhD in math checking a protocol simulation, and he proved the program correct. Unfortunately, both the proof and the program had a subtle bug. As for the authentication protocol, it doesn't have to be provably correct. The authentication protocol merely has to be correct. Provably correct would be nice, but its unlikely to happen, and systems like Kerberos have shown that good systems can be built without formal proofs of correctness. As I've said, any such "proof" is in any case rendered useless in the face of unprovable implementations, unprovable compilers compiling the implemenations, unprovable operating systems, unprovable hardware, etc. Perry From ipsec-request@ans.net Sat Feb 5 06:23:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05234 (5.65c/IDA-1.4.4 for ); Sat, 5 Feb 1994 01:27:56 -0500 Received: by interlock.ans.net id AA16180 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 5 Feb 1994 01:26:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 5 Feb 1994 01:26:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 5 Feb 1994 01:26:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 5 Feb 1994 01:26:33 -0500 Message-Id: <9402050623.AA05140@skidrow.lkg.dec.com> To: IP Secrity WG Subject: More reasons to IP security Date: Sat, 05 Feb 94 01:23:27 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp ------- Forwarded Message From: CERT Advisory Date: Thu, 3 Feb 94 21:14:40 EST To: cert-advisory@cert.org Subject: CERT Advisory - Ongoing Network Monitoring Attacks Organization: Computer Emergency Response Team : 412-268-7090 ============================================================================= CA-94:01 CERT Advisory February 3, 1994 Ongoing Network Monitoring Attacks - ----------------------------------------------------------------------------- In the past week, CERT has observed a dramatic increase in reports of intruders monitoring network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, /dev/nit, to capture host and user authentication information on all newly opened FTP, telnet, and rlogin sessions. In the short-term, CERT recommends that all users on sites that offer remote access change passwords on any network-accessed account. In addition, all sites having systems that support the /dev/nit interface should disable this feature if it is not used and attempt to prevent unauthorized access if the feature is necessary. A procedure for accomplishing this is described in Section III.B.2 below. Systems known to support the interface are SunOS 4.x (Sun3 and Sun4 architectures) and Solbourne systems; there may be others. Sun Solaris systems do not support the /dev/nit interface. If you have a system other than Sun or Solbourne, contact your vendor to find if this interface is supported. While the current attack is specific to /dev/nit, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of reusable passwords in clear-text over the network. - ----------------------------------------------------------------------------- I. Description Root-compromised systems that support a promiscuous network interface are being used by intruders to collect host and user authentication information visible on the network. The intruders first penetrate a system and gain root access through an unpatched vulnerability (solutions and workarounds for these vulnerabilities have been described in previous CERT advisories, which are available anonymous FTP from info.cert.org). The intruders then run a network monitoring tool that captures up to the first 128 keystrokes of all newly opened FTP, telnet, and rlogin sessions visible within the compromised system's domain. These keystrokes usually contain host, account, and password information for user accounts on other systems; the intruders log these for later retrieval. The intruders typically install Trojan horse programs to support subsequent access to the compromised system and to hide their network monitoring process. II. Impact All connected network sites that use the network to access remote systems are at risk from this attack. All user account and password information derived from FTP, telnet, and rlogin sessions and passing through the same network as the compromised host could be disclosed. III. Approach There are three steps in CERT's recommended approach to the problem: - Detect if the network monitoring tool is running on any of your hosts that support a promiscuous network interface. - Protect against this attack either by disabling the network interface for those systems that do not use this feature or by attempting to prevent unauthorized use of the feature on systems where this interface is necessary. - Scope the extent of the attack and recover in the event that the network monitoring tool is discovered. A. Detection The network monitoring tool can be run under a variety of process names and log to a variety of filenames. Thus, the best method for detecting the tool is to look for 1) Trojan horse programs commonly used in conjunction with this attack, 2) any suspect processes running on the system, and 3) the unauthorized use of /dev/nit. 1) Trojan horse programs: The intruders have been found to replace one or more of the following programs with a Trojan horse version in conjunction with this attack: /usr/etc/in.telnetd and /bin/login - Used to provide back-door access for the intruders to retrieve information /bin/ps - Used to disguise the network monitoring process Because the intruders install Trojan horse variations of standard UNIX commands, CERT recommends not using other commands such as the standard UNIX sum(1) or cmp(1) commands to locate the Trojan horse programs on the system until these programs can be restored from distribution media, run from read-only media (such as a mounted CD-ROM), or verified using cryptographic checksum information. In addition to the possibility of having the checksum programs replaced by the intruders, the Trojan horse programs mentioned above may have been engineered to produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. CERT recommends that you use both the /usr/5bin/sum and /bin/sum commands to compare against the distribution media and assure that the programs have not been replaced. The use of cmp(1), MD5, Tripwire (only if the baseline checksums were created on a distribution system), and other cryptographic checksum tools are also sufficient to detect these Trojan horse programs, provided these programs were not available for modification by the intruder. If the distribution is available on CD-ROM or other read-only device, it may be possible to compare against these volumes or run programs off these media. 2) Suspect processes: Although the name of the network monitoring tool can vary from attack to attack, it is possible to detect a suspect process running as root using ps(1) or other process-listing commands. Until the ps(1) command has been verified against distribution media, it should not be relied upon--a Trojan horse version is being used by the intruders to hide the monitoring process. Some process names that have been observed are sendmail, es, and in.netd. The arguments to the process also provide an indication of where the log file is located. If the "-F" flag is set on the process, the filename following indicates the location of the log file used for the collection of authentication information for later retrieval by the intruders. 3) Unauthorized use of /dev/nit: If the network monitoring tool is currently running on your system, it is possible to detect this by checking for unauthorized use of the /dev/nit interface. CERT has created a minimal tool for this purpose. The source code for this tool is available via anonymous FTP on info.cert.org in the /pub/tools/cpm directory or on ftp.uu.net in the /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum information is: Filename Standard UNIX Sum System V Sum -------------- ----------------- ------------ cpm.1.0.tar.Z: 11097 6 24453 12 MD5 Checksum MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 This archive contains a readme file, also included as Appendix C of this advisory, containing instructions on installing and using this detection tool. B. Prevention There are two actions that are effective in preventing this attack. A long-term solution requires eliminating transmission of clear-text passwords on the network. For this specific attack, however, a short-term workaround exists. Both of these are described below. 1) Long-term prevention: CERT recognizes that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network. CERT has collected some information on relevant technologies. This information is included as Appendix B in this advisory. Note: These solutions will not protect against transient or remote access transmission of clear-text passwords through the network. Until everyone connected to your network is using the above technologies, your policy should allow only authorized users and programs access to promiscuous network interfaces. The tool described in Section III.A.3 above may be helpful in verifying this restricted access. 2) Short-term workaround: Regardless of whether the network monitoring software is detected on your system, CERT recommends that ALL SITES take action to prevent unauthorized network monitoring on their systems. You can do this either by removing the interface, if it is not used on the system or by attempting to prevent the misuse of this interface. For systems other than Sun and Solbourne, contact your vendor to find out if promiscuous mode network access is supported and, if so, what is the recommended method to disable or monitor this feature. For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. The procedure for doing so is outlined below (see your system manuals for more details). Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional. Procedure for removing /dev/nit from the kernel: 1. Become root on the system. 2. Apply "method 1" as outlined in the System and Network Administration manual, in the section, "Sun System Administration Procedures," Chapter 9, "Reconfiguring the System Kernel." Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [Note that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.] # chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module [Comment out the preceding three lines; save and exit the editor before proceeding.] # config SYS_NAME # cd ../SYS_NAME # make # mv /vmunix /vmunix.old # cp vmunix /vmunix # /etc/halt > b [This step will reboot the system with the new kernel.] [NOTE that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.] C. Scope and recovery If you detect the network monitoring software at your site, CERT recommends following three steps to successfully determine the scope of the problem and to recover from this attack. 1. Restore the system that was subjected to the network monitoring software. The systems on which the network monitoring and/or Trojan horse programs are found have been compromised at the root level; your system configuration may have been altered. See Appendix A of this advisory for help with recovery. 2. Consider changing router, server, and privileged account passwords due to the wide-spread nature of these attacks. Since this threat involves monitoring remote connections, take care to change these passwords using some mechanism other than remote telnet, rlogin, or FTP access. 3. Urge users to change passwords on local and remote accounts. Users who access accounts using telnet, rlogin, or FTP either to or from systems within the compromised domain should change their passwords after the intruder's network monitor has been disabled. 4. Notify remote sites connected from or through the local domain of the network compromise. Encourage the remote sites to check their systems for unauthorized activity. Be aware that if your site routes network traffic between external domains, both of these domains may have been compromised by the network monitoring software. - --------------------------------------------------------------------------- The CERT Coordination Center thanks the members of the FIRST community as well as the many technical experts around the Internet who participated in creating this advisory. Special thanks to Eugene Spafford of Purdue University for his contributions. - --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Appendix A: RECOVERING FROM A UNIX ROOT COMPROMISE A. Immediate recovery technique 1) Disconnect from the network or operate the system in single- user mode during the recovery. This will keep users and intruders from accessing the system. 2) Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3) Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4) Change the password on all accounts. 5) Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. B. Improving the security of your system 1) CERT Security Checklist Using the checklist will help you identify security weaknesses or modifications to your systems. The CERT Security Checklist is based on information gained from computer security incidents reported to CERT. It is available via anonymous FTP from info.cert.org in the file pub/tech_tips/security_info. 2) Security Tools Use security tools such as COPS and Tripwire to check for security configuration weaknesses and for modifications made by intruders. We suggest storing these security tools, their configuration files, and databases offline or encrypted. TCP daemon wrapper programs provide additional logging and access control. These tools are available via anonymous FTP from info.cert.org in the pub/tools directory. 3) CERT Advisories Review past CERT advisories (both vendor-specific and generic) and install all appropriate patches or workarounds as described in the advisories. CERT advisories and other security-related information are available via anonymous FTP from info.cert.org in the pub/cert_advisories directory. To join the CERT Advisory mailing list, send a request to: cert-advisory-request@cert.org Please include contact information, including a telephone number. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Copyright (c) Carnegie Mellon University 1994 --------------------------------------------------------------------------- Appendix B: ONE-TIME PASSWORDS Given today's networked environments, CERT recommends that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. CERT has seen many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. These programs capture clear-text hostname, account name, password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password passes across the network in clear text. Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). This document provides a list of sources for products that provide this capability. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection. I. Public Domain packages S/KEY(TM) The S/KEY package is publicly available (no fee) via anonymous FTP from: thumper.bellcore.com /pub/nmh directory There are three subdirectories: skey UNIX code and documents on S/KEY. Includes the change needed to login, and stand-alone commands (such as "key"), that computes the one-time password for the user, given the secret password and the S/KEY command. dos DOS or DOS/WINDOWS S/KEY programs. Includes DOS version of "key" and "termkey" which is a TSR program. mac One-time password calculation utility for the Mac. II. Commercial Products Secure Net Key (SNK) (Do-it-yourself project) Digital Pathways, Inc. 201 Ravendale Dr. Mountainview, Ca. 94043-5216 USA Phone: 415-964-0707 Fax: (415) 961-7487 Products: handheld authentication calculators (SNK004) serial line auth interruptors (guardian) Note: Secure Net Key (SNK) is des-based, and therefore restricted from US export. Secure ID (complete turnkey systems) Security Dynamics One Alewife Center Cambridge, MA 02140-2312 USA Phone: 617-547-7820 Fax: (617) 354-8836 Products: SecurID changing number authentication card ACE server software SecureID is time-synchronized using a 'proprietary' number generation algorithm WatchWord and WatchWord II Racal-Guardata 480 Spring Park Place Herndon, VA 22070 703-471-0892 1-800-521-6261 ext 217 Products: Watchword authentication calculator Encrypting modems Alpha-numeric keypad, digital signature capability SafeWord Enigma Logic, Inc. 2151 Salvio #301 Concord, CA 94520 510-827-5707 Fax: (510)827-2593 Products: DES Silver card authentication calculator SafeWord Multisync card authentication calculator Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as other OS versions. Supports one-time passwords and super smartcards from several vendors. --------------------------------------------------------------------------- Appendix C: cpm 1.0 README FILE cpm - check for network interfaces in promiscuous mode. Copyright (c) Carnegie Mellon University 1994 Thursday Feb 3 1994 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 This program is free software; you can distribute it and/or modify it as long as you retain the Carnegie Mellon copyright statement. It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED WARRANTY of merchantability or fitness for a particular purpose. This package contains: README MANIFEST cpm.1 cpm.c To create cpm under SunOS, type: % cc -Bstatic -o cpm cpm.c On machines that support dynamic loading, such as Sun's, CERT recommends that programs be statically linked so that this feature is disabled. CERT recommends that after you install cpm in your favorite directory, you take measures to ensure the integrity of the program by noting the size and checksums of the source code and resulting binary. The following is an example of the output of cpm and its exit status. Running cpm on a machine where both the le0 and le2 interfaces are in promiscuous mode, under csh(1): % cpm le0 le2 % echo $status 2 % Running cpm on a machine where no interfaces are in promiscuous mode, under csh(1): % cpm % echo $status 0 % ------- End of Forwarded Message From ipsec-request@ans.net Sun Feb 6 09:32:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20324 (5.65c/IDA-1.4.4 for ); Sun, 6 Feb 1994 04:32:59 -0500 Received: by interlock.ans.net id AA12383 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 6 Feb 1994 04:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 6 Feb 1994 04:32:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 6 Feb 1994 04:32:46 -0500 Date: Sun, 6 Feb 1994 01:32:40 -0800 From: Phil Karn Message-Id: <199402060932.BAA20030@servo.qualcomm.com> To: crocker@tis.com Cc: ipsec@ans.net In-Reply-To: <9402022245.AA25123@tis.com> (message from Stephen D Crocker on Wed, 02 Feb 94 17:45:27 +0000) Subject: Re: IPsec near term work Steve, Sorry for the delay in following up. The ISOC conference kept me pretty busy over the past couple of days. >I believe it's entirely plausible to prototype any approach you want. >If there's trouble on this point, I would lend a hand to resolve >whatever the trouble might be. I hope you are correct, and I would welcome any assistance you can give us. Phil From ipsec-request@ans.net Sun Feb 6 22:25:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17153 (5.65c/IDA-1.4.4 for ); Sun, 6 Feb 1994 17:30:14 -0500 Received: by interlock.ans.net id AA14179 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 6 Feb 1994 17:29:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 6 Feb 1994 17:29:11 -0500 Message-Id: <199402062229.AA09055@interlock.ans.net> To: ipsec@ans.net Cc: solo@BBN.COM Subject: IPSEC KM Requirements Date: Sun, 06 Feb 94 17:25:28 -0500 From: solo@BBN.COM At the last meeting I offered to try to document the KM requirements as a means of moving forward/looking at alternatives. This is a first cut at that summary. I think we need to reach some form of agreement on our goals, particularly if we are going to consider other on-going key management efforts. In addition to the functional areas, I think other topics include general format orientation (e.g. ASN), use of X.509 certificates for identification, and other "customers" besides IPSP. Dave The purpose of this note is to summarize requirements for an Internet Key Management Protocol (IKMP), based largely on discussions during the last IETF IPSEC working group. The basic functions of the IKMP are to create, manage, and remove security associations used by the IP Security Protocol (IPSP) or other similar security protocols. A security association consists of the key(s) used for that association as well as attributes guiding the operation of the associated protocol. In particular, the IKMP is expected to handle negotiation of cryptographic algorithms, protocol format, and protocol options (e.g. security labels, integrity checks). IKMP is a management application invoked by a security protocol when it is determined that no existing security association exists which matches processing of for a PDU. Matching for IPSP may be based on a combination of addresses, security labels, and requested security services. IKMP may need to support two slightly different instances: an IKMP light which performs only the key management function for cases where the peers have already established (or assume) all the other attributes; and a full IKMP which supports negotiation of attributes and association maintenance functions. Functional requirements for IKMP include: Security Association ID (SAID) assignment (or Security Association Creation) - The SAID is the identifier used to refer to the security association. Its main use is in the clear portion of the security protocol to indicate to the receiver how to process the security PDU (e.g. what key to use). A distinct SAID exists for each direction of a security association and is generally assigned by the receiver. SAIDs are unique only for a specific receiver. The granularity of a security association depends upon the details of the security protocol, network topology, and security association attributes. An SAID may provide additional semantics such as indicating the format of the security protocol or use with multi-party (more than two) associations. Key generation/distribution - The primary function of IKMP is to establish the key(s) used by the security protocol for encryption (or other cryptographic functions). Depending upon the algorithms used, this function might transfer a key from one party to another or might support a distributed key generation process. IKMP should support both symmetric key distribution algorithms as well as asymmetric/distributed key management. The key management functions of IKMP are the basis for establishing data origin authentication services within the associated security protocol. Consequently, the IKMP processing needs to include a form of peer entity authentication. Attribute Negotiation - IKMP needs to establish the attributes used by the security protocol as well as attributes which are implicitly bound to use of the key. Attributes might include an implicit security label; protocol options (e.g. sequence numbers, integrity check functions); choice of cryptographic algorithm; association lifetime; or source/destination addresses. These exchanges may also be used to determine authorization and identification information used as part of an access control decision made either by IKMP or by IPSP (or other associated security protocol). The specific attributes to be negotiated will depend upon the specification of IPSP or other protocols which use IKMP. Terminate/Delete Association - When one party decides to delete the security association information, IKMP can be used to inform the other party(s). This is important when used with a connectionless protocol like IP and IPSP to coordinate termination. Security Association Maintenance - Maintenance functions for a security association include changing a key or changing attributes during the lifetime of an association. Such functions could be implemented either by changing the information while keeping the same SAID or by spawning a new security association. The latter option (creating new SAIDs) is far more robust and is strongly recommended. Peer Discovery and Authentication - When IPSP operates at an intermediate system, a peer IPSP entity may attempt to form a security association with an entity behind the secure IS. IKMP must include a facility whereby the initiator of the security association learns the identity of the secure IS; verifies that the intended end system is served by that particular IS; and forms or uses an appropriate security association. Recovery - IKMP needs to be able to clean up and recover from cases where the parties to a security association detect a failure (note: the detection or a failure is the responsibility of the security protocol or other protocol). The most common case is where one party has deleted the key and other security association information while the other party continues to send PDUs using that key. Mechanisms which support this recovery must be carefully reviewed with respect to denial of service concerns. Protocol Profile - To support interoperability, the protocols used by IKMP for peer exchanges need to be defined. Support might be included for both in-band and external (application level) interactions. Multiparty Associations - IKMP should support the establishment of associations between more than two parties. This might be used to support multicast, anycast, or multiple route scenarios. There are two primary implications of multiparty support: the ability to transfer SA information to multiple parties and the assignment of SAIDs. Transferring information to multiple parties can be achieved by repeating the pairwise model multiple times. The problem with SAIDs is that the general model calls for receiver generated identifiers. If there are multiple receivers, then an additional facility is needed to manage unique IDs among several parties. From ipsec-request@ans.net Mon Feb 7 15:12:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11966 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 10:19:19 -0500 Received: by interlock.ans.net id AA29619 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 10:17:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 10:17:15 -0500 Message-Id: <199402071517.AA15791@interlock.ans.net> To: pmetzger@lehman.com Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of Fri, 04 Feb 94 11:14:28 -0500. <199402041614.LAA17988@snark> Date: Mon, 07 Feb 94 10:12:30 -0500 From: Steve Kent Perry, One could do nothing more than make use of the services offered by a security protocol for end-to-end protection at layer 3, but this would ignore many of the potential security problems that arise in some mobile IP scenarios. For example, unless a host can authenticate its right to use an invariant IP address (not one assigned by the network currently providing the access service), then there are obvious denial of service vulnerabilities. There is also an option to tie such authenticated assertions into a billing scheme. Similarly, to avoid networks from claiming to be serving a given address for a mobile user, when he is actually elsewhere, one can use the basic assertion provided by the host to "convince" other networks that the service provider in question is currently authorized by the host to act as its portal into the Internet. This could be viewed as just a special case of a more general problem that, today, we address through the use of static routes. Steve From ipsec-request@ans.net Mon Feb 7 15:21:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11829 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 10:30:47 -0500 Received: by interlock.ans.net id AA34074 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 10:27:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 10:27:10 -0500 Message-Id: <199402071527.AA11030@interlock.ans.net> To: Derek Atkins Cc: ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of Fri, 04 Feb 94 14:12:43 -0500. <9402041912.AA26055@toxicwaste.media.mit.edu> Date: Mon, 07 Feb 94 10:21:43 -0500 From: Steve Kent Derek, You are right, I do tend to equate web of trust with PGP. Perhaps I have missed the published papers on that describe "web of trust" in more than casual terms. Since PGP itself has had a tendency to be defined more by its implementation, than by an implementation independent specification, this too may have lead to some of the confusion. Steve From ipsec-request@ans.net Mon Feb 7 16:39:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20391 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 11:40:38 -0500 Received: by interlock.ans.net id AA30195 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 11:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 7 Feb 1994 11:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 7 Feb 1994 11:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 7 Feb 1994 11:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Feb 1994 11:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 11:40:08 -0500 Message-Id: <199402071639.LAA04744@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: pmetzger@lehman.com, ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of "Mon, 07 Feb 1994 10:12:30 EST." <199402071517.KAA17385@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 07 Feb 1994 11:39:43 -0500 From: "Perry E. Metzger" Steve Kent says: > One could do nothing more than make use of the services > offered by a security protocol for end-to-end protection at layer 3, > but this would ignore many of the potential security problems that > arise in some mobile IP scenarios. For example, unless a host can > authenticate its right to use an invariant IP address (not one > assigned by the network currently providing the access service), then > there are obvious denial of service vulnerabilities. Sure, but why couldn't you simply use the IP security protocol to speak to the mobile's current cell router (I've forgotten the proper name) to verify your right to use the address? I don't understand why we would need a seperate protocol. > There is also an option to tie such authenticated assertions into a > billing scheme. Sure, but again, I see no legitimate reason that one would need a new security protocol to deal with this. Perry From ipsec-request@ans.net Mon Feb 7 17:06:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07899 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 12:08:27 -0500 Received: by interlock.ans.net id AA21976 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 12:06:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 7 Feb 1994 12:06:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 7 Feb 1994 12:06:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 7 Feb 1994 12:06:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Feb 1994 12:06:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 12:06:41 -0500 Message-Id: <199402071706.MAA04773@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: Derek Atkins , ipsec@ans.net Subject: Re: IPsec near term work In-Reply-To: Your message of "Mon, 07 Feb 1994 10:21:43 EST." <199402071527.AA11030@interlock.ans.net> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 07 Feb 1994 12:06:32 -0500 From: "Perry E. Metzger" Steve Kent says: > Derek, > > You are right, I do tend to equate web of trust with PGP. > Perhaps I have missed the published papers on that describe "web of > trust" in more than casual terms. There haven't been any, but that doesn't mean that the concept isn't reasonably well defined. .pm From ipsec-request@ans.net Mon Feb 7 17:00:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07904 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 12:09:07 -0500 Received: by interlock.ans.net id AA19682 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 12:07:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 12:07:10 -0500 Message-Id: <199402071707.AA30174@interlock.ans.net> To: pmetzger@lehman.com Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of Mon, 07 Feb 94 11:39:43 -0500. <199402071639.LAA04744@snark> Date: Mon, 07 Feb 94 12:00:07 -0500 From: Steve Kent Perry, The secure communication a user would establish with the local router via a IPSP would provide authentication, but would not allow the router to convince other routers, much less other autonomous systems, that the mopbile host in question was present. The requirement here is for a timely, non-repudiable statement of connectivity of bounded duration, authored by the host. Steve From ipsec-request@ans.net Mon Feb 7 17:13:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07714 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 12:14:43 -0500 Received: by interlock.ans.net id AA21797 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 12:14:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 7 Feb 1994 12:14:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 7 Feb 1994 12:14:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 7 Feb 1994 12:14:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Feb 1994 12:14:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 12:14:08 -0500 Message-Id: <199402071713.MAA04802@snark> X-Authentication-Warning: snark: Host localhost didn't use HELO protocol X-Authentication-Warning: snark: pmetzger owned process doing -bs To: Steve Kent Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of "Mon, 07 Feb 1994 12:00:07 EST." <199402071707.MAA18850@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 07 Feb 1994 12:13:59 -0500 From: "Perry E. Metzger" Steve Kent says: > Perry, > > The secure communication a user would establish with the local > router via a IPSP would provide authentication, but would not allow > the router to convince other routers, much less other autonomous > systems, that the mopbile host in question was present. Fine -- but the host could convince other routers. In any case, the key management can be the same. > The requirement here is for a timely, non-repudiable statement of > connectivity of bounded duration, authored by the host. Either that, or the remote routers could simply exchange some bytes with the host itself. Any really good protocol is going to be challenge response anyway, so the hosts might as well just set up a swIPe or similar connection with the the remote routers and exchange a few bytes if need be. The infrastructure can all be the same. Perry From ipsec-request@ans.net Mon Feb 7 17:24:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20384 (5.65c/IDA-1.4.4 for ); Mon, 7 Feb 1994 12:32:54 -0500 Received: by interlock.ans.net id AA33696 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 7 Feb 1994 12:28:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Feb 1994 12:28:59 -0500 Message-Id: <199402071728.AA21916@interlock.ans.net> To: pmetzger@lehman.com Cc: ipsec@ans.net Subject: Re: >IPSEC Charter - New Dra In-Reply-To: Your message of Mon, 07 Feb 94 12:13:59 -0500. <199402071713.MAA04802@snark> Date: Mon, 07 Feb 94 12:24:50 -0500 From: Steve Kent Perry, The normal IP model does not call for a host to communicate with other that the local router, except in case of error messages (ICMP) returned by these routers. While the development of mobile IP opens the way to make changes in our basic model, it may not be appropriate to require hosts to be cognizant of intermediate routers, especially considering the possibility of changes to the topology. A digitally signed object, asserting the link between a (mobile) host and the net that is currently serving that host, can be validated by any router, without requiring the host to know which routers might have to perform the validation. Steve From ipsec-request@ans.net Tue Feb 8 21:43:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14957 (5.65c/IDA-1.4.4 for ); Tue, 8 Feb 1994 16:58:47 -0500 Received: by interlock.ans.net id AA41345 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 8 Feb 1994 16:46:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 8 Feb 1994 16:46:08 -0500 Message-Id: <199402082146.AA40061@interlock.ans.net> To: Ran Atkinson Cc: sipp@sunroof.eng.sun.com, ipsec@ans.net, solo@BBN.COM Subject: Re: SIPP Security I-ds In-Reply-To: Your message of Thu, 27 Jan 94 16:43:36 -0500. <9401272143.AA15507@itd.nrl.navy.mil> Date: Tue, 08 Feb 94 16:43:32 -0500 From: solo@BBN.COM Ran, I've looked at the ESP and AP drafts you circulated. My first question is why this needs to be distinct from the IPSP effort. It seems to me that both are trying to define a simple (but possibly extensible) network layer encapsulation protocol which might be used with any IP style protocol (IPv4, IPng, etc.). In that vein, it seems to me that this draft (or a subtle variant) would also serve well as a candidate for progressing discussions in the IPSP context. The following comments have, therefore, somewhat of a dual nature and I've included the ipsec list. Dave ESP Section 1.1. You describe here a model which states that ESP must encapsulate a complete SIPP datagram (i.e. SIPP-ESP-SIPP-payload), while in sectio 5, you describe how SIPP-ESP-payload may be appropriate for end systems. I agree that the two cases are both appropriate, but wanted to understand your intent regarding when and how the two cases are selected. Section 3.1/SAID In the multicast case, even if I have a separate SAID and key for each originator, I cannot authenticate the sender. To support multicast, each recipient must hold the key of each of the originators. Assuming symmetric keys for ESP encryption, this means that any member of the group can masquerade as any other member of the group. Without dropping back to asymmetric techniques, you might as well have a single group SAID. Section 3.1/Pad I don't understand the placement. For a cryptographic pad to work, it needs to be part of the ciphertext. Section 3.2/Sequence Numbers The field is optional, so I won't complain too loudly, but I strongly dislike sequence numbers in a connectionless network layer protocol. I think the processing and related rules are more likely to disrupt than enhance service. As part of an overall architecture, I advocate pushing replay detection to the transport protocol or application which is concerned rather than placing the service in the network layer. Section 3.2 In addition to the fields you list, and based on IPSP drafts, have you considered a length field? Also, I believe that a security label within the protocol is a useful option, especially where you are tightly coupling access control decisions with the SA. You also have not discussed an integrity check (see AP comment below). Section 5/Labels I think this discussion highlights some of the reasons for including an optional label in ESP/IPSP. For certain environments where the enclave is treated as a whole, the label for security protocol processing may be different than that contained in the encapsulated SIPP datagram. AP I don't believe this needs to be a separate payload/protocol than the ESP. One of the features of IPSP is the inclusion of an ICV. This can be a simple checksum, MAC, or signature style of check and can accommodate the services you describe for AP. Since the services used on a particular security association are negotiated (or at least variable) a single protocol/payload specification can support authentication only, confidentiality only, or both. With recursive encapsulation I can even decouple them. On the other hand, by forcing them to be separate, I pay an overhead and performance penalty for the common case where I want both services since you have omitted an integrity check from ESP. From ipsec-request@ans.net Thu Feb 10 13:34:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11859 (5.65c/IDA-1.4.4 for ); Thu, 10 Feb 1994 08:35:28 -0500 Received: by interlock.ans.net id AA38472 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 10 Feb 1994 08:34:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 10 Feb 1994 08:34:54 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 10 Feb 1994 08:34:54 -0500 Date: Thu, 10 Feb 1994 14:34:11 +0100 X400-Originator: Pal.Hoff@TF.tele.no X400-Recipients: ipsec@ans.net X400-Mts-Identifier: [/PRMD=tele/ADMD=TELEMAX/C=NO/;1697 94/02/10 14:34] From: Pal.Hoff@TF.tele.no Message-Id: <"1697 94/02/10 14:34*/G=Pal/S=Hoff/O=TF/PRMD=tele/ADMD=TELEMAX/C=NO/"@MHS> To: ipsec@ans.net Subject: Comments on IPSP Dear IPSEC-ers, I was made aware of the IPSEC effort at the ISSNDSS '94 conference in San Diego. After that I have spent a few hours browsing through the IPSEC archive retrieved from ftp.ans.net. Personally, I have been working with IP security for two years as the leader of a project developing an IP encryption device based on the SDNS Security Protocol 3. This device may either act as an end system or as a router with integrated encryption functions. The primary objective in the project was to develop a device to be used for secure LAN interconnection. The results of this work was presented at the ISSNDSS '94. With this background, I would like to offer my comments on some of the work and proposed protocols in the IPSEC working group. 1) Comments on the swIPe protocol: - It is unclear why the author introduces an additional protocol type (the IPPROTO_SWIPE). Maybe the idea behind this was to leave the IP input routine unchanged and to add SWIPE as a new protocol that IP may include in it's protocol switch for higher layer protocols. However, the protocol type field of the IP header cannot be trusted, so such an implementation architecture would provide an intruder with a very easy way of bypassing the securiy functions. I assume therefore that the "policy engine" of the swIPe prototype uses other information (such as src and dst IP address) to decide what to do with a received packet. Note that it will always be necessary to change the IP input code to avoid bypass problems, so I can see no justification for introducing the IPPROTO_SWIPE protocol type. - The swIPe protocol claims to support a "wide variety" of crypto systems. Well, this wide variety actually excludes all stream ciphers. If you use a stream-cipher, you will have to carry some use-and-discard crypto synchronization per packet, such as a random IV or an encrypted random packet encryption key. There is no room for this in the swIPe header. - The packet sequence number of swIPe introduces a semantical problem, since an IP protocol engine does not know which transport connection a given datagram belongs to. The architecturally clean way to protect against replay is to include sequence numbers in higher layer protocols, as these will automatically be protected by the integrity mechanisms implemented in the IP security protocol. All this talk about sequence numbering in IPSP is, in my opinion, approximately nonsense. - I don't like the placement of the authenticator as a part of the protocol header. Place it at the end of the packet in stead, like in SP3 and NLSP-CL. This will ease the cryptographic processing of the PDU in many cases. - A good thing about swIPe is that it its header is word aligned. When we implemented SP3, we discovered that unless the header of the transport layer protocol (UDP of TCP) started on a 32-bit boundary, the OS panic'ed with "bus error" due to alignment problems (This was a Sparcstation 2 running SunOS 4.1.2). Of course, there are workarounds, but word alignment is a good idea and will be applauded by implementors. 2) Comments on key management: In our prototype, we solved the problem of key mangament in a way that I have not seen among the suggestions in the ipsec mailing list. We simply defined an enterprise specific MIB branch for encryption keys, the data type of the key information being OPAQUE as seen from the SNMP agent, who passes the value-part of a variable binding transparently to a hardware crypto module (HCM). The value-part of the variable binding represent a packet as defined by the HCM interface for setting keys, erasing keys etc. As such, the SNMP protocol was only used as a "bucket" protocol for exchange of general purpose data. Of course the packet format and "protocol" for exchanging data between the HCM and the host machine must be designed to counter threats like key disclosure, key corruption, replay etc. As an example, this may be an ANXI X9.17 interface. It actually works fine, although it admittedly has some weaknesses like limited opportunities of error reports etc. 3) Comment on the need for a new layer 3 security protocol: As Paul Lambert said at the ISSNDSS '94 no flaws or errors has been detected that makes SP3 unsuitable or inappropriate for use as a security protocol for IP. Also, there are several commercial network encryption products available using SP3. SP3 therefore seems a very good starting point for SPIP, may be it is enough to do write an "Internet SP3 profile" e. g. to ensure word alignment, or maybe it's necessary to change the semantics of the KeyID field to something like an SAID with the capability of optionally carrying crypto sync. The first NLSP-CL draft was generated by doing :s/SP3/NLSP-CL/g on the SP3 specification document. Unfortunately, the standardization process did not stop with that. 4) Question on the IToR flag: I would like to have a rather detailed explanation of the use of the Initiator-ro-reponder flag. I have never understood it's use, nor the "reflection" threat that I have seen mentioned various places. In our "trusted router" prototype we ignore the IToR flag completely. 5) The above comments are my personal views, and do not necessary conform to those of my company. Regards, Paal Hoff, Norwegian Telecom Research. e-mail: pal.hoff@tf.tele.no X.400: g=pal;s=hoff;o=tf;p=tele;a=telemax;c=no phone: +47 63 80 93 36 fax: +47 63 81 00 76 From ipsec-request@ans.net Thu Feb 10 14:52:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14985 (5.65c/IDA-1.4.4 for ); Thu, 10 Feb 1994 09:54:03 -0500 Received: by interlock.ans.net id AA33266 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 10 Feb 1994 09:53:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 10 Feb 1994 09:53:11 -0500 Message-Id: <199402101453.AA42222@interlock.ans.net> To: ipsec@ans.net Cc: solo@BBN.COM Subject: Authenticated PDUs Date: Thu, 10 Feb 94 09:52:52 -0500 From: solo@BBN.COM Some recent discussions on the SIPP list triggered some thoughts about authenticated datagrams. I believe that we have talked about IPSP as a general encapsulation service at the network layer which would also support authenticated network datagrams - making the "ICV" an authenticator and not encrypting the datagram at all. (of course, maybe this is out of scope of the group, in which case, it doesn't matter). Anyway, For encryption services, there is an explicit security association formed and all the information needed to process security PDUs is implicit in the SAID. These parameters are determined during SA establishment. (By the way, I've started lobbying to make some of the information, especially protocol options, explicitly indicated in the SAID - creating a partial SAID syntax.) For authenticated PDUs, I'm not sure the same argument holds. If I am using the protocol to authenticate information used by intermediate systems (I believe this is an essential requirement), then I don't know who the peers will be. In the case of firewalls, this is important because it allows the firewall to know with confidence who the originator of the datagram is. Consequently, the PDU must carry sufficient information to allow an arbitrary system to validate the check. This is similar to the PEM distinction between encrypted and signed messages where encrypted messages have per-recipient tokens while signed messages can be processed by anyone. I can imagine this working only for asymmetric based authentication since symmetric, MAC, style schemes require some external management which mirrors SA establishment. In order to keep within the encapsulation paradigm, for authenticated datagrams, I think we need to define a "global" SAID. This SAID is used to denote an authentication algorithm which permits validation by any network entity and explicitly indicates the algorithm used. If we follow this path, then along with support for multiparty associations (multicast, anycast); efficient demultiplexing and protocol processing, I think we need to discuss the management of SAID space. Dave From ipsec-request@ans.net Fri Feb 18 10:09:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15854 (5.65c/IDA-1.4.4 for ); Fri, 18 Feb 1994 05:51:29 -0500 Received: by interlock.ans.net id AA20109 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 18 Feb 1994 05:12:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Feb 1994 05:12:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Feb 1994 05:12:36 -0500 Date: Fri, 18 Feb 1994 11:09:07 +0100 From: Paal Hoff Message-Id: <199402181009.AA14948@hal.nta.no> To: ipsec@ans.net Subject: Comments on IPSEC work Dear IPSEC-ers, I was made aware of the IPSEC effort at the ISSNDSS '94 conference in San Diego. After that I have spent a few hours browsing through the IPSEC archive retrieved from ftp.ans.net. Personally, I have been working with IP security for two years as the leader of a project developing an IP encryption device based on the SDNS Security Protocol 3. This device may either act as an end system or as a router with integrated encryption functions. The primary objective in the project was to develop a device to be used for secure LAN interconnection. The results of this work was presented at the ISSNDSS '94. With this background, I would like to offer my comments on some of the work and proposed protocols in the IPSEC working group. 1) Comments on the swIPe protocol: - It is unclear why the author introduces an additional protocol type (the IPPROTO_SWIPE). Maybe the idea behind this was to leave the IP input routine unchanged and to add SWIPE as a new protocol that IP may include in it's protocol switch for higher layer protocols. However, the protocol type field of the IP header cannot be trusted, so such an implementation architecture would provide an intruder with a very easy way of bypassing the securiy functions. I assume therefore that the "policy engine" of the swIPe prototype uses other information (such as src and dst IP address) to decide what to do with a received packet. Note that it will always be necessary to change the IP input code to avoid bypass problems, so I can see no justification for introducing the IPPROTO_SWIPE protocol type. - The swIPe protocol claims to support a "wide variety" of crypto systems. Well, this wide variety actually excludes all stream ciphers. If you use a stream-cipher, you will have to carry some use-and-discard crypto synchronization per packet, such as a random IV or an encrypted random packet encryption key. There is no room for this in the swIPe header. - The packet sequence number of swIPe introduces a semantical problem, since an IP protocol engine does not know which transport connection a given datagram belongs to. The architecturally clean way to protect against replay is to include sequence numbers in higher layer protocols, as these will automatically be protected by the integrity mechanisms implemented in the IP security protocol. All this talk about sequence numbering in IPSP is, in my opinion, approximately nonsense. - I don't like the placement of the authenticator as a part of the protocol header. Place it at the end of the packet in stead, like in SP3 and NLSP-CL. This will ease the cryptographic processing of the PDU in many cases. - A good thing about swIPe is that it its header is word aligned. When we implemented SP3, we discovered that unless the header of the transport layer protocol (UDP of TCP) started on a 32-bit boundary, the OS panic'ed with "bus error" due to alignment problems (This was a Sparcstation 2 running SunOS 4.1.2). Of course, there are workarounds, but word alignment is a good idea and will be applauded by implementors. 2) Comments on key management: In our prototype, we solved the problem of key mangament in a way that I have not seen among the suggestions in the ipsec mailing list. We simply defined an enterprise specific MIB branch for encryption keys, the data type of the key information being OPAQUE as seen from the SNMP agent, who passes the value-part of a variable binding transparently to a hardware crypto module (HCM). The value-part of the variable binding represent a packet as defined by the HCM interface for setting keys, erasing keys etc. As such, the SNMP protocol was only used as a "bucket" protocol for exchange of general purpose data. Of course the packet format and "protocol" for exchanging data between the HCM and the host machine must be designed to counter threats like key disclosure, key corruption, replay etc. As an example, this may be an ANXI X9.17 interface. It actually works fine, although it admittedly has some weaknesses like limited opportunities of error reports etc. 3) Comment on the need for a new layer 3 security protocol: As Paul Lambert said at the ISSNDSS '94 no flaws or errors has been detected that makes SP3 unsuitable or inappropriate for use as a security protocol for IP. Also, there are several commercial network encryption products available using SP3. SP3 therefore seems a very good starting point for SPIP, may be it is enough to do write an "Internet SP3 profile" e. g. to ensure word alignment, or maybe it's necessary to change the semantics of the KeyID field to something like an SAID with the capability of optionally carrying crypto sync. The first NLSP-CL draft was generated by doing :s/SP3/NLSP-CL/g on the SP3 specification document. Unfortunately, the standardization process did not stop with that. 4) Question on the IToR flag: I would like to have a rather detailed explanation of the use of the Initiator-ro-reponder flag. I have never understood it's use, nor the "reflection" threat that I have seen mentioned various places. In our "trusted router" prototype we ignore the IToR flag completely. 5) The above comments are my personal views, and do not necessary conform to those of my company. Regards, Paal Hoff, Norwegian Telecom Research. e-mail: pal.hoff@tf.tele.no X.400: g=pal;s=hoff;o=tf;p=tele;a=telemax;c=no phone: +47 63 80 93 36 fax: +47 63 81 00 76 From ipsec-request@ans.net Fri Feb 18 17:15:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14889 (5.65c/IDA-1.4.4 for ); Fri, 18 Feb 1994 12:24:47 -0500 Received: by interlock.ans.net id AA15621 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 18 Feb 1994 12:15:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 18 Feb 1994 12:15:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 18 Feb 1994 12:15:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Feb 1994 12:15:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Feb 1994 12:15:54 -0500 Message-Id: <9402181715.AA19029@andria.lehman.com> To: Paal Hoff Cc: ipsec@ans.net Subject: Re: Comments on IPSEC work In-Reply-To: Your message of "Fri, 18 Feb 1994 11:09:07 +0100." <199402181009.AA14948@hal.nta.no> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 18 Feb 1994 12:15:18 -0500 From: "Perry E. Metzger" Paal Hoff says: > 1) Comments on the swIPe protocol: > > - It is unclear why the author introduces an additional protocol > type (the IPPROTO_SWIPE). Because the concept of swIPe is to provide security via encapsulation, so that existing IP implementations can transparently interoperate with secure routers and systems. > Maybe the idea behind this was to > leave the IP input routine unchanged and to add SWIPE as a > new protocol that IP may include in it's protocol switch for > higher layer protocols. I don't believe that implementation concerns played a part. I think it was the notion of IP in IP encapsulation for security that played a part. IP encapsulation allows one to shield against traffic analysis, do secure bridging, secure connections between hosts, etc, all with one simple and elegant paradigm. It easily accomodates multiple levels of security policy and other nice features -- two hosts can be connected by a secure connection and the connection might have a secured link in it without their needing to know and without the routers implementing the secured link needing to worry. > However, the protocol type field of the IP header cannot be > trusted, so such an implementation architecture would provide > an intruder with a very easy way of bypassing the securiy > functions. I'm sorry, but I don't understand why this would be the case at all. Assuming that your implementation is properly constructed, it would not be trusting IP header contents to be correct and would only accept swIPe packets as having been definatively authenticated. In particular, a proper implementation will not accept non-authenticated packets for a hostpair/protocol/port tuple that is already being handled by a secure policy. > I assume therefore that the "policy engine" of the swIPe prototype > uses other information (such as src and dst IP address) to decide > what to do with a received packet. This is not an "assumption" that you need to make -- that should be extremely clear from the design. > Note that it will always be necessary to change the IP input code > to avoid bypass problems, so I can see no justification for > introducing the IPPROTO_SWIPE protocol type. As I noted, the whole notion is security via secure encapsulation. Thats why you need the protocol. > - The swIPe protocol claims to support a "wide variety" of crypto > systems. Well, this wide variety actually excludes all stream > ciphers. I see no reason that this should be the case. > If you use a stream-cipher, you will have to carry > some use-and-discard crypto synchronization per packet, such as > a random IV or an encrypted random packet encryption key. > There is no room for this in the swIPe header. It needn't be in the header. If a policy is to be implemented with a stream cypher, the first bytes of the packet itself might contain the needed synchronizing information apart from the swIPe header qua swIPe header. Bits are bits, you know. swIPe does not overspecify the contents of the packet itself -- some of that can be handled on a per encryption system/policy basis. > - The packet sequence number of swIPe introduces a semantical > problem, since an IP protocol engine does not know which transport > connection a given datagram belongs to. So? > The architecturally clean way to protect against replay is to > include sequence numbers in higher layer protocols, These have not to my knowledge been abolished, you know. > 3) Comment on the need for a new layer 3 security protocol: > > As Paul Lambert said at the ISSNDSS '94 no flaws or errors > has been detected that makes SP3 unsuitable or inappropriate > for use as a security protocol for IP. Does being big and ugly and inflexible count? One of the things I like about swIPe is that its extremely simple and still potent. Minimal changes to the way we do business yield an extremely flexible and powerful mechanism on which to implement secure networks. I find short specification documents and simple design to be an enormous feature, especially in discussing security. As Marcus Ranum has mentioned more than once, anything too big to keep in your head at once is too big to trust. If you can't recall all the details of the spec off the top of your head, the system is too big to ever be truly bug free. Perry From ipsec-request@ans.net Wed Feb 23 22:18:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16861 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 16:09:29 -0500 Received: by interlock.ans.net id AA08127 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 16:02:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 28 Feb 1994 16:02:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 16:02:34 -0500 Date: Wed, 23 Feb 1994 14:18:59 -0800 Message-Id: <199402282102.NAA00777@servo.qualcomm.com> To: iab-retreat@isi.edu Cc: mobile-ip@ossi.com, ipsec@ans.net From: karn@qualcomm.com (Phil Karn) X-Attachments: At the IAB retreat and elsewhere, several people said that confidentiality (e.g., encryption) and authentication are separable, orthogonal issues. This didn't sit right with me, and I think I know why. Although encryption and authentication may be orthogonal in a theoretical sense, in practice this is not always true. In particular, encryption at some lower level than end-to-end is often a highly pragmatic substitute for end-to-end authentication. It can certainly be easier to deploy quickly. For example, in the terminal room at the last IETF I ran software on my laptop that constructed an encrypted IP tunnel back to my company's network. This let me access any machine on that network, including the vast majority that accept only ordinary passwords, without any passwords appearing in the clear outside the company. Setting up a secure tunnel is easy, since only one machine back on the company network (the other end of the tunnel) is aware of it. It decrypts incoming packets and routes them back out to the net. The other hosts couldn't care less. Without encryption I would have had no real choice but to install some form of secure end-to-end authentication (eg, S/KEY) on *every* machine I wanted to access remotely. Of course, I could have installed S/KEY on only one machine and then set up /etc/hosts or .rhosts entries on all the other machines to trust the S/KEY machine, but everyone knows how dangerous a permissive /etc/hosts file can be. (A moral here is that simply clamping down on .rhosts files can actually *worsen* security if it merely forces people to type their passwords in the clear over untrusted networks that much more often.) So I think encryption has a very important role to play in quickly dealing with the problem of plaintext passwords on the net. And the NSA deserves a lot of the blame for the present sorry state of internet security; they may try to distinguish between crypto for authentication and crypto for privacy, but the near-term practical distinction is bogus. Phil From ipsec-request@ans.net Mon Feb 28 21:42:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13943 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 17:01:39 -0500 Received: by interlock.ans.net id AA16534 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 16:44:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 28 Feb 1994 16:44:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 28 Feb 1994 16:44:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 28 Feb 1994 16:44:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 16:44:42 -0500 Message-Id: <9402282143.AA10246@andria.lehman.com> To: karn@qualcomm.com (Phil Karn) Cc: iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Wed, 23 Feb 1994 14:18:59 PST." <199402282102.NAA00777@servo.qualcomm.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 28 Feb 1994 16:42:55 -0500 From: "Perry E. Metzger" Phil Karn says: > At the IAB retreat and elsewhere, several people said that > confidentiality (e.g., encryption) and authentication are separable, > orthogonal issues. This didn't sit right with me, and I think I know > why. > > Although encryption and authentication may be orthogonal in a > theoretical sense, in practice this is not always true. In particular, > encryption at some lower level than end-to-end is often a highly > pragmatic substitute for end-to-end authentication. It can certainly be > easier to deploy quickly. I fully agree with Phil. Indeed, low level authentication is often accomplished with cryptographically signed cryptographic hashes, which is at least as expensive in the general case as fully encrypting the entire link. In general, if you have confidentiality, you have authentication since an interposer couldn't forge the packets, and if you have true authentication (that is, constant for the session and not just at the beginning of the session with the assumption that the session can't be hijacked), you have to use something that is likely cryptographic in nature and as expensive as confidentiality would be. Perry From ipsec-request@ans.net Mon Feb 28 22:02:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15870 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 17:19:20 -0500 Received: by interlock.ans.net id AA16563 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 17:06:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 17:06:20 -0500 Message-Id: <199402282206.AA15535@interlock.ans.net> To: pmetzger@lehman.com Cc: Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of Mon, 28 Feb 94 16:42:55 -0500. <9402282143.AA10246@andria.lehman.com> Date: Mon, 28 Feb 94 17:02:49 -0500 From: Steve Kent Perry, I think you may have misinterpreted Phil's point. The use of a signed or encrypted hash, at any layer, is still an application of crypto for autehntication and integrity and thus subject to different export controls than crypto useful for generic confidentiality. Phil's point was that use of confidentiality in bulk (e.g., at lower layers) can be used to provide some security for password-based user authentication with limited deployment problems. In contrast, end-to-end authentication technology requires widespread deployment to provide fine-grained protection. Confidentiality is applied in many link layer contexts without benefit of cryptographic authentication. However, depending on the mode of use of cryptography, and the underlying error detection mechanism, your statement about confidentiality being equivalent to crypto-based authentication may be false. For example, use of DES in OFB mode offers no protection against modification (through unpredictable error propagation) and thus it would be feasible for an attacker to modify valid, encrypted messages to yield encrypted messages that also would pass the non-cryptographic integrity checks employed in our network protocols. Steve From ipsec-request@ans.net Mon Feb 28 22:32:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16746 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 17:42:50 -0500 Received: by interlock.ans.net id AA04299 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 17:33:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 28 Feb 1994 17:33:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 17:33:27 -0500 Date: Mon, 28 Feb 1994 14:32:53 -0800 From: Phil Karn Message-Id: <199402282232.OAA01084@servo.qualcomm.com> To: kent@BBN.COM Cc: pmetzger@lehman.com, iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: <199402282206.AA06971@venera.isi.edu> (message from Steve Kent on Mon, 28 Feb 94 17:02:49 -0500) >benefit of cryptographic authentication. However, depending on the >mode of use of cryptography, and the underlying error detection >mechanism, your statement about confidentiality being equivalent to >crypto-based authentication may be false. For example, use of DES in >OFB mode offers no protection against modification (through "Doctor, it hurts when I do that." "Then don't do that!" So don't use OFB, use CFB! It's certainly the DES mode I use most often. My original point remains: bulk encryption is often much easier to deploy, and gives considerably more "bang for the buck", than end-to-end authentication. It seems pretty clear to me that had encrypted IP tunnels been in widespread use, the Internet's recent passive monitoring attacks would have been much less successful. Your other comment about Kerberos with authentication being okay for export also misses the point. Would you like to come and install authentication-only Kerberos on *all* of my company's computers so I can access them securely from overseas without having to violate ITAR by carrying my encrypted IP tunnel software out of the US? Phil From ipsec-request@ans.net Mon Feb 28 23:04:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21010 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 18:12:56 -0500 Received: by interlock.ans.net id AA15599 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 18:05:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 18:05:31 -0500 Message-Id: <199402282305.AA27371@interlock.ans.net> To: Phil Karn Cc: iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of Mon, 28 Feb 94 14:32:53 -0800. <199402282232.OAA01084@servo.qualcomm.com> Date: Mon, 28 Feb 94 18:04:15 -0500 From: Steve Kent Phil, I gave a specific example of why Perry's general assertion was untrue. That is a valid refutation of his assertion, period. While bulk encryption is easier to deploy that end-to-end encryption or authentication, it does not provide the same level of protection. Bulk encryption works best between sites that want communicate securely, e.g., distributed offices of an organization. However, in an environment where much of the communication is between a wide range of sites with varying degrees of local security, the utility of bulk encryption is lower. If a typical Internet site communicates with a wide range of other sites (e.g., for mail transport and WWW purposes), then it becomes less practical to employ bulk encryption for much of the traffic. Also, some folks concerned about net management have expressed concern that encryption, vs. authentication, will make it harder to diagnose some problems due to concealment of (IP and TCP) header info by IP layer encapsulation security protocols. There are tradeoffs. Steve From ipsec-request@ans.net Mon Feb 28 23:54:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17301 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 18:58:18 -0500 Received: by interlock.ans.net id AA12441 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 18:55:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 28 Feb 1994 18:55:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 28 Feb 1994 18:55:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 28 Feb 1994 18:55:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 18:55:40 -0500 Message-Id: <9402282354.AA10322@andria.lehman.com> To: Steve Kent Cc: pmetzger@lehman.com, Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Mon, 28 Feb 1994 17:02:49 EST." <199402282206.RAA16535@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 28 Feb 1994 18:54:04 -0500 From: "Perry E. Metzger" Steve Kent says: > I think you may have misinterpreted Phil's point. The use of > a signed or encrypted hash, at any layer, is still an application of > crypto for autehntication and integrity and thus subject to different > export controls than crypto useful for generic confidentiality. Perhaps I did misinterpret him a bit, but I frankly don't care about export controls, and neither should anyone else in this context. Not all of the world is run by the NSA. Outside the US there are plenty of smart people that can reimplement the cryptography specified any RFCs we produce, in spite of the pretense on the part of our "friends" in Washington that only Americans can implement cryptography software from specs. There is thus no reason to limit ourselves in any way. > Confidentiality is applied in many link layer contexts without > benefit of cryptographic authentication. However, depending on the > mode of use of cryptography, and the underlying error detection > mechanism, your statement about confidentiality being equivalent to > crypto-based authentication may be false. For example, use of DES in > OFB mode offers no protection against modification (through > unpredictable error propagation) Thats true, which is why checksums, CRCs, MD5s, etc, were invented. One always encrypts them if possible. They end up being a natural part of algorithms like swIPe -- they are built in by happy coincidence because the underlying protocols will checksum and they get encapsulated. In any case, OFB is a strange special case, and shouldn't be used anyway except under unusual circumstances -- and even then if one is talking about IP security one can presumably checksum. Perry From ipsec-request@ans.net Mon Feb 28 23:59:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13872 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 19:09:21 -0500 Received: by interlock.ans.net id AA28356 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 28 Feb 1994 19:01:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 28 Feb 1994 19:01:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 28 Feb 1994 19:01:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 28 Feb 1994 19:01:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 28 Feb 1994 19:01:01 -0500 Message-Id: <9402282359.AA10335@andria.lehman.com> To: Steve Kent Cc: Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Mon, 28 Feb 1994 18:04:15 EST." <199402282305.AA27371@interlock.ans.net> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 28 Feb 1994 18:59:31 -0500 From: "Perry E. Metzger" Steve Kent says: > I gave a specific example of why Perry's general assertion was > untrue. That is a valid refutation of his assertion, period. Huh? > However, in an environment where much of the communication is between > a wide range of sites with varying degrees of local security, the > utility of bulk encryption is lower. If a typical Internet site > communicates with a wide range of other sites (e.g., for mail > transport and WWW purposes), then it becomes less practical to employ > bulk encryption for much of the traffic. So use something like swIPe and not "bulk encryption". Who was proposing bulk encryption? Perry