From ipsec-request@ans.net Mon Aug 1 13:52:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48301 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 10:18:44 -0400 Received: by interlock.ans.net id AA03853 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 09:45:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 09:45:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 09:45:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 09:45:41 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408010852.ZM11630@hughes.network.com> Date: Mon, 1 Aug 1994 08:52:24 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: IPSEC@ans.net Subject: Ipsec Review postscript article. Cc: LINEHAN@watson.ibm.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Here is our first contribution. >From LINEHAN@watson.ibm.com: The review of IP security protocols is in ftp.network.com directory IETF/IPSEC as ipsec_review.ps. Here's the abstract: This paper discusses the concept of applying cryptographic techniques at the network layer of a communications system, and reviews and compares several proposals that have been made to the IPSEC working group of the IETF. This file can be accessed via anonymous FTP or WWW. The WWW interface is ftp://ftp.network.com/IETF/IPSEC/ipsec_review.ps Jim From ipsec-request@ans.net Mon Aug 1 14:51:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44622 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 11:21:25 -0400 Received: by interlock.ans.net id AA14852 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 10:51:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 10:51:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 10:51:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 10:51:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 10:51:23 -0400 Message-Id: <9408011451.AA07640@snark.imsi.com> To: ipsec@ans.net Subject: Internet Draft Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 Aug 1994 10:51:14 -0400 From: "Perry E. Metzger" Rough versions of documentation for the IPSP proposal that received consensus at the working group meeting should be done within a few days to a week. I'll be circulating copies to this list for comment before we send things to be posted as internet drafts. There was some last minute argument from the IPv6 folks who apparently thought that the opaque encapsulation was not 64 bit aligned, but since it was designed specifically with 64 bit alignment needs in mind that shouldn't actually pose an obstacle. I'm very glad that we all more or less came to agreement and can get on beyond the packet encapsulation formats and start dealing with the really hard problem, key management. Perry From ipsec-request@ans.net Mon Aug 1 07:37:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39332 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 12:04:39 -0400 Received: by interlock.ans.net id AA22117 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 11:37:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 11:37:24 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 11:37:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 11:37:24 -0400 Date: Mon, 1 Aug 94 11:37:50 EDT Message-Id: <9408011537.AA27972@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: John Linn (by way of shirey@mitre.org (Robert W. Shirey)) Subject: Query re work on GSS-API extensions for store-and-fwd support FYI. Please not part about IEEE 802.10c key management. -Rob- ------------ CAT fanciers: Late in one of last week's CAT sessions, I noted that I'd received a query about whether there would be interest within our forum in defining store-and-forward messaging support primitives for use in conjunction with GSS-API. In the interests of further detail, and for the benefit of anyone on the mailing list who wasn't in the room at the time, I attach (with permission) an excerpted message from Dave Gomberg of Mitre, a member of the ISO/IEC JTC 1/SC21 WG8 security group. They're interested in making use of other ongoing work in this area if available, but may take the task on themselves if no other work in this area is progressing. My view is that store-and-forward protection facilities (probably operating directly with credentials rather than security contexts, given that security contexts aren't multicast and are designed for association-oriented, timely delivery environments) would be well-formed additions for use with GSS-API, but I don't know what level of interest exists within CAT or the broader IETF to pursue this. Comments hereby solicited. --jl Excerpt from Dave Gomberg's message follows: I'm writing to you on behalf of the ISO/IEC JTC 1/SC21 WG 8 Security folks currently meeting at Southampton, UK. As you may be aware, we have recently begun work on a new project originally titled Authentication and Related Security Services, retitled (at this meeting) Security Association Management and Support (SAMS). It was agreed early on that we would use as the basis of the initial draft IEEE 802.10c key management, the ECMA Authentication Privilege Attribute Security Application, and the GSS-API. Our current discussions have noted that there is a requirement to support "store and forward" application needs, but that none of the base documents deal with this area. We are attempting to crate a model that, so far, has accounted only for the non-store and forward case. We need to include a model and interfaces and mechanisms to cover the store and forward cases. We include here not only the obvious cases of e-mail and file store/retrieval, but any situation where it is necessary to bind security information to a protected information object so that an entity (including the originator) may obtain the information object content at some time after the protection has been applied. One of the areas that will need extension or modification or re-interpretation for this purpose is the GSS-API. From ipsec-request@ans.net Mon Aug 1 16:20:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02374 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 12:39:25 -0400 Received: by interlock.ans.net id AA05537 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 12:14:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 12:14:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 12:14:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 12:14:00 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408011120.ZM12132@hughes.network.com> Date: Mon, 1 Aug 1994 11:20:51 -0500 In-Reply-To: "Perry E. Metzger" "Internet Draft" (Aug 1, 10:51am) References: <9408011451.AA07640@snark.imsi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net Subject: SIPP and SKIP. 2 subjects. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 As was discussed at the IETF, the SIPP encapsulation was a concensus.... The only change was a version field of 4 bits. First subject. In thinking about the compatibility of SKIP (with its implicit key exchange) with explicit key management, it seemed that SIPP encapsulation would require that the version be used to differentiate SAIDs that were generated by explicit key management and packets that use implicit key exchange of SKIP. I would suggest that 2 versions be generated, 0b0000 = SKIP 0b0001 = Explicit key management. 0b0010 - 0b1111 = Reserved. Second subject. In SKIP, could the overhead be reduced even further if the SAID was used cache the session key (Kp) and, if the stream offset (IV or other per packet info) were in the clear, then DES would not usually be needed at all on a per block basis. DES would only be needed if Kp (and the SAID changes). In SKIP, the SAID could be a one way random identifier. jim From ipsec-request@ans.net Mon Aug 1 17:36:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14679 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 14:23:12 -0400 Received: by interlock.ans.net id AA14677 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 13:49:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 13:49:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 13:49:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 13:49:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 13:49:11 -0400 Message-Id: <9408011736.AA08523@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Mon, 01 Aug 1994 11:20:51 CDT." <9408011120.ZM12132@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 Aug 1994 13:36:12 -0400 From: "Perry E. Metzger" James P. Hughes says: > In thinking about the compatibility of SKIP (with its implicit key > exchange) with explicit key management, it seemed that SIPP > encapsulation would require that the version be used to > differentiate SAIDs that were generated by explicit key management > and packets that use implicit key exchange of SKIP. The model we developed holds that SAIDs are assigned at the pleasure of the recipient. (Actually, for multicast purposes thats the pleasure of the entity controlling the address.) SKIP has several good features that should be incorporated in any key management protocol that is standardized on, but I think that purely implicit key management is not one of them. Explicitly assigning a security identifier is a cheap operation. Once assigned, a particular SAID might identify all subsequent packets bearing it as SKIP-style "implicit key exchange" encrypted packets. However, I'm very reluctant to support use of the four bit version field (which in the draft I am defining as an Must Be Zero field, at least for the moment) for this purpose, since it seems that the same purpose can be cheaply achieved without using the version space. Using the version number seems to just be a way to end-run around assigning a SAID for the purpose, which, as I said, is cheap. > In SKIP, could the overhead be reduced even further if the SAID was > used cache the session key (Kp) and, if the stream offset (IV or > other per packet info) were in the clear, then DES would not usually > be needed at all on a per block basis. DES would only be needed if > Kp (and the SAID changes). In SKIP, the SAID could be a one way > random identifier. The intention of the scheme we came up with was that particular security associations would be identified via the SAID and the SAID alone, but that the security transformation associated with the security association could use the encapsulated part of the packet in any manner it liked provided that 1) it is standardized for that transformation so that interoperable implementations are possible and 2) that the result of inverting the security transform was a 64 bit aligned packet (this being demanded by the IPv6 people). Anything that needs to be conveyed with the packet, be it a sequence number, an IV, or anything else that is not purely a SAID, is supposed to be contained in the encapsulated area in a security transformation dependant way. Perry From ipsec-request@ans.net Mon Aug 1 17:47:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39302 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 14:28:52 -0400 Received: by interlock.ans.net id AA28033 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 13:52:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 13:52:29 -0400 Message-Id: <199408011752.AA27773@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Mon, 01 Aug 94 11:20:51 -0500. <9408011120.ZM12132@hughes.network.com> Date: Mon, 01 Aug 94 13:47:40 -0400 From: Steve Kent Jim, Generally, the version number field in a protocol header is used to distinguish among different versions of the protocol, e.g., serially over time. What you described sounds more like one of many parameters bound to a security association, specifically, a paremeter related to the key management protocol being employed. I'm not sure that merits being identified as a different version of IPSP. Steve From ipsec-request@ans.net Mon Aug 1 18:38:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43851 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 15:03:32 -0400 Received: by interlock.ans.net id AA28598 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 14:31:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 14:31:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 14:31:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 14:31:22 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408011338.ZM12582@hughes.network.com> Date: Mon, 1 Aug 1994 13:38:05 -0500 In-Reply-To: Steve Kent "Re: SIPP and SKIP. 2 subjects." (Aug 1, 1:47pm) References: <9408011759.AA12377@hughes.network.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Steve Kent , "James P. Hughes" Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 1, 1:47pm, Steve Kent wrote: > Subject: Re: SIPP and SKIP. 2 subjects. > Jim, > I'm not sure that merits being identified as a different version of IPSP. Yes, what I have described is indeed not a version "of the encapsulation". I am not being trivial in using this important field. Let me start again by withdraw my suggestion as being "without foundation". I like SKIP and assume that it may be usable to get IP security into the field real quick. I also assume that we will have explicit authentication for future flexibility. 2 questions. 1) Do you envision that there will be 2 methods (implicit and explicit) of key establishment? 2) If so, how do I determine the key management method? (Let me ponder the possibilities.... The SAID is indeed the -only- field other than the version that is defined. The SAID field is flat and has no meaning at this time. I guess that a value of 0 could mean implicit key exchange? If you get a bad SAID, you could do implicit key management? Hmm.) I would like to hear 2 arguments. If you think question 1 is false, chime in. If you think the answer to 1 is true, please tell me how it is to interoperate in an internet that contains both implicit and explicit key management. I await your response. jim From ipsec-request@ans.net Mon Aug 1 18:54:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39408 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 15:18:47 -0400 Received: by interlock.ans.net id AA31318 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 14:56:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 14:56:23 -0400 Message-Id: <199408011856.AA28754@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Mon, 01 Aug 94 13:38:05 -0500. <9408011338.ZM12582@hughes.network.com> Date: Mon, 01 Aug 94 14:54:00 -0400 From: Steve Kent Jim, I think Perry captured the essence of the arguments. The SAID is THE selector used by a recipient to pick the key and other parameters for processing an inbound packet. Provcessing of outbound packets may be specified in different ways, depending on whether the processing is provided in the end system or an intermediate system. As Perry noted, there needs to be a well-defined means of specifying SAID selection for outbound traffic, e.g., values from the IP header (and maybe the transport layer header) that cause one SAID to be chosen over another. I believe that we need to specify the allowed selectors as part of the IPSP spec, and then an implementation can employ whichever ones are appropriate in its context. Steve From ipsec-request@ans.net Mon Aug 1 19:37:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14657 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 16:00:26 -0400 Received: by interlock.ans.net id AA09105 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 15:36:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 15:36:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 15:36:51 -0400 Date: Mon, 1 Aug 1994 12:37:20 -0700 From: Phil Karn Message-Id: <199408011937.MAA28003@servo.qualcomm.com> To: ipsec@ans.net Subject: Thoughts on a basic encryption mode I am encouraged by the progress toward concensus we made last week. Of course, much of that progress was made possible by minimizing what it was we had to agree on -- a 32 bit SAID, followed by something we haven't fully defined yet. To promote interoperability at at least a basic level of security, we should define an encryption encapsulation algorithm that everyone can implement, even though newer and better ones are certain to appear later. We need to discuss this algorithm. I propose that this basic algorithm be DES with cipher block chaining (CBC). Ciphertext produced by this algorithm will always be a multiple of 8 bytes long, so padding is necessary. The very last byte of the decrypted plaintext contains a value from 0-6 indicating how much of this last block should be considered valid data. And the second last byte of the last block is the IP protocol field. This leaves a few questions for discussion. First, should we use DES as opposed to IDEA? DES has a smaller key and is showing signs of age, but it is widely available and avoids patent issues (IDEA is patented in the US). DES is also more readily available in hardware, though I suspect that the vast majority of IPSEC implementations will do it in software. Second, should we use standard DES, or can we eliminate the initial and final permutations? These are widely regarded as having no cryptographic value, and eliminating them can improve software performance substantially. The only drawback is the loss of direct interoperability with "standard" DES in hardware, but such systems could always "undo" the permutations in software to remain compatible. And again, I expect the vast majority of IPSEC implementations will do DES in software. Third, do we need an explicit IV in every packet? 8 bytes is a lot of overhead, and it may not be necessary in every case to ensure "churn" in the resulting ciphertext. E.g., when encrypting an IP datagram the ID field will land within the first 8 bytes of plaintext, and this will ensure completely different ciphertext from packet to packet even if the remaining packet contents are identical. Remember, what I'm proposing here would be a basic encryption mode that everyone would implement to ensure interoperability, but its use would NOT be mandatory in any particular situation. Consenting hosts would always be able to negotiate the use of any alternative encryption scheme that they both support. Phil From ipsec-request@ans.net Mon Aug 1 21:30:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14748 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 16:50:54 -0400 Received: by interlock.ans.net id AA17668 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 16:30:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 1 Aug 1994 16:30:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 16:30:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 16:30:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 16:30:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 16:30:22 -0400 From: uri@watson.ibm.com Message-Id: <9408012030.AA15489@buoy.watson.ibm.com> Subject: Re: Thoughts on a basic encryption mode To: ipsec@ans.net Date: Mon, 1 Aug 1994 16:30:08 -0500 (EDT) In-Reply-To: <199408011937.MAA28003@servo.qualcomm.com> from "Phil Karn" at Aug 1, 94 12:37:20 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1874 Phil Karn says: > I propose that this basic algorithm be DES with cipher block chaining > (CBC). Ciphertext produced by this algorithm will always be a > multiple of 8 bytes long, so padding is necessary. The very last byte > of the decrypted plaintext contains a value from 0-6 indicating how much > of this last block should be considered valid data. And the second > last byte of the last block is the IP protocol field. I vote for it. > First, should we use DES as opposed to IDEA? DES has a smaller key and > is showing signs of age, but it is widely available and avoids patent > issues (IDEA is patented in the US). DES is also more readily > available in hardware, though I suspect that the vast majority of > IPSEC implementations will do it in software. Due to patent issues I suggest we use DES just for now, and in the [near] future it's likely we'll see new [stream] algorithm[s] faster than IDEA and at least as secure. But at least we won't have to worry about being sued if our implementations end up in a product (:-). > Second, should we use standard DES, or can we eliminate the initial > and final permutations? These are widely regarded as having no > cryptographic value, and eliminating them can improve software > performance substantially. The only drawback is the loss of direct > interoperability with "standard" DES in hardware, but such systems > could always "undo" the permutations in software to remain compatible. Well, even though those permutations indeed have no cryptographic value, I'd rather have them in to be 100% compatible with the hardware... > Third, do we need an explicit IV in every packet? I'd say - no we don't. The advantages of having it are too small, compared with the serious expense of adding extra 8 bytes. -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Mon Aug 1 20:37:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14767 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 16:54:34 -0400 Received: by interlock.ans.net id AA23370 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 16:38:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 16:38:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 16:38:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 16:38:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 16:38:10 -0400 Message-Id: <9408012037.AA08900@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Mon, 01 Aug 1994 13:38:05 CDT." <9408011338.ZM12582@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 Aug 1994 16:37:49 -0400 From: "Perry E. Metzger" James P. Hughes says: > I like SKIP and assume that it may be usable to get IP security into > the field real quick. SKIP is a nice proposal as far as it goes, but neither it nor any of the other proposals I've seen thus far address the real issues. Beyond this, there are large numbers of other issues involved in a key management system -- Steve Kent wrote down about fifteen important ones during the key management meeting. I won't pretend to get into them -- I'll let him mention his list on his own. From my own (different) perspective, the cryptographic details of any given key management system are the LEAST important problem. The most important problems are finding a common framework for negotiating which protocols are to be used, and a common framework for naming. Certainly one or possibly two strong protocols (a public key and a private key one might each be needed) for key management ought be standardized, but lets not kid ourselves into thinking we will be using the same ones in ten or fifteen years. New technologies are developed all the time, and tying ourselves for all time to a specific cryptographic algorithm is a big mistake (although it would also be a mistake not to try to get people to use a single standard today.) A good structure that lets us move forward when the time comes to do so is the real challenge. As defined, SKIP and all the rest don't provide an open framework -- most of them are very tied to specific cryptographic techniques. This is not to say that we shouldn't design and deploy quickly -- I think Jeff Schiller made it clear we have very little time to dilly-dally. However, I believe it is important not to chain ourselves to Diffie-Hellman or any other specific technique. > 2 questions. > > 1) Do you envision that there will be 2 methods (implicit and > explicit) of key establishment? I expect there will more than two, although I expect that there will probably only be one popular one in the internet community at any one time. I certainly expect that we will evolve to new techniques through time and must set our structure up to permit that. Steve Bellovin has noted that we cannot survive with too many options -- interoperability will suffer. I fully agree with this. However, we must recognise that what we do today and what we do tomorrow will not be the same -- techniques WILL continue to evolve, and it would be suicidal to chain ourselves to one particular set of algorithms. > 2) If so, how do I determine the key management method? I envision it being negotiated. The requester sends a capability packet, and the responder selects (or some such.) This can be done in an extremely simple manner -- it need not be a complex negotiation, not even as complicated as that of Telnet. > (Let me ponder the possibilities.... The SAID is indeed the -only- > field other than the version that is defined. The SAID field is flat > and has no meaning at this time. That was what we more or less agreed on in the IPSP meeting, yes. The negotiation between hosts is to determine the meaning of the field, although implementations are free to try and play tricks, since the receiver chooses the SAID. The SAID is basically a selector for a security transform/key pair on the receiver end. It has no meaning other than that which the receiver has selected for ITS convenience. > I guess that a value of 0 could mean implicit key exchange? Actually, it makes far more sense to have it either be a reserved value or mean the null security transformation (that is, pure IP in IP or similar encapsulation, though I'm not sure what that would be useful for.) Having a reserved SAID value for a particular key management system doesn't really make much sense, since the notion is that a SAID indexes a particular transform, as I've noted, and not a key management system. The SAID it isn't really related to key management at all -- it is the partial output of the key management negotiation, not an input. > If you get a bad SAID, you could do implicit key management? I think you can't avoid doing some negotiation, period. Why fear this? Its not such a bad thing. Perry From ipsec-request@ans.net Mon Aug 1 20:47:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13399 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 17:07:40 -0400 Received: by interlock.ans.net id AA09182 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 16:50:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 16:50:22 -0400 Message-Id: <199408012050.AA30170@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of Mon, 01 Aug 94 12:37:20 -0700. <199408011937.MAA28003@servo.qualcomm.com> Date: Mon, 01 Aug 94 16:47:39 -0400 From: Steve Kent Phil, In response to your questions: - I think CBC is a fine mode for DES, triple DES, etc. The last byte pad length trick has been codified in other proposals, but everyone should realize that it means that sometimes you will add 8 bytes, because the original packet was an integral multiple of 8 bytes already and you need to make room for the pad count. With the IP next protocol field there too, sometimes you will need to add 9 bytes. - I think that the option to use crypto hardware is worth preserving and the lack of license requirements for DES, on a worldwide basis, may make it attractive for many folks. (DES was patented in the U.S., by IBM, but it granted royalty free license as a quid pro quo of DES being adopted as a FIPS.) - My experience with writing software implementations of DES suggested that the initial permutation and its inverse do not really take much time, and thus the performance savings are not all that great. (Our implementation of IP or IP-inverse, back in 1978, used 8 table lookups, 8 ORs, 7 rotates, and a few ANDs. I believe better implementations are availabel today.) One would loose hardware compatability if these operations were omitted. Imagine a typical IPSP association from a laptop to a router at a site, where the router may have hardware assist to enable it to processes many associations. That sort of scenario motivates use of an algorithm that is available in hardware. - As for per-packet IVs, the argument about the IP unique ID field may be OK for IP encapsulation, but when a transport protocol is directly above IPSP this argument cannot be used. Also, use of some hardware may be adversely affected by the need to process the first block in ECB mode (no IV), then switch over to CBC for the remainder of the packet. However, FIPS 81 does permit a fixed IV for a "session" in CBC mode, transmitted during session establishment and integrity protected. Thus use of the same IV for every packet is consistent with this FIPS and would avoid the per-packet overheard you are concerned about. Steve From ipsec-request@ans.net Mon Aug 1 21:21:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13548 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 17:42:01 -0400 Received: by interlock.ans.net id AA20308 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 17:23:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 17:23:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 17:23:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 17:23:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 17:23:30 -0400 Message-Id: <9408012121.AA08977@snark.imsi.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of "Mon, 01 Aug 1994 12:37:20 PDT." <199408011937.MAA28003@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 Aug 1994 17:21:32 -0400 From: "Perry E. Metzger" Phil Karn says: > To promote interoperability at at least a basic level of security, we > should define an encryption encapsulation algorithm that everyone can > implement, even though newer and better ones are certain to appear > later. This is clear. A baseline of functionality is needed by all implementations in order to assure that we don't die of optionitis. I'll discuss what you mention out of order. > I propose that this basic algorithm be DES with cipher block chaining > (CBC). Ciphertext produced by this algorithm will always be a > multiple of 8 bytes long, so padding is necessary. The very last byte > of the decrypted plaintext contains a value from 0-6 indicating how much > of this last block should be considered valid data. And the second > last byte of the last block is the IP protocol field. This seems 100% perfectly reasonable, except for the fact that you haven't discussed MACs, check fields, or other options to assure integrity (although you do discuss the question of IVs later on). We need to decide on whether the "base algorithm" should have some explicit integrity check. > Third, do we need an explicit IV in every packet? 8 bytes is a lot of > overhead, and it may not be necessary in every case to ensure "churn" > in the resulting ciphertext. E.g., when encrypting an IP datagram the > ID field will land within the first 8 bytes of plaintext, and this > will ensure completely different ciphertext from packet to packet even > if the remaining packet contents are identical. Sequence numbers in TCP-only encapsulations might serve a similar purpose. I'm not sure, however, that either is long enough to really provide good initialization. Does anyone else have an opinion on this? > First, should we use DES as opposed to IDEA? DES has a smaller key and > is showing signs of age, but it is widely available and avoids patent > issues (IDEA is patented in the US). DES is also more widely recognised as "good" -- IDEA does not have sufficiently widespread buy-in. DES is also (nearly) patent free. > DES is also more readily available in hardware, though I suspect > that the vast majority of IPSEC implementations will do it in > software. This is true, but don't forget that several vendors ARE selling encrypting tunneling gateways (UUNET among them) and it might be nice to get them interoperable. > Second, should we use standard DES, or can we eliminate the initial > and final permutations? These are widely regarded as having no > cryptographic value, and eliminating them can improve software > performance substantially. The only drawback is the loss of direct > interoperability with "standard" DES in hardware, but such systems > could always "undo" the permutations in software to remain compatible. > And again, I expect the vast majority of IPSEC implementations will do > DES in software. Undoing them in hardware might also be quite feasable. However, my feeling is that we ought to stick to the DES as specified if only to keep things "standard". Since we've opened up the floodgates for negotiated encryption, a very easy "optional" change would be DES without the initial and final permutations. My feeling is, however, since hardware manufacturers are a major potential client of the protocol that the "mandatory" algorithm should be standard. > Remember, what I'm proposing here would be a basic encryption mode > that everyone would implement to ensure interoperability, but its use > would NOT be mandatory in any particular situation. Consenting hosts > would always be able to negotiate the use of any alternative > encryption scheme that they both support. I like virtually everything you've proposed, except that I somewhat feel that the "no permutation" mode might better be a negotiated option rather than the "mandatory" part of the algorithm set. Perry From ipsec-request@ans.net Mon Aug 1 21:32:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13331 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 17:49:12 -0400 Received: by interlock.ans.net id AA27080 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 17:32:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 17:32:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 17:32:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 17:32:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 17:32:54 -0400 Message-Id: <9408012132.AA09030@snark.imsi.com> To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of "Mon, 01 Aug 1994 16:30:08 CDT." <9408012030.AA15489@buoy.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 01 Aug 1994 17:32:28 -0400 From: "Perry E. Metzger" uri@watson.ibm.com says: > Due to patent issues I suggest we use DES just for now, and in the [near] > future it's likely we'll see new [stream] algorithm[s] faster than IDEA > and at least as secure. But at least we won't have to worry about > being sued if our implementations end up in a product (:-). I assume you are refering to Coppersmith's SEAL algorithm -- which sounds rather neat... > Well, even though those permutations indeed have no cryptographic value, > I'd rather have them in to be 100% compatible with the hardware... The more I think about this, the more I agree -- UUNet, TIS and other firms are going to be selling hardware based IPSP to many of their customers -- you are going to need hardware to securely bridge two networks at T1 or similar speeds. An optional "consenting adults" protocol without the permutations seems better. Perry From ipsec-request@ans.net Mon Aug 1 22:19:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02544 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 18:28:03 -0400 Received: by interlock.ans.net id AA23488 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 18:12:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 18:12:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 18:12:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 18:12:42 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408011719.ZM12997@hughes.network.com> Date: Mon, 1 Aug 1994 17:19:32 -0500 In-Reply-To: "Perry E. Metzger" "Re: SIPP and SKIP. 2 subjects." (Aug 1, 4:37pm) References: <9408012037.AA08900@snark.imsi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: perry@imsi.com, hughes@hughes.network.com (James P. Hughes) Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 1, 4:37pm, Perry E. Metzger wrote: > Subject: Re: SIPP and SKIP. 2 subjects. > > 2) If so, how do I determine the key management method? > > I envision it being negotiated. The requester sends a capability > packet, and the responder selects (or some such.) This can be done in > an extremely simple manner -- it need not be a complex negotiation, > not even as complicated as that of Telnet. There is a significant difference between simple and none. > I think you can't avoid doing some negotiation, period. Why fear this? > Its not such a bad thing. Do you have anything more concrete than "you think" that negotiation is unavoidable? jim From ipsec-request@ans.net Mon Aug 1 23:39:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34970 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 19:03:52 -0400 Received: by interlock.ans.net id AA07337 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 18:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 1 Aug 1994 18:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 18:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 18:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 18:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 18:39:06 -0400 From: uri@watson.ibm.com Message-Id: <9408012239.AA22890@buoy.watson.ibm.com> Subject: Re: Thoughts on a basic encryption mode To: perry@imsi.com Date: Mon, 1 Aug 1994 18:39:03 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <9408012132.AA09030@snark.imsi.com> from "Perry E. Metzger" at Aug 1, 94 05:32:28 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1948 Perry E. Metzger says: > > Due to patent issues I suggest we use DES just for now, and in the [near] > > future it's likely we'll see new [stream] algorithm[s] faster than IDEA > > and at least as secure. But at least we won't have to worry about > > being sued if our implementations end up in a product (:-). > I assume you are refering to Coppersmith's SEAL algorithm -- which > sounds rather neat... That's correct, SEAL by Coppersmith and Rogaway. [From SEAL docs by Coppersmith and Rogaway, all the errors are mine] SEAL is a length-increasing pseudo-random function. Under control of a 160-bit key A it maps 32-bit string N to an L-bit string. The number L can be made as large or as small as is needed for a target application, but output lengths ranging from 512 to 4096 bytes are anticipated. As a pseudo-random function, SEALa(.) should "look like a random function" if A is random and unknown. Forst a key A is taken at random (a 16-bit long bit sequence). Next the adversary is given at random either a black-box for the function SEALa(.), or a black-box for a truly random funcrion R(.). Either one maps 32 bits to L bits. The adversary's job is to guess which type of box she has. The adversary wins, if she correctly guesses "Random" or "Pseudorandom". A pseudorandom function can be used to make a good stream cipher. In a stream cipher the encryption of a message depends not only on the key A and the message X, but also on the message's position in the data stream. This position is often a sequence number, present already in the application that would be useing the cryptographic method... The cipher is optimized for 32-bit processor. The algorithm is table-driven and uses approximately 3Kbytes of table space. Computational cost on a 32-bit processor is about 5 elementary machine instructions per byte of text... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Mon Aug 1 14:51:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39464 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 19:25:30 -0400 Received: by interlock.ans.net id AA09268 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 18:53:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 18:53:15 -0400 Message-Id: <199408012253.AA25904@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 18:53:15 -0400 To: perry@imsi.com Cc: Phil Karn , ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode Date: Mon, 01 Aug 94 18:51:05 EDT DES is also more widely recognised as "good" -- IDEA does not have sufficiently widespread buy-in. DES is also (nearly) patent free. Completely free now -- the patent has expired. From ipsec-request@ans.net Mon Aug 1 05:42:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14119 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 20:21:42 -0400 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Mon, 1 Aug 1994 20:18:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 1 Aug 1994 20:18:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 1 Aug 1994 20:18:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 20:18:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 20:18:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-0); Mon, 1 Aug 1994 20:18:31 -0400 Date: Mon, 1 Aug 94 12:42:02 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408011942.AA08679@miraj.Eng.Sun.COM> To: hughes@hughes.network.com, perry@imsi.com Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 0 >From ipsec-request@ans.net Mon Aug 1 11:35:07 1994 > Explicitly assigning a security identifier is a >cheap operation. Once assigned, a particular SAID might identify all >subsequent packets bearing it as SKIP-style "implicit key exchange" >encrypted packets. However, I'm very reluctant to support use of the >four bit version field (which in the draft I am defining as an Must Be >Zero field, at least for the moment) for this purpose, since it seems >that the same purpose can be cheaply achieved without using the >version space. Using the version number seems to just be a way to >end-run around assigning a SAID for the purpose, which, as I said, is >cheap. Yes, as I mentioned at the presentation, my proposal was to assign a few SAIDs for use by SKIP. This seems like the best way to do things. I am contemplating three or four SAIDs at the moment, one for default encryption context, one (or two) for integrity-only and another for supporting ephemeral SKIP contexts. Ashar. From ipsec-request@ans.net Tue Aug 2 01:45:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16708 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 22:03:55 -0400 Received: by interlock.ans.net id AA24794 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 21:45:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 21:45:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 21:45:36 -0400 Date: Mon, 1 Aug 1994 21:45:33 -0400 From: *Hobbit* Message-Id: <199408020145.VAA11690@asylum.sf.ca.us> To: ipsec@ans.net Subject: encryption algorithms.. The vast majority of implementations might do encryption in software initially, but I often daydream of a time in the future when security-aware routers or such like will contain several dedicated DES or IDEA chips. Once keys and IVs were established, data would get cranked through them just like any other controller chip inside, with minimal overhead... _H* From ipsec-request@ans.net Tue Aug 2 03:46:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39533 (5.65c/IDA-1.4.4 for ); Mon, 1 Aug 1994 23:58:04 -0400 Received: by interlock.ans.net id AA14347 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Aug 1994 23:45:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 1 Aug 1994 23:45:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Aug 1994 23:45:48 -0400 Date: Mon, 1 Aug 1994 20:46:17 -0700 From: Phil Karn Message-Id: <199408020346.UAA28696@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <199408020145.VAA11690@asylum.sf.ca.us> (message from *Hobbit* on Mon, 1 Aug 1994 21:45:33 -0400) Subject: Re: Thoughts... Thanks for the helpful remarks. Sounds like hardware DES chips will be more common sooner than I thought. I'll go bum some more instructions off my DES code and see if I can push the initial and final permutations down into the noise. So the consensus seems to be: standard DES, CBC, padding encoded as previously described, no per-packet IV (although there could be a per-SAID IV, I'm not sure how useful this would be given unique keys per SAID). Anybody got the nroff macros for Internet Drafts? Perry, I deliberately left off authentication because I want to keep that separate. I note that you can get a very modest amount of authentication for free from CBC by simply specifying the pad char values and checking them when you decrypt. If the padding is wrong, the PID is invalid or the length byte isn't 0-6, then you toss the packet. And of course there are the imbedded IP and TCP checksums, if any, which would be hard to get right given CBC's error propagation feature. (Strictly speaking, all this isn't "free" - it comes from the overhead of CBC). Certainly this is nowhere near as strong as keyed MD5 with a 16 byte authenticator, but I suspect many will balk at that much overhead on a slow link. Perhaps our "baseline" authentication mode should use only a piece of the MD5 output? If so, how much? Phil From ipsec-request@ans.net Tue Aug 2 12:12:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44581 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 08:32:20 -0400 Received: by interlock.ans.net id AA19371 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 08:13:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 08:13:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 08:13:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 08:13:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 08:13:02 -0400 Message-Id: <9408021212.AA09858@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Mon, 01 Aug 1994 17:19:32 CDT." <9408011719.ZM12997@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 08:12:47 -0400 From: "Perry E. Metzger" James P. Hughes says: > > I think you can't avoid doing some negotiation, period. Why fear this? > > Its not such a bad thing. > > Do you have anything more concrete than "you think" that negotiation is > unavoidable? 1) Different groups are going to want different encryption methods. Some people are going to be satisfied with DES, some with 3DES, some with IDEA, etc. Security Transform negotiation is therefore utterly unavoidable, and part of the point of the SAID mechanism was to permit such negotiation. (BTW, this is not to say that a mandatory baseline should not be part of the standard -- merely that consenting hosts are going to want to and will in fact use other security transforms than the baseline.) 2) Of course, transform negotiation and key management systems are not necessarily the same issue, as I've noted. However, it would seem foolish to set up a system that allowed utter flexibility in security transform and then locked us in to, say, Diffie-Hellman for key negotiation FOREVER. Not being able to pass back and forth a negotiation packet, a very cheap operation, effectively locks us in for good, with no way to maintain backward compatibility as new key management protocols are developed. Again, I think a baseline system must be defined and made mandatory for conformant implementations, but in five years it might turn out that, say, some system based on the factoring of finite automata becomes obviously far better than, say, RSA signed Diffie Hellman, or whatever else we pick. Being locked in forever is nonsensical. As I've said, negotiation is CHEAP. There is no point in avoiding something thats cheap and easy when it provides us with so much forward flexibility. In order to make it cheaper, it may even be possible to have key management negotiation piggy back on top of security transform negotiation, which would make things "super-cheap". Perry From ipsec-request@ans.net Tue Aug 2 14:39:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07116 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 10:57:03 -0400 Received: by interlock.ans.net id AA18962 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 10:32:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 10:32:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 10:32:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 10:32:46 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408020939.ZM13610@hughes.network.com> Date: Tue, 2 Aug 1994 09:39:34 -0500 In-Reply-To: Steve Kent "Re: Thoughts on a basic encryption mode" (Aug 1, 4:47pm) References: <199408012050.AA30170@interlock.ans.net> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Steve Kent , Phil Karn Subject: Re: Thoughts on a basic encryption mode Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 1, 4:47pm, Steve Kent wrote: > - As for per-packet IVs, the argument about the IP unique ID > field may be OK for IP encapsulation, but when a transport protocol is > directly above IPSP this argument cannot be used. Also, use of some > hardware may be adversely affected by the need to process the first > block in ECB mode (no IV), then switch over to CBC for the remainder > of the packet. However, FIPS 81 does permit a fixed IV for a > "session" in CBC mode, transmitted during session establishment and > integrity protected. Thus use of the same IV for every packet is > consistent with this FIPS and would avoid the per-packet overheard you > are concerned about. Fixed per packet IV would cause some protocols (not IP, TCP or UDP) to possibly spill some information. If the protocol has a small number of differences in the first doubleword, then a frequency analysis would be all that is necessary to crack the meaning of that word. Phil said: >> Third, do we need an explicit IV in every packet? 8 bytes is a lot of >> overhead, and it may not be necessary in every case to ensure "churn" >> in the resulting ciphertext. E.g., when encrypting an IP datagram the >> ID field will land within the first 8 bytes of plaintext, and this >> will ensure completely different ciphertext from packet to packet even >> if the remaining packet contents are identical. I agree with phil. This is a real foot hold to crack a packet. If you know through frequency analysis what the plain text of a single block is, you are a lot further towards break it. I do not agree, however, that it is too much overhead. For file transfers, 8 bytes added to a 1k packet is less than 1%. For transactions over a 19Kb/s line it is less than 3.5ms added latency. jim From ipsec-request@ans.net Tue Aug 2 14:33:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07131 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 10:58:10 -0400 Received: by interlock.ans.net id AA14669 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 10:39:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 10:39:06 -0400 Message-Id: <199408021438.AA22089@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Thoughts... In-Reply-To: Your message of Mon, 01 Aug 94 20:46:17 -0700. <199408020346.UAA28696@servo.qualcomm.com> Date: Tue, 02 Aug 94 10:33:28 -0400 From: Steve Kent Phil, The error propogation of CNBC is strictly limited, so using a specified pad value at the end and checking it will not detect modification that occurred more than one block earlier in the data stream. Given that limitation, it might be better to use a real manipulation detection function, or, as you suggested, rely on the transport layer error detection functions and view IPSP, in this instance, as providing only "support for" integrity at higher layers. As for the IV issue, as I noted earlier, a per security association IV would be consistent with the guidance of FIPS 81, the DES modes standard. It also might avoid any possible problems with hardware that is designed to implemet DES modes according to FIPS 81. The incremental performance cost in a software implementation is just that of XORing the 64-bit IV for the first block, which seems rather minimal. Steve From ipsec-request@ans.net Tue Aug 2 14:42:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44565 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 11:00:35 -0400 Received: by interlock.ans.net id AA23219 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 10:46:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 10:46:06 -0400 Message-Id: <199408021446.AA23215@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Mon, 01 Aug 94 12:42:02 -0700. <9408011942.AA08679@miraj.Eng.Sun.COM> Date: Tue, 02 Aug 94 10:42:19 -0400 From: Steve Kent Ashar, I'm a bit confused by the comments about SAIDs being reserved to indicate a particular key exchange. The idea of an SAID is that it is selected by the local IPSP entity (IPSPE?) for use as the SOLE selector for security transformation processing for incoming packets. (This ignores multicast security associations for the moment. Multicast SAIDs will reuqire more than purely local selection, as they need to be unqiue across all multicast recipients.) Assuming that an IPSPE uses the same key management technique for multiple SAs, then it cannot use the same SAID to identify all of these SAs. It may elect to encode info about the key management technique in these SAIDs, since any structure is purely a local matter, but it cannot use the same SAID for multiple, distinct SAs. Was the focus of this discussion the use of SAIDs for the SA negotiation packets? I don't think we have talked about how the packets exchanged for SA negotiation are handled, so far, e.g. what protocol ID is appropriate for them, how are they "bypassed" through the IPSP layer, etc. Steve From ipsec-request@ans.net Tue Aug 2 15:50:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07017 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 11:05:46 -0400 Received: by interlock.ans.net id AA09961 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 10:49:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 10:49:27 -0400 Subject: Re: IPSP negotiation To: perry@imsi.com Date: Tue, 2 Aug 1994 10:50:00 -0500 (EST) From: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: <9408021212.AA09858@snark.imsi.com> from "Perry E. Metzger" at Aug 2, 94 08:12:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1618 Message-Id: <9408021550.aa14940@sundance.itd.nrl.navy.mil> It is not clear to me that "negotiation is cheap" in all cases, but it seems clear that some (not yet fully determined) amount of negotiation will be required in the world-wide Internet. Algorithms are one thing that clearly will need to be negotiated because not everyone will want to use DES-CBC. Certain other things will need to be _communicated_ between the parties but might not need to be _negotiated_. Sensitivity level might be one of these items. I know that at least Steve Bellovin and Steve Kent have some set of items that each thinks probably should be negotiable. I think that the newly formed key management group should probably try to reach rough consensus on which items need to be negotiable early on in their work. I don't think many people would argue against (1) trying to keep the negotiable items minimised and (2) trying to keep the negotiation process simple. Ran atkinson@itd.nrl.navy.mil PS: In the IPv6 Implementers Meeting in Toronto on the morning of 7/29, an early implementer of the IPv6 Authentication Header reported that a well known commercial 64-bit RISC processor could only process about 20 Mbps through MD5. I hope that we'll see MD5 hardware soon to make increase the processing rate. However, the implementers all wanted to explore alternatives to MD5 that would be faster (100 Mbps on a RISC processor would be nice to have so that FDDI line rates and near ATM line rates are practical) and yet provide authentication adequate for commercial users. All suggestions on alternate algorithms are welcome, preferably with citations into the published literature. From ipsec-request@ans.net Tue Aug 2 14:49:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17007 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 11:08:06 -0400 Received: by interlock.ans.net id AA22055 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 10:52:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 10:52:30 -0400 Message-Id: <199408021452.AA25635@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of Tue, 02 Aug 94 09:39:34 -0500. <9408020939.ZM13610@hughes.network.com> Date: Tue, 02 Aug 94 10:49:00 -0400 From: Steve Kent Jim, I agree with the general thrust of your observations. When I teach my tutorial on network security, I argue in favor of per-packet IVs. Without their use, identical prefixes of packets are visible. I am less concerned about the ability you cite to do frequency analysis with most of the Internet transport layer protocols, but in general the use of a per-packet IV is a good practice. However, I was pointing out that the FIPS does allow for not using a per-packet IV with CBC mode, which addresses the concern of Phil and others who want to be frugal about bandwidth in wireless environments. Steve From ipsec-request@ans.net Tue Aug 2 15:48:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01767 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 12:05:31 -0400 Received: by interlock.ans.net id AA19017 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 11:49:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 11:49:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 11:49:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 11:49:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 11:49:49 -0400 Message-Id: <9408021548.AA10322@snark.imsi.com> To: Steve Kent Cc: Phil Karn , ipsec@ans.net Subject: Re: Thoughts... In-Reply-To: Your message of "Tue, 02 Aug 1994 10:33:28 EDT." <199408021438.AA22089@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 11:48:14 -0400 From: "Perry E. Metzger" Steve Kent says: > The error propogation of CNBC is strictly limited, so using a > specified pad value at the end and checking it will not detect > modification that occurred more than one block earlier in the data > stream. Given that limitation, it might be better to use a real > manipulation detection function, or, as you suggested, rely on the > transport layer error detection functions and view IPSP, in this > instance, as providing only "support for" integrity at higher layers. I've got mixed feelings on on this -- on the one hand, I'd like to see MD5 or SHA based authentication, since TCP checksums aren't particularly robust. On the other hand, I wouldn't want to see everyone wrecked to do it. Although multiplying "required" entities is probably not a good idea, I'd propose (as a strawman) that the following three things end up in the base standard... 1) MD5 only authentication for use with the Authentication header. (We haven't been discussing this yet, but its probably fairly non-controversial). 2) DES only for use with the Encryption header, using a session IV, relying largely on things like the TCP sequence number to scramble blocks of identical data differently, and incorporating no message authentication beyond the TCP or similar checksum... 3) a DES+MD5 mode with an explicit authentication block at the end and an explicit IV at the beginning that also serves as a sequence number against replay, this mode available for paranoids without any speed concerns or with heavy hardware. Phil is a big proponent of the "don't specify too much" school, and he's one of the people actually implementing, so I will wait for him to throw bricks at me for suggesting #3 :-)... Myself, I think that these three are a sufficiently modest base that they aren't sooo bad. Perhaps #3 should use 3DES instead of DES since its the "paranoid mode". Perhaps not. Perhaps as I've suggested #3 is a bad idea altogether because it multiplies requirements too much (but I don't think its actually so bad.) Ran mentions that MD5 is somewhat slow even on 64bit RISC processors. Unfortunately, beyond clever implementations, I'm not sure that we know of good ways to improve that without hardware, and other than the (equally slow) SHA, I'm not sure I know of anything else thats really trustworthy for authentication. Anyone else have ideas? > As for the IV issue, as I noted earlier, a per security > association IV would be consistent with the guidance of FIPS 81, the > DES modes standard. It also might avoid any possible problems with > hardware that is designed to implemet DES modes according to FIPS 81. > The incremental performance cost in a software implementation is just > that of XORing the 64-bit IV for the first block, which seems rather > minimal. Of course, a per-association IV doesn't actually buy much in the sense that identical blocks still look identical -- NFS transfers of large fields of zeros are likely to be easily spotted, for example. It would still be reasonable to use a per-association IV over no IV at all since its fairly cheap. Perry From ipsec-request@ans.net Tue Aug 2 03:27:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15439 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 13:47:14 -0400 Received: by interlock.ans.net id AA05698 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 13:28:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 13:28:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 13:28:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 13:28:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 13:28:02 -0400 Date: Tue, 2 Aug 94 10:27:45 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408021727.AA09199@miraj.Eng.Sun.COM> To: perry@imsi.com Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 1899 >From ipsec-request@ans.net Mon Aug 1 13:58:30 1994 >SKIP is a nice proposal as far as it goes, but neither it nor any of >the other proposals I've seen thus far address the real issues. > >>From my own (different) perspective, the cryptographic details of any >given key management system are the LEAST important problem. The most >important problems are finding a common framework for negotiating >which protocols are to be used, and a common framework for >naming. Certainly one or possibly two strong protocols (a public key >and a private key one might each be needed) for key management ought >be standardized, but lets not kid ourselves into thinking we will be >using the same ones in ten or fifteen years. New technologies are >developed all the time, and tying ourselves for all time to a specific >cryptographic algorithm is a big mistake (although it would also be a >mistake not to try to get people to use a single standard today.) A >good structure that lets us move forward when the time comes to do so >is the real challenge. As defined, SKIP and all the rest don't provide >an open framework -- most of them are very tied to specific >cryptographic techniques. Perry, The last key-management scheme that I designed (with Whit Diffie) attempted to negotiate several parameters of interest, key sizes and encryption algorithms being some of them. (This was published in "IEEE Personal Communications", Feb 94, and is also available on the mobile-IP ftp site. This design was in the context of connection- oriented wireless LAN protocols.) In designing this scheme, one of the things that I came to realize was that although one could negotiate many things easily, the public-key algorithm in the certificate was not one of them. Ultimately, certificates become part of the infrastructure, and negotiating a different infrastructure is quite difficult in practice. Ashar. From ipsec-request@ans.net Tue Aug 2 17:54:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50225 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 14:12:29 -0400 Received: by interlock.ans.net id AA17334 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 13:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 13:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 13:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 13:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 13:57:47 -0400 Message-Id: <9408021754.AA10706@snark.imsi.com> To: ashar@firstperson.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Tue, 02 Aug 1994 10:27:45 PDT." <9408021727.AA09199@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 13:54:52 -0400 From: "Perry E. Metzger" Ashar Aziz says: > In designing this scheme, one of the things that I came to > realize was that although one could negotiate many things easily, > the public-key algorithm in the certificate was not one of them. > Ultimately, certificates become part of the infrastructure, and > negotiating a different infrastructure is quite difficult in > practice. You are assuming people will even necessarily have certificates. I think its a good bet that they will, but many people would like to extend the use of kerberos on their LANs to do IPSP key negotiation. I, for one, have sympathy for this notion, and don't want to make it impossible, although I think that in an inter-organization application it isn't practical. Some might say that we should not make these provisions because they will lead to an inability of different groups to interoperate, but this denies the reality that protocols evolve through time -- 1984 TCP is not well behaved in a 1994 TCP environment (no slow start or Van J's algorithm), and the same goes for almost everything else in our protocol suite. Certainly we need to mandate some base functionality, but it is not at all unreasonable for consenting hosts to go beyond it. Furthermore, from my perspective, I do not think that SKIP or *ANY* of the protocols proposed thus far is, on its own as proposed, sufficient. Even ignoring the whole question of management system selection, there are lots of issues like naming that haven't been properly addressed. I agree that it is difficult to choose a new infrastructure once one is built. That is why I am suggesting that the infrastructure we build not exclude possible future key management technologies. Perry PS. Cryptographic algorithms and the like are the BEST understood part of our problem. Our difficulty is not in picking a clever and fast cryptographic algorithm but in embedding it within a good set of conventions for how to use it, or alternatives to it. From ipsec-request@ans.net Tue Aug 2 04:21:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07032 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 14:39:40 -0400 Received: by interlock.ans.net id AA23391 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 14:24:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 14:24:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 14:24:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 14:24:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 14:24:19 -0400 Date: Tue, 2 Aug 94 11:21:25 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408021821.AA09227@miraj.Eng.Sun.COM> To: kent@BBN.COM Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 2145 >From kent@BBN.COM Tue Aug 2 07:47:17 1994 >Ashar, > > I'm a bit confused by the comments about SAIDs being reserved >to indicate a particular key exchange. The idea of an SAID is that it >is selected by the local IPSP entity (IPSPE?) for use as the SOLE >selector for security transformation processing for incoming packets. Yes, I understand that this is the model that one uses with SAIDs and session-oriented key-management. However, this is not the model that SKIP uses, and I am not sure that the IPSP protocol should constrain the meaning of the SAID, simply to rule out SKIP-like key-management. The way the SAID would be used with SKIP is that the SAID is combined with further information following the SAID itself (namely the packet encryption key) to determine how to perform the security transformation. This, I believe, is a more general use of SAIDs than the one you've described above. Certainly, Clause 2 of the 802.10 protocol permits this style of determining how to perform the security transformation (using the MDF field which optionally follows the SAID), and I, for one, would not be happy to see a more restrictive model be part of the IPSP description. In SKIP the security association (as you have described it) exists by virtue of two pieces of information, one of them is an implicit key, and another a packet key which is in the packet. The SAID is being used merely to determine the mode of processing, e.g confidentiality, integrity etc, and thereby types the information following the SAID. My current encryption-only implementation of SKIP in fact has no SAID field. > Was the focus of this discussion the use of SAIDs for the SA >negotiation packets? I don't think we have talked about how the >packets exchanged for SA negotiation are handled, so far, e.g. what >protocol ID is appropriate for them, how are they "bypassed" through >the IPSP layer, etc. No, this was not what I was referring to. Also, in the SKIP model, there is no "bypass" traffic. Is it your view that this usage of SAIDs is inappropriate? If so, how would you use the SAID field with SKIP-like key-management? Ashar. From ipsec-request@ans.net Tue Aug 2 10:22:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40300 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 14:38:18 -0400 Received: by interlock.ans.net id AA20563 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 14:23:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 2 Aug 1994 14:23:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 14:23:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 14:23:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 14:23:09 -0400 Date: Tue, 2 Aug 94 14:22:59 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9408021822.AA24878@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 14:23:09 -0400 To: ipsec@ans.net Subject: just to be clear... Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Just to be clear, the limit of the negotiation I'm envisioning is something on the order of complexity of: requester sends UDP (or similar) packet saying: I can handle this list of security transformations, and I can handle this list of key management protocols. (Implicitly, this is a request to initialize a new SAID.) responder sends UDP packet saying: lets use this transformation, and this key management system. (Possibly the responder notes what SAID it has assigned at this point -- possibly not.) This is just a straw man, understand, but its about the limit of what I believe will be needed. One doesn't need something complicated, but we are far too constrained without such an exchange taking place at all. Perhaps the transform and key management lists should not be in the same packet. Perhaps the SAID comes back in the response, perhaps not. Perhaps a responder initiated version is needed, too. Perhaps information needed to build bi-directional SAs need to be passed -- what I've mentioned has no such data yet, and doesn't provide other needed information. I'm not proposing anything specific yet. I'm just arguing we need such a layer, but that it need not be complex. Perry From ipsec-request@ans.net Tue Aug 2 04:43:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15434 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:01:07 -0400 Received: by interlock.ans.net id AA08466 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 14:43:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 14:43:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 14:43:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 14:43:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 14:43:05 -0400 Date: Tue, 2 Aug 94 11:43:33 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408021843.AA09240@miraj.Eng.Sun.COM> To: perry@imsi.com Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 1476 >From ipsec-request@ans.net Tue Aug 2 11:17:28 1994 >You are assuming people will even necessarily have certificates. I >think its a good bet that they will, but many people would like to >extend the use of kerberos on their LANs to do IPSP key >negotiation. I, for one, have sympathy for this notion, and don't want >to make it impossible, although I think that in an inter-organization >application it isn't practical. I also have sympathy for this notion (and I dont mean that sarcastically :-). I dont believe that in proposing a key-management scheme, my motivation is to disallow other schemes. I believe the goal of the IPSP protocol is explicitly to allow different schemes to be pluggable, and I completely agree with this goal. I do believe, however, as you've noted in your messages and also others have mentioned in the past, that there is a tension between generality and interoperability. We will need to pick specific mechanisms, at some point in time, and they will be dependent on certain algorithms. If there is something that we can come up with, in terms of a specific proposal and software to support that, that makes it easy to transition from one mechanism to another, then I am all for it. Is there a concrete proposal that exists now, or that someone is working on, that meets these requirements of generality? Are you in the process of writing such a proposal? Any pointers to documents, even in draft form, would be appreciated. Ashar. From ipsec-request@ans.net Tue Aug 2 18:56:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17352 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:12:50 -0400 Received: by interlock.ans.net id AA27851 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 14:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 14:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 14:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 14:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 14:57:49 -0400 Message-Id: <9408021856.AA10904@snark.imsi.com> To: ashar@firstperson.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Tue, 02 Aug 1994 11:43:33 PDT." <9408021843.AA09240@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 14:56:45 -0400 From: "Perry E. Metzger" Ashar Aziz says: > If there is something that we can come up with, in terms > of a specific proposal and software to support that, that > makes it easy to transition from one mechanism to another, > then I am all for it. > > Is there a concrete proposal that exists now, > or that someone is working on, that meets these requirements > of generality? Are you in the process of writing such a > proposal? Any pointers to documents, even in draft form, > would be appreciated. No proposal currently exists, to my knowledge. I believe that one is needed, but I would also agree that we can't wait very long for one. I've posted my (EXTREMELY rough) notion of what such a layer would look like, and I would suggest that some of us hash out the notions, possibly in private. Perry From ipsec-request@ans.net Tue Aug 2 19:01:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17138 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:21:45 -0400 Received: by interlock.ans.net id AA24167 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 15:05:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 15:05:41 -0400 Message-Id: <199408021905.AA23389@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Tue, 02 Aug 94 10:27:45 -0700. <9408021727.AA09199@miraj.Eng.Sun.COM> Date: Tue, 02 Aug 94 15:01:33 -0400 From: Steve Kent Ashar, While I certainly agree about the problems of establishing an infrastructure, let me observe that we will almost certainly have multiple certificate systems in place among the (hopefully) wide range of prospective users of IPSP. For example, while a certificate signed with RSA and containing a D-H public key is one reasonable candidate, the DoD is establishing a certificate system win which there are certificates signed by the DSS and containing a KEA public key (plus a DSS public key for signing). So, there are at least two obvious certificate systems that could be widely deployed and which use different key exchange algorithms. Thus some means of specifying what algorithms are being used, even if they cannot be "negotiated" seems like an essential aspect of the security association establishment protocol. Steve From ipsec-request@ans.net Tue Aug 2 19:19:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07038 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:39:30 -0400 Received: by interlock.ans.net id AA23429 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 15:23:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 15:23:08 -0400 Message-Id: <199408021923.AA24705@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Tue, 02 Aug 94 11:21:25 -0700. <9408021821.AA09227@miraj.Eng.Sun.COM> Date: Tue, 02 Aug 94 15:19:13 -0400 From: Steve Kent Ashar, Thanks for clarifying the concern re SAID use. I feel that I have to read the material on SKIP to better understand how general it is and whether accommodating it in IPSP is worth adpoting a different mode of SAIDs. When I alluded to the general notion for SAIDs, I was referring to not only that of SILS, but also NLSP and other association- oriented security protocols. I'm preparing some text on the topic so that folks can see exactly what I think this general model is, as there are some subtle aspects of it that don't seem to have been well articulated in any of the dicusssions on this list, and in several other fora. I don't mean to suggest that other approaches to SAID use should be ruled out at this point, but I'd like to understand whether there are other, comprehensive models for SAIDs that also are generic with regard to key management. It may be the case that we can't come up with an SA management model that meets all of these goals, at which point we may have to decide which goals are most important as a means of selecting an SAID model. Steve From ipsec-request@ans.net Tue Aug 2 20:26:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07068 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:41:48 -0400 Received: by interlock.ans.net id AA27839 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 15:26:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 2 Aug 1994 15:26:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 15:26:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 15:26:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 15:26:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 15:26:27 -0400 From: uri@watson.ibm.com Message-Id: <9408021926.AA13188@buoy.watson.ibm.com> Subject: Re: Thoughts on a basic encryption mode To: kent@BBN.COM (Steve Kent) Date: Tue, 2 Aug 1994 15:26:21 -0500 (EDT) Cc: hughes@hughes.network.com, ipsec@ans.net In-Reply-To: <199408021452.AA25635@interlock.ans.net> from "Steve Kent" at Aug 2, 94 10:49:00 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 Steve Kent says: > I agree with the general thrust of your observations. When I > teach my tutorial on network security, I argue in favor of per-packet > IVs. Without their use, identical prefixes of packets are visible. Doesn't it depend on the encryption algorithm you use? I don't think there even *is* IV for a stream cipher, for example! > pointing out that the FIPS does allow for not using a per-packet IV > with CBC mode, which addresses the concern of Phil and others who want > to be frugal about bandwidth in wireless environments. Why go too far to wireless? (:-) My plain CSLIP wouldn't appreciate extra 8 bytes! -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 2 19:27:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17126 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 15:44:05 -0400 Received: by interlock.ans.net id AA26593 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 15:27:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 15:27:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 15:27:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 15:27:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 15:27:44 -0400 Message-Id: <9408021927.AA10978@snark.imsi.com> To: ashar@firstperson.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Tue, 02 Aug 1994 11:21:25 PDT." <9408021821.AA09227@miraj.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 15:27:32 -0400 From: "Perry E. Metzger" Ashar Aziz says: > The SAID is being used merely to determine the mode of processing, > e.g confidentiality, integrity etc, and thereby types the information > following the SAID. > > My current encryption-only implementation of SKIP in fact has > no SAID field. How does your current implementation deal with the possibility of different encryption algorithms being used at the same time? I noticed you presenting performance figures for several differing algorithms -- DES, RC4, etc, so I assume you have such a provision. Perry From ipsec-request@ans.net Tue Aug 2 20:58:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50187 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 16:14:50 -0400 Received: by interlock.ans.net id AA15031 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 15:58:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 2 Aug 1994 15:58:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 15:58:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 15:58:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 15:58:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 15:58:42 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9408021958.AA44087@hawpub1.watson.ibm.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: (Your message of Tue, 02 Aug 94 15:19:13 D.) <199408021923.AA24705@interlock.ans.net> Date: Tue, 02 Aug 94 15:58:26 -0500 In an earlier note, Perry mentioned that you had a list of requirements for an Internet key management protocol. I was only able to attend one of the ipsec meetings, and I did not hear your list of requirements. If it is not too much typing, would you consider sending out your list for the consideration of others on this list (e.g, me)? Thanks, Charlie P. From ipsec-request@ans.net Tue Aug 2 20:48:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50421 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 17:07:42 -0400 Received: by interlock.ans.net id AA28234 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 16:50:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 16:50:34 -0400 Message-Id: <199408022050.AA24134@interlock.ans.net> To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of Tue, 02 Aug 94 15:26:21 -0500. <9408021926.AA13188@buoy.watson.ibm.com> Date: Tue, 02 Aug 94 16:48:16 -0400 From: Steve Kent Uri, You're right, not all algorithms use IVs in the form we described. In my tutorial I use DES as a pedagogical symmetric algorithm example and review the FIPS 81 modes and their characteristics. However, many algorithms do make use of IVs, not just DES, including some stream ciphers, so the concept, while not universal, is fairly general. I chose wireless as the example that has been cited by Phil, but any low data rate path can raise similar concerns. Unlike the fat addresses in the IPng header, one can't generally compress IVs. Steve From ipsec-request@ans.net Tue Aug 2 21:00:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16972 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 17:14:39 -0400 Received: by interlock.ans.net id AA20416 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 17:00:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 17:00:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 17:00:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 17:00:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 17:00:28 -0400 Message-Id: <9408022100.AA11173@snark.imsi.com> To: perk@watson.ibm.com (Charlie Perkins) Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of "Tue, 02 Aug 1994 15:58:26 CDT." <9408021958.AA44087@hawpub1.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 17:00:18 -0400 From: "Perry E. Metzger" Actually, it was just a list of open issues. Steve Bellovin also presented a list of open issues. Perry Charlie Perkins says: > In an earlier note, Perry mentioned that you had a list of > requirements for an Internet key management protocol. > I was only able to attend one of the ipsec meetings, and > I did not hear your list of requirements. If it is not > too much typing, would you consider sending out your list > for the consideration of others on this list (e.g, me)? > > Thanks, > Charlie P. From ipsec-request@ans.net Tue Aug 2 07:00:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41554 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 17:15:50 -0400 Received: by interlock.ans.net id AA15302 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 17:00:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 17:00:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 17:00:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 17:00:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 17:00:31 -0400 Date: Tue, 2 Aug 94 14:00:54 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408022100.AA09371@miraj.Eng.Sun.COM> To: kent@BBN.COM Subject: Re: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 706 >From kent@BBN.COM Tue Aug 2 12:24:37 1994 > I don't mean to suggest that other approaches to SAID use >should be ruled out at this point, but I'd like to understand whether >there are other, comprehensive models for SAIDs that also are generic >with regard to key management. It may be the case that we can't come >up with an SA management model that meets all of these goals, at which >point we may have to decide which goals are most important as a means >of selecting an SAID model. Sounds like a reasonable approach. One of the things that I would like in the comparison list of SAID models is how well that model works for encrypted multicast IP with key-seeded stream ciphers like RC4. Ashar. From ipsec-request@ans.net Tue Aug 2 21:35:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16718 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 17:51:30 -0400 Received: by interlock.ans.net id AA15322 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 17:36:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 2 Aug 1994 17:36:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 2 Aug 1994 17:36:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 2 Aug 1994 17:36:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 17:36:21 -0400 Message-Id: <9408022135.AA11252@snark.imsi.com> To: Steve Kent Cc: uri@watson.ibm.com, ipsec@ans.net Subject: Re: Thoughts on a basic encryption mode In-Reply-To: Your message of "Tue, 02 Aug 1994 16:48:16 EDT." <199408022050.AA24134@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Aug 1994 17:35:27 -0400 From: "Perry E. Metzger" Steve Kent says: > You're right, not all algorithms use IVs in the form we > described. In my tutorial I use DES as a pedagogical symmetric > algorithm example and review the FIPS 81 modes and their > characteristics. However, many algorithms do make use of IVs, not > just DES, including some stream ciphers, so the concept, while not > universal, is fairly general. In any case, since we are descussing the packet format for a specific security transform (whether the DES security transform packet format needs an IV), the decision is specific to the algorithm in question. One of the great things about the encapsulation and authentication headers we picked is their ability to allow us to choose the features we need for any specific security transform. For IPSP using SEAL, say, an IV may become meaningless, but the format can simply not provide for one and all is well. Perry From ipsec-request@ans.net Tue Aug 2 22:01:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01693 (5.65c/IDA-1.4.4 for ); Tue, 2 Aug 1994 18:16:03 -0400 Received: by interlock.ans.net id AA26605 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Aug 1994 18:02:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Aug 1994 18:02:01 -0400 Message-Id: <199408022202.AA28393@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Tue, 02 Aug 94 14:00:54 -0700. <9408022100.AA09371@miraj.Eng.Sun.COM> Date: Tue, 02 Aug 94 18:01:53 -0400 From: Steve Kent Ashar, What I am preparing is a description of what I think of as the most common SAID model. I was not offering to provide a comparative analysis of this versus other models that, I argue, are not well articulated. Once I have provided this text, we could use it as a basis for describing other models, at least in so far as other descriptions should cover all of the points in my text. As for your "test case," I think it is one of several that we should examine in determining the suitability of any SAID model, but the group needs to decide, later, whether an inability to support any of the examples we may cook up constitutes a fatal flaw. Steve From ipsec-request@ans.net Wed Aug 3 07:26:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16943 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 03:43:03 -0400 Received: by interlock.ans.net id AA13798 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 03:26:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 03:26:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 03:26:32 -0400 Date: Wed, 3 Aug 1994 03:26:30 -0400 From: *Hobbit* Message-Id: <199408030726.DAA00899@asylum.sf.ca.us> To: ipsec@ans.net Subject: IVs how about inserting two or maybe four bytes of "confounder", a la Kerberos, before the actual packet, and throwing them away after decryption? Minimal overhead, and they can be essentially random. If a single PRNG is used to seed all the packets going out of an IPSP box, the confounders will be even more random if it's talking to more than one place... _H* From ipsec-request@ans.net Wed Aug 3 15:11:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43491 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 10:27:37 -0400 Received: by interlock.ans.net id AA29781 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:12:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:12:50 -0400 To: ipsec@ans.net Subject: reserving some SAIDs Date: Wed, 3 Aug 94 15:11:46 GMT From: Ran Atkinson Sender: atkinson@sundance.itd.nrl.navy.mil Message-Id: <9408031511.aa16550@sundance.itd.nrl.navy.mil> One subject that I've been asked about several times by IPv6 folks is whether we could reserve some SAID values. These could be used for predefined meanings (e.g. use RSA with the public keys from the DNS to encrypt/decrypt this packet). In the IPv6 drafts I'm proposing to reserve 0xFFFFFF01 through 0xFFFFFFFF for future use along these lines. Comments ?? Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Aug 3 15:20:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48182 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 10:35:16 -0400 Received: by interlock.ans.net id AA27432 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:22:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:22:53 -0400 To: ipsec@ans.net Subject: IPSP & IPv6 Date: Wed, 3 Aug 94 15:20:43 GMT From: Ran Atkinson Sender: atkinson@sundance.itd.nrl.navy.mil Message-Id: <9408031520.aa16555@sundance.itd.nrl.navy.mil> At the IPv6 Implementers meeting on Friday morning I gave a quick overview of the IPSP proposal discussed at the end of the encapsulation meeting last week (e.g. the packet format and basic operation outline). There was extensive discussion from the audience, most all of whom have SIP-8, SIPP-8, or SIPP-16 code somewhat working. After the discussion, there was broad consensus on the packet format outlined below. It isn't clear to me that this format is necessarily best for IPv4. It also isn't clear to me that IPv4 and IPv6 need to have the same packet formats, understanding that there is a lot of value in having the same mechanisms for both even though bit formats might vary slightly. The IPv6 alignment concerns run very deep as you'll see below. Discussion on this is solicited. Proposed IPv6 SP packet format: +--------+--------+---------+---------+ | Security Association ID | (32 bits) +--------+--------+---------+---------+ | Algorithm-dependent init stuff | (variable number of 64 bit doublewords) +--------+--------+---------+---------+ |Next Hdr| Length | Reserved | (8/8/16 bits; per usual IPv6 practice) +--------+--------+---------+---------+ | TCP/UDP payload or header indicated | + | (variable size) | by Next Hdr value above | +--------+--------+---------+---------+ | Algorithm-dependent trailing stuff | (variable size, would put padding +--------+--------+---------+---------+ for block-mode algorithms here, etc) Thanks, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Aug 3 14:39:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01670 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 10:47:37 -0400 Received: by interlock.ans.net id AA19159 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:32:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 10:32:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 10:32:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:32:31 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408030939.ZM15973@hughes.network.com> Date: Wed, 3 Aug 1994 09:39:14 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: IPSEC@ans.net Subject: SKIP presentation available in postscript Cc: ashar@firstperson.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 --- Forwarded mail from ashar@FirstPerson.COM (Ashar Aziz) The postscript of the Toronto IETF presentation slides on SKIP to the ipsec working group on key-management is now available for anonymous ftp. --- End of forwarded mail from ashar@FirstPerson.COM (Ashar Aziz) The document skip_slides.ps can be retrieved from ftp.network.com, user anonymous directory IETF/IPSEC. The document can also be accessed via WWW as ftp://ftp.network.com/IETF/IPSEC/skip_slides.ps If you have any problems, please let me know. jim From ipsec-request@ans.net Wed Aug 3 14:44:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44569 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:02:53 -0400 Received: by interlock.ans.net id AA15296 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:47:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:47:30 -0400 Message-Id: <199408031447.AA24252@interlock.ans.net> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Wed, 03 Aug 94 15:11:46 +0000. <9408031511.aa16550@sundance.itd.nrl.navy.mil> Date: Wed, 03 Aug 94 10:44:36 -0400 From: Steve Kent Ran, I'd feel much more comfortable if there was a lot of explanation to match the request (the same way Jon Postel used to ask the requestior of a class A network number why they wanted to many addresses). The form of the explanation would not just be what combination of algorithms they are thinking about, but how the reservation of this big chunk of the SAID space fits in with the problem of establishing the overall set of attributes that are bound to an SA, why it's necessary to fix bit for these specific attributes when there are lots of others that need to be specified, how management of SAIDs by the IPSP end points is simplified by this a priori assigment, etc. If we start fixing bits in SAIDs to mean specific things re key management, we can chop up this space in a hurry. When I said I could live with fewer SAID bits, I did not envision this sort of pre-allocation. Steve From ipsec-request@ans.net Wed Aug 3 14:46:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44585 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:04:43 -0400 Received: by interlock.ans.net id AA29904 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:48:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:48:34 -0400 Message-Id: <199408031448.AA08394@interlock.ans.net> To: *Hobbit* Cc: ipsec@ans.net Subject: Re: IVs In-Reply-To: Your message of Wed, 03 Aug 94 03:26:30 -0400. <199408030726.DAA00899@asylum.sf.ca.us> Date: Wed, 03 Aug 94 10:46:26 -0400 From: Steve Kent An IV serves the same purpose as the confounder. If one wants to use smaller IVs that the 64 bit nominal size defined for the DES, then one can fix part of the IV, either as part of a spec or during SA establishment, and transmit fewer IV bits on a per packet basis. Steve From ipsec-request@ans.net Wed Aug 3 14:57:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41688 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:11:25 -0400 Received: by interlock.ans.net id AA25673 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 10:57:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 3 Aug 1994 10:57:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 10:57:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 10:57:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 10:57:16 -0400 Message-Id: <9408031457.AA12450@snark.imsi.com> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Wed, 03 Aug 1994 15:11:46 GMT." <9408031511.aa16550@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 03 Aug 1994 10:57:04 -0400 From: "Perry E. Metzger" Ran Atkinson says: > > One subject that I've been asked about several times by IPv6 folks > is whether we could reserve some SAID values. These could be > used for predefined meanings (e.g. use RSA with the public keys > from the DNS to encrypt/decrypt this packet). In the IPv6 drafts > I'm proposing to reserve 0xFFFFFF01 through 0xFFFFFFFF for future > use along these lines. I think reserved ranges may make some sense, but I'm not sure that they are needed for the proposed purpose -- after all, it only takes one packet to request a SAID assignment from the counterparty, and only one to get one back -- pre-assigning meanings doesn't seem that worth while given this. Can you envision a set of conditions that might make exchange of such information impractical? Perry From ipsec-request@ans.net Wed Aug 3 15:00:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17132 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:15:38 -0400 Received: by interlock.ans.net id AA19885 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:02:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 11:02:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 11:02:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:02:15 -0400 Message-Id: <9408031500.AA15655@skidrow.lkg.dec.com> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Wed, 03 Aug 94 15:11:46 GMT." <9408031511.aa16550@sundance.itd.nrl.navy.mil> Date: Wed, 03 Aug 94 11:00:33 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I haven't been keeping up with the ipsec stuff due to overload but I think this is an excellent idea. (See the "global SAID" idea in my incomplete PIPS proposal.) To my mind, any complete IP security proposal must make it possible to send an isolated datagram without end to end set up. This sort of thing is the only way I can see to achieve that. Donald From: Ran Atkinson To: ipsec@ans.net Sender: atkinson@sundance.itd.nrl.navy.mil > >One subject that I've been asked about several times by IPv6 folks >is whether we could reserve some SAID values. These could be >used for predefined meanings (e.g. use RSA with the public keys >from the DNS to encrypt/decrypt this packet). In the IPv6 drafts >I'm proposing to reserve 0xFFFFFF01 through 0xFFFFFFFF for future >use along these lines. > >Comments ?? > >Ran >atkinson@itd.nrl.navy.mil > From ipsec-request@ans.net Wed Aug 3 11:18:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50187 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:18:07 -0400 Received: by interlock.ans.net id AA16344 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:04:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 11:04:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 11:04:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:04:10 -0400 Date: Wed, 03 Aug 94 07:24:05 From: "Housley, Russ" Encoding: 1912 Text Message-Id: <9407037759.AA775923845@uu0892.spyrus.com> To: ashar@firstperson.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re[2]: SIPP and SKIP. 2 subjects. Ashar: You said: >> I'm a bit confused by the comments about SAIDs being reserved >>to indicate a particular key exchange. The idea of an SAID is that it >>is selected by the local IPSP entity (IPSPE?) for use as the SOLE >>selector for security transformation processing for incoming packets. > >Yes, I understand that this is the model that one uses with SAIDs >and session-oriented key-management. However, this is not the >model that SKIP uses, and I am not sure that the IPSP protocol >should constrain the meaning of the SAID, simply to rule out >SKIP-like key-management. > >The way the SAID would be used with SKIP is that the SAID is >combined with further information following the SAID >itself (namely the packet encryption key) to determine how to >perform the security transformation. > >This, I believe, is a more general use of SAIDs than the one >you've described above. Certainly, Clause 2 of the 802.10 >protocol permits this style of determining how to perform the >security transformation (using the MDF field which optionally >follows the SAID), and I, for one, would not be happy to see >a more restrictive model be part of the IPSP description. You are correct that the MDF follows the SAID in IEEE 802.10b (a.k.a. Secure Data Exchange (SDE)). However, your discussion does not point out that the MDF must be a constant for a given security association. That means that a particular SAID vlaue must be followed by the same MDF value forever. DEC wanted this capability in the standard to support a scheme where the SAID specified a key encryption key. The MDF contained the traffic key (and possibly an integrity algorithm key as well), and the key(s) were encrypted in the key encryption key specified by the SAID. I do not think that a few reserved SAID values will provide the capability that you want... Russ From ipsec-request@ans.net Wed Aug 3 11:19:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50194 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:19:26 -0400 Received: by interlock.ans.net id AA26606 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:05:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 11:05:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 11:05:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:05:00 -0400 Date: Wed, 03 Aug 94 07:24:09 From: "Housley, Russ" Encoding: 1467 Text Message-Id: <9407037759.AA775923849@uu0892.spyrus.com> To: sils@arc.nasa.gov, ipsec@ans.net, psrg-interest@isi.edu Subject: Fwd: Lawsuits Against PKP Anyone know any more about these? ---------- From: Bruce Schneier To: Subject: Lawsuits Against PKP Date: Sunday, July 31, 1994 11:55PM Two lawsuits were recently filed in federal court, northern district of Calif, which may cripple Public Key Partners. Cylink v. RSA Data Security, C-94-02332-CW, June 30, 1994, San Fran. It alleges that the RSA patent is invalid. RSA Data had denied Cylink a patent license. Schlafly v. Public Key Partners, C-94-20512-SW, July 27, 1994, San Jose. It alleges that almost all of the PKP patent claims are invalid and unenforceable. From the complaint: Plaintiff makes complaint against defendants for unfair business practices, including libel, interference with contractual relationships, patent misuse, fraud, monopolization, and racketeering, and demands remedies available under federal law, including jury trial, declaratory judgment, monetary damages, and injunctive relief. You can probably get a copy from the court by calling Kinko's, 408-279-0655, 408-295-4336 fax. Ask for document #1. It is bulky, at about 270 pages. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier@chinet.com ************************************************************************** From ipsec-request@ans.net Wed Aug 3 15:04:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48148 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:19:27 -0400 Received: by interlock.ans.net id AA23786 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:04:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 3 Aug 1994 11:04:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 11:04:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 11:04:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:04:51 -0400 Message-Id: <9408031504.AA12473@snark.imsi.com> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: IPSP & IPv6 In-Reply-To: Your message of "Wed, 03 Aug 1994 15:20:43 GMT." <9408031520.aa16555@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 03 Aug 1994 11:04:04 -0400 From: "Perry E. Metzger" Ran Atkinson says: > At the IPv6 Implementers meeting on Friday morning I gave a quick > overview of the IPSP proposal discussed at the end of the encapsulation > meeting last week (e.g. the packet format and basic operation outline). [...] > After the discussion, > there was broad consensus on the packet format outlined below. I'm glad that there was consensus, since this is the same format we agreed on in the IPSP meeting, other than the fact that we declared everyting past the SAID to be association and security transformation dependant -- I believe that the intention was that the opaque part be formatted as you specify, but that since the region was "opaqued" by the security transformation one wouldn't NECESSARILY know that. > It isn't clear to me that this format is necessarily best for IPv4. Its not necessarily IDEAL, but it seems close enough, to me, that having a different layout of the bits doesn't make much sense, especially since v4 is doomed in the long run. > It also isn't clear to me that IPv4 and IPv6 need to have the same > packet formats, understanding that there is a lot of value in having > the same mechanisms for both even though bit formats might vary > slightly. Well, having the same format will probably facilitate some kinds of code sharing and there doesn't seem to be much of a point in having a different format. Perry From ipsec-request@ans.net Wed Aug 3 15:25:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15498 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:41:24 -0400 Received: by interlock.ans.net id AA12995 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:28:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 11:28:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 11:28:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:28:07 -0400 Message-Id: <9408031525.AA16374@skidrow.lkg.dec.com> To: Steve Kent Cc: Ran Atkinson , ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Wed, 03 Aug 94 10:44:36 EDT." <199408031447.AA24252@interlock.ans.net> Date: Wed, 03 Aug 94 11:25:03 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, Maybe I'm confused. I understood the proposal to be to reserve a tiny part of the SAID space, 16 values out of 2**32, for the same purpose as the global SAIDs servered in my PIPS proposal. Donald From: Steve Kent To: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: Your message of Wed, 03 Aug 94 15:11:46 +0000. <9408031511.aa16550@sundance.itd.nrl.navy.mil> >Ran, > > I'd feel much more comfortable if there was a lot of >explanation to match the request (the same way Jon Postel used to ask >the requestior of a class A network number why they wanted to many >addresses). The form of the explanation would not just be what >combination of algorithms they are thinking about, but how the >reservation of this big chunk of the SAID space fits in with the >problem of establishing the overall set of attributes that are bound >to an SA, why it's necessary to fix bit for these specific attributes >when there are lots of others that need to be specified, how >management of SAIDs by the IPSP end points is simplified by this a >priori assigment, etc. If we start fixing bits in SAIDs to mean >specific things re key management, we can chop up this space in a >hurry. When I said I could live with fewer SAID bits, I did not >envision this sort of pre-allocation. > >Steve From ipsec-request@ans.net Wed Aug 3 16:46:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48362 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 11:58:12 -0400 Received: by interlock.ans.net id AA08986 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 11:45:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 11:45:47 -0400 Subject: Re: IPSP & IPv6 To: perry@imsi.com Date: Wed, 3 Aug 1994 11:46:28 -0500 (EST) From: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: <9408031504.AA12473@snark.imsi.com> from "Perry E. Metzger" at Aug 3, 94 11:04:04 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1685 Message-Id: <9408031646.aa16815@sundance.itd.nrl.navy.mil> Perry, There are some who believe that the extra bits used by the format I posted are not appropriate for low bandwidth links, in particular for existing 2400 baud radio links currently used to carry TCP/IP. I think you will find that not everyone agrees on the layout and use of the first 32-bits inside the protected data area shown on my diagram. I certainly heard several different points of view on that in the IPSP meeting. Code to parse these headers is the easy part of IPSP so I don't find "code sharing" to be a persuasive argument that IPv4 and IPv6 must have the same packet format. I'm not against having the same format, but code sharing doesn't seem like a very solid justification IMHO. The allocation of Next-Header/Length/Reserved inside the protected area as the first 32-bits is MANDATORY for all IPSP usage with IPv6 in the opinion of the IPv6 implementers meeting. Also, the IPSP meeting talked about the first algorithm-dependent field (right after SAID) as variable length and the IPv6 Implementers want that field to be variable with the restriction of _always_ being a multiple of 64 bits (the meaningful data within that field might not be the entire field size of course since not all algorithms are 64-bit aligned :-). It is not clear that IPv4 SP and IPv6 SP are necessarily identical in these areas. I'm not trying to impede progress, just trying to inform folks of the IPv4/IPv6 convergence issues so that they can be discussed. I think there is uniform consensus amongst all on the principles of operation, we're just talking about packet format differences as near as I can tell right now. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Aug 3 16:17:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16909 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 12:35:29 -0400 Received: by interlock.ans.net id AA27066 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 12:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 3 Aug 1994 12:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 12:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 12:20:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 12:20:24 -0400 Message-Id: <9408031617.AA12644@snark.imsi.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: Ran Atkinson , ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Wed, 03 Aug 1994 11:00:33 EDT." <9408031500.AA15655@skidrow.lkg.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 03 Aug 1994 12:17:39 -0400 From: "Perry E. Metzger" "Donald E. Eastlake 3rd (Beast)" says: > To my mind, any complete IP security proposal must make it possible to > send an isolated datagram without end to end set up. This sort of > thing is the only way I can see to achieve that. You have to exchange packets with KDCs or key servers to get keys, so you are already experiencing some traffic overhead. SAID setup can likely be accomplished with the exchange of one datagram -- this is hardly high overhead, especially since a SAID is typically a fairly long lived thing compared to the length of the exchange. The model, as I understood it originally, was that SAIDs were assigned by the receiver in any way the receiver saw fit. Is there a really good reason to abandon this? Perry From ipsec-request@ans.net Wed Aug 3 12:35:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16914 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 12:35:46 -0400 Received: by interlock.ans.net id AA30935 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 12:22:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 12:22:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 12:22:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 12:22:01 -0400 Date: Wed, 03 Aug 94 08:39:06 From: "Housley, Russ" Encoding: 2670 Text Message-Id: <9407037759.AA775928346@uu0892.spyrus.com> To: ipsec@ans.net, Ran Atkinson Subject: Re: reserving some SAIDs Ran: Since you have chosen to use a 32 bit SAID (the same size as the IEEE 802.10 SAID), I suggest that you consider the reserved SAIDs that IEEE 802.10 has set aside. Here is what is says on page 12 of IEEE Std 802.10-1992: The SAID fields identifies the security association. It contains the SAID associated with the destination SDE entity. If the destination is a group address, the SAID value is common for all the stations in the group and is negotiated by key management or system management. The SAID field is four octets in length and is mandatory when the Clear Header is present. Figure 2-5 -- SAID Format {The figure names the most significant bit the G-bit, and it names the rest of the bits the ID bits. When the G-bit is zero, the SAID denotes an individual security association. When the G-bit is one, the SAID denotes a group security association.} Four SAID values are reserved for the purpose of establishing initial communication with key management or system management when an SAID has not already been negotiated. These SAID values are called "bootstrap" SAIDs, and identify preestablished security associations. If the bootstrap SAID is used for key management, the ID bits contain all zeros. If the bootstrap SAID is used for system management, the ID bits contain all ones. The use of the bootstrap SAID mechanism is optional. Communication to the System management and Key Management Stacks may be accomplished via the use of any security association whose SDE_SAP object indicates the appropriate stack. Also note that the function of key management or system management can reside on a User stack; however, the bootstrap SAIDs cannot be used to support those implementations. If you do not choose to follow these rules, please do not reuse the four bootstrap SAIDs. Keep them reserved. Russ ______________________________ Reply Separator _________________________________ Subject: reserving some SAIDs Author: Ran Atkinson at internet Date: 8/3/94 3:11 PM One subject that I've been asked about several times by IPv6 folks is whether we could reserve some SAID values. These could be used for predefined meanings (e.g. use RSA with the public keys from the DNS to encrypt/decrypt this packet). In the IPv6 drafts I'm proposing to reserve 0xFFFFFF01 through 0xFFFFFFFF for future use along these lines. Comments ?? Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Aug 3 17:25:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44894 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 13:42:14 -0400 Received: by interlock.ans.net id AB29904 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 13:26:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 13:26:54 -0400 Message-Id: <199408031726.AA19916@interlock.ans.net> To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Wed, 03 Aug 94 11:25:03 -0400. <9408031525.AA16374@skidrow.lkg.dec.com> Date: Wed, 03 Aug 94 13:25:46 -0400 From: Steve Kent Don, The path advocated by the approach Ran forwarded would use bits to convey SA-specific parameters. There are lots of these parameters. So, unless we are going to favor just a few parameters and just a few algorithms with their own reserved bits, we will quickly start using up large chunks of the SAID space. Steve From ipsec-request@ans.net Wed Aug 3 17:28:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41583 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 13:45:26 -0400 Received: by interlock.ans.net id AA31019 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 13:32:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 13:32:05 -0400 Message-Id: <199408031732.AA12838@interlock.ans.net> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: IPSP & IPv6 In-Reply-To: Your message of Wed, 03 Aug 94 11:46:28 -0500. <9408031646.aa16815@sundance.itd.nrl.navy.mil> Date: Wed, 03 Aug 94 13:28:16 -0400 From: Steve Kent Ran, I think having a common format for IPSP in the IPv4 and IPv6 contexts would be especially useful if there is any way for transition strategies to take advantage of the uniformity. Steve From ipsec-request@ans.net Wed Aug 3 08:08:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44888 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 18:26:55 -0400 Received: by interlock.ans.net id AA22574 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 18:08:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 3 Aug 1994 18:08:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 18:08:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 18:08:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 18:08:21 -0400 Date: Wed, 3 Aug 94 15:08:47 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408032208.AA10162@miraj.Eng.Sun.COM> To: housley@spyrus.com Subject: Re: Re[2]: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 1179 >From housley@spyrus.com Wed Aug 3 08:05:05 1994 >You are correct that the MDF follows the SAID in IEEE 802.10b (a.k.a. >Secure Data Exchange (SDE)). However, your discussion does not point out >that the MDF must be a constant for a given security association. That >means that a particular SAID vlaue must be followed by the same MDF value >forever. Where exactly in the 802.10 standard does it say this? (I dont have it handy, so I cant check). >DEC wanted this capability in the standard to support a scheme where the >SAID specified a key encryption key. The MDF contained the traffic key >(and possibly an integrity algorithm key as well), and the key(s) were >encrypted in the key encryption key specified by the SAID. I am not sure I understand this. If the MDF is to remain constant for a security association, and the SAID identifies the key-encrypting key, then the only time the traffic key (which is in the MDF) can be changed is when the key-encrypting-key changes. What is the value of separating the two keys then? >I do not think that a few reserved SAID values will provide the capability >that you want... Why? Could you elaborate? Ashar. From ipsec-request@ans.net Thu Aug 4 00:45:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02358 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 21:02:56 -0400 Received: by interlock.ans.net id AA23681 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 20:45:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 20:45:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 20:45:25 -0400 Date: Wed, 3 Aug 1994 17:45:51 -0700 From: Phil Karn Message-Id: <199408040045.RAA09740@servo.qualcomm.com> To: kent@BBN.COM Cc: hobbit@asylum.sf.ca.us, ipsec@ans.net In-Reply-To: <199408031448.AA08394@interlock.ans.net> (message from Steve Kent on Wed, 03 Aug 94 10:46:26 -0400) Subject: Re: IVs How about if we just use the outer (plaintext) IP ID field as a confounder/IV? After all, it's free, and when combined with the source IP address it's intended to make each packet relatively unique. I know it's only 16 bits, but that still gives us 65536 unique packet IVs. Simply rekeying (e.g., creating new SAIDs) more often than that will take care of the rest. Phil From ipsec-request@ans.net Thu Aug 4 01:55:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17039 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 22:15:09 -0400 Received: by interlock.ans.net id AA20425 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 21:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 21:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 21:58:38 -0400 Date: Wed, 3 Aug 1994 18:55:19 -0700 From: Phil Karn Message-Id: <199408040155.SAA09786@servo.qualcomm.com> To: dee@skidrow.lkg.dec.com Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <9408031500.AA15655@skidrow.lkg.dec.com> (dee@skidrow.lkg.dec.com) Subject: Re: reserving some SAIDs >To my mind, any complete IP security proposal must make it possible to >send an isolated datagram without end to end set up. This sort of >thing is the only way I can see to achieve that. I'm sympathetic, but I'm concerned that this sort of facility is inherently susceptible to active sabotage. Although verifying an RSA signature is much faster than generating one, I suspect I can generate random "signed" packets with random IP source addresses much faster than you can execute your RSA "verify" routine. If I lob these at your machine long enough, eventually you'll give up and "go clear" just to get some useful work done -- which is precisely the idea of the attack. Active sabotage may be relatively rare now, but just wait until we plug up the "easy" holes like sniffer attacks. The potential may not be unique to the Internet, but I think it's a safe bet that it'll happen here first. That's why we really need to be sensitive to it in our designs. I've seen very little of it in other security standards, which is one reason we need our own. Phil From ipsec-request@ans.net Thu Aug 4 04:38:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34923 (5.65c/IDA-1.4.4 for ); Wed, 3 Aug 1994 23:54:49 -0400 Received: by interlock.ans.net id AA25696 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 23:38:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 3 Aug 1994 23:38:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 3 Aug 1994 23:38:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 3 Aug 1994 23:38:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 23:38:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 23:38:39 -0400 From: uri@watson.ibm.com Message-Id: <9408040338.AA16410@buoy.watson.ibm.com> Subject: Re: IVs To: karn@qualcomm.com (Phil Karn) Date: Wed, 3 Aug 1994 23:38:32 -0500 (EDT) Cc: kent@BBN.COM, hobbit@asylum.sf.ca.us, ipsec@ans.net In-Reply-To: <199408040045.RAA09740@servo.qualcomm.com> from "Phil Karn" at Aug 3, 94 05:45:51 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 Phil Karn says: > How about if we just use the outer (plaintext) IP ID field as a > confounder/IV? After all, it's free, and when combined with the source > IP address it's intended to make each packet relatively unique. > I know it's only 16 bits, but that still gives us 65536 unique packet > IVs. Simply rekeying (e.g., creating new SAIDs) more often than that > will take care of the rest. I'm all for it. -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Wed Aug 3 19:46:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02313 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 00:03:56 -0400 Received: by interlock.ans.net id AA09403 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Aug 1994 23:46:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Aug 1994 23:46:02 -0400 Message-Id: <199408040346.AA05047@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Aug 1994 23:46:02 -0400 Date: Wed, 3 Aug 94 23:46:05 EDT From: hugo@watson.ibm.com To: ipsec@ans.net Subject: working keys The purpose of this note is to open a discussion on the need for freshness in the keys used by IPSP to compute the different cryptographic functions (encryption, authentication, etc), and ways to achieve this freshness. Let me stress from the beginning that (IMHO) this is not a high level issue but an essential piece in the basic key management required by IPSP. Although, there have been discussions in the list about the purpose, structure and information in the SAID, I saw no discussion on the ways in which two parties decide on their common keys for application to the security transformations, and how this information is carried in the SAID. I am NOT referring here to the way two parties exchange A FIRST SHARED KEY (that is a more complex/controversial issue about particular public-key techniques, the support of key distribution centers, etc). I mean, how the parties derive session keys (or working keys) from an already "master shared key". (Since sharing a key using PK or KDC techniques may be expensive, one would want to expose this key to a minimum, e.g. use it just to derive other "working keys"). The only implicit solution on this issue that was considered is the one proposed by Ashar in SKIP. Namely, the sender encrypts the (working) encryption key (what about authentication key?) under the "master" shared key (which in case of SKIP is derived from the public/private keys of the parties) and attaches these encrypted key(s) to the (encrypted) IP packet. This "one-way solution" can be useful and desirable in some cases but it lacks the level of security desirable and affordable in many, possibly most, cases. A basic problem with this one-way solution is the fact that an adversary that gets to know one encryption/authentication key from the past can reuse it to send encrypted/authenticated information of its choice without the receiver being able to detect the cheating. (A sound cryptographic design needs to provide protection against re-use of past compromised keys; compromise can come from temporary breaks into an interent node, cryptanalysis, etc) These problems can be solved via mechanisms for key refreshment in which the parties re-share keys such that the compromise of old keys doesn't help reusing them or breaking the new ones. We have presented such a key refreshment mechanism in our proposal (let's call it STEP: Secure Tunnel Establishment Protocol) during the IETF. Indeed, whoever was there (or saw our posting to the list on 6/1/94) could notice the simplicity of that protocol (it appears in our proposal as a sub-protocol for session-key establishment). Although this solution requires interaction between the parties, it is very efficient (in particular, uses no public-key operations) and needs to be done only periodically (the frequency would be a function of the security the specific parties require). The same interaction can also carry negotiation of other parameters like crypto algorithms, length of keys, expiration of keys, etc. We intend to post to the list a more complete proposal in this sense, but we are interested in comments people may already have on this kind of approach. In particular, how SAIDs should be used to carry information about the key in use. Hugo From ipsec-request@ans.net Thu Aug 4 13:45:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA45038 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 10:05:19 -0400 Received: by interlock.ans.net id AA22693 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 09:46:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 09:46:43 -0400 Message-Id: <199408041346.AA32673@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: Re[2]: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Wed, 03 Aug 94 15:08:47 -0700. <9408032208.AA10162@miraj.Eng.Sun.COM> Date: Thu, 04 Aug 94 09:45:50 -0400 From: Steve Kent Ashar, DEC devised a clever way to use per-SA keys, without requiuring each SDE entity to have a table of the keys. The approach used was to transmit the session (per-SA) key encrypted in the master key of the receiving SDE entity. This encrypted form of the session key was supplied by the receiving entity itself (so there is no need to shre this master key) as part of SA establishment. The session key was constant for the duration of the SA, but each new SA can have a new session key. This is consistent with the commnet Russ made about the MDF vaule being constant per SA. Steve From ipsec-request@ans.net Thu Aug 4 06:06:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38469 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 10:16:14 -0400 Received: by interlock.ans.net id AA15173 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 10:06:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 10:06:20 -0400 Message-Id: <199408041406.AA20289@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 10:06:20 -0400 Date: Thu, 4 Aug 94 10:06:22 EDT From: amir@watson.ibm.com To: ipsec@ans.net Subject: Re: reserving some SAIDs (re: Karn re: dee re: Ran...) Summary: Ran suggested to keep a block of SAIDs reserved, e.g. to indicate this message is encrypted with RSA key to be got from DNS. Donald said this is great as it would allow datagrams w/o any setup. Phil raised concern this would allow a clogging attack which would cause the hosts to give up on verification. I argue below that this is a valid concern in general, but does not have to prevent such an optional datagram service; if clogged, the host would _not_ allow this service. Details follow. I agree with Phil, that (this kind of) denial of service may become common, partially as a way to make a site remove defenses. In fact this is a well known technique which _is_ in use to defeat link level encryption, and in fact it is extremely successful and hard to protect against. However, I also agree with Ran and Donald that such a datagram service without any setup may be useful. I suggest such a service would be an option that the host would disable if clogged by too many requests, either valid or invalid. This can not, therefore, be our only means of IP layer security; in fact, since this is a very computationally intensive solution, clearly we must support a set up mechanism too. One question remains: how many SAIDs should be reserved for such uses? Here I agree with Steve: we should be careful in justifying any pre-assignments. It appears that for this `datagram' function, we need only ONE special SAID. Ran, could you explain why you want to reserve such a large number of SAIDs? We need these bits for their `basic' use, too... Best, Amir Herzberg p.s. I hope my summary above accurately reflects the positions of the authors. I tried to help the reader... Hope I did not mislead. From ipsec-request@ans.net Thu Aug 4 06:24:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17016 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 10:37:36 -0400 Received: by interlock.ans.net id AA19624 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 10:25:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 10:25:41 -0400 Message-Id: <199408041425.AA19620@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 10:25:41 -0400 To: Steve Kent Cc: Ashar Aziz , ipsec@ans.net Subject: Re: Re[2]: SIPP and SKIP. 2 subjects. Date: Thu, 04 Aug 94 10:24:30 EDT Ashar, DEC devised a clever way to use per-SA keys, without requiuring each SDE entity to have a table of the keys. The approach used was to transmit the session (per-SA) key encrypted in the master key of the receiving SDE entity. This encrypted form of the session key was supplied by the receiving entity itself (so there is no need to shre this master key) as part of SA establishment. The session key was constant for the duration of the SA, but each new SA can have a new session key. This is consistent with the commnet Russ made about the MDF vaule being constant per SA. To fit our precise model, that would require a 64-bit SAID. From ipsec-request@ans.net Thu Aug 4 14:20:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39303 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 10:38:13 -0400 Received: by interlock.ans.net id AA19913 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 10:28:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 10:28:08 -0400 Message-Id: <199408041428.AA07365@interlock.ans.net> To: hugo@watson.ibm.com Cc: ipsec@ans.net Subject: Re: working keys In-Reply-To: Your message of Wed, 03 Aug 94 23:46:05 -0400. <199408040346.AA05047@interlock.ans.net> Date: Thu, 04 Aug 94 10:20:37 -0400 From: Steve Kent Hugo, In general, I think the SAID model assumes that an SAID identifies the session key to be used, along with all of the other parameters of the SA. So, under this model, if you change session keys, you change SAIDs, because the SA parameters have changed. Changing over from one SA to another is a clean way to change keys, as it means that any packets processed under the old key are cleanly identified and, after a "grace period" the old SA can be terminated and the old keys will go away. That seems easier than trying to co-ordinate key changeover within a fixed SA, given that the model we have for SA management does not assume SA management packets will be transmitted over the same IP "flow" as the SA packets. Steve From ipsec-request@ans.net Thu Aug 4 15:40:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14245 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 10:50:52 -0400 Received: by interlock.ans.net id AA20419 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 10:39:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 10:39:23 -0400 Subject: Re: reserving some SAIDs (re: Karn re: dee re: Ran...) To: amir@watson.ibm.com Date: Thu, 4 Aug 1994 10:40:02 -0500 (EST) From: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: <199408041406.AA20289@interlock.ans.net> from "amir@watson.ibm.com" at Aug 4, 94 10:06:22 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 326 Message-Id: <9408041540.aa18321@sundance.itd.nrl.navy.mil> Amir & Steve Kent, What number of reserved SAIDs would you consider appropriate ? Btw, I agree with Phil that the active attack threat on predetermined SAID traffic is a serious problem that must be discussed and adequately resolved before we get too far down the Reserved SAID road. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Aug 4 14:47:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39232 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:02:52 -0400 Received: by interlock.ans.net id AA20407 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 10:51:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 10:51:22 -0400 Message-Id: <199408041451.AA15283@interlock.ans.net> To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: Re[2]: SIPP and SKIP. 2 subjects. In-Reply-To: Your message of Thu, 04 Aug 94 10:24:30 -0400. Date: Thu, 04 Aug 94 10:47:37 -0400 From: Steve Kent Steve, I don't think it requires a 64-bit SAID. It just means that a field after the SAID would be defined to carry the encrypted session key. This is what SDE does, using the MDF construct in conjunction with a 32-bit SAID. Steve From ipsec-request@ans.net Thu Aug 4 14:50:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44796 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:20:47 -0400 Received: by interlock.ans.net id AA25847 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:07:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 11:07:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 11:07:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:07:49 -0400 Message-Id: <9408041450.AA10410@skidrow.lkg.dec.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Wed, 03 Aug 94 13:25:46 EDT." <199408031726.AA19916@interlock.ans.net> Date: Thu, 04 Aug 94 10:50:28 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, Ran may have advocted this but his message that I was repsonding too suggested only the reserveration of 256 values out of the 2**32 bit SAID space under consideration. See copy of his message at end below. Donald From: Steve Kent To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net In-Reply-To: Your message of Wed, 03 Aug 94 11:25:03 -0400. <9408031525.AA16374@skidrow.lkg.dec.com> >Don, > > The path advocated by the approach Ran forwarded would use >bits to convey SA-specific parameters. There are lots of these >parameters. So, unless we are going to favor just a few parameters >and just a few algorithms with their own reserved bits, we will >quickly start using up large chunks of the SAID space. > >Steve Subject: reserving some SAIDs Author: Ran Atkinson at internet Date: 8/3/94 3:11 PM One subject that I've been asked about several times by IPv6 folks is whether we could reserve some SAID values. These could be used for predefined meanings (e.g. use RSA with the public keys from the DNS to encrypt/decrypt this packet). In the IPv6 drafts I'm proposing to reserve 0xFFFFFF01 through 0xFFFFFFFF for future use along these lines. Comments ?? Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Aug 4 11:28:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38455 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:28:43 -0400 Received: by interlock.ans.net id AA09376 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 11:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 11:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:15:03 -0400 Date: Thu, 04 Aug 94 07:56:30 From: "Housley, Russ" Encoding: 666 Text Message-Id: <9407047760.AA776012190@uu0892.spyrus.com> To: ipsec@ans.net, hugo@watson.ibm.com Subject: Re: working keys Hugo: I prefer the model that is described in the draft IEEE 802.10c key management protocol document. I posted a note a month ago about the anonymous FTP location for that document. In the IEEE 802.10c model, the SAID denotes a shared symmetric key and its associated attributes. If the key needs to be "refreshed" then the SPAWN_SA exhange is used. SPAWN_SA can use a one way function to transform the current traffic key into a "fresh" one, but a new SAID is assigned. I believe that the assignment of the new SAID is critical. This avoids all possible confusion about which key or attributes apply to a particular datagram. Russ From ipsec-request@ans.net Thu Aug 4 11:28:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44604 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:28:44 -0400 Received: by interlock.ans.net id AA31376 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:14:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 11:14:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 11:14:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:14:52 -0400 Date: Thu, 04 Aug 94 07:56:20 From: "Housley, Russ" Encoding: 651 Text Message-Id: <9407047760.AA776012180@uu0892.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[2]: reserving some SAIDs Perry: > The model, as I understood it originally, was that SAIDs were > assigned by the receiver in any way the receiver saw fit. Is > there a really good reason to abandon this? On the contrary, there is a really good reason to keep it the way that it is. If you look at the draft IEEE 802.10c key management protocol, you will see that each party tells the other party what SAID it has assigned to the security association. This is simple and straightforward. There is no reason why both ends need to use the same SAID for the security association, but they do need to know the SAID that each other has assigned. Russ From ipsec-request@ans.net Thu Aug 4 11:31:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13393 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:31:01 -0400 Received: by interlock.ans.net id AA21212 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:18:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 11:18:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 11:18:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:18:57 -0400 Date: Thu, 04 Aug 94 07:56:32 From: "Housley, Russ" Encoding: 3494 Text Message-Id: <9407047760.AA776012192@uu0892.spyrus.com> To: ashar@firstperson.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re[4]: SIPP and SKIP. 2 subjects. Ashar: >>You are correct that the MDF follows the SAID in IEEE 802.10b (a.k.a. >>Secure Data Exchange (SDE)). However, your discussion does not point out >>that the MDF must be a constant for a given security association. That >>means that a particular SAID vlaue must be followed by the same MDF value >>forever. > >Where exactly in the 802.10 standard does it say this? (I dont have it >handy, so I cant check). On pages 12 and 13, in section 2.5.2.1.3, IEEE Std 802.10-1992 says: The MDF allows the transfer of information that may facilitate, but is not required for, the processing of the PDU. The MDF is variable in length and is an integral number of octets up to a maximum of 20. Its value is indicated by an entry in the SMIB. The MDF my contain any value and is not used to determine the appropriate security association. The MDF value is unidirectional attribute of the security association an is *constant* for the duration of that securty association. The MDF is optional. An example of the application of the MDF is an SDE implementation that does not retain cryptographic state information. the transfer of cryptographic state information and keting information in the MDF could facilitate reception processing. I added the emphasis. >>DEC wanted this capability in the standard to support a scheme where the >>SAID specified a key encryption key. The MDF contained the traffic key >>(and possibly an integrity algorithm key as well), and the key(s) were >>encrypted in the key encryption key specified by the SAID. > >I am not sure I understand this. If the MDF is to remain constant >for a security association, and the SAID identifies the >key-encrypting key, then the only time the traffic key (which is in >the MDF) can be changed is when the key-encrypting-key changes. What >is the value of separating the two keys then? In the IEEE 802.10 model, the SAID denotes a shared symmetric key and its associated attributes. In the case where the MDF is used, the key is the key encrypting key (KEK), and the MDF value determines the traffic encryption key (TEK). This scheme offeres two possible advantages: 1. The traffic in each direction can be encrypted in two different TEKs, while a single KEK is used. 2. When there are many security associations in place between the same two hosts, the same KEK can be used for all of them, while different TEKs are used to cryptographically separate each of them. >>I do not think that a few reserved SAID values will provide the capability >>that you want... > >Why? Could you elaborate? This ties back to my model of a security association, which is the one used in IEEE 802.10. In the IEEE 802.10 model, the SAID denotes a shared symmetric key and its associated attributes. Therefore, it names the KEK. For a moment, assume that the key management is all worked out, and the "reserved" SAID tells the destination IPSP how to decrypt the MDF to obtain the TEK. Fine. Where do the other attributes for the security association come from? The IEEE 802.10 definition of the MDF explicity says that the MDF "is not used to determine the appropriate security association." Reserved SAIDs simply do not get you the two things that are needed to process the datagram: the key(s) and the attributes of the security association. Russ From ipsec-request@ans.net Thu Aug 4 15:22:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38498 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:36:49 -0400 Received: by interlock.ans.net id AA22085 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:23:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 4 Aug 1994 11:23:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 11:23:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 11:23:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:23:13 -0400 Message-Id: <9408041522.AA14550@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: reserving some SAIDs In-Reply-To: Your message of "Thu, 04 Aug 1994 07:56:20." <9407047760.AA776012180@uu0892.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 04 Aug 1994 11:22:22 -0400 From: "Perry E. Metzger" "Housley, Russ" says: > > Perry: > > > The model, as I understood it originally, was that SAIDs were > > assigned by the receiver in any way the receiver saw fit. Is > > there a really good reason to abandon this? > > On the contrary, there is a really good reason to keep it the way that it > is. If you look at the draft IEEE 802.10c key management protocol, you > will see that each party tells the other party what SAID it has assigned to > the security association. This is simple and straightforward. Its also more or less the model we were following. > There is no reason why both ends need to use the same SAID for the > security association, but they do need to know the SAID that each > other has assigned. I fully agree -- in fact, I believe the assumption always was that SAIDs were one-way constructs and that any SA would involve two of them, which would typically not be the same. I am not certain that there is much of a point in the schemes that are being thought of to allow IPSP traffic with no previous communication (except in cases of manual key management). Little previous negotiation makes enormous sense to me, but I don't really understand why one or two IP packets before communicating would necessarily be a horrible thing. They would also permit the Karn "magic cookie" trick to prevent denial of service attacks, which I think is a big win. I've really yet to be convinced by the current discussion that we need reserved, preassigned SAIDs... Perry From ipsec-request@ans.net Thu Aug 4 15:29:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44671 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 11:46:47 -0400 Received: by interlock.ans.net id AA21000 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 11:33:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 11:33:25 -0400 Message-Id: <199408041533.AA10756@interlock.ans.net> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Wed, 03 Aug 94 08:39:06 -0500. <9407037759.AA775928346@uu0892.spyrus.com> Date: Thu, 04 Aug 94 11:29:45 -0400 From: Steve Kent Russ, We have a slight problem with alignming the SILS SAID and the IPSP SAID, in that we were planning to make the four high order bits of the SAID a version number field for the protocol, leaving us with a 28-bit SAID. This doesn't show up in Ran's diagram. The motivation was that a different version of IPSP should retain the same protocol ID (its not a big space), and we wanted a way to distinguish among a few different versions of IPSP. Still, the discussion of 4 reserved values for SAIDs is a useful one, even if we don't wind up using the same bits. I understand the motivation for having a bit to differentiate between multicast and unicast SAIDs, because the selection criteria is different, i.e., in the latter case the destinations do not select the SAID. Is the model that, for a packet with a multicast SAID, this SAID may not be unique at the destination, because the same SAID may have been used for different multicast address groups to which the destination may belong? In that case, is the intent to use the destination multicast address to uniquely qualify the SAID? If the recipient examines the desitnation address first, and then looks for SAIDs based on that qualifier, the processing would seem to be the same for unicast and multicast. This approach would make the task of selecting a multicast SAID easier for whoever manages the multicast address, since there would be no requirement for global uniqueness, only uniqueness relative to the multicast address. That makes sense to me, but I wanted to get confirmation from your perspective in the SILS community. Any feedback from Internet multicast experts would be appreciated too. The second aspect of the reserved SAIDs is use for key and system management. I assume the intent here is to use the same protocol ID for key/system management packets, but to reserve these two SAIDs to allow such packets to be vectored to the key/system management entity. Is this mostly a means of economizing on protocol ID space and allowing efficient vectoring for all security-related packets? I'm not sure that we have a need for the system (vs. key) management aspect of this, but it would not be too wasteful to reserve the obvious value for that or some other purpose. Again, just checking to make sure that the intent behind the standards text is understood. Steve From ipsec-request@ans.net Thu Aug 4 12:22:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39322 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 12:22:04 -0400 Received: by interlock.ans.net id AA19411 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 12:10:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 12:10:29 -0400 Message-Id: <199408041610.AA27086@interlock.ans.net> Date: 4 Aug 94 16:41:00 WET From: "PYRO::MARTIN" Subject: SAIDs and formats To: "ipsec" I attended the IP6 implementers meeeting on Friday and have been watching the discussions on SAIDs and packet formats. - Please accept my applogies if I have missed a vital piece of recent history in the following. From the point of view of the receiver of a packet when security is in use: It will see either an Authentication Header: +--------+--------+---------+---------+ |Nxt Plod| Length | Reserved | +--------+--------+---------+---------+ | Security Association ID | (32 bits) +--------+--------+---------+---------+ | Auth data (variable length) | | | | | (variable size, random binary data) +--------+--------+---------+---------+ or a Security Header: +--------+--------+---------+---------+ | Security Association ID | (32 bits) +--------+--------+---------+---------+ | Secure data (variable length) | | | | | (variable size, random binary data) +--------+--------+---------+---------+ I make the following observations: 1) The Auth data length is limited to the range 0 - 255 2) The Security payload *MUST* be the last and *ONLY* Security Payload in the packet since there is no cleartext Next Payload field. 3) If the "Authentication" Header were to have its length field extended to 16 or 24 bits this would allow a larger amount of variable binary data which could be used for Authentication, Security or both. Further, more than one Secure Payload could be carried in a packet if required and it need not be last payload. The interpretation of the variable length binary data is be controlled by the SAID. The receiver uses the SAID as an index or key into an array of records which contain information which enable the received data to be interpreted. The records would indicate: The security mechanisms to be used (DES, MD5 etc) The data required by those mechanisms (keys etc) How the mechanisms are to be applied to the data (order of mechanism application, range of data to be processed, location of Algorithm-dependent init stuff etc) How the security processed data is to be interpreted after processing (Authentication, protected data packet e.g.: Security Processed Data: +--------+--------+---------+---------+ |Next Hdr| Length | Reserved | (8/8/16 bits; per usual IPv6 practice) +--------+--------+---------+---------+ | TCP/UDP payload or header indicated | + | (variable size) | by Next Hdr value above | +--------+--------+---------+---------+ | Algorithm-dependent trailing stuff | (variable size, would put padding +--------+--------+---------+---------+ for block-mode algorithms here, etc) Thus the SAID can be used by the receiver to differentiate between Authentication and other uses of the data. In some cases several uses may be optimised such as the case when pairwise unique secret keys are used for encryption. This may give both Authentication and Confidentiality in one go. The records at the receiver (and sender) corresponding to the SAIDs must be complete for the security functionality to work. The information may be placed in a number of different ways: o Pre-defined in a RFC standard and compiled in, o Loaded locally (floppy disk, smart card? etc) o Set up in some on-line management exchange (ICMP-like or DNS lookup). The DNS will most likely contain certificates with Public keys in, so the format could also contain the associated SAID for initial contact. Some allocation of the SAID space for local/global allocation as propossed in IEEE 802.10 seems to be sensible to allow for multicast. Antony Martin Defence Research Agency Malvern UK From ipsec-request@ans.net Thu Aug 4 08:31:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41026 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 12:43:37 -0400 Received: by interlock.ans.net id AA20328 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 12:32:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 12:32:31 -0400 Message-Id: <199408041632.AA20324@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 12:32:31 -0400 To: Steve Kent Cc: "Housley, Russ" , ipsec@ans.net Subject: Re: reserving some SAIDs Date: Thu, 04 Aug 94 12:31:30 EDT I have a different model in mind for multicast. Unless public keys are used -- and they're too expensive for general bulk traffic -- everyone in a multicast group has to share the same key. The SAID is therefore redundant. I thus suggest using SAID 0 with multicast to denote the per-address key. Non-zero keys would be bound to the source/destination pair, and would be used with public key, for low-volume transmissions. (I envision its use with things like sd, where the sending rate is on the order of once per minute, and the packet contents may not even change.) From ipsec-request@ans.net Thu Aug 4 17:15:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48333 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 13:28:17 -0400 Received: by interlock.ans.net id AA21108 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 13:16:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 4 Aug 1994 13:16:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 4 Aug 1994 13:16:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 13:16:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 13:16:49 -0400 Message-Id: <9408041715.AA14790@snark.imsi.com> To: smb@research.att.com Cc: Steve Kent , "Housley, Russ" , ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Thu, 04 Aug 1994 12:31:30 EDT." <199408041632.AA20324@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 04 Aug 1994 13:15:50 -0400 From: "Perry E. Metzger" smb@research.att.com says: > I thus suggest using SAID 0 with multicast to denote the per-address > key. I've sort of been hoping we could reserve SAID 0 -- reserving the number zero like this has proven useful in the past. I'd suggest that the allocator of the multicast address can make some decision on what the SAID should be and just stick with it, but if people insist on having a fixed one, it ought not (IMHO) be zero. Perry From ipsec-request@ans.net Thu Aug 4 17:50:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA36039 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 14:01:18 -0400 Received: by interlock.ans.net id AA20421 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 13:51:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 13:51:34 -0400 Message-Id: <199408041751.AA19393@interlock.ans.net> To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Thu, 04 Aug 94 10:50:28 -0400. <9408041450.AA10410@skidrow.lkg.dec.com> Date: Thu, 04 Aug 94 13:50:02 -0400 From: Steve Kent Don, While it's true that Ran advocated reserving only a small part of the space, my point was that he cited just a very few of the total set of parameters that are bound to an association. Thus, I contend that unless we want to nail down only a subset of the parameters this way (which doesn't seem useful to me), or unless we want to favor some small subset of the combinatoric possibilities to be represented this way (which does not seem to be a good approach to me), then I don't see this as a viable path to follow. I may not have been very clear in articulating my concern in the previous message. I hope this helps calrify my concern. Steve From ipsec-request@ans.net Thu Aug 4 18:35:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13532 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 14:52:51 -0400 Received: by interlock.ans.net id AA12817 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 14:37:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 14:37:07 -0400 Message-Id: <199408041837.AA17165@interlock.ans.net> To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Thu, 04 Aug 94 12:31:30 -0400. Date: Thu, 04 Aug 94 14:35:00 -0400 From: Steve Kent Steve, In reviewing Ashar's talk, I think there is a general model for multicast that encompasses what he described and which is not incompatible with the SAID model we have been discussing. Also, I disagree with your assesment that the SAID is redundant in the multicast context and should be ignored. Use of the SAID is a great unifying principle and allows considerable flexibility in the granularity at which security services are provided. In the model Ashar presented, the critical element was that each source needs to use a different key (with the same stream cipher) when transmitting, to avoid the problems of key stream reuse in this multicast scenario. Ashar points out that, for packet video, the software performance of a cipher like DES, even when used as a key stream generator, is not generally adequate for this application. (In contrast, packet voice has proven to be amenable to DES encryption in the Internet for some time.) So, we should be prepared to accommodate stream ciphers that, like RC4, can operate at the requisite data rates. I agree with Ashar that it seems too hard to try to develop some scheme for apportioning the key stream space to avoid reuse, so having a different key per source is a good way to deal with this problem. The interchange key approach Ashar described, without the Diffie-Hellman specific aspects, seem like a general solution to this problem and it can be modeled using the current SAID approach. In this approach, the interchange key is established as part of SA establishment and can be effected using unicast or multicast key distribution techniques. We then view that key as the SA key, common to all the multicast group members. The per-source key, which may be changed by the source whenever it wishes, is sent 9encrypted under the interchange key) as part of the per-packet crypto control into after the SAID. This makes the per-source key look like a per-packet IV and the fact that its processing is somewhat different from a real IV is really just a function of the specific encryption algorithm-mode that is a characteristic of this SA. The length and processing semantics for the crypto control info following the SAID is determined by the parameters that were bound to the SA when it was created, so this does not represent a deviation from that general model. So, with that interpretation, I think that the SA model we are developing accommodates Ashar's general requirement. His specific choice of how to encrypt the per-source key is just one option; I can imagine ways of doing this using a DES interchange key, but the result would not provide the same level of authentication. However, since we have been talking about an encryption function here, the idea that different choices of interchange key encryption will result in different security services other than confidentiality should not be a problem. Steve From ipsec-request@ans.net Thu Aug 4 18:53:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39065 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 15:06:41 -0400 Received: by interlock.ans.net id AA16186 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 14:55:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 14:55:08 -0400 Message-Id: <199408041855.AA23862@interlock.ans.net> To: "PYRO::MARTIN" Cc: ipsec Subject: Re: SAIDs and formats In-Reply-To: Your message of 04 Aug 94 16:41:00 +0700. <199408041610.AA27086@interlock.ans.net> Date: Thu, 04 Aug 94 14:53:27 -0400 From: Steve Kent Antony, I'm a bit puzzled by your diagram, since it doesn't match the one Ran sent earlier this week. Ran's showed algorithm-dependent (and thus SAID-specified) IPSP control info both immediately after the SAID and after the encapsulated protocol. However, I didn't attend the IPv6 meeting ypu refer to, so there is opportunity for confusion here. I believe the plan was that there would be two different protocol IDs used: one for authentication (really integrity with authentication based on key distribution) only, which will be carried in the IPv6 header, and one for confidentiality and/or autehntication and integrity, which will come after the IPv6 header, i.e., as a legitimate next protocol layer. Perhaps the header length format (and thus size) constraint you described applies only to the first of these two? Steve From ipsec-request@ans.net Thu Aug 4 19:53:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48268 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 16:09:53 -0400 Received: by interlock.ans.net id AA25946 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 15:54:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 15:54:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 15:54:08 -0400 Message-Id: <9408041953.AA24171@columbia.sparta.com> To: smb@research.att.com Cc: Steve Kent , "Housley, Russ" , ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Thu, 04 Aug 94 12:31:30 EDT." <199408041632.AA20324@interlock.ans.net> Date: Thu, 04 Aug 94 15:53:17 -0400 From: Carl Muckenhirn Steve Bellovin write: > I have a different model in mind for multicast. Unless public > keys are used -- and they're too expensive for general bulk traffic > -- everyone in a multicast group has to share the same key. The > SAID is therefore redundant. I thus suggest using SAID 0 with > multicast to denote the per-address key. Non-zero keys would be > bound to the source/destination pair, and would be used with public > key, for low-volume transmissions. (I envision its use with things > like sd, where the sending rate is on the order of once per minute, > and the packet contents may not even change.) I'm not sure that this will work either. Assuming that one will desire to rekey the multicast SA, what SAID (read keyid) will be used? My model here is that for some period of time two keys will be valid. Everyone sends on the new key and receives on either, the SAID telling you which. Assignment of the multicast SAID would be made by the creator of the multicast key, and its value relayed to multicast participants when the key is distributed. Also, is there any desire to allow multiple classifications/services to use the same low-level multi-cast address? Today, a single multicast address carries serveral types of traffic, if each type is encrypted differently, or has different access rules, a different key may be needed. For example, a particular multicast address may carry both video and audio, the video unencrypted, and the audio encrypted, how would SAIDs be established to denote this. (I admit that it just occurred to me will there be a NULL key for which an SAID may be assigned to denote bypass?) (Alternatively think of video encrypted with RC4 and audio encrypted with DES.) carl. From ipsec-request@ans.net Thu Aug 4 20:20:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40103 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 16:36:19 -0400 Received: by interlock.ans.net id AA23956 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 16:21:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 16:21:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 16:21:41 -0400 Message-Id: <9408042020.AA24249@columbia.sparta.com> To: Carl Muckenhirn Cc: smb@research.att.com, Steve Kent , "Housley, Russ" , ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: reserving some SAIDs In-Reply-To: Your message of "Thu, 04 Aug 94 15:53:17 EDT." <9408041953.AA24171@columbia.sparta.com> Date: Thu, 04 Aug 94 16:20:37 -0400 From: Carl Muckenhirn Hate to be pedantic but I wrote > Steve Bellovin write: which should obviously be: > Steve Bellovin writes: (or maybe wrote) ^ carl. From ipsec-request@ans.net Thu Aug 4 15:13:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38608 (5.65c/IDA-1.4.4 for ); Thu, 4 Aug 1994 19:28:45 -0400 Received: by interlock.ans.net id AA31087 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 4 Aug 1994 19:13:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 4 Aug 1994 19:13:15 -0400 Message-Id: <199408042313.AA20075@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 4 Aug 1994 19:13:15 -0400 Date: Thu, 4 Aug 94 19:13:06 EDT From: amir@watson.ibm.com To: ipsec@ans.net Subject: Re: Russ's re:[4]: SIPP and SKIP. 2 subjects. I'll like to add to Russ's answer to Ashar: >>SAID specified a key encryption key. The MDF contained the traffic key >>(and possibly an integrity algorithm key as well), and the key(s) were >>encrypted in the key encryption key specified by the SAID. Ashar asks: A> A>I am not sure I understand this. If the MDF is to remain constant A>for a security association, and the SAID identifies the A>key-encrypting key, then the only time the traffic key (which is in A>the MDF) can be changed is when the key-encrypting-key changes. What A>is the value of separating the two keys then? Russ replies (and I agree): >In the IEEE 802.10 model,the SAID denotes a shared symmetric key and its associated attributes. In the case where the MDF is used, the key is the >key encrypting key (KEK), and the MDF value determines the traffic >encryption key (TEK). This scheme offeres two possible advantages: > >1. The traffic in each direction can be encrypted in two different TEKs, >while a single KEK is used. > >2. When there are many security associations in place between the same two >hosts,the same KEK can be used for all of them, while different TEKs are >used to cryptographically separate each of them. Let me just add: another reason is to speed up the operation of an hardware encryption implementation. DEC has a hardware DES design that makes use of the fact that the key is encrypted as a part of the data stream, so it does not have to be fetched by software and loaded. I suspect this was one of the main reasons that DEC were opting for this option. Personally, I find this neat. Best, Amir [E92] `A High speed DES...', Hans Eberle (DEC), Crypto' 92, pp. 521- 539, see section 5.1. From ipsec-request@ans.net Fri Aug 5 03:53:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40366 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 00:19:39 -0400 Received: by interlock.ans.net id AA12107 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 00:08:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 00:08:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 00:08:57 -0400 Date: Fri, 5 Aug 94 03:53:56 GMT From: "William Allen Simpson" Message-Id: <2985.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Writing I didn't see an answer to who is writing what. Ran did a nice job on the SIPP Authentication Header, and we have agreed to use it essentially unchanged. Can we agree that Ran does that writing? When can you promise it will be done, Ran? Phil Karn has done a lot of the implementation experience, starting with swIPe. Implementation is what counts with me. Can we get the swIPe folks to write the Encrypted Security Payload document? When can you promise it will be done, Phil? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Aug 5 03:49:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40383 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 00:20:43 -0400 Received: by interlock.ans.net id AA09287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 00:08:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 00:08:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 00:08:55 -0400 Date: Fri, 5 Aug 94 03:49:35 GMT From: "William Allen Simpson" Message-Id: <2984.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Versions > From: Steve Kent > We have a slight problem with alignming the SILS SAID and the > IPSP SAID, in that we were planning to make the four high order bits > of the SAID a version number field for the protocol, leaving us with > a 28-bit SAID. This doesn't show up in Ran's diagram. The motivation > was that a different version of IPSP should retain the same protocol > ID (its not a big space), and we wanted a way to distinguish among > a few different versions of IPSP. > I question the need for a version. The only way we'll get widespread security is if we settle on one version and stick with it for a long time. Multiple versions will lead to non-interoperability. If we stick with this version long enough, we may have another version in 10 years. Four IP Protocol numbers in 10 years won't hurt too badly. Let's just do it, and get it right. Phil has given us some nice implementation experience, we all agree pretty much on what we want. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Aug 5 03:41:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40388 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 00:21:25 -0400 Received: by interlock.ans.net id AA26432 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 00:08:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 00:08:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 00:08:54 -0400 Date: Fri, 5 Aug 94 03:41:21 GMT From: "William Allen Simpson" Message-Id: <2983.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: reserving some SAIDs Well, I kept saying, "we shouldn't call this a SAID, or people will confuse it with other protocols which call it SAID, and mean something different". We should come up with a better name: sign me up for the "I hate acronyms (IHA)" party. Let's just call the field "Security Association". We can pronounce it "essay" when we are lazy. I suggest we reserve only 0, 8000000, 7ffffff and fffffff; this will avoid confusion with 802.10. We then should prohibit their use for IP, allowing them to be used by the other security protocols. After the problems raised by Phil, I agree we shouldn't have "well known" SAIDs. I don't see how it would even help trusted one-shot DNS requests. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Aug 5 05:33:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35048 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 05:33:20 -0400 Received: by interlock.ans.net id AA29464 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 05:12:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 05:12:52 -0400 Message-Id: <199408050912.AA29460@interlock.ans.net> Date: 5 Aug 94 10:09:00 WET From: "PYRO::MARTIN" Subject: Re: SAIDs and formats To: "kent" Cc: "ipsec" Steve, < I'm a bit puzzled by your diagram, since it doesn't match the I believe the plan was that there would be two different >protocol IDs used: one for authentication (really integrity with >authentication based on key distribution) only, which will be carried >in the IPv6 header, and one for confidentiality and/or autehntication >and integrity, which will come after the IPv6 header, i.e., as a >legitimate next protocol layer. Perhaps the header length format (and >thus size) constraint you described applies only to the first of these >two? Your thoughts align completely with my understanding of the current proposals. My point was that with a 'minor' change, one protocol id could perform both functions because the SAID would imply the distinction between them (which may be blurred in some cases). This change would give the 'advantages' of: 1) less differentiation of security information which might aid an attacker 2) it might simplify the security processing by have a single SAID space to manage rather that the potential for two. 3) greater flexibility in the use of the security payload by allowing more than one (not a particularly good reason because you could put two into one anyway if you really wanted to do this) 4) allow flexible mixing of protected and unprotected data in the same packet in any order 5) it seemed more elegant to me. Antony From ipsec-request@ans.net Fri Aug 5 11:54:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14325 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 08:03:53 -0400 Received: by interlock.ans.net id AA11593 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 07:54:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 07:54:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 07:54:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 07:54:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 07:54:55 -0400 Message-Id: <9408051154.AA16448@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Versions In-Reply-To: Your message of "Fri, 05 Aug 1994 03:49:35 GMT." <2984.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 05 Aug 1994 07:54:32 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > I question the need for a version. The only way we'll get widespread > security is if we settle on one version and stick with it for a long > time. Multiple versions will lead to non-interoperability. The version bits were asked for during the meeting on the basis that IP's version number has allowed us a nice transition facility. I'm unsure as to whether the version bits are valuable or not. I'd personally like to hear some discussion of this. > If we stick with this version long enough, we may have another version > in 10 years. Four IP Protocol numbers in 10 years won't hurt too badly. I would tend to agree with that, too. Remember that if we rig the negotation protocol right, most of the important things get put in the negotated choice of security transform. If it turns out that the way we are doing things now is bad, we can likely just abandon the current security transforms over time for new ones without changing the encapsulation at all. Perry From ipsec-request@ans.net Fri Aug 5 11:58:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17205 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 08:06:10 -0400 Received: by interlock.ans.net id AA26220 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 07:58:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 07:58:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 07:58:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 07:58:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 07:58:30 -0400 Message-Id: <9408051158.AA16458@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Writing In-Reply-To: Your message of "Fri, 05 Aug 1994 03:53:56 GMT." <2985.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 05 Aug 1994 07:58:22 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > I didn't see an answer to who is writing what. I'm editing or writing most of the stuff right now. I'm expecting some draft text from Phil on the "base" security transformations (an authentication transform and a simple encryption transform, likely based on DES). I've gotten some text from Steve Kent on the nature of SAIDs. I'm likely going to be soliciting some other text. Ran's text from his SIPP security drafts is likely going to be massively stolen, to the poing that I'm going to declare him the author of most of one of the drafts since it will be his text with some editing. > Ran did a nice job on the SIPP Authentication Header, and we have agreed > to use it essentially unchanged. Can we agree that Ran does that writing? Well, in some sense, he's already done it. :-) I notice you asking when things will be written. I'm putting in a marathon editing session this weekend. I'm leaving some large stretches blank, but other than that there should be text posted here early next week for comment. Perry From ipsec-request@ans.net Fri Aug 5 04:19:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14100 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 08:32:48 -0400 Received: by interlock.ans.net id AA17772 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 08:22:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 08:22:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 08:22:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 08:22:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 08:22:09 -0400 Date: Fri, 5 Aug 94 08:19:39 EDT Message-Id: <9408051219.AA25478@mailserv-D.ftp.com> To: perry@imsi.com Subject: Re: Versions From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: bsimpson@morningstar.com, ipsec@ans.net Content-Length: 938 > "William Allen Simpson" says: > > I question the need for a version. The only way we'll get widespread > > security is if we settle on one version and stick with it for a long > > time. Multiple versions will lead to non-interoperability. > > The version bits were asked for during the meeting on the basis that > IP's version number has allowed us a nice transition facility. I'm > unsure as to whether the version bits are valuable or not. I'd > personally like to hear some discussion of this. if you don't have a version field someplace then you may find yourself in a position where you need one and don't have it and therefore are up the proverbial tributary without obvious means of propulsion. if you have a version field and it turns out that you don't need it, then you just carry around a couple of extra bits. and if we are smart, later on we may figure out how to reclaim those bits... -- Frank Kastenholz From ipsec-request@ans.net Fri Aug 5 05:22:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48264 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 09:34:03 -0400 Received: by interlock.ans.net id AA14405 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 09:22:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 09:22:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 09:22:06 -0400 Date: Fri, 5 Aug 94 09:22:46 EDT From: Robert Glenn Message-Id: <9408051322.AA20679@osi.ncsl.nist.gov> To: bsimpson@morningstar.com Subject: Re: Versions Cc: ipsec@ans.net Bill, I'll go along with the idea that both a version number and a protocol ID will give you enough information to demultiplex different (versions of) protocols. The only differences between the two that I can think of are: 1) The numbers come out of a different number space. This results in a different level of control over being able to change/adapt. 2) The recipient of a new version of an IPSP protocol packet will interpret an unsupported packet differently. In one case the packet will be interpreted as an IPSP packet with an unsupported SAID. The other case is that IP will receive a packet and be unable to determine the next protocol (ie., IP won't be able to determine if this is a security protocol, or any thing else). 3) One results in changing the IP code space, the other results in changing the IPSP code space. I'm not sure as to the importance of these points. 1) seemed to be the primary factor at the IPSEC meeting for having a version number instead of using new protocol numbers. 2) is an interesting observation, and what is done with the implied information could fall into a managment issue. The initial result is the same (ie., the packet is dropped), but the overal result might be different depending on how that information could be used. 3) is trivial in a BSD OS environment where users can recompile there kernels, it might not be trivial in a more proprietary OS. Along these lines, I'd prefer the version number. I agree with Perry, I'd like to see more discussion on this. Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Fri Aug 5 09:34:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38542 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 09:34:59 -0400 Received: by interlock.ans.net id AA22659 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 09:25:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 09:25:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 09:25:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 09:25:41 -0400 Date: Fri, 05 Aug 94 06:12:35 From: "Housley, Russ" Encoding: 670 Text Message-Id: <9407057760.AA776092355@uu0892.spyrus.com> To: ipsec@ans.net Subject: Re: working keys Hugo: I prefer the model that is described in the draft IEEE 802.10c key management protocol document. I posted a note a month ago about the anonymous FTP location for that document. In the IEEE 802.10c model, the SAID denotes a shared symmetric key and its associated attributes. If the key needs to be "refreshed" then the SPAWN_SA exhange is used. SPAWN_SA can use a one way function to transform the current traffic key into a "fresh" one, but a new SAID is assigned. I believe that the assignment of the new SAID is critical. This avoids all possible confusion about which key or attributes apply to a particular datagram. Russ From ipsec-request@ans.net Fri Aug 5 13:41:44 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34863 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 09:55:00 -0400 Received: by interlock.ans.net id AA14426 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 09:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 09:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 09:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 09:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 09:42:03 -0400 Message-Id: <9408051341.AA16734@snark.imsi.com> To: kasten@ftp.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Versions In-Reply-To: Your message of "Fri, 05 Aug 1994 08:19:39 EDT." <9408051219.AA25478@mailserv-D.ftp.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 05 Aug 1994 09:41:44 -0400 From: "Perry E. Metzger" Frank Kastenholz says: > > The version bits were asked for during the meeting on the basis that > > IP's version number has allowed us a nice transition facility. I'm > > unsure as to whether the version bits are valuable or not. I'd > > personally like to hear some discussion of this. > > if you don't have a version field someplace then you may find > yourself in a position where you need one and don't have it and > therefore are up the proverbial tributary without obvious means of > propulsion. > > if you have a version field and it turns out that you don't need it, > then you just carry around a couple of extra bits. and if we are > smart, later on we may figure out how to reclaim those bits... I'm unsure we really need them, however -- allocating a new header type may turn out to be better for the implementations and would also satisfy versioning, and as I've noted, most of the changes we anticipate would be in evolution of the security transformations and key management algorithms through time, which the current (minimalist) header will support without any trouble. If we do go for reserving bits for a version, I recommend that we declare them Must Be Zero so that if it proves unneeded we can reclaim them later. I really encourage as much discussion of this as possible, btw -- its important that we have strong consensus either way. Perry From ipsec-request@ans.net Fri Aug 5 14:42:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17357 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 10:56:00 -0400 Received: by interlock.ans.net id AA14379 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 10:43:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 10:43:43 -0400 Message-Id: <199408051443.AA25893@interlock.ans.net> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: reserving some SAIDs In-Reply-To: Your message of Fri, 05 Aug 94 03:41:21 +0000. <2983.bill.simpson@um.cc.umich.edu> Date: Fri, 05 Aug 94 10:42:15 -0400 From: Steve Kent Bill, I don't think that confusion necessarily results because our SAIDs and thiose of several other security protocols are not exactly the same in size, resreved values, etc. So long as the semantics are more or less in keeping with those of the other users of this acronym, I think we gain more from retaining it than in making up a new one. Comne on, Bill, relax! Steve From ipsec-request@ans.net Fri Aug 5 14:44:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14602 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 11:03:07 -0400 Received: by interlock.ans.net id AA25990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 10:50:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 10:50:09 -0400 Message-Id: <199408051450.AA12674@interlock.ans.net> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Versions In-Reply-To: Your message of Fri, 05 Aug 94 03:49:35 +0000. <2984.bill.simpson@um.cc.umich.edu> Date: Fri, 05 Aug 94 10:44:33 -0400 From: Steve Kent Bill, I think there was a lot of sympathy for having a small version field, as do many other protocols. Since you argue against the need to be perfectly aligned with the SILS SAID anyway, I'm not sure why you are concered about this field. After all, it's not really designed to encourage multiple, non-interoperable versions, but rather to allow a smoother transition when we need to move from one version to another. Steve From ipsec-request@ans.net Fri Aug 5 15:03:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14843 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 11:19:48 -0400 Received: by interlock.ans.net id AA26527 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 11:07:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 11:07:31 -0400 Message-Id: <199408051507.AA26011@interlock.ans.net> To: "PYRO::MARTIN" Subject: Re: SAIDs and formats Cc: ipsec Date: Fri, 05 Aug 94 11:03:53 -0400 From: Steve Kent Antony, The algorithm-dependent control info that Ran was referring to is variable on a per-message basis, and thus cannot be subsumed by reference through the SAID. For example, a encryption mode that requires a per-packet IV or padding that is required to match an algorithm's block size would go in these areas. The SAID will indicate which services are employed and so it can be used to indicated wether encryption and/or integrity checking transforms have been applied. However, if the representation needed for integrity for all traffic (as a default), and which is intended to live in the IP header, conflcits with some of the requirements for an explicit IPSP layer, then using different IDs seems approriate. Steve From ipsec-request@ans.net Fri Aug 5 14:01:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02321 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 14:01:42 -0400 Received: by interlock.ans.net id AA35293 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 13:39:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 13:39:07 -0400 Message-Id: <199408051739.AA35288@interlock.ans.net> Date: 5 Aug 94 18:29:00 WET From: "PYRO::MARTIN" Subject: Re: SAIDs and formats To: "kent" Cc: "ipsec" Steve, > The algorithm-dependent control info that Ran was referring to >is variable on a per-message basis, Yes, I agree. > and thus cannot be subsumed by >reference through the SAID. For example, a encryption mode that >requires a per-packet IV or padding that is required to match an >algorithm's block size would go in these areas. No, I disagree, there is nothing to stop the SAID referencing via a record, a procedure which knows the location in the message of these fields and can perform appropriate padding etc on a per message basis. In summary, a receiver's implementation could have the following distinct pieces of code: 1) code for common clear header analysis and processing, (always used) 2) code for security processing, (implied by SAID). There may be a number of these pieces of code implemented in a system for different security schemes but the SAID will imply the use of only one at a time. 3) code for interpreting and processing the result of (2). This may be the same as (1) in all cases as with the current proposal. However alternative formats (e.g. authentication data or a compressed header format) could be implied by SAID, independent of (2). What I am suggesting is that the specifications of the three parts be unbundled so as to ease future independent enhancement with new security schemes or different protected data formats. > The SAID will indicate which services are employed and so it >can be used to indicated wether encryption and/or integrity checking >transforms have been applied. However, if the representation needed >for integrity for all traffic (as a default), and which is intended to >live in the IP header, conflcits with some of the requirements for an >explicit IPSP layer, then using different IDs seems approriate. This may be the case, but I thought I heard agreement last week that the IP6 security formats would not be constrained by IP4 format requirements. The only constraint was to be the use of the same security mechanisms in both cases. Antony (I'm having my computer surgically removed for the next two weeks for my summer holiday -> no response does not mean I'm sulking! :-) From ipsec-request@ans.net Fri Aug 5 18:02:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38642 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 14:23:39 -0400 Received: by interlock.ans.net id AA17716 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 14:03:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 14:03:44 -0400 Message-Id: <199408051803.AA32302@interlock.ans.net> To: "PYRO::MARTIN" Cc: ipsec Subject: Re: SAIDs and formats In-Reply-To: Your message of 05 Aug 94 18:29:00 +0700. Date: Fri, 05 Aug 94 14:02:17 -0400 From: Steve Kent Antony, I think there was a miscommunication and your latest response suggests we are in synch now. My interpretation of Ran's diagram was as an example of where algorithm-dependent header and tralier data would be in the IPSP format. Thus, the presence or absence of such data, and, in some cases its size, is determined by the SAID. So I think we are in agreement there. As for commonality of formats, I think it's not an issue of IPv4 constraining use in IPv6, but rather the other way around. My comment was predicated on the observation that there is a strong push to have an integrity option bound into the IPv6 header and to make this option as efficient as possible, to support its use as a default. My opinion is that this is just right, and that if this integrity option is to encompass parts of the IP header, then this is precisely where it should be, i.e., in the header itself. I would further suggest that both end-to-end and end-to-intermediate system use of the option can be provided naturally based on placement of this option in the appropriate areas of the IPv6 header. How this may apply directly to IPv4 since there is not a corrsponding header option capability. However, IPSP as a protocol that sits above IP, encapsulating a transport layer PDU, or as a protocol that encapsulates IP (when IPSP is implemented at an intermediate system) can be equally at home in IPv6 and IPv4, I believe. It can avoid dependencies on the (outer) IP header by not trying to include it in the integrity calculation, focusing instead on protecting whatever payload is encapsulated by IPSP. Steve From ipsec-request@ans.net Fri Aug 5 04:46:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38444 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 15:18:59 -0400 Received: by interlock.ans.net id AA16337 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 15:00:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 5 Aug 1994 15:00:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 15:00:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 15:00:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 15:00:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 15:00:23 -0400 Message-Id: <00112.2858932602.2803@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: smb#064#research.att.com%INTERNET@email.mot.com (smb 064 research.att.com) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 5 Aug 1994 11:46:05 MST Subject: Re: >Re[2]- SIPP and SKIP. 2 Reply to: RE>>Re[2]: SIPP and SKIP. 2 >> Ashar, >> >> DEC devised a clever way to use per-SA keys, without Note- DEC has patented this clever technique. >> requiuring each SDE entity to have a table of the keys. The approach >> used was to transmit the session (per-SA) key encrypted in the master >> key of the receiving SDE entity. This encrypted form of the session >> key was supplied by the receiving entity itself (so there is no need >> to shre this master key) as part of SA establishment. The session key >> was constant for the duration of the SA, but each new SA can have a >> new session key. This is consistent with the commnet Russ made about >> the MDF vaule being constant per SA. >> >To fit our precise model, that would require a 64-bit SAID. No it would not. The per-SA encrypted key could just be included in the front of the initial security transformation specific stuff much like an IV. Paul From ipsec-request@ans.net Fri Aug 5 05:23:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44650 (5.65c/IDA-1.4.4 for ); Fri, 5 Aug 1994 15:49:48 -0400 Received: by interlock.ans.net id AA09203 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 5 Aug 1994 15:22:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 5 Aug 1994 15:22:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 5 Aug 1994 15:22:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 5 Aug 1994 15:22:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Aug 1994 15:22:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Aug 1994 15:22:15 -0400 Message-Id: <00112.2858934403.2808@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 5 Aug 1994 12:23:13 MST Subject: Key Management Requirements Key Management Requirements >In an earlier note, Perry mentioned that you had a list of >requirements for an Internet key management protocol. >I was only able to attend one of the ipsec meetings, and >I did not hear your list of requirements. If it is not >too much typing, would you consider sending out your list >for the consideration of others on this list (e.g, me)? > >Thanks, >Charlie P. Here are our Key Management requirements. >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 Sat Aug 6 06:44:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48365 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 02:59:27 -0400 Received: by interlock.ans.net id AA27427 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 02:45:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 02:45:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 02:45:04 -0400 Date: Fri, 5 Aug 1994 23:44:24 -0700 From: Phil Karn Message-Id: <199408060644.XAA00375@unix.ka9q.ampr.org> To: ipsec@ans.net Cc: karn@unix.ka9q.ampr.org Subject: fast 386 DES code figures To see if software DES could really be made acceptable in a IP security protocol, I've been bumming cycles out of my old DES code. I've completely translated the encrypt and decrypt routines to assembler, with no calls or jumps inside either routine. I picked up Richard Outerbridge's seriously clever initial and final permutation algorithm from Schneier, along with a few of his other tricks. The bottom line: about 38,373 encryptions/sec (2.456 megabits/sec) on a 50 Mhz Intel 486 running in 16-bit real mode. This includes the overhead of the C loop that calls the encrypt function and prints a status line every 10,000 loops. The code would probably run faster if assembled and run in 32-bit native mode, as this would eliminate a lot of 1-clock operand size prefixes (I do many 32-bit operations). Oh, by the way, if I eliminate the permutations the speed goes up to about 42,986 encryptions/sec (2.751 megabits/sec), an increase of about 12%. That says I should be able to do triple-DES at about 13,777 blocks/sec (881.7 kbit/sec) although I haven't tried it yet. What still bugs me is that Schneier lists the speed of one commercial DES implementation as 40,600 encryptions/sec on a 33 Mhz 486. I just don't see how that's possible without using a lot more memory for lookup table space (I use only 2K, which is nice in a DOS environment). In any event, this should be enough for a T1 link (half duplex) as long as too many cycles aren't needed for things like routing packets. :-) Phil From ipsec-request@ans.net Sat Aug 6 04:53:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39153 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 09:05:39 -0400 Received: by interlock.ans.net id AA26602 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 08:54:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 08:54:01 -0400 Message-Id: <199408061253.AA29158@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 08:54:01 -0400 To: Phil Karn Cc: ipsec@ans.net Subject: Re: fast 386 DES code figures Date: Sat, 06 Aug 94 08:53:10 EDT What still bugs me is that Schneier lists the speed of one commercial DES implementation as 40,600 encryptions/sec on a 33 Mhz 486. I just don't see how that's possible without using a lot more memory for lookup table space (I use only 2K, which is nice in a DOS environment). Well, yes -- you can use a lot more table space. In particular, you can compose the S and P boxes. Or maybe it does run in 32 bit mode; Schneier's table imlies that it does. Or maybe a branch-free implementation is the wrong strategy, since it could mean that you aren't executing out of the instruction cache. From ipsec-request@ans.net Sat Aug 6 17:11:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13398 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 13:21:11 -0400 Received: by interlock.ans.net id AA24765 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 13:11:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 13:11:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 13:11:25 -0400 Date: Sat, 6 Aug 1994 10:11:17 -0700 From: Phil Karn Message-Id: <199408061711.KAA00757@unix.ka9q.ampr.org> To: smb@research.att.com Cc: ipsec@ans.net In-Reply-To: <199408061254.FAA16986@qualcomm.com> (smb@research.att.com) Subject: Re: fast 386 DES code figures I'm currently using a 2K precomputed SP table. Takes 8 lookups per round. The 8K 486 cache *ought* to be large enough to hold everything: the encrypt routine, the SP table and the calling function loop. If not the on-chip cache, then certainly the external cache on my motherboard. So unrolling probably doesn't hurt once you've made the first few passes around the calling loop. I assume that the DES code will get called "many" times in a tight loop whenever it is used, thus landing it in the cache for most of the loop. This is probably true when encrypting or decrypting moderate to large packets. Maybe I'll go check this. Good point. Phil From ipsec-request@ans.net Sat Aug 6 21:23:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34860 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 16:30:19 -0400 Received: by interlock.ans.net id AA36228 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 16:22:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 16:22:21 -0400 Subject: Re: IPsec and patents To: ipsec@ans.net Date: Sat, 6 Aug 1994 16:23:05 -0500 (EST) From: Ran Atkinson In-Reply-To: <00112.2858932602.2803@poncho.phx.sectel.mot.com> from "Paul Lambert" at Aug 5, 94 11:46:05 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1442 Message-Id: <9408062123.aa21245@sundance.itd.nrl.navy.mil> > Note- DEC has patented this clever technique. I'd like to put out a request and reminder since there are many on this list who are somewhat new to the IETF way of doing things. 1) The IETF normally tries to avoid using patented techniques in IETF specifications, though it is not always possible (sigh). 2) In any event, it is ALWAYS important to note ALL possible intellectual property claims relating to any proposal in the FIRST note or presentation of the proposal. It is not good practice to propose a technology which is subject to intellectual property claims (e.g. patents) without that up front disclosure. IMHO, we do NOT want a repeat of recent events in another area of the IETF where a vendor pushed a particular algorithm and did not disclose patent claims up front. If that happens here, I _will_ formally make a process violation complaint at or before Last Call. However clever one might consider the DEC technique, I don't want to include it in any portion of the standards-track specification UNLESS DEC formally agrees in writing to license it to all comers at no cost. One of the best reasons to use DES-CBC as a mandatory algorithm is that one does NOT have to obtain any license to use or implement that algorithm. The same is true of MD4 and MD5. These facts are a large part of the reason that existing IETF specs use DES and MD5 as the mandatory algorithms. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Sat Aug 6 16:51:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18926 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 20:58:39 -0400 Received: by interlock.ans.net id AA26041 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 20:51:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 6 Aug 1994 20:51:08 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 20:51:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 20:51:08 -0400 Date: Sat, 6 Aug 94 20:51:45 EDT Message-Id: <9408070051.AA25490@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ran Atkinson , ipsec@ans.net From: shirey@mitre.org (Robert W. Shirey) Subject: Re: IPsec and patents At 4:23 PM 8/6/94 -0500, Ran Atkinson wrote: ... >I'd like to put out a request and reminder since there are many on this >list who are somewhat new to the IETF way of doing things. Ran, Do you thin that the the following draft text states the situation correctly? -------------------------------------------------------------------------------- Internet protocols should not avoid using a technology just because patent rights may have been asserted in some countries. For example, many cryptographic algorithms, especially asymmetric algorithms, are patented. The situation with cryptographic patents is similar to that with trade controls. That is, not all algorithms are patented in all countries, and parallel, independent implementations in different countries are both possible and customary in the Internet. Therefore, use of patented technology in Internet standards should not precluded so long as the licensing conditions are reasonable and non-discriminatory, as specified in [RFC1602]. Since patents can potentially restrict application and use of Internet standards, Internet protocols should avoid using patented technology whenever there is an appropriate substitute technology that is unrestricted. Internet standards should also avoid encryption algorithms and other technologies that are commercially proprietary, governmentally sensitive, militarily restricted (i.e., classified), or otherwise prevented from being publicly disclosed. Such conditions preclude open peer review that is fundamental to Internet standards development. -------------------------------------------------------------------------------- Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA From ipsec-request@ans.net Sat Aug 6 21:13:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02454 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 21:13:46 -0400 Received: by interlock.ans.net id AA29927 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 21:04:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 21:04:24 -0400 Subject: Re: IPsec and patents To: "Robert W. Shirey" Date: Sat, 6 Aug 1994 21:05:08 -0500 (EST) From: Ran Atkinson Cc: ipsec@ans.net In-Reply-To: <9408070051.AA25490@smiley.mitre.org.sit> from "Robert W. Shirey" at Aug 6, 94 08:51:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 651 Message-Id: <9408070205.aa21782@sundance.itd.nrl.navy.mil> > Do you thin that the the following draft text states the situation > correctly? Yes, as far as it goes. However it doesn't explicitly address the real need for IMMEDIATE disclosure to the relevant working group(s) and Area Director(s) of all related intellectual property claims (e.g. patent filings or pending patent filings) during the development of Internet protocols and specifications. Since there have been recent problems with patents not being promptly disclosed during IETF working group activity, I want to be sure that we get immediate and complete disclosure in the work going on in IPsec. Thanks, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Sat Aug 6 21:58:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48363 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 21:58:40 -0400 Received: by interlock.ans.net id AA26286 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 21:50:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 21:50:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 21:50:21 -0400 Date: Sat, 6 Aug 1994 18:50:53 -0700 From: Phil Karn Message-Id: <199408070150.SAA11574@servo.qualcomm.com> To: Paul_Lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net, smb#064#research.att.com%INTERNET@email.mot.com In-Reply-To: <00112.2858932602.2803@poncho.phx.sectel.mot.com> (Paul_Lambert@poncho.phx.sectel.mot.com) Subject: Re: >Re[2]- SIPP and SKIP. 2 >> >> DEC devised a clever way to use per-SA keys, without >Note- DEC has patented this clever technique. Right. Also, I can't get too excited about a technique that saves 8 bytes in a table by sending it over and over again in each packet. But maybe that's because I care about irrelevant things like "bandwidth" and "overhead". :-) Speaking of patents, the US Patent Office is accepting comments until the end of August on whether the current standards for "non-obviousness" ought to be tightened. (Is the Pope Polish?) Since I suspect many of you also have opinions on this topic, I thought you might like to put them into writing where they might do some good. For some time I have seen the PTO much like the drunken drivers who stagger away unhurt from one fatal wreck after another, oblivious to the destruction they cause. Since a large part of the solution to both alcoholism and bureaucratism is simply admitting that one may actually have a problem, I take the PTO's solicitation as a hopeful sign. Phil From ipsec-request@ans.net Sat Aug 6 18:49:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18853 (5.65c/IDA-1.4.4 for ); Sat, 6 Aug 1994 23:13:00 -0400 Received: by interlock.ans.net id AA11771 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 6 Aug 1994 23:04:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 6 Aug 1994 23:04:26 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Aug 1994 23:04:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Aug 1994 23:04:26 -0400 Date: Sat, 6 Aug 94 22:49:36 EDT Message-Id: <9408070249.AA01026@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ran Atkinson From: shirey@mitre.org (Robert W. Shirey) Subject: Re: IPsec and patents Cc: ipsec@ans.net OK. But that is procedural and belongs in the regulatory RFCs. So I guess that what I have is alright for just an architecture document. From ipsec-request@ans.net Sun Aug 7 23:42:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02457 (5.65c/IDA-1.4.4 for ); Sun, 7 Aug 1994 19:53:03 -0400 Received: by interlock.ans.net id AA03469 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 7 Aug 1994 19:43:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 7 Aug 1994 19:43:43 -0400 Message-Id: <199408072343.AA35721@interlock.ans.net> To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: fast 386 DES code figures In-Reply-To: Your message of Sat, 06 Aug 94 08:53:10 -0400. <199408061253.AA29158@interlock.ans.net> Date: Sun, 07 Aug 94 19:42:09 -0400 From: Steve Kent Steve & Phil, When four us did an implementation back in the late 70s, as grad students at MIT, we used tables to compose SP and E. Later one of the grad students figured out how to E in a very efficient fashion, whic allowed us to go back to just an S&P composition, with 32-bit vs. 48 bit values. I think that's the common approach today, with the asusmption that the space devoted to the tables is not a big deal on most modern machines. Our fastest implementations were in line code, but instruction cacheing may argue for loops. Steve From ipsec-request@ans.net Mon Aug 8 00:02:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07059 (5.65c/IDA-1.4.4 for ); Sun, 7 Aug 1994 20:12:13 -0400 Received: by interlock.ans.net id AA15351 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 7 Aug 1994 20:03:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 7 Aug 1994 20:03:52 -0400 Message-Id: <199408080003.AA20466@interlock.ans.net> To: "Robert W. Shirey" Cc: ipsec@ans.net, kent@BBN.COM Subject: Re: IPsec and patents In-Reply-To: Your message of Sat, 06 Aug 94 22:49:36 -0400. <9408070249.AA01026@smiley.mitre.org.sit> Date: Sun, 07 Aug 94 20:02:55 -0400 From: Steve Kent Rob and Ran, The text about the need to discpluse intellectual property claims IS in the IAB standards process RFC already. Steve From ipsec-request@ans.net Mon Aug 8 09:32:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34907 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 09:32:12 -0400 Received: by interlock.ans.net id AA25053 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 09:18:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 8 Aug 1994 09:18:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 09:18:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 09:18:46 -0400 Date: Mon, 08 Aug 94 06:02:34 From: "Housley, Russ" Encoding: 2102 Text Message-Id: <9407087763.AA776350954@uu0892.spyrus.com> To: ipsec@ans.net, Ran Atkinson Subject: Re[2]: IPsec and patents Ran: Good points. In IEEE 802.10b, Secure Data Exchange, we added the optional MDF to accomodate the DEC technique (and perhaps other tchniques). I would argue that an optional field than can be used to support a patented technique is not a big concern. The big concern occurrs when the paptented approach is the only (or only reasonable) way to implement the standard. Russ ______________________________ Reply Separator _________________________________ Subject: Re: IPsec and patents Author: Ran Atkinson at internet Date: 8/6/94 1:46 PM > Note- DEC has patented this clever technique. I'd like to put out a request and reminder since there are many on this list who are somewhat new to the IETF way of doing things. 1) The IETF normally tries to avoid using patented techniques in IETF specifications, though it is not always possible (sigh). 2) In any event, it is ALWAYS important to note ALL possible intellectual property claims relating to any proposal in the FIRST note or presentation of the proposal. It is not good practice to propose a technology which is subject to intellectual property claims (e.g. patents) without that up front disclosure. IMHO, we do NOT want a repeat of recent events in another area of the IETF where a vendor pushed a particular algorithm and did not disclose patent claims up front. If that happens here, I _will_ formally make a process violation complaint at or before Last Call. However clever one might consider the DEC technique, I don't want to include it in any portion of the standards-track specification UNLESS DEC formally agrees in writing to license it to all comers at no cost. One of the best reasons to use DES-CBC as a mandatory algorithm is that one does NOT have to obtain any license to use or implement that algorithm. The same is true of MD4 and MD5. These facts are a large part of the reason that existing IETF specs use DES and MD5 as the mandatory algorithms. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Aug 8 10:29:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38960 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 14:46:29 -0400 Received: by interlock.ans.net id AA35345 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 14:29:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 14:29:13 -0400 Message-Id: <199408081829.AA35341@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 14:29:13 -0400 Date: Mon, 8 Aug 94 14:29:13 EDT From: amir@watson.ibm.com To: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Cc: hamid@watson.ibm.com, rosepl@watson.ibm.com Subject: IBM patents on key distribution and authentication Recently, both Ran Atkinson (in the note below sent to IP-SEC) and Bill Simpson (verbally) raised the issue of disclosing patent claims which may be relevant to IETF proposals for standards. While I'm not a patent lawyer and I'm not authorized to represent IBM as to its position on specific patents, I decided to do a reasonable effort to provide the necessary details on IBM policy. I am also initiating an internal IBM discussion as to the very specific license conditions for the specific patents and standards (in simple words, I want to make sure the fee is none or minimal). In fact, I've asked Kannan to check if the following IBM official statement is enough to allow discussions. Since Ran and Bill already raised the question before Kannan could come back to me, let me offer this statement here. If this statement is not enough, and/or if we should have resolved/disclosed this before now, let me clearly express my regret; I'm really new in IETF activities and I'm focusing on technical work (I believe this holds for Hugo and Juan too). The summary of the statement below, as I understand it, is that IBM policy is to make licenses available on non-discriminatory and non-onerous basis (i.e. to all and for reasonable cost). Note also that IBM have made several important patents available for free or for a reasonable lump-sum, e.g. DES; so this is not just theory. Also, while there are many objections to patents on software, I think IBM does fall into the more `fair users' of s/w patents by not being too aggressive in collection and by really investing a lot in research which is made public. So, at least this is not one of these companies that just try to make money by stopping others. Well, end of pro-IBM pitch... Here is the statement, which I received from John Lowe from Licensing: `In the event that the proposed standard is adopted and the standard cannot be practiced without the use of one or more issued patents, including design patents for type fonts but excluding other design patents, which are now or hereafter owned or controlled by IBM, IBM agrees upon request to grant a non-exclusive license under such patent or patents on a nondiscriminatory basis and on reasonable terms and conditions including its then current royalty rates and provided a similar grant under lincensee's patents within the scope of the license granted to licensee is made available upon request to IBM.' IBM has quite a few patents and patent applications on cryptography and cryptographic protocols. There is one of them which I think covers several of the recent key management and authentication proposals. In particular, I believe this patent covers the proposals we are about to make to both IP-SEC and mobile-IP; I suspect it may cover some of the other proposals too, maybe even the basic mobile-IP protocol in either timestamp or nonces versions. (It is not up to me to argue if these claims in this patent are defendable in court or not.) This is US patent 5,148,479, issued Sept 15, 1992 to IBM and invented by Bird et al.; claim 1 in it says: 1. A method of auth a user... comprising the steps of - transmitting a first challenge N1 from a first user A to ... B, - transmitting a first response... [from B to A] - verifying at ... [A] that the first response is correct, - said first response being of the minimal form f(S1,N1,D1,...), wherein S1 is a shared secret between... [A and B], D1 is an indication of the direction of flow of the message of the message... and f() is a function selected such that f(S1,N1',D1',...) = f(S1, N1, D1,...) cannot be solved for N1' without knowledge of S1, wherein f(), N1', D1' represent expressions in a reference connection. (Doesn't make any sense to you? I can't blame you... I hate this patentish and never understand it myself.) For more (formal) information you can contact IBM diretor of licensing at 914-742-6729 (fax), or call John Lowe at 914-742-6275, cc:ed above. Best regards, Amir Herzberg From: Ran Atkinson > Note- DEC has patented this clever technique. I'd like to put out a request and reminder since there are many on this list who are somewhat new to the IETF way of doing things. 1) The IETF normally tries to avoid using patented techniques in IETF specifications, though it is not always possible (sigh). 2) In any event, it is ALWAYS important to note ALL possible intellectual property claims relating to any proposal in the FIRST note or presentation of the proposal. It is not good practice to propose a technology which is subject to intellectual property claims (e.g. patents) without that up front disclosure. IMHO, we do NOT want a repeat of recent events in another area of the IETF where a vendor pushed a particular algorithm and did not disclose patent claims up front. If that happens here, I _will_ formally make a process violation complaint at or before Last Call. However clever one might consider the DEC technique, I don't want to include it in any portion of the standards-track specification UNLESS DEC formally agrees in writing to license it to all comers at no cost. One of the best reasons to use DES-CBC as a mandatory algorithm is that one does NOT have to obtain any license to use or implement that algorithm. The same is true of MD4 and MD5. These facts are a large part of the reason that existing IETF specs use DES and MD5 as the mandatory algorithms. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Aug 8 11:49:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07123 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 16:04:06 -0400 Received: by interlock.ans.net id AA10006 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 15:49:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 15:49:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 15:49:36 -0400 Date: Mon, 8 Aug 94 15:49:16 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9408081949.AA18613@tsx-11.MIT.EDU> To: amir@watson.ibm.com Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com, hamid@watson.ibm.com, rosepl@watson.ibm.com In-Reply-To: amir@watson.ibm.com's message of Mon, 8 Aug 94 14:29:13 EDT, <199408081829.AA35341@interlock.ans.net> Subject: Re: IBM patents on key distribution and authentication Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 8 Aug 94 14:29:13 EDT From: amir@watson.ibm.com (It is not up to me to argue if these claims in this patent are defendable in court or not.) This is US patent 5,148,479, issued Sept 15, 1992 to IBM and invented by Bird et al.; claim 1 in it says: 1. A method of auth a user... comprising the steps of - transmitting a first challenge N1 from a first user A to ... B, - transmitting a first response... [from B to A] - verifying at ... [A] that the first response is correct, - said first response being of the minimal form f(S1,N1,D1,...), wherein S1 is a shared secret between... [A and B], D1 is an indication of the direction of flow of the message of the message... and f() is a function selected such that f(S1,N1',D1',...) = f(S1, N1, D1,...) cannot be solved for N1' without knowledge of S1, wherein f(), N1', D1' represent expressions in a reference connection. Yikes! Someone should correct me if I'm wrong, but if I'm reading the claim correctly, it claims to cover all all forms of challenge-response authentication. Fortunately, there shouldn't be any lack of prior art if this is the case..... Do you know when the patent was actually filed, as opposed to when it was issued? - Ted From ipsec-request@ans.net Mon Aug 8 12:06:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16554 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 16:21:36 -0400 Received: by interlock.ans.net id AA12066 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 16:06:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 16:06:43 -0400 Message-Id: <199408082006.AA27166@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 16:06:43 -0400 Date: Mon, 8 Aug 94 16:06:45 EDT From: amir@watson.ibm.com To: tytso@ATHENA.MIT.EDU, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Cc: hamid@watson.ibm.com Subject: Re Ted Re: IBM patents on key distribution and authentication Ted says: >Yikes! Someone should correct me if I'm wrong, but if I'm reading the >claim correctly, it claims to cover all all forms of challenge-response >authentication. Fortunately, there shouldn't be any lack of prior art >if this is the case..... I completely agree with you, but that's my personal position, of course. >Do you know when the patent was actually filed, as opposed to when it >was issued? Yep, March 20, 1991. Well, don't blame me, I'm just the messenger! For IBM I'll say that I'm sure there is no policy to over-claim. But, of course, the best patent lawyers are only (somewhat) human :-( Best, Amir From ipsec-request@ans.net Mon Aug 8 20:27:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48243 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 16:42:39 -0400 Received: by interlock.ans.net id AA32552 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 16:27:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 8 Aug 1994 16:27:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 8 Aug 1994 16:27:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 16:27:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 16:27:27 -0400 Message-Id: <9408082027.AA21973@snark.imsi.com> To: ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Subject: Re: IBM patents on key distribution and authentication In-Reply-To: Your message of "Mon, 08 Aug 1994 14:29:13 EDT." <199408081829.AA35341@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 08 Aug 1994 16:27:01 -0400 From: "Perry E. Metzger" amir@watson.ibm.com says: > Here is the statement, which I received from John Lowe from Licensing: > > `In the event that the proposed standard is adopted and the standard > cannot be practiced without the use of one or more issued patents, > including design patents for type fonts but excluding other design > patents, which are now or hereafter owned or controlled by IBM, IBM > agrees upon request to grant a non-exclusive license under such patent > or patents on a nondiscriminatory basis and on reasonable terms and > conditions including its then current royalty rates and provided a similar > grant under lincensee's patents within the scope of the license granted > to licensee is made available upon request to IBM.' I am extraordinarily reluctant to propose that we use any patented technology at all under any circumstances if it is at all avoidable, unless the patent is made available without any license fee whatsoever. This is for many reasons, including the fact that patented technology makes freely available implementations nearly impossible, and drastically slows the spread of a given technology. I also find it difficult to stomach being part of a processed that imposes on third parties the payment of royalties to one particular company that managed to get its "foot in the door" -- and I wonder what the anti-trust implications are for the IETF should a competitor, also with a patented technology, become upset that their royalty machine wasn't picked instead of, say, IBM's. I've been forced to accept the necessity of using patented public key technology in certain places, but I do so only with extreme reluctance and because there are no reasonable substitutes for this technology. Under most circumstances I personally would not support the use of any technology for use in internet standard protocols, even if technically superior in some minor ways, if they were patented and the patent holders refused to relinquish any rights as a prerequisite of standardization. I am also very much horrified by the notion that anyone would propose the use of patented technology, knowing it was patented, without disclosing it during the working group process, as has apparently happened in certain instances. Perry From ipsec-request@ans.net Mon Aug 8 20:40:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06961 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 16:56:30 -0400 Received: by interlock.ans.net id AA18220 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 16:41:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 16:41:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 16:41:03 -0400 Date: Mon, 8 Aug 1994 13:40:19 -0700 From: Tony Li Message-Id: <199408082040.NAA04498@lager.cisco.com> To: mobile-ip@sunroof.eng.sun.com Cc: atkinson@sundance.itd.nrl.navy.mil, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com, hamid@watson.ibm.com, rosepl@watson.ibm.com In-Reply-To: amir@watson.ibm.com's message of Mon, 8 Aug 94 14:29:13 EDT <9408081829.AA16809@Sun.COM> Subject: (mobile-ip) IBM patents on key distribution and authentication Gents, I've referred the matter to our lawyers. I suspect that what will come back will be: - cisco has no problems if IBM is willing to make the terms be "free" to all comers - otherwise we should find other technology Again, this is my personal opinion. Tony From ipsec-request@ans.net Mon Aug 8 21:40:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15425 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 18:05:20 -0400 Received: by interlock.ans.net id AA27281 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 17:40:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 17:40:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 17:40:11 -0400 Date: Mon, 8 Aug 1994 14:40:00 -0700 From: Phil Karn Message-Id: <199408082140.OAA25478@servo.qualcomm.com> To: perry@imsi.com Cc: ipsec@ans.net, mobile-ip@sunroof.eng.sun.com In-Reply-To: <9408082027.AA21973@snark.imsi.com> (perry@imsi.com) Subject: Re: IBM patents on key distribution and authentication I fully agree with Perry's sentiments about completely avoiding patented technology to the greatest possible extent. But when incredibly broad (and bogus) patents appear like the recent ones from IBM on state machine protocols, assigning temporary IP addresses to mobile users and now this one on challenge-authentication, what can we do? Give up and go home? I think we should ask if IBM (or whoever) is willing to grant free use. If so, the problem is solved. If not, I don't see any alternative but to simply ignore those patents we consider bogus (i.e., for which we have ample prior art), press on and hope we don't get sued. The patent office does have a reexamination procedure, but by all accounts it is a complete joke. I keep hearing that IBM never sues you unless you sue them first. Maybe so. I've seen many examples of companies that never sue as long as they're successful, even with plenty of provocation. But the moment they get into trouble because of failure to innovate, the infringement suits start flying. And in their death throes they'll take down as much of the industry with them as they can. Maybe IBM isn't at that stage yet, but I wouldn't bet on it. Phil From ipsec-request@ans.net Mon Aug 8 22:04:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44720 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 18:28:53 -0400 Received: by interlock.ans.net id AA23248 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 18:05:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 8 Aug 1994 18:05:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 8 Aug 1994 18:05:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 18:05:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 18:05:01 -0400 Message-Id: <9408082204.AA22144@snark.imsi.com> To: ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Subject: Re: IBM patents on key distribution and authentication In-Reply-To: Your message of "Mon, 08 Aug 1994 14:40:00 PDT." <199408082140.OAA25478@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 08 Aug 1994 18:04:50 -0400 From: "Perry E. Metzger" Phil Karn says: > I fully agree with Perry's sentiments about completely avoiding > patented technology to the greatest possible extent. But when > incredibly broad (and bogus) patents appear like the recent ones from > IBM on state machine protocols, assigning temporary IP addresses to > mobile users and now this one on challenge-authentication, what can we > do? Give up and go home? I fully agree that we should not give in to egregiously bad patents. The X consortium and MIT have refused to give in to AT&T's claims that it owns a patent on the use of backing store in windowing systems, and I similarly would suggest that it would be unreasonable to give in to a claimed patent on challenge-response systems. I was addressing only the question of whether we should knowingly specify the use of technology that we know to have a *valid* patent on it, and whether it is ethical for participants in working groups to knowingly suggest such technology without mentioning the patents on it -- the answer I give to both questions is "no". Perry From ipsec-request@ans.net Mon Aug 8 09:10:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40415 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 19:33:55 -0400 Received: by interlock.ans.net id AA21590 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 19:09:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 8 Aug 1994 19:09:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 8 Aug 1994 19:09:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 19:09:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 19:09:55 -0400 Date: Mon, 8 Aug 94 16:10:16 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408082310.AA12584@miraj.Eng.Sun.COM> To: housley@spyrus.com Subject: Re: Re[4]: SIPP and SKIP. 2 subjects. Cc: ipsec@ans.net Content-Length: 489 Russ, Amir and Steve, Thanks for the clarification regarding the use of MDF in 802.10. So far, none of the benefits that have been listed for the scheme strike me as unachievable even if the MDF was not constrained to be a constant (including the benefit of a table-less key-lookup scheme). Constraining the MDF to be constant per SA, as currently specified, does have the (unfortunate) side-effect of precluding the use of key-seeded stream ciphers with multicast in 802.10. Ashar. From ipsec-request@ans.net Mon Aug 8 15:28:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02502 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 20:05:20 -0400 Received: by interlock.ans.net id AA31777 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 19:28:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 19:28:30 -0400 Message-Id: <199408082328.AA10013@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 19:28:30 -0400 Date: Mon, 8 Aug 94 19:28:32 EDT From: hugo@watson.ibm.com To: perry@imsi.com, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Subject: IBM patents on key distribution and authentication Ref: Your note of Mon, 08 Aug 1994 18:04:50 -0400 Perry Metzger says: > addressing only the question of whether we should knowingly specify > the use of technology that we know to have a *valid* patent on it, and > whether it is ethical for participants in working groups to knowingly > suggest such technology without mentioning the patents on it -- the > answer I give to both questions is "no". Indeed, I already mentioned during my presentation in the IETF this issue of the patents and our current work to clarify IBM's position with respect to them. Our personal position is to influence IBM decision so that the patents are waived for use in the Internet protocols but the final decision is not ours. In addition, let put it very clear that we have not patented or intend to patent the particular protocols that we are proposing to these lists. Hugo From ipsec-request@ans.net Tue Aug 9 00:00:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38902 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 20:34:43 -0400 Received: by interlock.ans.net id AA15012 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 20:00:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 20:00:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 20:00:21 -0400 Date: Mon, 8 Aug 1994 17:00:15 -0700 (PDT) From: Everett F Batey WA6CRE Subject: Re: IBM patents on key distribution and authentication To: ipsec@ans.net Cc: perry@imsi.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: <9408082204.AA22144@snark.imsi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII IFF was a challenge and response system developed around the time of my birth .. for those examining PRIOR ART .. now Im 50 .. whose original work ? + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle_s | WWW b-news postmaster xntp dns WAFFLE + + Info Super Highway Consulting Puts Business or Country on the Internet + From ipsec-request@ans.net Mon Aug 8 21:57:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02434 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 21:21:45 -0400 Received: by interlock.ans.net id AA37308 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 8 Aug 1994 20:46:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 8 Aug 1994 20:46:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Aug 1994 20:46:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Aug 1994 20:46:21 -0400 Message-Id: <9408082157.AA07292@alpha.zk3.dec.com> To: ipsec@ans.net Cc: atkinson@itd.nrl.navy.mil, amir@watson.ibm.com, kaufman@zk3.dec.com Subject: Encrypted Key Patent Date: Mon, 08 Aug 94 17:57:48 -0400 From: kaufman@zk3.dec.com X-Mts: smtp There has been some confusion around a patent Digital holds on using an encrypted key as a key identifier. As one of the guilty parties having filed the patent, I'd like to try to clear it up. Reference: Patent #5,081,678 filed 6/28/89 issued 1/14/92: "Method for Utilizing an Encrypted Key as a Key Identifier in a Data Packet in a Computer Network". Q: What is patented: A: The technique of encrypting a session key under a per-node private master key and putting that encrypted key in the packet header. Q: Why would anyone want to do that??: A: As Phil Karn pointed out, this consumes network bandwidth by having a large (8 bytes) key identifier when a small one (1-2 bytes) would do with no obvious savings. We needed to do it because of a particular type of cryptographic hardware we built. We wanted the hardware to be able to decrypt packets as they arrive off the net before they enter the node's memory. The conventional way to do this is to have a key table in the hardware looks up keys based on a key-id (or connection id) in the packet header. Because we didn't want to have enough memory in the hardware to store keys for the largest possible number of connections, we came up with putting the encrypted key in the packet header. An anomoly of hardware solutions is that sometimes they can decrypt faster than they can do table lookups. Q: And we wanted the IETF to standardize that kludge!? A: No. We wanted the IETF standard to permit it. Almost any protocol is going to have some sort of key identifier in the packet header. We needed two things: 1) For the key identifier to be allowed to be large enough to hold an encrypted key. That's 8 bytes for DES and more for better algorithms. 2) For the key establishment algorithm to permit the destination to specify the key id to use rather than having one somehow selected algorithmically. This is useful in other contexts as well; a conventional implementation, for example, is likely to want the key identifier to be a small integer used to index into a table. For best use of memory, it would like that integer to be chosen from a dense space. Q: So is this on the standards track now? A: Sort of. We had proposed a variable length "SAID" that could hold the big key identifier. It was pointed out that this data need not be in the SAID, but rather could be in the algorithm-specific header. Since we aren't yet debating algorithm specific formats, the debate has effectively been postponed. Since this has to be settled before we can actually build things that interoperate, I hope it will come up again soon. >From: Ran Atkinson > >> Note- DEC has patented this clever technique. > >I'd like to put out a request and reminder since there are many on this >list who are somewhat new to the IETF way of doing things. > >1) The IETF normally tries to avoid using patented techniques in IETF >specifications, though it is not always possible (sigh). > >2) In any event, it is ALWAYS important to note ALL possible >intellectual property claims relating to any proposal in the FIRST >note or presentation of the proposal. It is not good practice to >propose a technology which is subject to intellectual property claims >(e.g. patents) without that up front disclosure. > As noted above, it is not necessary or even useful for the standard to prescribe use of the patented technique, so I don't think that is an issue. I was up-front about mentioned the existence of the patent when I proposed the formats. At issue is to what degree should the IETF go out of its way to accomodate a technique that is not freely available. Clearly, the answer is not very far. I don't think it needs to, but reasonable people will differ on how far is too far (and unreasonable people will flame). > >However clever one might consider the DEC technique, I don't want to >include it in any portion of the standards-track specification UNLESS >DEC formally agrees in writing to license it to all comers at no cost. > I'm sure Digital's policy is the same as that vague one quoted from IBM about reasonable, non-discriminatory, etc. etc. There was a time when we might have been willing to sign up for free licenses to grease the path through standards. Today, this effort has a much lower priority and I wouldn't know how to motivate someone with the authority to do this to spend the time to think about it. I continue to advocate this approach because I think it is sound engineering that someone may take advantage of someday. --Charlie (kaufman@zk3.dec.com) From ipsec-request@ans.net Tue Aug 9 02:59:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43345 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 00:25:22 -0400 Received: by interlock.ans.net id AA24360 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 00:10:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 00:10:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 00:10:31 -0400 Date: Tue, 9 Aug 94 02:59:48 GMT From: "William Allen Simpson" Message-Id: <3001.bill.simpson@um.cc.umich.edu> To: mobile-ip@sunroof.eng.sun.com Cc: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Validity of Patents > From: jhalpern@Newbridge.COM (Joel Halpern) > The difficulty I see with your approach is that we end up with > IETF working groups trying to decide what is or is not a valid > patent. That is clearly useless, and could get us into worse > trouble if we decide wrongly. > Thank you, but sometimes we _have_ to decide the validity of patents. So far, I have only been exposed to 4 cases where patents might apply to work we have underway, and in all cases the patents were bogus: 1) In the PPP WG, DEC first proposed using a certain technique for multiplying the series that define the 16-bit and 32-bit CRCs, to yield a CRC that was correct for both 16 bits and 32 bits. This was used for a single transition packet when switching hardware modes. After we adopted it, DEC informed us it had applied for a patent on the technique. They wanted $20,000 per license, which they were willing to grant on a "non-discriminatory basis". Since I license a complete PPP stack for less (and Phil Karn licenses a complete TCP/IP/DNS/email/operating system for less), this was not deemed "reasonable" for one packet. It took me about 20 minutes to remove that technique, and standardize sending 2 packets back to back with the different CRCs [RFC-1570]. Since when is multiplying 2 series considered "original"? We all learned how in second semester calculus. Or is creating CRCs from series "original"? No, that's how CRCs have been defined for decades. Yet, we chose to avoid the issue in this case. The minor inefficiency was not worth the legal hassle. 2) In the PPP WG, we have a PPP Compression draft ready to go. It is stalled by a patent claim by Motorola. Motorola claims to have invented sending a NAK back to the sender when a sequence check or CRC is bad, when sending "encoded" data over an unreliable link. The intent is apparently to claim that compressed or encrypted data have never before been sent over unreliable links with sequence numbers or CRC protection, and no feedback has ever been sent back. Is this valid? Clearly, no. I've sent compressed or encrypted files over IP for years. Yet, we are held up at the IESG. 3) In Mobile-IP, we learned that IBM has been granted a patent on dynamically assigning addresses, keeping a registry of such addresses, and distributing these addresses through a server. The claim to fame is that this only applies when such a system is used to connect a wired network to a wireless network, although all kinds of such links are claimed. TCP/IP is explicitly mentioned. Is this valid? Shall we stop developing Mobile-IP? DHCP? In this case, Charlie admits that he was not a Ham, and had never heard of the IETF when he applied for the patent. Clearly, he was not "skilled in the art". Never-the-less, Mobile-IP avoids using the technique. (It wastes bandwidth and IP addresses.) But a lot of people want it (see the recent "popup" discussion). 4) Now, we learn that IBM claims a patent on challenge/response authentication, and negotiating a session key with such an exchange. Is this valid? Shall we stop developing Mobile-IP? IP-Security? It took me about 3 hours to remove every taint of this from Mobile-IP. But, I did it by referencing IP-Security.... > 1) Always prefer unpatent technology if it will do the job Yes, that's the way we handled #1 above. > 2) Only use patented technology with a committment to non-discriminatory > licensing at a reasonable fee. This is the standard that IEEE and > ANSI use. > Define "reasonable". My position is that the only reasonable terms are "none". My experience negotiating a "free" license (with Stac) is that it involves 3 contract exchanges, 6 months, and argument over terms and limits. And Lawyers. That is unreasonable. So, what do we do about cases #2, #3, or #4, where we know there is plenty of prior art? I say we ignore the bogus patents, and continue. After all, in case #3, we would have to "license" PPP, BOOTP and the DNS.... Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Aug 9 02:31:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43350 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 00:26:14 -0400 Received: by interlock.ans.net id AA15648 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 00:10:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 00:10:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 00:10:19 -0400 Date: Tue, 9 Aug 94 02:31:18 GMT From: "William Allen Simpson" Message-Id: <2998.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: mobile-ip@sunroof.eng.sun.com Reply-To: bsimpson@morningstar.com Subject: Re: IBM patents on key distribution and authentication Ran has stated that he will initiate a formal "process" complaint if any undisclosed patents are inserted into IP-Sec WG Drafts. I have already initiated a formal "process" complaint with the Chair of the IESG, of undisclosed patents inserted into Mobile-IP drafts, and am in the process of completely removing any tainted material. In this case, Amir and Hugo started a long diatribe on the Mobile-IP list about authentication, long after we had already adopted a simpler scheme and finished drafting the authentication sections. After much discussion, they got many in the WG to agree to change to their technique of challenge/response, rather than simple keyed-MD5, for authentication. At no time did they disclose their Intellectual Property interest to the mailing list. At IETF in Toronto on Monday, after prompting from Ran, I asked Kannan to ask Amir and Hugo about any I-P rights. I understand that Kannan spoke with them before the WG meeting began. During their presentations at Mobile-IP, they still did not disclose their I-P interest before beginning, and did not disclose at any time during the presentation. Only after the meeting was over did they admit to Kannan in my presence that there might be I-P rights included. Nor is this the first problem from the _same_ IBM lab with regard to Mobile-IP. Last March, after many months of discussion, Charlie Perkins disclosed that he had patented one of the ideas he had been pushing during the WG discussion. At that time, I was willing to let it slide, since our I-P guidelines were new and recently published. I certainly expect that Charlie explained the IETF rules to them, and they claim to be published elsewhere, which means they should know the similar IEEE, ANSI, et alia, I-P disclosure rules. A second violation from the same lab does not appear to be coincidental. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Aug 9 14:53:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34818 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 10:07:19 -0400 Received: by interlock.ans.net id AA03476 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 09:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 9 Aug 1994 09:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 9 Aug 1994 09:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 9 Aug 1994 09:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 09:53:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 09:53:09 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9408091353.AA26020@np2.watson.ibm.com> To: mobile-ip@sunroof.eng.sun.com, ipsec@ans.net Subject: Patents Date: Tue, 09 Aug 94 09:53:06 -0500 After reading Simpson's intentionally bruising and misleading statements regarding IBM patents and participation in the IETF process, I feel that I must respond. First, there are engineers involved here, not demons from hell. These people, some of which I know, spend time researching new technology and developing it. Sometimes, after the successful conclusion of a project, it is decided to try to patent the mechanisms which were invented during the development of the project. Is this unreasonable? Surely not! Second, anyone who has good ideas should be welcomed as part of the IETF process. Shall we all disclose our entire patent portfolio before we speak? Maybe for completeness, we should preface each public statement with a description of possible corporate interests? Somehow, it doesn't seem quite right. No, indeed, I would think that all participants should be well informed of the importance of disclosing patents, when they realize that they have knowledge of patents that are relevant. This has to be balanced with the obvious desire to avoid disclosing patented technology which may not be relevant. I'd hate to see any IETF working group spend all of its time hassling over patent law. In fact, I'm alarmed at the amount of time spent hassling in general! I thought the last mobile-IP working group went very well, because the consensus building and direct participation of our working group chair. With the same approach, and no changes to our working paradigm, I'm sure we could have had at least one working draft last fall. I sure am tired of hearing accusations. In fact, these accusations are quite counterproductive. Bill Simpson paints a bleak picture of ostracism for any "unfortunate" engineers who might be named in a patent disclosure. Who wants to stand up to that sort of public invective? Why not instead welcome participation by such engineers according to mutually beneficial and productive bylaws? Bill's strategy of division and nastiness is really wrong. IETF working groups should not favor poor technology to avoid patents, when the patented technology is to be made available at low or no cost. We'd just be agreeing that IETF protocols are what's left over after the cream is skimmed. I think it would be a lot smarter to increase the recognition within the working groups for exploring patent issues early, make sure that the participants get reasonable corporate statements when patented technology may be incorporated as part of a proposed protocol, and stop these misguided assertions of malevolence. On the subject of patents in general, I almost agree with Phil's assessment of damage. The problem seems to be that getting a patent is too expensive, beyond the reach of the average working engineer who might come up with a slick idea. Thus corporations and corporate lawyers have an advantage. And, since the lawyers want to maximize corporate advantage, they ask for everything they can get from the Patent Office, without intentionally trying to claim prior art. As far as they are concerned, it's a matter of building a case, arguing it, and winning as much as possible. To change that, the Patent Office must change what it will grant, since it's unlikely anyone can change the legal profession. From what I've seen, "routing" is a patented technology, as is the "cursor", the infamous "backing store", etc... But this is not the fault of engineers! Charlie P. From ipsec-request@ans.net Tue Aug 9 09:09:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15378 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 13:25:57 -0400 Received: by interlock.ans.net id AA30715 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 13:09:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 13:09:38 -0400 Message-Id: <199408091709.AA30711@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 13:09:38 -0400 Date: Tue, 9 Aug 94 13:09:40 EDT From: amir@watson.ibm.com To: perry@imsi.com, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Cc: hamid@watson.ibm.com Subject: Patents: fees, validity, and disclosure process. Let me clarify my personal position on this matter, which I believe reflects the feelings of the others in my group (Hugo and Juan, for example), but is not (yet?) the official IBM position. Also, let me explain our plan. Firstly, I completely agree with Phil, Perry and others, that this specific patent seems to be extremely broad, and one wonders if it cannot be (partially, probably) invalidated. Furthermore, I personally agree that standards should avoid patents when possible (when fee is required). Certainly, the internet policy on this is extremely reasonable; in fact I think it is the same as an IBM policy I've seen which says ``... provided such patents are made available on a non-discriminatory basis under a nonexclusive license on reasonable terms.'' Unfortunately, this specific patent does have these broad claims which are hard to escape in a good authentication and key distribution protocol. Even if these claims, or some of them, are invalid, we should resolve this issue before establishing them in a standard. One simple solution is for IBM to give the patent for free. This would be especially nice since some of the more specific claims of this patent covers really pretty neat ideas which we like to use for efficiency and (provable) security. I like this simple solution! Let me clarify that this is my personal position, and that I've been for quite a while working on getting IBM to decide to allow free use of this patent for both mobile-IP and IP-SEC purposes. But IBM is not quick on such decisions. I've had to talk to several groups, product owners,... and I'm not quite through yet. But I do have hope to be successful. In fact, I have even more ambitious plans: I'm trying to get our IP Key Management code to be free. Well, it ain't easy, I can tell you. Note, however, that even if I fail, it should still be pretty easy to produce _free_ versions. If I understood our licensing guys correctly, a freeware version would not have to pay any royalties, except maybe a one time fee of 5000$ (I may be wrong!). So, as a fallback strategy I'll try to get this fee waived, so at least freeware versions may avoid any payment. But of course I may succeed to get a complete waiver... Now, about the claims that we have been too late to disclose the patent issues. We certainly had no intention to `sneak in' a patent. It took long time from the moment we started suspecting there may be a patent problem, until we actually got hold of the patent, tried to understand if it does apply, and so on. Even today, I can't say I'm sure there is a problem... These patents are so tricky and use such strange language that I feel only an expert lawyer should be asked to do such evaluations. We are doing what we can on a best effort basis, and with a reasonable amount of time. In the IETF, Hugo did make the issue clear before our presentations in IP-SEC. At the time, I did not consider that the patent may apply to the basic mobile-IP protocol (I'm not sure it does even now). I did speak for 5 minutes on a possible optional extension for key distribution, and I guess I did not mention under these time constraints the patent... But I certainly did not hide it! Let me express my regret of not raising this issue earlier, which is partially due to the time it took me to investigate and find the patent, partially due to my concentration on technical work rather than on such `business' issues, and partially due to my lack of experience in the Internet process. Best regards, Amir Herzberg From ipsec-request@ans.net Tue Aug 9 09:57:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40347 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 14:22:47 -0400 Received: by interlock.ans.net id AA29329 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 14:06:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 9 Aug 1994 14:06:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 14:06:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 14:06:14 -0400 Date: Tue, 9 Aug 94 13:57:56 EDT From: Marcus J Ranum Message-Id: <9408091757.AA14091@tis.com> To: amir@watson.ibm.com, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com, perry@imsi.com Subject: Re: Patents: fees, validity, and disclosure process. Cc: hamid@watson.ibm.com >One simple solution is for IBM to give the patent for free. This would be I dislike this idea, personally, since that implies that such a ridiculous patent might have some validity, and sets a bad precedent. Broad, vague patents covering prior art should be laughed away, not given away. Taking them seriously to any degree means that sooner or later some vulture is going to try to demand royalties. mjr. From ipsec-request@ans.net Tue Aug 9 06:47:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40420 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 17:04:35 -0400 Received: by interlock.ans.net id AA17687 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 16:49:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 16:49:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 16:49:03 -0400 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Date: Tue, 9 Aug 94 13:47:36 PDT Message-Id: <9408092047.AA21595@slced1> To: ipsec@ans.net Subject: Re: Patents: fees, validity, and disclosure process. Cc: hamid@watson.ibm.com, perry@imsi.com, mobile-ip@sunroof.eng.sun.com, amir@watson.ibm.com Does the patent claimant also claim that all similar key exchanging systems which predominated in military hardware in the last 50 years are the intellectual property of the claimant ??? From ipsec-request@ans.net Tue Aug 9 20:56:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43881 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 17:14:50 -0400 Received: by interlock.ans.net id AA30606 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 16:59:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 9 Aug 1994 16:59:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 9 Aug 1994 16:59:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 16:59:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 16:59:28 -0400 Message-Id: <9408092056.AA25614@snark.imsi.com> To: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Cc: ipsec@ans.net, mobile-ip@sunroof.eng.sun.com Subject: Re: Patents: fees, validity, and disclosure process. In-Reply-To: Your message of "Tue, 09 Aug 1994 13:47:36 PDT." <9408092047.AA21595@slced1> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 09 Aug 1994 16:56:08 -0400 From: "Perry E. Metzger" Everett F Batey says: > Does the patent claimant also claim that all similar key exchanging > systems which predominated in military hardware in the last 50 years > are the intellectual property of the claimant ??? IBM has also recently successfully patented finite state machines. Is it too late for me to attempt to patent the use of bit strings to encode letters of alphabet and other symbols for transmission over data networks incorporating retransmission of corrupted packets? Perry From ipsec-request@ans.net Tue Aug 9 22:57:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41439 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 18:09:44 -0400 Received: by interlock.ans.net id AA36651 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 17:57:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 9 Aug 1994 17:57:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 9 Aug 1994 17:57:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 9 Aug 1994 17:57:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 17:57:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 17:57:38 -0400 From: uri@watson.ibm.com Message-Id: <9408092157.AA17737@buoy.watson.ibm.com> Subject: Re: Patents: fees, validity, and disclosure process. To: perry@imsi.com Date: Tue, 9 Aug 1994 17:57:33 -0500 (EDT) Cc: efb@suned1.Nswses.Navy.Mil, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com In-Reply-To: <9408092056.AA25614@snark.imsi.com> from "Perry E. Metzger" at Aug 9, 94 04:56:08 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Perry E. Metzger says: > IBM has also recently successfully patented finite state machines. Oh? > Is it too late for me to attempt to patent the use of bit strings to > encode letters of alphabet and other symbols for transmission over > data networks incorporating retransmission of corrupted packets? So why don't you try? You never know... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 9 14:54:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16682 (5.65c/IDA-1.4.4 for ); Tue, 9 Aug 1994 19:05:39 -0400 Received: by interlock.ans.net id AA16322 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Aug 1994 18:54:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Aug 1994 18:54:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Aug 1994 18:54:28 -0400 Date: Tue, 9 Aug 94 18:54:16 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9408092254.AA29266@tsx-11.MIT.EDU> To: perry@imsi.com Cc: efb@suned1.Nswses.Navy.Mil, ipsec@ans.net, mobile-ip@sunroof.eng.sun.com In-Reply-To: Perry E. Metzger's message of Tue, 09 Aug 1994 16:56:08 -0400, <9408092056.AA25614@snark.imsi.com> Subject: Re: Patents: fees, validity, and disclosure process. Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Tue, 09 Aug 1994 16:56:08 -0400 From: "Perry E. Metzger" Everett F Batey says: > Does the patent claimant also claim that all similar key exchanging > systems which predominated in military hardware in the last 50 years > are the intellectual property of the claimant ??? IBM has also recently successfully patented finite state machines. Is it too late for me to attempt to patent the use of bit strings to encode letters of alphabet and other symbols for transmission over data networks incorporating retransmission of corrupted packets? Why not? Everyone should play the patent lottery, and see if they can win! The chances may be better than Publisher's Clearinghouse, and the payoff might even be better. :-) Seriously, perhaps we should take this discussion off-line. I suspect most everyone agrees that overly broad patents are a bad thing, just as export controls on cryptography are a bad thing. Unfortunately, it's a fact of life, at least in the United States, and so we're going to have to live with it. (Or at least those things we can do, like lobby Congress, *really* fall outside the scope of this these working group lists.) If there are specific patent issues that are particular to either the ipsec working group, or the mobile-ip working group, we should discuss them in our respective WG mailing lists. But this public hand-wringing about how the PTO is destroying western civilization by granting vague, over-broad patents which have decades of prior art is only going to be preaching to the choir. People who really care about these issues should be sending these flame-o-grams^H^H^H^H^H^H^H^H^H^H^H^H^H^H expressions of concern to their congressmen. - Ted From ipsec-request@ans.net Wed Aug 10 01:43:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44697 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 12:01:56 -0400 Received: by interlock.ans.net id AA35932 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 11:46:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 10 Aug 1994 11:46:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 10 Aug 1994 11:46:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 11:46:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 11:46:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 11:46:17 -0400 Message-Id: <00112.2859353285.3636@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: minutes@cnri.reston.va.us (minutes) Cc: jis@mit.edu (Jeff Schiller), zmuda@spyrus.com (Jim Zmuda), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 10 Aug 1994 8:43:12 MST Subject: IPSEC Minutes - July 94 IPSEC Minutes - July 94 Minutes of the IP Security (IPSEC) WG at the Thirtieth IETF (July 27 and 28, 1994) The IP Security (IPSEC) Working Group met twice during the Thirtieth IETF in Toronto. On Wednesday July 27, the IPSEC working group met and discussed the IP Security Protocol (IPSP). On Thursday July 28, the working group discussed IPSEC key management and possible algorithms and embodiments of the Internet Key Management Protocol (IKMP). Wednesday July 27, IPSEC Working Group Meeting (IPSP) A brief summary of the working group status, charter, goals, and related work was presented. The IPSEC Working Group will develop a security protocol in the network layer to provide cryptographic security services to protect client protocols of IP (IPv4 and IPv6). The protection shall support combinations of authentication, integrity, access control, and confidentiality services. The IP Security Protocol (IPSP) shall be independent of the cryptographic algorithm and support host-to-host security, and subnet-to-subnet and host-to-subnet topologies. Many implementations and specification of network exist. The swIPe protocol has recently been released as a freely available software. A brief summary of swIPe was provided by Perry Metzger. Paul Lambert gave a brief overview of the Secure Data Network System (SDNS) protocol SP3. Many implementations of SP3 or SP3-like devices exist, but none are freely available. Few of these implementations interoperate (a feature?). It was noted that SP3 can't directly protect TCP without a selector of some sort.The SP3 SAID controlled formats inside the packets: permits I sandwich or a non-IP sandwich. The SP3 features provided a little of anything. The problems with SP3 include a difficult to read specification, unnecessary fields in the clear header (very minor problem), closely tied to ISO TP (makes support of TCP and other Internet protocol slightly harder). Rob Glenn, of NIST discussed NLSP and his recent enhanced proposals. He felt that NLSP was not a bad place to start, but was difficult to understand, overly complex, had an inefficient packet structure, was flexible and extensible, but too much so. NLSP was rejected by the IPSEC working group. Rob has documented two proposals that have evolved from his work with NLSP. He has an implementation of I-NLSP done in BSD 4.4. kernel and has offered to release the code. The working group has defined a baseline approach and format for IPSP based on the lessons learned from existing implementations. The approach is to define a simple cryptographic encapsulation protocol that supports algorithm independence through the use of a Security Association Identifier (SAID). The baseline consists of a single field in the Rclear headerS - the SAID. The SAID is pre-established and is used to determine the algorithm, key, and protocol formats for the Rsecurity transformationS. The only information that must be carried (besides the protected data) in the protected portion of the PDU is a Next Protocol field. At least two security transformations will be defined in the base specification. Currently the group seems to favor including DES-CBC-MD5 (for confidentiality and integrity) and Keyed-MD5 (for integrity and authentication only). Additional transformations may include facilities for sequence integrity (without recovery), and additional algorithms (IDEA, triple DES, etc.). A version number was proposed for inclusion in the first three or four bits of the clear header of the protocol (or as the first bits of the SAID). Steve Bellovin described authentication in IPng. Authentication is required, encryption will not be used everywhere. Packet filters may need to filter data encapsulated within a authentication header. SIPP defined a separate payload type for the authentication only header. Summary of IPSP Issues Protocol numbers need to be assigned for IPSP. A proposal to use one of the SIPP/IPng numbers was made and will be investigated. The relationship of IPSP to the SIPP authentication only header needs additional investigation. More documentation of IPSP is required (Perry Metzger has volunteered to edit). The use of SAIDs with multicast needs to be clarified. Key management attributes need to be defined for IPSP for use in the negotiation by key management. Thursday July 28, IPSEC Working Group Meeting (IKMP) IPSEC key management is an application layer protocol that will be developed independently of IPSP. It is coupled loosely to IPSP via the SAID. The Internet Key Management Protocol (IKMP) is expected to handle negotiation of cryptographic algorithms, protocol format, and protocol options. The functional requirements for IPSP include SAID assignment, key generation/distribution, attribute negating, terminate/delete association, SAID maintenance, peer discovery and authentication, recovery, multiparty associations, etc. Multiparty associations are important for multicast. Phil Karn has been building an experimental protocol. He has introduced a goal of eliminating ReasyS denial of service attacks. His RphoturisS system currently uses Diffie-Hellman techniques. Other design goal is to hide as much identity information as possible in the protocol. Numerous key management specifications and implementations exist that could be leveraged to help create IKMP. These include: SDNS KMP, SAMP, IEEE 802.10C, GULS (sense is that ISO specification is too ugly) PEM might provide certificates, or perhaps pgp. DNS security work may be a good source for certificates. SAEP is connected to NLSP but may have some good components. Kerberos was mentioned as a key management approach, but does not meet current requirements. John Linn gave a presentation on the relationship of GSS/CAT API to IPSEC. The CAT work is focusing on providing callable services to application protocols, which use RcredentialsS to produce security contexts. Applications shouldn't care about what mechanism is used. IKMP could be one of these mechanisms. Implementations of variety of underlying mechanisms exist. SOme of these existing mechanisms could also be used to establish keys for IPSP (like kerberos). Ashar Aziz presented SKIP - simple key management for IP. Hugo Krawczyk presented a Secure Tunnel Establishment Protocol (see proceedings). Amir Herzberg presented ideas on ideas on key look-ahead for key management. Steve Bellovin discussed his personal key management requirements. He feels that excessive options are a bad thing -- negotiation should be as simple as possible, as minimal as possible. Note - presenters are now encouraged to publish postscript versions of viewgraphs to the IPSEC ftp archive. Jim Hughes (hughes@network.com) has established a ftp archive for IPSEC at Ftp.Network.Com:IETF/IPSEC. Summary of IKMP Issues How does the IPSEC IKMP relate to other IETF key management related activities? How are shared keys established (e.g. for multicast)? What name and certificate structures should the IKMP support? Need to work quickly to field workable solutions. An interim IPSEC meeting for key management was proposed. This meeting will occur before the next IETF plenary and the agenda and location will be posted to the IPSEC mailing list. Attendees Jim Hughes Hughes@network.com Rob Shirey Shirey@mitre.org Perry Metzger Perry@gnu.ai.mit.edu Ward Bathrick Ward@mis.hac.com Rob Glenn Glenn@osi.ncsi.nist.gov Lisa Carnahan LCarnahan@nist.gov Ashar Aziz ashar.aziz@eng.sun.com Dick Brackney Brackned@cc.ims.disa.mil Dan Frommer danf@radmail.rad.co.il Charlie Kaufman kaufman@zk3.dec.com Tim Dean dean@hydra.ora.mmg.gb Antony Martin Martn@ccint1.rsre.mod.uk Jim Mahon mahonj@hfsi.com Shane Davis Shane@delphi.com David Beyer d.beyer@ieee.org Jeffrey Weiss jaw@magna.telco.com Stuart Starley StuartS@Apertus.com Steve Bellovin smb@research.att.com Jerry Freedman jfjr@mbunix.mitre.org Mike Michnikov mbmg@mitre.org Cynthia Martin martin@spica.disa.mil Todd Wittbold jtw@mitre.org Anne Bennett anne@alcor.concordia.ca Craig Fox craig@ftp.com Piers McMahon p.v.mcmahon@rea0802.wins.icl.6.uk Don Stephenson dons@eng.sun.com Steve Feldman feldman@mfsdatanet.com Kazu Yamamoto kazu@is.aist-nara.ac.jp Carl Smith cs@eng.sun.com Louis A. Mamakos louie@alter.net Carlisle Adams cadams@bnr.ca Doug Rosenthal rosenthal@mcc.com Craig Labovitz labovit@merit.edu Lee Chastain lee@huachuca-jitcosi.army.mil Doug Schrauf dhs@cccl.com Ran Atkinson atkinson@itd.nrl.navy.mil Mikt St. Johns StJohns@arpa.mil Howard Weiss hsw@columbia.sparta.com Masataka Ohen mohen@necom830.cc.fltech.ac.jp John Flick johnf@hpmd.rose.hp.com Marcus Leech Mleech@bnr.ca Tom Arons arons@ece.ucdavis.edu Steve Kent kent@bbn.com John Lowry jlowry@bbn.com Winston Chung wchung@vnet.ibm.com Anish Bhimani anish@ctt.bellcore.com Walter Wiebe wwiebe@nsf.gov Chris Garsuch chrisg@lobby.ti.com Amir Herzberg amir@watson.lbm.com Hugo Krawczyk hugo@watson.ibm.com Chris Seabrook cds@ossi.com Shin Yoshida yoshida@sumitomo.com Bill Owens owens@utd.rochester.edu Richard Graveman rfg@ctt.bellcore.com Neil Haller nmh@thumper.bellcore.com Antonio Fernandez Afa@thumper.bellcore.com Dale Gessey gessey_dale@bah.com Henry Sinnreich hsinnreich@mcimail.com David Gaon Gaond@cc.ims.disa.miz Uri Blumenthal uri@watson.ibm.com Cheryl Madson cmadson@wellfleet.com David Woodgate davidw@its.csiro.au Phil Karn karn@qualcomm.com David Carrel carrel@cisco.com Con Healy con@sprinthawk.com Dragan Grebovich dragan@bnt.ca Jerry Toporek jt@mentat.com Antony Martin martin@ccin1.rsre.mod.uk Tim Dean dean@hydra.dra.hmg.gb Dan Frommer danf@radmail.rad.co.il Phil Nesser pjnesser@rocket.com p. Rajaram rajaram@ctt.bellcore.com Barbara Fraser byf@cert.org Charles Perkins perk@watson.ibm.com David Beyer d.beyer@ieee.org Bill Owens owens@utd.rochester.edu Carl Muckenhirn cfm@columbia.sparta.com Walter Cuilarte guilarte@wg.com David Kristol dmk@research.att.com Cyrus Chow cchow@ames.arc.nasa.gov Mark Oliver oli@hyperk.com James M. Galvin galvin@tis.com Glenn Davis davis@realtime.als.ca Richard Carlson racarlson@anl.gov Tom Lyon pugs@mdv.com James Carlson carlson@xylogies.com John Hawkinson jhawk@panix.com Steve Kent kent@bbr.com Kenneth Kung ken@mls.hac.com Jeff Schiller jis@mit.edu Laurene J. Wolf wolf@instinet.com John Linn linn@cam.ov.com Peter Kirstein kirstein@cs.ucl.ac.uk Michael Sam Chee mschell@bnr.ca Richard R. Moore Moorerr@msu.edu Dave Johnson dsj@cs.cmu.edu Paul Lambert Paul_Lambert@email.mot.com From ipsec-request@ans.net Wed Aug 10 01:49:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41427 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 13:16:55 -0400 Received: by interlock.ans.net id AA35258 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 12:54:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 10 Aug 1994 12:54:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 10 Aug 1994 12:54:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 12:54:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 12:54:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 12:54:36 -0400 Message-Id: <00112.2859357412.3640@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 10 Aug 1994 8:49:21 MST Subject: Comments on Minutes Comments on Minutes If there are any comments on the minutes (before August 12), please send them to Jim Zmuda (zmuda@spyrus.com). I will be on vacation until August 22 and will not be able to make the editorial changes. Regards, Paul From ipsec-request@ans.net Wed Aug 10 19:04:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40387 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 15:29:27 -0400 Received: by interlock.ans.net id AA29122 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 15:08:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 15:08:03 -0400 Message-Id: <199408101907.AA29118@interlock.ans.net> To: ipsec@ans.net Subject: IPSEC SMIB Date: Wed, 10 Aug 94 15:04:00 -0400 From: Steve Kent IPSP "SMIB Variables" The following are (in a very general sense) parameters for an IPSPE SMIB. The first set are for the IPSPE in general, and the second set are for each SA. I'm not a MIB/SMIB kind'a guy, so please excuse the inappropriate format, etc. This is a first cut, in which I am just trying to get the fundamental ideas across and provide a basis for discussion. Another reason for examining these values, is that they enter into the security attribute negotiation procedure and this list will provide a starting point for a discussion of what should be negotiable. I'm sure there are some things I have omitted, but I've gotten to a point where I thought it would be useful to distribute this brief document to the list Steve -------------------------------------------------------------- LOCAL-ADDRESS This is the IP address for this IPSPE. Note that an IPSPE at a router will need to distinguish this IP address from those of its clients. CLIENTS {If this is a router implementation of IPSP, then it needs to be aware of the addresses, or address range, for hosts that are clients "behind" it. Depending on the key management approach, it may be necessary to present a signed list or address range to the peer IPSPE in order to convince it that this IPSPE is authorized to represent the clients. However, this variable is just the list of client address. It could be a sorted list, by IP address, or one might adopt some form of sparse representation, ... I'm not sure what to do here yet.} ALGORITHMS This structure lists the algorithms that this IPSPE is prepared to negotiate for an SA. Each list is ordered in terms of preference, but no algorithms should be used that would be considered insecure. The structure is organized according to the security services being provided. An IPSPE in an end system should allow an application to request services from this list for each SA created on its behalf. This is used as part of the SA negotiation procedure. Each of these lists must contain at least one entry if the security service is supported, but it need not contain more than one entry. KEY-MANAGEMENT This is the ordered list of supported key management techniques. ENCRYPTION This is the ordered list of encryption algorithms. INTEGRITY This is the ordered list of integrity algorithms. COMPRESSION This is the ordered list of compression algorithms. {Compression of the IPSP payload is likely to be needed for low speed IP access links when encryption is employed, due to the loss of compression ability after encryption has been applied.} ALGROTIHM-SELECTORS This structure provides selectors to be applied to inbound and outbound packets in order to determine what security services must be negotiated for these packets. There are separate selectors for inbound vs. outbound traffic. OUTBOUND In an end system, if applications always make explicit requests for security services, this structure may be null, i.e., no screening is required. Otherwise, for administrative control over what services are afforded to what traffic, this structure is applied. In principle, each outgoing IP packet would have to be screened against the entries in this data structure to determine what, if any, IPSP processing is required. This could be either a positive or a negative screen, depending on what the most common case is. For example, if most packets will be subject to IPSP processing, then the screen should be designed to make that most efficient, while if only some packets are to receive IPSP processing, then the bypass of packets should be the most efficient outcome of the screen. For an end system, the most likely implementation approach would entail taking advantage of the state information present in a streams, sockets, or similar interface. One can then screen "connection" establishment calls to these interface to make a determination of what IPSP processing, if any, may be applicable. Then subsequent calls to transfer data on the established data stream can have any IPSP processing applied automatically. In the case of a router implementation, there is no standard facility for maintaining the sort of state information described above, and so every outbound packet must be screened to determine if it is a candidate for IPSP processing. Each entry in this data structure is nominally a triple. The first element is a filter applied to selected fields of the IP header and the transport layer header. The following fields may be used for this filter, but not all fields need to be used in all IPSPEs: IP-DESTINATION-ADDRESS IP-SOURCE-ADDRESS NEXT-PROTOCOL IP-SECURITY-LABEL TRANSPORT-DESTINATION-PORT TRANSPORT-SOURCE-PORT The second element is a flag indicating whether a packet matching the mask is or is not to be processed by IPSP. The third element is a pointer to the SA entry if one exists for data matching this filter, or it is an indication of the IPSP services to be provided to this class of traffic, when an SA is established. INBOUND Screening is required only if the traffic is not already IPSP protected, and if the IPSPE has a security policy that requires IPSP use on traffic flows not initiated by its client(s). In this case, there is a need to screen non-IPSP packets as above and to send an ICMP Unreachable, Destination Requires IPSP {a new ICMP sub code} message to trigger SA establishment by the source of the traffic. {more to be supplied ...} --------------------------------------------------------------- The following is a set of possible parameters for each security association (SA), e.g., candidate MIB data items where each SA has its own MIB entry. They may be negotiated or pre-determined, but all are important for each SA in the most general case. SAID.INBOUND SAID.OUTBOUND These variables contain the SAIDs for this SA and thus are used to select this MIB entry for IPSP protected traffic. ENCAPSULATION This Boolean indicates whether IPSP is used to encapsulate packets on this SA. If TRUE, then encapsulation is employed, otherwise packets are not encapsulated. INBOUND-CRITERIA This data structure specifies the checking applied to inbound packet received on this SA before releasing the packets to the client. Each data item is either null, or is a value against which the inbound packet is checked. If encapsulation is employed, the checks are applied to the encapsulated header(s), otherwise the checks are applied to the outer header(s). {needs work, e.g., to express star names} IP-DESTINATION-ADDRESS IP-SOURCE-ADDRESS NEXT-PROTOCOL IP-SECURITY-LABEL TRANSPORT-DESTINATION-PORT TRANSPORT-SOURCE-PORT PEER-ADDRESS This variable specifies the IP address of the IPSPE that defines the other end of the SA. For a multicast SA, this is an IP multicast address. ENCRYPTION This data structure provides the parameters required for provision of a connectionless confidentiality service, if employed for this SA. ENABLED This is a Boolean and is TRUE if encryption is to be employed for this SA. ALGORTIHM This is a structured, IANA-registered algorithm ID that also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or DES-CFB-8. KEY.INBOUND KEY.OUTBOUD If the same key is used for encryption in both directions, then the values are the same for both of these variables, otherwise different values must be present. (For some algorithms and modes, this value may be an interchange key, and the key to be used to decrypt an individual packet may encrypted by this key and carried in the packet in the manner of an IV.) The size of the key is determined by ENCRYPTION.ALGORITHM and if a multi-key algorithm mode is employed, e.g., DES-EDE, all of the keys for a given direction are stored in the appropriate variable, and the algorithm mode specifies how each key is extracted from the variable. IV.INBOUND IV.OUTBOUND If the algorithm and mode require use of an IV, and if the IV (or a portion thereof) is constant for the SA, then these per-SA values are stored here. The size of these variable and the portion used in forming an IV is determined by ENCRYPTION.ALGORITHM. INTEGRITY This data structure contains all of the parameters required for provision of a connectionless integrity service, if employed for this SA. ENABLED This is a Boolean that is TRUE if an integrity transformation is applied for this SA. PLAINTEXT This value is TRUE if the integrity transformation is applied to plaintext, and is FALSE if it is applied to ciphertext; FALSE may be selected only if ENCRYPTION.ENABLED = TRUE DIRECTION.ENABLED This is a Boolean that is TRUE if a direction flag is used in packets. DIRECTION.VALUE This is a Boolean that specifies the one-bit direction flag value inserted into outbound packets. The value is meaningful only if INTEGRITY.DIRECTION.ENABLED is TRUE. ALGORITHM This is a structured, IANA-registered algorithm ID that specifies the integrity algorithm employed and the mode of use, e.g., MD5, MD5-keyed, SHA, DES-MAC, etc. KEY.OUTBOUND KEY.INBOUND These items have meaning only if a keyed integrity function is employed, as defined in INTEGRITY.ALGORITHM. If ENCRYPTION.ENABLED = FALSE, then a keyed integrity function must be employed, if INTEGRITY.ENABLED = TRUE. If the same key is used in both directions, then these variables have the same value, otherwise different values must be present. The size of key is a function of the algorithm selected in INTEGRITY.ALGORIHTM and if a multi-key algorithm mode is employed, all of the keys for a given direction are stored in the appropriate variable, and the algorithm mode specifies how each key is extracted from the variable. COMPRESSION This data structure provides parameters required for provision of compression (and corresponding decompression) of plaintext data. ENABLED This Boolean is TRUE if compression is to be applied to traffic on this SA. ALGORITHM This is a structured, IANA-registered algorithm ID that specifies the compression algorithm employed. REPLAY This data structure provides the parameters required for provision of replay countermeasures, if employed for this SA. ENABLED This Boolean is TRUE if a sequence number is included in each outbound packet and is checked on each inbound packet for this SA. SIZE This item defines the size of sequence number, expressed in 16-bit words. {we could bound this at 64 bits} NUMBER.OUTBOUND This is the value of the sequence number to be assigned to next outbound packet. The size of this variable is determined by REPLAY.SIZE. NUMBER.INBOUND This is the sequence number expected in next inbound packet; if an integrity checked packet arrives with a sequence number greater than or equal to this value, the variable is updated to be one greater than that received value, and REPLAY.WINDOW is updated to reflect the received packet sequence number. WINDOW.SIZE This is the size of the window within which late arriving packets will be checked for duplication. {we could fix this value, or allow it to be only one of a few small values, e.g., 32/64/128, rather than allowing arbitrary window sizes} WINDOW This is logically an array of packet sequence numbers for packets received within the current window. Its dimension is REPLAY.WINDOW.SIZE. It may be implemented as a bit map, rather than an array of sequence numbers, using OR operations and end- off shifts to efficiently manage the list. It is checked only when a packet arrives with a sequence number less than REPLAY.NUMBER.INBOUND and greater than REPLAY.NUMBER.INBOUND - REPLAY.WINDOW.SIZE + 1 (since all sequence numbers less than this are, by definition, too old). It is updated every time a sequence numbered packet is received FRAGMENTATION This data structure provides the parameters required for provision of denial of service protection with regard to attacks exploiting the fragmentation features of IP. INBOUND If FALSE, no fragments are accepted on inbound traffic, otherwise fragments are acceptable for inbound traffic. OUTBOUND If FALSE, no fragments may be transmitted by the IPSPE (unless encapsulated), otherwise fragments may be transmitted. KEY-MANAGEMENT This data structure provides the key management parameters associated with this SA. NEGOTIATED If TRUE, then IKMP is used to negotiate the key management technique for this SA. If FALSE, a pre-defined key management technique is used. TECHNIQUE This variable specifies the key management technique used for this SA. The identifier used here is structured, e.g., to specify symmetric vs. asymmetric techniques, and is IANA registered. PARAMETERS Technique-specific parameters ??? REKEY This data structure indicates what criteria are used to determine when a new key must be established for this traffic flow. When a new key is established, the traffic will be migrated to a new SA, identified by the NEXT.SA pointer below. GRACE This is the time value (in seconds) that incoming traffic is permitted to be processed on the old SA after a new SA has been established, in response to a rekey. NEXT-SA This is a pointer to the data structure for the new SA to which traffic will be routed when the rekey is complete. TIME-BASED This data structure contains variables for time based rekey management. ENABLE This Boolean is TRUE if time-based rekey management is employed. TRIGGER This is a local time value that specifies when a new key and SAID should be created, after which the traffic for this SA will be transferred to the new SAI. This variable should be zero unless this IPSPE initiated the SA and unless REKEY.TIME-BASED.ENABLE is TRUE. {is this an acceptable simplification, or should either end be able to initiate a rekey?} TRAFFIC-BASED This structure contains parameters for traffic- based rekey control. ENABLE This Boolean is TRUE if traffic-based rekey management is employed. PACKET-COUNT.INBOUND PACKET-COUNT.OUTBOUND These are counters for traffic that will be used to trigger a rekey. They are maintained only if REKEY.TRAFFIC-BASED.ENABLE is TRUE. TRIGGER.INBOUND TRIGGER.OUTBOUND These are values that are compared against the packet counters to trigger a rekey. They are non-zero only if REKEY.TRAFFIC-BASED.ENABLE is TRUE. From ipsec-request@ans.net Wed Aug 10 20:50:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44794 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 17:10:22 -0400 Received: by interlock.ans.net id AA37282 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 16:44:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 16:44:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 16:44:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 16:44:05 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408101550.ZM3252@hughes.network.com> Date: Wed, 10 Aug 1994 15:50:46 -0500 In-Reply-To: Steve Kent "IPSEC SMIB" (Aug 10, 3:04pm) References: <199408101907.AA29118@interlock.ans.net> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Steve Kent , ipsec@ans.net Subject: Re: IPSEC SMIB Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 At the risk of starting another flurry of notes..... On Aug 10, 3:04pm, Steve Kent wrote: > COMPRESSION > This is the ordered list of compression algorithms. > {Compression of the IPSP payload is likely to be needed for low > speed IP access links when encryption is employed, due to the > loss of compression ability after encryption has been applied.} The speed of compression hardware is becoming fast enough that compressing a 150Mb/s stream is possible. Thus the verbage "for low speed IP access links" is not correct. In any case, without these words, the point is still valid. > ENCRYPTION > > ALGORTIHM > This is a structured, IANA-registered algorithm ID that > also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or > DES-CFB-8. (nit) The acronym IANA is not defined in this document. There must be a method of giving entities (corporations?) sets of numbers which they are allowed to control. It would be nice if these numbers were prefaced in such a way as being globally unique, as the IEEE 48 bit MAC addresses are. This is true for all of the algorithms. jim From ipsec-request@ans.net Wed Aug 10 20:57:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41237 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 17:14:11 -0400 Received: by interlock.ans.net id AA16141 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 16:51:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 16:51:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 16:51:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 16:51:02 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408101557.ZM3321@hughes.network.com> Date: Wed, 10 Aug 1994 15:57:45 -0500 In-Reply-To: hugo@watson.ibm.com "SKIP presentation available in postscript" (Aug 10, 2:55pm) References: <9408101905.AA03025@hughes.network.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: hugo@watson.ibm.com, ipsec@ans.net Subject: Re: SKIP presentation available in postscript Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 10, 2:55pm, hugo@watson.ibm.com wrote: > The postscript version of IBM's presentation to the IPSEC > group in Toronto are now available for ftp from Ftp.Network.Com; > the file name is step_slides.ps (step = secure tunnel establishment > protocol). > Hugo >-- End of excerpt from hugo@watson.ibm.com You may access this repository using anonymous FTP. The directory is IETF/IPSEC. WWW access for this file is: ftp://ftp.network.com/IETF/IPSEC/step_slides.ps jim From ipsec-request@ans.net Wed Aug 10 21:09:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44706 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 17:33:35 -0400 Received: by interlock.ans.net id AA27772 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 17:13:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 17:13:48 -0400 Message-Id: <199408102113.AA32632@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of Wed, 10 Aug 94 15:50:46 -0500. <9408101550.ZM3252@hughes.network.com> Date: Wed, 10 Aug 94 17:09:53 -0400 From: Steve Kent Jim, The reason I spoke about compression in the context of low speed links has nothing to do with the speed of compression algorithm implementations. One usually finds compression performed at low layers in the protocol hierarchy, and on a link-by-link basis in the Internet. Low speed dialup links benefit considerably from such compression, usuallu performed by the modem. The introduction of encryption at the IP layer negates the effect of lower layer encryption and this motivates the use of compression in conjunction with IPSP. I agree that compression could be used in a wider range of circumstances in the Internet, and hardware compression at end systems could become more attractive than software compression in such systems is today. However, what really motivates use of compression with IPSP is precisely the scenario I cited. IANA-registration of algorithm identifiers serves to promote interoperability. One can probably register IDs that are essentially private, but it encourages non-interoperability and thus I'm not too anxious to promote that approach. Steve From ipsec-request@ans.net Wed Aug 10 21:42:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39159 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 18:01:23 -0400 Received: by interlock.ans.net id AA30638 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 17:42:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 10 Aug 1994 17:42:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 17:42:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 17:42:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 17:42:50 -0400 Message-Id: <9408102142.AA27603@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of "Wed, 10 Aug 1994 15:50:46 CDT." <9408101550.ZM3252@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 10 Aug 1994 17:42:35 -0400 From: "Perry E. Metzger" James P. Hughes says: >> ENCRYPTION >> >> ALGORTIHM >> This is a structured, IANA-registered algorithm ID that >> also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or >> DES-CFB-8. > There must be a method of giving entities (corporations?) sets of numbers > which they are allowed to control. It would be nice if these numbers were > prefaced in such a way as being globally unique, as the IEEE 48 bit MAC > addresses are. I oppose this notion in the strongest possible way. We do not need fourty thousand incompatible transforms in use. The IANA should assign one transform at a time, period. I anticipate no more than a couple dozen being assigned in the next decade, if that many, the bulk of those being assigned for use by groups like the military that want specialized algorithms. I anticipate no more than a half dozen being in common us. If more than that are assigned, and more than half a dozen are in common use, we have done something horribly, horribly wrong. Remember that two hosts can only communicate using a transform if they both implement it -- huge spaces of proprietary transforms being designed totally destroys the notion of open protocols and open networking. Perry From ipsec-request@ans.net Thu Aug 11 00:33:51 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07102 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 20:42:20 -0400 Received: by interlock.ans.net id AA12769 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 20:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 20:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 20:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 20:27:08 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408101933.ZM3666@hughes.network.com> Date: Wed, 10 Aug 1994 19:33:51 -0500 In-Reply-To: "Perry E. Metzger" "Re: IPSEC SMIB" (Aug 10, 5:42pm) References: <9408102142.AA27603@snark.imsi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: perry@imsi.com, hughes@hughes.network.com (James P. Hughes) Subject: Re: IPSEC SMIB Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 10, 5:42pm, Perry E. Metzger wrote: > Subject: Re: IPSEC SMIB > > James P. Hughes says: > >> ENCRYPTION > >> > >> ALGORTIHM We must have a way of negotiate proprietary, experimental, or special purpose algorithms which do not have the possibility of being misinterpreted by the responder. Requiring IANA blessing of all algorithms is too harsh. Too inflexible. jim From ipsec-request@ans.net Wed Aug 10 10:49:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48360 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 21:03:32 -0400 Received: by interlock.ans.net id AA18539 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 20:48:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 10 Aug 1994 20:48:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 20:48:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 20:48:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 20:48:37 -0400 Date: Wed, 10 Aug 94 17:49:09 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408110049.AA14684@miraj.Eng.Sun.COM> To: perry@imsi.com, hughes@hughes.network.com Subject: Re: IPSEC SMIB Cc: ipsec@ans.net Content-Length: 513 >From ipsec-request@ans.net Wed Aug 10 17:44:51 1994 >>We must have a way of negotiate proprietary, experimental, or special purpose > algorithms which do not have the possibility of being misinterpreted by the >responder. > >Requiring IANA blessing of all algorithms is too harsh. Too inflexible. My recommendation here would be to allocate a range of user-defined algorithm identifiers, that would be up to cooperating entities to interpret, and which would not interfere with globally assigned ids. Ashar. From ipsec-request@ans.net Thu Aug 11 01:06:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07008 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 21:23:34 -0400 Received: by interlock.ans.net id AA36867 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Aug 1994 21:08:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 10 Aug 1994 21:08:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Aug 1994 21:08:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Aug 1994 21:08:06 -0400 Message-Id: <9408110106.AA12907@tis.com> To: hughes@hughes.network.com (James P. Hughes) Cc: perry@imsi.com, ipsec@ans.net, iana@isi.edu Subject: Re: IPSEC SMIB In-Reply-To: Your message of "Wed, 10 Aug 94 19:33:51 CDT." <9408101933.ZM3666@hughes.network.com> Date: Wed, 10 Aug 94 21:06:40 -0400 From: Stephen D Crocker Jim, The IANA is usually excellent about honoring requests for assignments of numbers or identifiers. There's almost never a determination of the merits of the use. This is entirely distinct from the creation of standards. If this nonetheless turned out to be a burden, I can imagine it might make sense to ask for the allocation of a set of identifiers for private experimental use, e.g. EXPALG1, EXPALG2, etc., whose meanings are to be known by the users and which might vary from implementation to implementation. (I'm not sure what the accepted practice is on this point though; after 25 years, most of the hare-brained ideas have been proposed more than once, so there may be a standard answer to this one too.) In any case, until the IANA gives us cause to doubt its efficacy, this is a red herring. Steve > We must have a way of negotiate proprietary, experimental, or special purpose > algorithms which do not have the possibility of being misinterpreted by the > responder. > > Requiring IANA blessing of all algorithms is too harsh. Too inflexible. From ipsec-request@ans.net Thu Aug 11 11:17:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07159 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 07:28:05 -0400 Received: by interlock.ans.net id AA26569 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 07:17:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 11 Aug 1994 07:17:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 07:17:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 07:17:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 07:17:22 -0400 Message-Id: <9408111117.AA28272@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of "Wed, 10 Aug 1994 19:33:51 CDT." <9408101933.ZM3666@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 11 Aug 1994 07:17:12 -0400 From: "Perry E. Metzger" James P. Hughes says: > On Aug 10, 5:42pm, Perry E. Metzger wrote: > > Subject: Re: IPSEC SMIB > > > > James P. Hughes says: > > >> ENCRYPTION > > >> > > >> ALGORTIHM > > We must have a way of negotiate proprietary, experimental, or special purpose > algorithms which do not have the possibility of being misinterpreted by the > responder. > > Requiring IANA blessing of all algorithms is too harsh. Too inflexible. People get IANA numbers every day for their network numbers, and no one seems to think that is "harsh" and "inflexible". Most organizations will never, ever play with proprietary transforms, let alone thousands or tens of thousands of them, as granting "blocks" to organizations would imply. I see no reason whatsoever to produce a mechanism to actively encourage proprietary transforms, especially since they are detrimental to the cause of open networking. If you want a number assigned, you'll get one from IANA, which does not take any appreciable time to assign things like this, and that will be that. Unless you can code up new transforms at a rate of dozens a day, you will never notice the time it takes to get a number from IANA. Perry From ipsec-request@ans.net Thu Aug 11 13:59:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13372 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 10:03:32 -0400 Received: by interlock.ans.net id AA12590 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 09:52:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 09:52:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 09:52:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 09:52:56 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408110859.ZM4097@hughes.network.com> Date: Thu, 11 Aug 1994 08:59:28 -0500 In-Reply-To: Stephen D Crocker "Re: IPSEC SMIB" (Aug 10, 9:06pm) References: <9408110106.AA12907@tis.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Stephen D Crocker , hughes@hughes.network.com (James P. Hughes) Subject: Re: IPSEC SMIB Cc: perry@imsi.com, ipsec@ans.net, iana@isi.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 10, 9:06pm, Stephen D Crocker wrote: > Subject: Re: IPSEC SMIB > Jim, > > The IANA is usually excellent about honoring requests for assignments > of numbers or identifiers. There's almost never a determination of > the merits of the use. This is entirely distinct from the creation of > standards. > > If this nonetheless turned out to be a burden, I can imagine it might > make sense to ask for the allocation of a set of identifiers for > private experimental use, e.g. EXPALG1, EXPALG2, etc., whose meanings > are to be known by the users and which might vary from implementation > to implementation. (I'm not sure what the accepted practice is on > this point though; after 25 years, most of the hare-brained ideas have > been proposed more than once, so there may be a standard answer to > this one too.) I agree that experimental stuff could use this, but proprietary algorithms that either do not want to be interoperable or are forced (for various reasons which I will not go into) to remain proprietary, may continue to use the experimental label. This would be a problem. The use of EXPALG1, EXPALG2, etc., may cause confusion -if- my interpretation of this field and some other vendor's interpretation of this field are different -and- these 2 units accidently come into contact. In the past, NSC has used the enterprise specific SNAP header to create protocol mappings that are of interest to us, but to no others. I cite the example of HYPERchannel over FDDI (I am showing my age here). There is no use in requesting a standard "ethertype" for this. There is no problem with this method because there will never be a problem with this field being misinterpreted. > In any case, until the IANA gives us cause to doubt its efficacy, this > is a red herring. Maybe I am wrong. I need 2 mapping right now for proprietary algorithms. I can disclose the mappings but can not disclose the algorithms being used. Will I have a problem getting these mappings? jim From ipsec-request@ans.net Thu Aug 11 15:01:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA41298 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 10:17:25 -0400 Received: by interlock.ans.net id AA29162 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 10:05:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 10:05:43 -0400 From: Ran Atkinson Message-Id: <9408111001.ZM4427@sundance.itd.nrl.navy.mil> Date: Thu, 11 Aug 1994 10:01:01 -0500 In-Reply-To: hughes@hughes.network.com (James P. Hughes) "Re: IPSEC SMIB" (Aug 10, 19:33) References: <9408102142.AA27603@snark.imsi.com> <9408101933.ZM3666@hughes.network.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: "James P. Hughes" , perry@imsi.com Subject: Re: IPSEC SMIB Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Aug 10, 19:33, James P. Hughes wrote: % We must have a way of negotiate proprietary, experimental, or special % purpose algorithms which do not have the possibility of being % misinterpreted by the responder. One approach is to make the algorithm namespace beginning with the string "X-" reserved for private experiments. This has been used in other Internet namespaces in the past. % Requiring IANA blessing of all algorithms is too harsh. Too inflexible. Requiring IANA registration of all algorithms is entirely appropriate. No one said anything about "blessing", just registration. IANA has shown much flexibility and done an excellent job in management of various Internet namespaces through the years. Registration of algorithms is an _entirely_ appropriate activity for IANA. The alternative really is chaos and non-interoperability. There is no way that I will go along willingly down the road to non-interoperability. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Aug 11 14:57:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39063 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 11:12:20 -0400 Received: by interlock.ans.net id AA38758 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 10:59:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 10:59:07 -0400 Message-Id: <199408111459.AA35682@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of Wed, 10 Aug 94 19:33:51 -0500. <9408101933.ZM3666@hughes.network.com> Date: Thu, 11 Aug 94 10:57:21 -0400 From: Steve Kent Jim, IANA registration of an algorithm ID is not the same as "IANA blessing" of the algorithm. Look at the assigend numbers list for UDP ports, for example, and you'll see examples that are clearly experimental. I don't think that registration is especially onerous. I agree with Perry that we don't want to encourage proliferation of algorithm IDs for operational purposes, but I also agree with your observation that we need to be able to conduct experiments without confusing others. I think IANA registration has proven to be fairly good in that regard, over the years. Steve From ipsec-request@ans.net Thu Aug 11 16:26:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44598 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 12:39:53 -0400 Received: by interlock.ans.net id AA17777 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 12:26:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 11 Aug 1994 12:26:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 12:26:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 12:26:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 12:26:28 -0400 Message-Id: <9408111626.AA29007@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of "Thu, 11 Aug 1994 08:59:28 CDT." <9408110859.ZM4097@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 11 Aug 1994 12:26:12 -0400 From: "Perry E. Metzger" James P. Hughes says: > I agree that experimental stuff could use this, but proprietary > algorithms that either do not want to be interoperable or are forced > (for various reasons which I will not go into) to remain > proprietary, may continue to use the experimental label. This would > be a problem. As has been noted repeatedly, IANA registration is not onerous and is easily accomplished for proprietary protocols. Very large numbers of completely unofficial and proprietary protocols have been IANA registered. IANA registration implies nothing about IETF standardization, openness, or anything else. It simply implies that you've asked IANA for a number. > > In any case, until the IANA gives us cause to doubt its efficacy, this > > is a red herring. > > Maybe I am wrong. > > I need 2 mapping right now for proprietary algorithms. I can disclose the > mappings but can not disclose the algorithms being used. > > Will I have a problem getting these mappings? None in all likelyhood. The only way that would happen would be if the registration space was small -- but it is in fact likely to be vast, and the probability of being denied an assigned number is close to zero. Perry From ipsec-request@ans.net Thu Aug 11 16:44:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA44713 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 12:58:51 -0400 Received: by interlock.ans.net id AA30092 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 12:45:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 12:45:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 12:45:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 12:45:24 -0400 Message-Id: <9408111645.AA08820@ next85.darpa.mil > To: hughes@hughes.network.com (James P. Hughes) Cc: Stephen D Crocker , perry@imsi.com, ipsec@ans.net, iana@isi.edu Reply-To: stjohns@ARPA.MIL Subject: Re: IPSEC SMIB In-Reply-To: Your message of Thu, 11 Aug 1994 08:59:28 -0500. <9408110859.ZM4097@hughes.network.com> Date: Thu, 11 Aug 1994 12:44:59 -0400 From: "Michael St. Johns" James - you have to at least give a unique name so that people can match this stuff up.. > On Aug 10, 9:06pm, Stephen D Crocker wrote: > > Subject: Re: IPSEC SMIB > > Jim, > > > > The IANA is usually excellent about honoring requests for assignments > > of numbers or identifiers. There's almost never a determination of > > the merits of the use. This is entirely distinct from the creation of > > standards. > > > > If this nonetheless turned out to be a burden, I can imagine it might > > make sense to ask for the allocation of a set of identifiers for > > private experimental use, e.g. EXPALG1, EXPALG2, etc., whose meanings > > are to be known by the users and which might vary from implementation > > to implementation. (I'm not sure what the accepted practice is on > > this point though; after 25 years, most of the hare-brained ideas have > > been proposed more than once, so there may be a standard answer to > > this one too.) > > I agree that experimental stuff could use this, but proprietary algorithms that > either do not want to be interoperable or are forced (for various reasons which > I will not go into) to remain proprietary, may continue to use the experimental > label. This would be a problem. > > The use of EXPALG1, EXPALG2, etc., may cause confusion -if- my interpretation > of this field and some other vendor's interpretation of this field are > different -and- these 2 units accidently come into contact. > > In the past, NSC has used the enterprise specific SNAP header to create > protocol mappings that are of interest to us, but to no others. I cite the > example of HYPERchannel over FDDI (I am showing my age here). There is no use > in requesting a standard "ethertype" for this. There is no problem with this > method because there will never be a problem with this field being > misinterpreted. > > > In any case, until the IANA gives us cause to doubt its efficacy, this > > is a red herring. > > Maybe I am wrong. > > I need 2 mapping right now for proprietary algorithms. I can disclose the > mappings but can not disclose the algorithms being used. > > Will I have a problem getting these mappings? > > jim > From ipsec-request@ans.net Thu Aug 11 19:27:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07543 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 15:37:54 -0400 Received: by interlock.ans.net id AA08215 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 15:21:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 15:21:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 15:21:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 15:21:13 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408111427.ZM5040@hughes.network.com> Date: Thu, 11 Aug 1994 14:27:35 -0500 In-Reply-To: "Michael St. Johns" "Re: IPSEC SMIB" (Aug 11, 12:44pm) References: <9408111645.AA08820@ next85.darpa.mil > X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: stjohns@arpa.mil, hughes@hughes.network.com (James P. Hughes) Subject: Re: IPSEC SMIB Cc: Stephen D Crocker , perry@imsi.com, ipsec@ans.net, iana@isi.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 11, 12:44pm, Michael St. Johns wrote: > Subject: Re: IPSEC SMIB > James - you have to at least give a unique name so that people can > match this stuff up.. Yes, I agree. Unique names (such as NSC-1 and NSC-2 or maybe STK-1 and STK-2) would be more than sufficient. >From Mr. Perry's very constructive reply: > None in all likelyhood. The only way that would happen would be if the > registration space was small -- but it is in fact likely to be vast, > and the probability of being denied an assigned number is close to > zero. The words "likelyhood", "probability" and "close to zero" are difficult for me. I agree that these terms may be correct, but their exact meaning escapes me. I am trying to direct this entire line of discussion towards defining -exactly- what the policy that vendors can expect to be used when the IANA determines if a number -may- be registered. (For instance, must all numbers be approved by the working group?) A policy should be interpretable as being absolute. I am sure that the working group will recommend to the IANA a policy it would like to see regarding the allocation of assigned numbers which are applicable only to the standard that they develop. I am sure the IANA would like to see as clear a policy as possible so that they can meet the wishes of the working group. The consensus I seem to be hearing, which I will attempt to state with the minimum number of words is: Designators for open or proprietary algorithms (for encryption, authentication, compression and replay prevention) will be provided by the Internet Assigned Numbers Authority (IANA) when requested. Is this correct? >From the original posting > ALGORTIHM > This is a structured, IANA-registered algorithm ID that > also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or > DES-CFB-8. scared me. The word "registered" is correct, it was the policy for registration was left open. Maybe this is the wrong document for the registration policy to be placed, but this is the first time that a potential limit to algorithms have been discussed on this (aptly named) exploader. What -we- will have when this is all done is a set of words in a standard. Email regarding the meaning of the words is useless folklore after the standard is published. This is why I would like to have a more specific statements in the document. This is also why I challenge the exact wording of the drafts so closely. jim From ipsec-request@ans.net Thu Aug 11 20:00:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07035 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 16:13:55 -0400 Received: by interlock.ans.net id AA05723 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 16:01:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 11 Aug 1994 16:01:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 16:01:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 16:01:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 16:01:10 -0400 Message-Id: <9408112000.AA29859@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: IPSEC SMIB In-Reply-To: Your message of "Thu, 11 Aug 1994 14:27:35 CDT." <9408111427.ZM5040@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 11 Aug 1994 16:00:52 -0400 From: "Perry E. Metzger" James seems to be worried that the IANA is not going to allocate him a number for proprietary or experimental use when he wants one. As those of us who've dealt with this sort of issue before understand, there is no reason for him to worry. On that basis, I'd suggest we move on from this discussion. Perry From ipsec-request@ans.net Thu Aug 11 21:03:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14469 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 16:17:39 -0400 Received: by interlock.ans.net id AA35529 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 16:05:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 16:05:40 -0400 From: Ran Atkinson Message-Id: <9408111603.ZM5435@sundance.itd.nrl.navy.mil> Date: Thu, 11 Aug 1994 16:03:07 -0500 In-Reply-To: hughes@hughes.network.com (James P. Hughes) "Re: IPSEC SMIB" (Aug 11, 14:27) References: <9408111645.AA08820@ next85.darpa.mil > <9408111427.ZM5040@hughes.network.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: "James P. Hughes" Subject: Re: IPSEC SMIB Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Jim, You are worrying about a non-existent problem. Everyone is telling you this. Please listen to our words. This is not a problem. IANA registration has worked well for over a decade. I am aware of ZERO problems during this time period. IMHO, it is NOT appropriate for an IETF standards-track protocol spec to contain any kind of "policy". Protocol specifications should specify protocols. Period. The current wording requiring registration with IANA is completely correct and completely consistent with other existing IETF specifications. See the MIME documentation requiring registration of character sets for another worked example. Please lets concentrate on specifying the protocol. Thanks very much, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Aug 11 21:32:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04287 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 17:36:32 -0400 Received: by interlock.ans.net id AA14123 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 17:25:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Aug 1994 17:25:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 17:25:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 17:25:52 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408111632.ZM5419@hughes.network.com> Date: Thu, 11 Aug 1994 16:32:32 -0500 In-Reply-To: Ran Atkinson "Re: IPSEC SMIB" (Aug 11, 4:03pm) References: <9408111645.AA08820@ next85.darpa.mil > <9408111427.ZM5040@hughes.network.com> <9408111603.ZM5435@sundance.itd.nrl.navy.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: IPSEC SMIB Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 11, 4:03pm, Ran Atkinson wrote: > Subject: Re: IPSEC SMIB > > Jim, > > You are worrying about a non-existent problem. Everyone is telling you > this. Please listen to our words. This is not a problem. IANA > registration has worked well for over a decade. I am aware of > ZERO problems during this time period. I am obviously not experienced with the IETF proces for allocating this type of number. If someone had said "you may get proprietary numbers from IANA by asking" without "in all likelyhood", "probability" and "close to zero" I would have backed off. > Please lets concentrate on specifying the protocol. Not a problem. jim From ipsec-request@ans.net Thu Aug 11 16:48:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07629 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 20:57:51 -0400 Received: by interlock.ans.net id AA08146 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Aug 1994 20:48:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Aug 1994 20:48:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Aug 1994 20:48:05 -0400 Date: Thu, 11 Aug 94 20:48:00 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9408120048.AA13696@tsx-11.MIT.EDU> To: hughes@hughes.network.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: James P. Hughes's message of Thu, 11 Aug 1994 16:32:32 -0500, <9408111632.ZM5419@hughes.network.com> Subject: Re: IPSEC SMIB Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: hughes@hughes.network.com (James P. Hughes) Date: Thu, 11 Aug 1994 16:32:32 -0500 If someone had said "you may get proprietary numbers from IANA by asking" without "in all likelyhood", "probability" and "close to zero" I would have backed off. The reason for not putting in absolutes is because you can always find ways to abuse absolute policies. Say, for example, if there field is 2**32 bits, and someone in one fell swoop asks for 2**32-1 proprietary numbers, for no good reason? Clearly the IANA should tell that person to go take a hike. OK, so we make the rule that you can't ask for more than 8 numbers at a time --- and someone sends in 2**24 requests for 8 numbers apiece. Any process can be abused. This is why there is such a thing as leaving latitude for human discretion. The IANA has done a good job for the past decade; your fears are misplaced. - Ted From ipsec-request@ans.net Tue Aug 16 17:12:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13632 (5.65c/IDA-1.4.4 for ); Tue, 16 Aug 1994 15:08:21 -0400 Received: by interlock.ans.net id AA12845 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 16 Aug 1994 14:50:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 16 Aug 1994 14:50:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 16 Aug 1994 14:50:20 -0400 Date: Tue, 16 Aug 94 17:12:48 GMT From: "William Allen Simpson" Message-Id: <3039.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: I-D ACTION:draft-ietf-sipp-ap-04.txt With the posting of Ran's most recent Authentication Header draft, I formally request that this WG adopt it as a Proposed Standard for IPv4. This would require the removal of very little IPv6 language. I believe this action to be the consensus at the Toronto IETF. > Mime-Version: 1.0 > Content-Type: Multipart/Mixed; Boundary="NextPart" > To: IETF-Announce:@CNRI.Reston.VA.US@Eng.Sun.COM@Sun.COM; > Cc: sipp@sunroof.eng.sun.com > From: Internet-Drafts@CNRI.Reston.VA.US > Subject: (sipp) I-D ACTION:draft-ietf-sipp-ap-04.txt > Date: Tue, 16 Aug 94 10:47:35 -0400 > Message-Id: <9408161047.aa05277@IETF.CNRI.Reston.VA.US> > Sender: owner-sipp@sunroof.eng.sun.com > Precedence: bulk > Reply-To: sipp@sunroof.eng.sun.com > > --NextPart > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Simple Internet Protocol Plus > Working Group of the IETF. > > Title : IPv6 Authentication Header > Author(s) : R. Atkinson > Filename : draft-ietf-sipp-ap-04.txt > Pages : 9 > Date : 08/15/1994 > > This draft specifies the Authentication Header to be used to provide > authentication and integrity without confidentiality to IPv6 datagrams. > It is one of two security mechanisms proposed for IPv6. > > Internet-Drafts are available by anonymous FTP. Login with the > username "anonymous" and password "guest". After logging in, > Type "cd internet-drafts". > "get draft-ietf-sipp-ap-04.txt". > > Internet-Drafts directories are located at: > > o US East Coast > Address: ds.internic.net (198.49.45.10) > > o US West Coast > Address: ftp.isi.edu (128.9.0.32) > > o Pacific Rim > Address: munnari.oz.au (128.250.1.21) > > o Europe > Address: nic.nordu.net (192.36.148.17) > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-sipp-ap-04.txt". > > NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > For questions, please mail to Internet-Drafts@cnri.reston.va.us. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version > of the Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ds.internic.net" > > Content-Type: text/plain > Content-ID: <19940815131545.I-D@CNRI.Reston.VA.US> > > ENCODING mime > FILE /internet-drafts/draft-ietf-sipp-ap-04.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-sipp-ap-04.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <19940815131545.I-D@CNRI.Reston.VA.US> > > --OtherAccess-- > > --NextPart-- Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Aug 16 20:34:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15036 (5.65c/IDA-1.4.4 for ); Tue, 16 Aug 1994 15:45:48 -0400 Received: by interlock.ans.net id AA12962 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 16 Aug 1994 15:34:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 16 Aug 1994 15:34:47 -0400 From: Ran Atkinson Message-Id: <9408161534.ZM17827@sundance.itd.nrl.navy.mil> Date: Tue, 16 Aug 1994 15:34:11 -0500 In-Reply-To: "William Allen Simpson" "I-D ACTION:draft-ietf-sipp-ap-04.txt" (Aug 16, 17:12) References: <3039.bill.simpson@um.cc.umich.edu> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Folks, While I appreciate Bill's vote of confidence, it might be good if the draft were _at least_ thoroughly reviewed and debugged before we turned it loose on the world. Experimental IPv6 implementations of the earlier draft exist, but have not had interoperability testing yet. The changes between drafts are small but important and are largely based on implementation experience. In particular, performance issues remain with the use of keyed MD5. An untuned implementation of MD5 on a fast 64-bit commercial RISC processor only calculates at 20 Mbps; smaller and slower processors would not go so fast. This does not bode particularly well for networks using FDDI or other high-speed technologies. A commercially strong but less computationally expensive algorithm would be more desirable than MD5, IMHO. I don't know of any such algorithms -- suggestions are solicited. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Aug 16 20:22:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02529 (5.65c/IDA-1.4.4 for ); Tue, 16 Aug 1994 16:42:11 -0400 Received: by interlock.ans.net id AA11862 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 16 Aug 1994 16:28:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 16 Aug 1994 16:28:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 16 Aug 1994 16:28:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 16 Aug 1994 16:28:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 16 Aug 1994 16:28:09 -0400 Message-Id: <9408162022.AA03592@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt In-Reply-To: Your message of "Tue, 16 Aug 1994 17:12:48 GMT." <3039.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 16 Aug 1994 16:22:40 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > With the posting of Ran's most recent Authentication Header draft, > I formally request that this WG adopt it as a Proposed Standard for > IPv4. This would require the removal of very little IPv6 language. > > I believe this action to be the consensus at the Toronto IETF. Thats the general idea, but there is some more language that will need to be changed to make it compatible with both. Patience... Perry From ipsec-request@ans.net Tue Aug 16 20:24:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02534 (5.65c/IDA-1.4.4 for ); Tue, 16 Aug 1994 16:42:29 -0400 Received: by interlock.ans.net id AA21911 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 16 Aug 1994 16:31:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 16 Aug 1994 16:31:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 16 Aug 1994 16:31:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 16 Aug 1994 16:31:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 16 Aug 1994 16:31:49 -0400 Message-Id: <9408162024.AA03600@snark.imsi.com> To: atkinson@itd.nrl.navy.mil Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt In-Reply-To: Your message of "Tue, 16 Aug 1994 15:34:11 CDT." <9408161534.ZM17827@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 16 Aug 1994 16:24:41 -0400 From: "Perry E. Metzger" Ran Atkinson says: > In particular, performance issues remain with the use of keyed MD5. > An untuned implementation of MD5 on a fast 64-bit commercial RISC > processor only calculates at 20 Mbps; smaller and slower processors > would not go so fast. This does not bode particularly well for > networks using FDDI or other high-speed technologies. A commercially > strong but less computationally expensive algorithm would be more > desirable than MD5, IMHO. I don't know of any such algorithms -- > suggestions are solicited. I know of none, either. SHA is actually likely slower. Tuned implementations of MD5 would, of course, be interesting to play with. Perry From ipsec-request@ans.net Wed Aug 17 13:50:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15633 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 09:01:08 -0400 Received: by interlock.ans.net id AA22969 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 08:50:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 17 Aug 1994 08:50:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 17 Aug 1994 08:50:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Aug 1994 08:50:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 08:50:48 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 08:50:48 -0400 From: uri@watson.ibm.com Message-Id: <9408171250.AA20777@buoy.watson.ibm.com> Subject: SEAL description To: ipsec@ans.net Date: Wed, 17 Aug 1994 08:50:42 -0500 (EDT) Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 582 Hi, Sorry for some delay... Here's the reference I was given to post here: Phillip Rogaway and Don Coppersmith, "A Software-Optimised Encryption Algorithm," in "Fast Software Encryption," Ross Anderson (Ed), Springer-Verlag Necture Notes in Computer Science, vol 809, pp 56-63, March, 1994. The application for patent was submitted. Don't know the results. No further comments at this time. Oh BTW - you'll find lots of interesting things in that book! (:-) -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Wed Aug 17 15:25:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13377 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 11:57:09 -0400 Received: by interlock.ans.net id AA23870 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 11:42:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 11:42:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 11:42:47 -0400 Date: Wed, 17 Aug 94 15:25:00 GMT From: "William Allen Simpson" Message-Id: <3044.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt > From: "Perry E. Metzger" > "William Allen Simpson" says: > Thats the general idea, but there is some more language that will need > to be changed to make it compatible with both. Patience... > Patience? Why? We have a draft. Let us examine it. If you have a proposal for changes to language, please post it to the list, so that Ran can make them. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Aug 17 17:45:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02470 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 14:03:05 -0400 Received: by interlock.ans.net id AA29350 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 13:51:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 17 Aug 1994 13:51:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Aug 1994 13:51:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 13:51:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 13:51:37 -0400 Message-Id: <9408171745.AA04902@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt In-Reply-To: Your message of "Wed, 17 Aug 1994 15:25:00 GMT." <3044.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Aug 1994 13:45:55 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > > From: "Perry E. Metzger" > > "William Allen Simpson" says: > > Thats the general idea, but there is some more language that will need > > to be changed to make it compatible with both. Patience... > > > Patience? Why? We have a draft. Let us examine it. > > If you have a proposal for changes to language, please post it to the > list, so that Ran can make them. I'm a week late delivering them (purely my fault), but I *have* already promised Ran that I'll be coordinating some changes with him. Perry From ipsec-request@ans.net Wed Aug 17 15:44:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02553 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 15:50:07 -0400 Received: by interlock.ans.net id AA20703 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 15:38:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 15:38:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 15:38:32 -0400 Date: Wed, 17 Aug 94 15:44:31 GMT From: "William Allen Simpson" Message-Id: <3047.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Changes in AP draft > From: "William Allen Simpson" > If you have a proposal for changes to language, please post it to the > list, so that Ran can make them. > To follow my own advice: There is an error in your Appendix on keyed-MD5. The secret should be both before and after the protected data. Otherwise, "inverse MD5" could unroll the data hash, and learn the hash of the secret, allowing spoofing of the authentication. In response to Ran's list comment that MD5 is too slow, why not use MD4? Any speed tests there? Is it enough faster? There are several typos in the appendix, including a missing period. I'd split the reference, method of selecting a key, calculation, and specification of invariant fields into separate paragraphs. The information on what is protected should probably be in its own section. Maybe the description of invariant fields would go there, too. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Aug 17 21:02:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13815 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 16:15:57 -0400 Received: by interlock.ans.net id AA30227 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 16:02:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 17 Aug 1994 16:02:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 17 Aug 1994 16:02:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Aug 1994 16:02:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 16:02:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 16:02:09 -0400 From: uri@watson.ibm.com Message-Id: <9408172002.AA18143@buoy.watson.ibm.com> Subject: Re: Changes in AP draft To: bsimpson@morningstar.com Date: Wed, 17 Aug 1994 16:02:05 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <3047.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Aug 17, 94 03:44:31 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 668 William Allen Simpson says: > There is an error in your Appendix on keyed-MD5. The secret should be > both before and after the protected data. > Otherwise, "inverse MD5" could unroll the data hash, and learn the hash > of the secret, allowing spoofing of the authentication. If you know how to "inverse MD5" - mind sharing it with us? > In response to Ran's list comment that MD5 is too slow, why not use MD4? > Any speed tests there? Is it enough faster? MD5 was brought forth, because the gurus thought MD4 is not secure enough (even though it wasn't broken). -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Wed Aug 17 20:03:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17680 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 16:20:53 -0400 Received: by interlock.ans.net id AA19096 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 16:07:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 16:07:56 -0400 Message-Id: <199408172007.AA14228@interlock.ans.net> To: atkinson@itd.nrl.navy.mil Cc: bsimpson@morningstar.com, ipsec@ans.net, kent@BBN.COM Subject: Re: I-D ACTION:draft-ietf-sipp-ap-04.txt In-Reply-To: Your message of Tue, 16 Aug 94 15:34:11 -0500. <9408161534.ZM17827@sundance.itd.nrl.navy.mil> Date: Wed, 17 Aug 94 16:03:29 -0400 From: Steve Kent From ipsec-request@ans.net Wed Aug 17 20:07:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17688 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 16:22:40 -0400 Received: by interlock.ans.net id AA29432 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 16:12:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 16:12:50 -0400 Message-Id: <199408172012.AA25588@interlock.ans.net> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Changes in AP draft In-Reply-To: Your message of Wed, 17 Aug 94 15:44:31 +0000. <3047.bill.simpson@um.cc.umich.edu> Date: Wed, 17 Aug 94 16:07:14 -0400 From: Steve Kent Bill, One cannot invert the MD5 hash, and thus change (undetectably) the data at near the end of the packet or substitute a new hash, in the absence of a trailing secret value. For some hash algorithms, it is possible to add additional data to the end in the absence of a trailing secret value, and in the absence of a length field embedded in the intergity-protected text. Steve From ipsec-request@ans.net Wed Aug 17 20:30:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17737 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 16:50:15 -0400 Received: by interlock.ans.net id AA27980 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 16:35:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 17 Aug 1994 16:35:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Aug 1994 16:35:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 16:35:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 16:35:32 -0400 Message-Id: <9408172030.AA05288@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Changes in AP draft In-Reply-To: Your message of "Wed, 17 Aug 1994 15:44:31 GMT." <3047.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Aug 1994 16:30:03 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > In response to Ran's list comment that MD5 is too slow, why not use MD4? > Any speed tests there? Is it enough faster? It is considered insecure these days. At least two-thirds of the rounds have been successfully cryptanalyzed. Although I hate to say it, ultimately the stranglepoint on all encryption and authentication technology is going to end up being algorithm speed. For most algorithms currently known, hardware is going to be needed to produce sufficient speed. This is unpleasant, but it is something I've come to accept. Maybe new algorithms like SEAL will rescue us from the morass -- I don't know. For the moment, I'm not worrying about trying to get algorithm speed up at the expense of security because even fairly bad algorithms are quite slow -- no point in sacrificing security if you won't get anything for it. This is not to say that software only systems should not be made as fast as is possible or that things should not be designed to run as fast as we can manage in software -- many, if not most, people aren't going to be buying hardware, period, because of the cost. However, people wanting to do serious security on their links are pretty much going to need hardware, especially on today's fastest lines. Gigabit links are not going to be achieved without specialized hardware no matter what we do about optimizing security transforms. Low latency needs for some applications also require hardware to achieve. Sigh. Perry From ipsec-request@ans.net Wed Aug 17 20:39:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14179 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 16:59:49 -0400 Received: by interlock.ans.net id AA29337 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 16:39:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Aug 1994 16:39:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Aug 1994 16:39:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 16:39:11 -0400 Date: Wed, 17 Aug 1994 13:39:04 -0700 From: Hilarie Orman Message-Id: <199408172039.NAA28035@umbra.CS.Arizona.EDU> To: bill.simpson@um.cc.umich.edu Cc: ipsec@ans.net In-Reply-To: Mymessage <3047.bill.simpson@um.cc.umich.edu> Subject: Re: Changes in AP draft The speed ratio is theoretically 3/4 (MD4/MD5); measured on a DEC Alpha as 5/6. MD4 is considered risky business. From ipsec-request@ans.net Wed Aug 17 22:45:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16516 (5.65c/IDA-1.4.4 for ); Wed, 17 Aug 1994 17:56:30 -0400 Received: by interlock.ans.net id AA12496 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Aug 1994 17:45:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Aug 1994 17:45:26 -0400 From: Ran Atkinson Message-Id: <9408171745.ZM19879@sundance.itd.nrl.navy.mil> Date: Wed, 17 Aug 1994 17:45:55 -0500 In-Reply-To: Hilarie Orman "Re: Changes in AP draft" (Aug 17, 13:39) References: <199408172039.NAA28035@umbra.CS.Arizona.EDU> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: MD5 performance Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil MD5 Performance update: On the 64-bit RISC processor that got 20 Mbps using the RFC-1321 code, there is new news that by hand tweaking the code in a one can get about triple the speed. Simply swapping the RFC-1321 code out and substituting the Karn MD5 code reportedly about doubles the speed. I'm being deliberately vague here on exact performance because slightly different system configurations were used by different groups to get these numbers. My concerns over MD5 performance are significantly abated by these more recent results. It looks like IP/FDDI, IP/HyperChannel, IP/ATM, and IP/PPP/SONET may have performance problems with MD5. Most users are at Ethernet speed or below and will be fine. IMHO, we need to consider selectively authenticating packets in any event -- protect "important" packets for some metric of "important" (perhaps source routed packets for example). Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Aug 18 06:28:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01618 (5.65c/IDA-1.4.4 for ); Thu, 18 Aug 1994 06:28:28 -0400 Received: by interlock.ans.net id AA27888 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 18 Aug 1994 06:09:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 18 Aug 1994 06:09:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 18 Aug 1994 06:09:29 -0400 From: Masataka Ohta Return-Path: Message-Id: <9408181001.AA18293@necom830.cc.titech.ac.jp> Subject: Re: MD5 performance To: atkinson@itd.nrl.navy.mil Date: Thu, 18 Aug 94 19:01:31 JST Cc: ipsec@ans.net In-Reply-To: <9408171745.ZM19879@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Aug 17, 94 5:45 pm X-Mailer: ELM [version 2.3 PL11] > MD5 Performance update: > > On the 64-bit RISC processor that got 20 Mbps using the > RFC-1321 code, I observed the same figure on 100MHz HP (32bit RISC). As MD5 is 32bit based, 64-bitness does not help. > there is new news that by hand tweaking the code in a > one can get about triple the speed. In general, "hand tweaking" can not do better than compilers on RISC. It is obvious from my "prof" command analysis that the two thirds of the time is wasted for bytewise-I/O and byte-aligning (byte-aligned IPng is really a good news), removing which will results in triple performance, 60Mbps. > I'm being deliberately vague here on exact performance because > slightly different system configurations were used by different groups > to get these numbers. Counting the number of basic operations (about 700 for 64 bytes), theoretical maximum for software approach is at about 1 MB/sec for 10 MIPS. Considering that super scaler boosting does not help so much for MD5, maximum speed with 100MHz processor is at about 80Mbps and we are now close to that limit. > My concerns over MD5 performance are significantly abated by these > more recent results. It looks like IP/FDDI, IP/HyperChannel, IP/ATM, > and IP/PPP/SONET may have performance problems with MD5. Most users > are at Ethernet speed or below and will be fine. We will soonly have a new news that most users are much above at Ethernet speed. > IMHO, we need to > consider selectively authenticating packets in any event Or hardware MD5 generator. Masataka Ohta From ipsec-request@ans.net Sun Aug 21 19:03:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05060 (5.65c/IDA-1.4.4 for ); Mon, 22 Aug 1994 03:15:01 -0400 Received: by interlock.ans.net id AA30825 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Aug 1994 03:03:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 22 Aug 1994 03:03:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 22 Aug 1994 03:03:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 22 Aug 1994 03:03:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Aug 1994 03:03:37 -0400 Message-Id: Date: Mon, 22 Aug 94 01:03 MDT From: colin@nyx.cs.du.edu (Colin Plumb) To: karn@qualcomm.com Subject: Re: IVs Cc: ipsec@ans.net Phil Karn says: > How about if we just use the outer (plaintext) IP ID field as a > confounder/IV? After all, it's free, and when combined with the source > IP address it's intended to make each packet relatively unique. > I know it's only 16 bits, but that still gives us 65536 unique packet > IVs. Simply rekeying (e.g., creating new SAIDs) more often than that > will take care of the rest. It will do quite nicely; as I've explained to more people than I can count (it might be impolite to mention names, but some of their addresses are pgut1@cs.aukuni.ac.nz and prz@acm.org) there is absolutely no requirement for IVs to be secret; it is sufficient that they be different for each packet. In CBC mode, it also helps if they are uncorrelated with the first block of plaintext, because otherwise you might find that IV1 ^ x1[0] == IV2 ^ x2[0], so y1[0] = crypt(IV1 ^ x1[0], Key) == y2[0] = crypt(IV2 ^ x2[0], Key). You can observe that the ciphertext y1[0] == y2[0], and since you know the IVs, you can conclude things about x1[0] and x2[0]. One technique that I came up with and works well is used in Peter Gutmann's SFS. It requires that the message be at least two cipher blocks long. Basically, you do two encryption passes, and use the last block of the first pass as the IV for the second pass. On decryption, you have to decrypt the tail (not including the first block, but including the last block; the exact division is irrelevant) of the message to find the IV needed to decrypt the head. Now, before you say that this makes things twice as slow, the first pass can be a very trivial cipher, as long as it has good cascade properties. I use a scrambler polynomial. In fact, you can just take any checksum of all but the last block of the message and combine it using some invertible operation with the last block. Use that as the IV, and after undoing the outer encryption, recompute the checksum and undo the combination. In the case of a scrambler polynomial, the combining operation is XOR, but you can add, multiply in a Galois field, encrypt with the checksum as a key, or whatever you like. As long as the data is not deliberately constructed to defeat the inner checksum computation, the IV is nicely random. If the data is so constructed, you can get a chosen IV, leading to a chosen plaintext attack, but so what? If you can construct such data, you have a chosen plaintext attack anyway. The two-pass nature of this is a problem for some applications, but it does not appreciably slow down encryption and it generates a unique IV per (distinct) packet without extra overhead. Anyway, it's something to think about. (Sorry I haven't been participating; I've been swamped with work. I'm going through about a zillion messages I haven't read for two weeks.) -- -Colin From ipsec-request@ans.net Sun Aug 21 20:11:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04987 (5.65c/IDA-1.4.4 for ); Mon, 22 Aug 1994 04:20:25 -0400 Received: by interlock.ans.net id AA12386 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Aug 1994 04:11:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 22 Aug 1994 04:11:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 22 Aug 1994 04:11:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 22 Aug 1994 04:11:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Aug 1994 04:11:34 -0400 Message-Id: Date: Mon, 22 Aug 94 02:11 MDT From: colin@nyx.cs.du.edu (Colin Plumb) To: Steve Kent Subject: Re: fast 386 DES code figures Cc: ipsec@ans.net > When four us did an implementation back in the late 70s, as > grad students at MIT, we used tables to compose SP and E. Later one > of the grad students figured out how to E in a very efficient fashion, > whic allowed us to go back to just an S&P composition, with 32-bit > vs. 48 bit values. I think that's the common approach today, with > the asusmption that the space devoted to the tables is not a big deal > on most modern machines. Our fastest implementations were in line code, > but instruction cacheing may argue for loops. I had correspondence a while ago with a fellow who managed to beat my assembler IDEA code with DES. I was *very* impressed. I can't find that code around, but it was based on a very efficient E that let you go back to a 32-bit implementation. As usual, the S-boxes include the final P and are 32 bits wide, and you use 12-bit inputs. The idea was to scramble the bits into some odd order such that you'd have the data in (say) ah, al, dh and dl, and move pairs of bytes into bh and bl, mask off the two low bits and the two high bits, XOR in some key material, and do a table lookup. The tables fit nicely into one 64K segment, so if you prepare the key schedule with the high two bits set properly, after the XOR, you are left with the address of the 32-bit word to accumulate. The trick was that the S-boxes that you did the lookups in simultaneously were NOT adjacent. Let me see if I can recreate the technique... When DES encoding, the E expansion duplicates half the bits. (To be precise, the ones congruent to 3 and 0 mod 4 in the original 32-bit word.) In this modified form, the bits that appear twice are the middle 4 bits of each byte register. Each byte appears once in each position (high or low) of the lookup, when the high or low 2 bits are masked off, so those bits are only used in one lookup. So let's analyze what requirements are needed for the shared bits. A simple mapping, where 1ah2 Means that the high two bits of AH are the private bits of S-box 1 and the low bits are the private bits of S-box 2. From this, I'll derive a schedule for the shared bits. Assuming the registers are used in pairs in the order: ah:al al:dh dh:dl dl:ah Then assigning 1ah2:3al4 can't work, because when that pair is loaded and masked, (resulting in ah2:3al), the private bits of S-boxes 2 and 3 are visible, requiring that the shared bits that are visible are the 1/2, 2/3, 2/3 and 3/4 pairs. But the two 2/3's need to be in different positions, so they can be XORed with different key material. No good! The first schedule to consider is: 1ah2:4al3:5dh6:8dl7:1ah2 For the first pair, ah2:4al, the shared bits in ah and al must include 1/2, 2/3, 3/4 and 4/5. For the second pair, al3:5dh, the shared bits in al and dh must include 2/3, 3/4, 4/5 and 5/6. For the third pair, dh6:8dl, the shared bits in ah and al must include 5/6, 6/7, 7/8, and 8/1. For the second pair, dl7:1ah, the shared bits in al and dh must include 6/7, 7/8, 8/1 and 1/2. Thus, al must contain 2/3, 3/4 and 4/5. H'm. That's not going to work. How about 2ah1:4al3:6dh5:8dl7:2ah1.... ah1:4al -> 8/1, 1/2, 3/4, 4/5 al -> 3/4, ??? al3:6dh -> 2/3, 3/4, 5/6, 6/7 No, that won't work, either. Each pair must share two things with the next pair. Okay, let's try: 1ah8:2al7:3dh6:4dl5:1ah8 ah8:2al -> 7/8, 8/1, 1/2, 2/3 al -> 7/8, 2/3 al7:3dh -> 6/7, 7/8, 2/3, 3/4 dh -> 6/7, 3/4 dh6:4dl -> 5/6, 6/7, 3/4, 4/5 dl -> 5/6, 4/5 dl5:1ah -> 4/5, 5/6, 8/1, 1/2 ah -> 8/1, 1/2 ah8:2al -> 7/8, 8/1, 1/2, 2/3 That schedule works. The trick was arranging things to that consecutive paris always had two pairs of numbers differing by 1. Mostly, cyclic works, but you have to end the cycle somewhere. Another one that works is 8ah1:5al2:6dh3:7dl4:8ah1 ah1:5al -> 8/1, 1/2, 4/5, 5/6 al -> 1/2, 5/6 al2:6dh -> 1/2, 2/3, 5/6, 6/7 dh -> 2/3, 6/7 dh3:7dl -> 2/3, 3/4, 6/7, 7/8 dl -> 3/4, 7/8 dl4:8ah -> 3/4, 4/5, 7/8, 8/1 ah -> 4/5, 8/1 ah1:5al -> 8/1, 1/2, 4/5, 5/6 This is somewhat more symmetric. Anyway, it appeared to produce blazing speed on a 16-bit 8086 with a not-totally-unreasonable table requirement. (48 bits of key per round, 64K of fixed s-box tables, and some tables to do the new, different, IP and IP'. I can dig up the impmentor from my e-mail files and ask for his code if you'd like. I think I still have it somewhere. -- -Colin From ipsec-request@ans.net Wed Aug 24 18:35:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06947 (5.65c/IDA-1.4.4 for ); Thu, 25 Aug 1994 02:48:42 -0400 Received: by interlock.ans.net id AA03836 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 25 Aug 1994 02:35:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 25 Aug 1994 02:35:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 25 Aug 1994 02:35:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 25 Aug 1994 02:35:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 25 Aug 1994 02:35:04 -0400 Message-Id: Date: Thu, 25 Aug 94 00:35 MDT From: colin@nyx.cs.du.edu (Colin Plumb) To: ipsec@ans.net Subject: IVs, summary of discussion I just had a fairly long discussion with uri@watson.ibm.com about IVs, the need for security thereon, etc., and we managed to come to an agreement that's worth sharing with a wider audience. Basically, many ciphers need some sort of IV or other extra initialization data to encrypt a message. In most cases, it is useful for these IVs to be distinct per message. In some cases, these should be well-distributed, while others can accept sequence numbers. Some need the IV data encrypted. The entire issue of how much padding is added to an encrypted message is a parameter of the cipher. I think that taking the packet size, adding a constant, rounding up (or down) to a multiple of another constant (which need not be a power of 2), and adding a third constant is general enough, if either additive constant may be negative, but if there's no particular use in standardizing that model, don't bother. In some cases some IP sequence numbers can be used by the cipher to avoid what would otherwise need to be an explicit IV field, so the general secure IP standard should say what information of that nature is available to the encryption layer, and it is the responsibility of the encryption sub-standard to say how that information is used. So, basically, using the IP sequence number may be great for DES-CBC, but don't mandate it. I'm sure Uri will correct me if I got anything wrong. -- -Colin From ipsec-request@ans.net Fri Aug 26 20:55:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01731 (5.65c/IDA-1.4.4 for ); Fri, 26 Aug 1994 17:10:48 -0400 Received: by interlock.ans.net id AA21288 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 26 Aug 1994 16:55:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 26 Aug 1994 16:55:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 26 Aug 1994 16:55:17 -0400 Date: Fri, 26 Aug 1994 13:55:36 -0700 From: Phil Karn Message-Id: <199408262055.NAA17112@unix.ka9q.ampr.org> To: colin@nyx.cs.du.edu Cc: ipsec@ans.net In-Reply-To: (colin@nyx.cs.du.edu) Subject: Re: IVs, summary of discussion Reply-To: karn@qualcomm.com I concur with what Colin says - using the IP ID as an IV may be just one of the allowable techniques. Question for those who know BSD kernel internals better than me -- is this easily done? Or is the IP ID assigned after the transport layer (IPSEC, in this case) has already handed its packet down to IP? Phil From ipsec-request@ans.net Sat Aug 27 05:37:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17876 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 01:46:00 -0400 Received: by interlock.ans.net id AA07448 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 01:37:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 27 Aug 1994 01:37:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 27 Aug 1994 01:37:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 27 Aug 1994 01:37:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 01:37:39 -0400 Date: Fri, 26 Aug 1994 22:37:27 -0700 From: Kelly.Goen@eng.sun.com (Kelly Goen [CONTRACTOR]) Message-Id: <199408270537.WAA11295@jurassic.Eng.Sun.COM> To: ipsec@ans.net Subject: subscribe X-Sun-Charset: US-ASCII subscribe From ipsec-request@ans.net Sat Aug 27 08:57:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15841 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 13:09:50 -0400 Received: by interlock.ans.net id AA07680 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 12:59:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 27 Aug 1994 12:59:22 -0400 Message-Id: <199408271659.AA24316@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 12:59:22 -0400 To: karn@qualcomm.com Cc: colin@nyx.cs.du.edu, ipsec@ans.net Subject: Re: IVs, summary of discussion Date: Sat, 27 Aug 94 12:57:23 EDT I concur with what Colin says - using the IP ID as an IV may be just one of the allowable techniques. Question for those who know BSD kernel internals better than me -- is this easily done? Or is the IP ID assigned after the transport layer (IPSEC, in this case) has already handed its packet down to IP? Traditionally, IP assigns the id field. From ipsec-request@ans.net Sat Aug 27 17:22:50 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16096 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 13:33:20 -0400 Received: by interlock.ans.net id AA23730 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 13:22:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 27 Aug 1994 13:22:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 13:22:11 -0400 Date: Sat, 27 Aug 1994 10:22:50 -0700 From: Phil Karn Message-Id: <199408271722.KAA13170@servo.qualcomm.com> To: smb@research.att.com Cc: colin@nyx.cs.du.edu, ipsec@ans.net In-Reply-To: <199408271659.JAA28731@qualcomm.com> (smb@research.att.com) Subject: Re: IVs, summary of discussion >Traditionally, IP assigns the id field. Right. So does my code, although I give the caller of the IP send routine the option of specifying one. I generate ID fields with a global variable used as a counter, so another module (e.g. IPSEC) could conceivably access it. Or IPSEC could maintain a separate ID counter of its own without worrying about collisions with "regular" IP datagrams because the protocol field is logically appended to the ID field for the purpose of reassembling fragments. The closest RFC-1122 comes to discussing this issue is the subject of whether retransmitted segments could have the same IP ID. It seems to be silent on the specific issue of whether IP should give a transport protocol direct control over the IP ID field, although the example upper level interface in RFC-791 does show it as one of the parameters. So I guess the question is, does the BSD IP send routine allow its caller to specify its own ID field? If not, can it be easily modified to do so? Phil From ipsec-request@ans.net Sat Aug 27 19:02:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06997 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 14:38:32 -0400 Received: by interlock.ans.net id AA15993 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 14:04:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 14:04:28 -0400 From: Ran Atkinson Message-Id: <9408271402.ZM5786@sundance.itd.nrl.navy.mil> Date: Sat, 27 Aug 1994 14:02:21 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: IVs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil IPv6 doesn't have the IDENT field of IPv4 in its base header. Using the IDENT field won't work for IPv6. This is not necessarily a problem since IPv4 and IPv6 aren't interoperable anyway... Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Sat Aug 27 10:06:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06235 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 14:39:37 -0400 Received: by interlock.ans.net id AA11197 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 14:07:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 27 Aug 1994 14:07:07 -0400 Message-Id: <199408271807.AA18105@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 14:07:07 -0400 To: Phil Karn Cc: colin@nyx.cs.du.edu, ipsec@ans.net Subject: Re: IVs, summary of discussion Date: Sat, 27 Aug 94 14:06:25 EDT So I guess the question is, does the BSD IP send routine allow its caller to specify its own ID field? If not, can it be easily modified to do so? All I have conveniently accessible is the SunOS source. In it, it would be an easy change; there's already a flag parameter passed to the ip_output routine. For that matter, there's currently a `forwarding'' parameter; if it's set, the id field and a few other fields are assumed to be set already. One could overload its meaning, I suppose. From ipsec-request@ans.net Sat Aug 27 18:19:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06247 (5.65c/IDA-1.4.4 for ); Sat, 27 Aug 1994 14:42:20 -0400 Received: by interlock.ans.net id AA29972 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 27 Aug 1994 14:19:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 27 Aug 1994 14:19:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 27 Aug 1994 14:19:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 27 Aug 1994 14:19:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Aug 1994 14:19:37 -0400 Message-Id: <9408271819.AA22369@poplar006> To: Phil Karn Cc: smb@research.att.com, colin@nyx.cs.du.edu, ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Sat, 27 Aug 1994 10:22:50 PDT. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <22358.778011550.1@poplar006> Date: Sat, 27 Aug 1994 13:19:12 -0500 From: Mark Christenson Content-Length: 2817 ------- =_aaaaaaaaaa0 Content-Type: text/enriched; charset="us-ascii" Content-ID: <22358.778011550.2@poplar006> In message <<199408271722.KAA13170@servo.qualcomm.com>, you write: >Traditionally, IP assigns the id field. Right. So does my code, although I give the caller of the IP send routine the option of specifying one. I generate ID fields with a global variable used as a counter, so another module (e.g. IPSEC) could conceivably access it. Or IPSEC could maintain a separate ID counter of its own without worrying about collisions with "regular" IP datagrams because the protocol field is logically appended to the ID field for the purpose of reassembling fragments. The closest RFC-1122 comes to discussing this issue is the subject of whether retransmitted segments could have the same IP ID. It seems to be silent on the specific issue of whether IP should give a transport protocol direct control over the IP ID field, although the example upper level interface in RFC-791 does show it as one of the parameters. So I guess the question is, does the BSD IP send routine allow its caller to specify its own ID field? If not, can it be easily modified to do so? Phil IP will fill in the ID field unless the IP_RAWOUTPUT bit is set in the flags parameter to ip_output(). If IP_RAWOUTPUT is set, the caller must fill in the IP version, the ID field and the header length field. The relevant code from 4.4-lite is attached. This is the only bit of code that does anything different based on IP_RAWOUTPUT. Mark -- M. G. Christenson < - Cray Research, Eagan, MN - (612) 683-5208 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22358.778011550.3@poplar006> /* * IP output. The packet in mbuf chain m contains a skeletal IP * header (with len, off, ttl, proto, tos, src, dst). * The mbuf chain containing the packet will be freed. * The mbuf opt, if present, will not be freed. */ int ip_output(m0, opt, ro, flags, imo) struct mbuf *m0; struct mbuf *opt; struct route *ro; int flags; struct ip_moptions *imo; { register struct ip *ip, *mhip; register struct ifnet *ifp; register struct mbuf *m = m0; register int hlen = sizeof (struct ip); int len, off, error = 0; struct route iproute; struct sockaddr_in *dst; struct in_ifaddr *ia; #ifdef DIAGNOSTIC if ((m->m_flags & M_PKTHDR) == 0) panic("ip_output no HDR"); #endif if (opt) { m = ip_insertoptions(m, opt, &len); hlen = len; } ip = mtod(m, struct ip *); /* * Fill in IP header. */ if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { ip->ip_v = IPVERSION; ip->ip_off &= IP_DF; ip->ip_id = htons(ip_id++); ip->ip_hl = hlen >> 2; ipstat.ips_localout++; } else { hlen = ip->ip_hl << 2; } ------- =_aaaaaaaaaa0-- From ipsec-request@ans.net Sun Aug 28 02:54:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01663 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 02:54:06 -0400 Received: by interlock.ans.net id AA25389 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 02:42:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 02:42:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 02:42:15 -0400 Date: Sat, 27 Aug 1994 23:42:27 -0700 From: Phil Karn Message-Id: <199408280642.XAA13665@servo.qualcomm.com> To: mgc@ironwood.cray.com Cc: smb@research.att.com, colin@nyx.cs.du.edu, ipsec@ans.net In-Reply-To: <9408271819.AA22369@poplar006> (message from Mark Christenson on Sat, 27 Aug 1994 13:19:12 -0500) Subject: Re: IVs, summary of discussion Thanks for the comments on and code excerpts from BSD. Looks like there's no real problem in doing this. So I take it that there's general agreement that Mode 1 encryption (single key DES/CBC, as we've already discussed) can use the IPv4 ID field as the IV? Remember that we intend this mode to be mandatory in all IPSEC implementations to provide basic interoperability (only the implementation is mandatory, not its actual use). So it's really important that it not be too difficult to add to existing implementations. By the way, in the draft text I sent yesterday to Perry, I specify that the ID value be left-justified in the 8-byte IV field, with the remaining 6 bytes set to zero. My thinking is that the first two bytes of a TCP or an IP header (depending on what is being encapsulated) are usually constant from one packet to the next. This makes it fairly unlikely that XORing in the ID field (which is incremented after every packet) would produce the same plaintext input to DES for more than one packet. But the ID field could just as easily be placed elsewhere in the IV, or it could even be repeated 4 times if necessary. Comments? Phil From ipsec-request@ans.net Sun Aug 28 04:17:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06153 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 08:26:52 -0400 Received: by interlock.ans.net id AA09257 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 08:18:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 08:18:36 -0400 Message-Id: <199408281218.AA31780@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 08:18:36 -0400 To: Phil Karn Cc: mgc@ironwood.cray.com, colin@nyx.cs.du.edu, ipsec@ans.net Subject: Re: IVs, summary of discussion Date: Sun, 28 Aug 94 08:17:24 EDT So I take it that there's general agreement that Mode 1 encryption (single key DES/CBC, as we've already discussed) can use the IPv4 ID field as the IV? Remember that we intend this mode to be mandatory in all IPSEC implementations to provide basic interoperability (only the implementation is mandatory, not its actual use). So it's really important that it not be too difficult to add to existing implementations. Except, of course, that IPv6 doesn't have the id field. By the way, in the draft text I sent yesterday to Perry, I specify that the ID value be left-justified in the 8-byte IV field, with the remaining 6 bytes set to zero. My thinking is that the first two bytes of a TCP or an IP header (depending on what is being encapsulated) are usually constant from one packet to the next. This makes it fairly unlikely that XORing in the ID field (which is incremented after every packet) would produce the same plaintext input to DES for more than one packet. But the ID field could just as easily be placed elsewhere in the IV, or it could even be repeated 4 times if necessary. Comments? In a theoretical sense, I don't like it much, since it means that there's almost no variability in the first input block, which in turn could aid cryptanalysts. In a practical sense, I doubt that it matters much against anyone who can attack DES... From ipsec-request@ans.net Sun Aug 28 14:59:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13318 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 10:13:13 -0400 Received: by interlock.ans.net id AA25349 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 09:59:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 09:59:50 -0400 From: Ran Atkinson Message-Id: <9408280959.ZM6131@sundance.itd.nrl.navy.mil> Date: Sun, 28 Aug 1994 09:59:34 -0500 In-Reply-To: Phil Karn "Re: IVs, summary of discussion" (Aug 27, 23:42) References: <199408280642.XAA13665@servo.qualcomm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: Phil Karn Subject: Re: IVs, summary of discussion Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Aug 27, 23:42, Phil Karn wrote: % Subject: Re: IVs, summary of discussion % % So I take it that there's general agreement that Mode 1 encryption % (single key DES/CBC, as we've already discussed) can use the IPv4 ID % field as the IV? Remember that we intend this mode to be mandatory in % all IPSEC implementations to provide basic interoperability (only the % implementation is mandatory, not its actual use). So it's really % important that it not be too difficult to add to existing % implementations. }-- End of excerpt from Phil Karn All, Last Monday I gave an MBONE talk on the IPv6 security stuff as part of the open IPv6 Design Review. During that talk, Jeff Schiller suggested that DES OFB mode might be preferable since IP can both lose and re-order packets. I'm wondering what folks on this list think of that idea instead of DES CBC mode. Phil, What would you propose for the IV for use with IPv6 ? Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Sun Aug 28 06:47:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06396 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 11:04:34 -0400 Received: by interlock.ans.net id AA19141 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 10:48:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 10:48:14 -0400 Message-Id: <199408281448.AA31937@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 10:48:14 -0400 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion Date: Sun, 28 Aug 94 10:47:15 EDT Last Monday I gave an MBONE talk on the IPv6 security stuff as part of the open IPv6 Design Review. During that talk, Jeff Schiller suggested that DES OFB mode might be preferable since IP can both lose and re-order packets. I'm wondering what folks on this list think of that idea instead of DES CBC mode. I fail to see Jeff's point -- why should those properties of IP mean that OFB is better? If nothing else, each packet would be encrypted separately with CBC, so the interpacket properties don't matter. (They would matter if we were trying to use a computed IV for each packet, since then the ordering and delivery guarantees would be very critical. Even then, OFB wouldn't help. OFB would work on top of TCP, but that's not what we're talking about.) Let me give a concrete -- though possibly not realistic -- example of how OFB might be totally unacceptable. Suppose that we decide that we don't need a separate checksum, since the TCP checksum will detect any modifications. A key property of OFB is that the attacker can make predictable changes to the plaintext. I suspect that corresponding changes could be made to the very simple TCP checksum. From ipsec-request@ans.net Mon Aug 29 00:06:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15865 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 20:18:54 -0400 Received: by interlock.ans.net id AA09590 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 20:06:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 28 Aug 1994 20:06:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 28 Aug 1994 20:06:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 20:06:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 20:06:55 -0400 Message-Id: <9408290006.AA09837@snark.imsi.com> To: karn@qualcomm.com Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Sun, 28 Aug 1994 08:17:24 EDT." <199408281218.AA31780@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 28 Aug 1994 20:06:35 -0400 From: "Perry E. Metzger" smb@research.att.com says: > So I take it that there's general agreement that Mode 1 encryption > (single key DES/CBC, as we've already discussed) can use the IPv4 ID > field as the IV? Remember that we intend this mode to be mandatory in > all IPSEC implementations to provide basic interoperability (only the > implementation is mandatory, not its actual use). So it's really > important that it not be too difficult to add to existing > implementations. > > Except, of course, that IPv6 doesn't have the id field. I see this as something of a problem. Maybe there is some way we can specify this so that when packets go through a V6/V4 translation we get some sort of reasonable move of the IV into/out of the IPSP section of the packet... Perry From ipsec-request@ans.net Mon Aug 29 00:09:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15870 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 20:19:25 -0400 Received: by interlock.ans.net id AA19082 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 20:09:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 28 Aug 1994 20:09:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 28 Aug 1994 20:09:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 20:09:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 20:09:42 -0400 Message-Id: <9408290009.AA09853@snark.imsi.com> To: atkinson@itd.nrl.navy.mil Cc: Phil Karn , ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Sun, 28 Aug 1994 09:59:34 CDT." <9408280959.ZM6131@sundance.itd.nrl.navy.mil> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 28 Aug 1994 20:09:24 -0400 From: "Perry E. Metzger" Ran Atkinson says: > Last Monday I gave an MBONE talk on the IPv6 security stuff as part > of the open IPv6 Design Review. During that talk, Jeff Schiller > suggested that DES OFB mode might be preferable since IP can both lose > and re-order packets. I'm wondering what folks on this list think of > that idea instead of DES CBC mode. The problem is that if you use OFB you are practically obligated to use an authenticator because the ability to twiddle known bits in the packet becomes just too much of a risk, or at least so it would seem to me. Comments? Perry From ipsec-request@ans.net Mon Aug 29 01:46:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16059 (5.65c/IDA-1.4.4 for ); Sun, 28 Aug 1994 21:02:57 -0400 Received: by interlock.ans.net id AA22923 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 28 Aug 1994 20:47:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Sun, 28 Aug 1994 20:47:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 28 Aug 1994 20:47:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 28 Aug 1994 20:47:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 28 Aug 1994 20:47:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 28 Aug 1994 20:47:18 -0400 From: uri@watson.ibm.com Message-Id: <9408290046.AA21264@buoy.watson.ibm.com> Subject: Re: IVs, summary of discussion To: perry@imsi.com Date: Sun, 28 Aug 1994 20:46:36 -0500 (EDT) Cc: atkinson@itd.nrl.navy.mil, karn@qualcomm.com, ipsec@ans.net In-Reply-To: <9408290009.AA09853@snark.imsi.com> from "Perry E. Metzger" at Aug 28, 94 08:09:24 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 725 Perry E. Metzger says: > > .....During that talk, Jeff Schiller > > suggested that DES OFB mode might be preferable since IP can both lose > > and re-order packets....... > The problem is that if you use OFB you are practically obligated to > use an authenticator because the ability to twiddle known bits in the > packet becomes just too much of a risk, or at least so it would seem > to me. Comments? I could see why DES OFB can increase overall performance - but what this mode has to do with packet loss is beyond me... Would somebody care to explain, please? Maybe Ron could post Jeff's arguments, if you recall them? -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Mon Aug 29 06:18:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14591 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 10:44:32 -0400 Received: by interlock.ans.net id AA19279 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 10:20:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 10:20:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 10:20:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 10:20:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 10:20:52 -0400 Date: Mon, 29 Aug 94 10:18:08 EDT Message-Id: <9408291418.AA08201@mailserv-D.ftp.com> To: ipsec@ans.net Subject: IVs and IDENTs From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 375 > From: Ran Atkinson > IPv6 doesn't have the IDENT field of IPv4 in its base header. Using > the IDENT field won't work for IPv6. This has come up a couple of times. If the bits are needed, why not add a couple of bytes to the IP6 security header to hold an equivalent field (used just in the security role)? -- Frank Kastenholz From ipsec-request@ans.net Mon Aug 29 15:18:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14501 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 11:52:04 -0400 Received: by interlock.ans.net id AA19273 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 11:18:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 11:18:59 -0400 Message-Id: <199408291518.AA08005@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Sat, 27 Aug 94 23:42:27 -0700. <199408280642.XAA13665@servo.qualcomm.com> Date: Mon, 29 Aug 94 11:18:02 -0400 From: Steve Kent Phil, Note that it is possible to change the value of the IV in CBC mode and change the resulting first enciphered bolck in a totally predictable fashion. From that perspective, it would not be appropriate to adopt the IPv4 fragment ID for an IV unless there was also an integrity check covering this field as an integral part of the negotiated mode of operation. Also, I think we need to discuss further the need for uniformity in IPv4/6 modes, since Ran's comment suggests that the same hack can't be used in IPv6. Finally, there may be a need for some discussion of the desirability of binding selected portions of the IP header into the integrity check, through means other than encapsulation. Steve From ipsec-request@ans.net Mon Aug 29 15:26:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13495 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 11:57:39 -0400 Received: by interlock.ans.net id AA27122 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 11:29:33 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 11:29:33 -0400 Message-Id: <199408291529.AA12270@interlock.ans.net> To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Sun, 28 Aug 94 09:59:34 -0500. <9408280959.ZM6131@sundance.itd.nrl.navy.mil> Date: Mon, 29 Aug 94 11:26:05 -0400 From: Steve Kent Ran, I assumed that Phil was proposing to use the fragment ID from each packet to act an an IV for a packet. If the packet is NOT fragmented enroute, as I suggested in a memo a while ago, then this ID provides sufficient context to decrypt each arriving packet, irrespective of order of arrival. So, in that context, I'm confused by the comment you attribue to Jeff re OFB vs. CBC mode and packet arrival/loss problems. Note my comment about the importance of not having packets fragment enroute. If fragmentation can occur before and after encryption, then there is ambiguity in the reassembly/decryption process. Also, one is left open to denial of service attacks if enroute fragmentation is allowed. Steve From ipsec-request@ans.net Mon Aug 29 15:31:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13416 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 12:09:34 -0400 Received: by interlock.ans.net id AA04920 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 11:34:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 11:34:47 -0400 Message-Id: <199408291534.AA09011@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Sun, 28 Aug 94 20:09:24 -0400. <9408290009.AA09853@snark.imsi.com> Date: Mon, 29 Aug 94 11:31:45 -0400 From: Steve Kent Perry, Yes, OFB is so trivially susceptible to manipulation, and the TCP checksum admits such trivial invariant transformations, that the combination of the two is (should be?) unacceptable. However, one could define an IPSP mode operation that combined encryption and integrity checking, so that the decoupling was not an "accepted" mode. Still, my earlier comments, and those of Steve Bellovin, about why OFB doesn't seem to matter here, are more to the point. Steve From ipsec-request@ans.net Mon Aug 29 15:36:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13432 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 12:12:35 -0400 Received: by interlock.ans.net id AA20593 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 11:41:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 11:41:01 -0400 Message-Id: <199408291541.AA16237@interlock.ans.net> To: kasten@ftp.com Cc: ipsec@ans.net Subject: Re: IVs and IDENTs In-Reply-To: Your message of Mon, 29 Aug 94 10:18:08 -0400. <9408291418.AA08201@mailserv-D.ftp.com> Date: Mon, 29 Aug 94 11:36:52 -0400 From: Steve Kent Frank, We have the ability to carry an IV in the IPSP header info. What Phil is trying to do is to economize on "extra" bits carried just for security purposes. In fact, the IPv4 frag ID is not an ideal IV from a security standpoint, but rather represents a compromise in terms of minimal overhead. Steve From ipsec-request@ans.net Mon Aug 29 16:49:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17616 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 12:25:48 -0400 Received: by interlock.ans.net id AA13539 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 11:52:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 11:52:04 -0400 From: Ran Atkinson Message-Id: <9408291149.ZM7428@sundance.itd.nrl.navy.mil> Date: Mon, 29 Aug 1994 11:49:23 -0500 In-Reply-To: kasten@ftp.com (Frank Kastenholz) "IVs and IDENTs" (Aug 29, 10:18) References: <9408291418.AA08201@mailserv-D.ftp.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: kasten@ftp.com Subject: Re: IVs and IDENTs Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Frank, IMHO there is no need to use the IDENT field from IPv4. The needed space, if any, can be part of the algorithm-dependent stuff just after the SAID. This approach works for both IPv4 and IPv6. Ran From ipsec-request@ans.net Mon Aug 29 08:54:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15458 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 13:24:38 -0400 Received: by interlock.ans.net id AA29646 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 12:54:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 12:54:35 -0400 Message-Id: <199408291654.AA29642@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 12:54:35 -0400 To: ipsec@ans.net Subject: Re: OFB for IPSEC Date: Mon, 29 Aug 94 12:54:01 EDT I asked Jeff what he meant; this was his reply. ------- Forwarded Message Replied: Sun, 28 Aug 94 23:58:24 EDT Replied: "Jeffrey I. Schiller" Forwarded: Sun, 28 Aug 94 23:50:15 EDT Forwarded: uri@watson.ibm.com Return-Path: mit.edu!jis Received: by research.att.com; Sun Aug 28 23:41 EDT 1994 Received: by big-screw id AA25892; Sun, 28 Aug 94 23:41:05 -0400 Date: Sun, 28 Aug 94 23:41:05 -0400 Message-Id: <9408290341.AA25892@big-screw> From: Jeffrey I. Schiller Sender: jis@MIT.EDU To: smb@research.att.com In-Reply-To: <9408290200.AA17959@MIT.EDU> (smb@research.att.com) Subject: Re: OFB for IPSEC From: smb@research.att.com Date: Sun, 28 Aug 94 21:59:47 EDT Jeff, Ran Atkinson quoted you as suggesting that OFB be used instead of CBC mode, because of packet loss and reordering. I confess that your rationale escapes me, among others. Could you possibly elucidate? My rationale is being able to pre-create the pad. Its got nothing to do with packet loss and reordering. -Jeff ------- End of Forwarded Message From ipsec-request@ans.net Mon Aug 29 17:27:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16374 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 13:53:41 -0400 Received: by interlock.ans.net id AA09132 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 13:26:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 13:26:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 13:26:34 -0400 Date: Mon, 29 Aug 1994 10:27:07 -0700 From: Phil Karn Message-Id: <199408291727.KAA21198@servo.qualcomm.com> To: atkinson@itd.nrl.navy.mil Cc: kasten@ftp.com, ipsec@ans.net In-Reply-To: <9408291149.ZM7428@sundance.itd.nrl.navy.mil> (message from Ran Atkinson on Mon, 29 Aug 1994 11:49:23 -0500) Subject: Re: IVs and IDENTs > IMHO there is no need to use the IDENT field from IPv4. The needed >space, if any, can be part of the algorithm-dependent stuff just after >the SAID. This approach works for both IPv4 and IPv6. Yes, but the whole point to this exercise was to see if we could keep the overhead to a minimum. I occasionally run an IPSEC prototype over my SLIP link. I can easily tell when it is there by the decreased performance. There is no VJ header compression and no V.42bis data compression. And the X server makes things even worse by disabling the Nagle algorithm in TCP that would otherwise work to limit header overhead with increasing load. This is bad if we want to make this stuff universal. True, using the IP ID field as an IV doesn't fix any of this other stuff, but at least it keeps it from getting any worse. Phil From ipsec-request@ans.net Mon Aug 29 18:37:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16219 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 15:17:55 -0400 Received: by interlock.ans.net id AA18576 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 14:38:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 14:38:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 14:38:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 14:38:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 14:38:54 -0400 Message-Id: <9408291837.AA11522@snark.imsi.com> To: Phil Karn Cc: atkinson@itd.nrl.navy.mil, kasten@ftp.com, ipsec@ans.net Subject: Re: IVs and IDENTs In-Reply-To: Your message of "Mon, 29 Aug 1994 10:27:07 PDT." <199408291727.KAA21198@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 29 Aug 1994 14:37:28 -0400 From: "Perry E. Metzger" Phil Karn says: > Yes, but the whole point to this exercise was to see if we could keep > the overhead to a minimum. > > I occasionally run an IPSEC prototype over my SLIP link. I can easily > tell when it is there by the decreased performance. There is no VJ > header compression and no V.42bis data compression. I've been wondering if there isn't some way we could put in header compression in such instances -- after all, the two ends of the encrypting tunnel are effectively a point to point link. .pm From ipsec-request@ans.net Mon Aug 29 20:34:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13082 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 16:14:57 -0400 Received: by interlock.ans.net id AA26892 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 15:39:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 15:39:35 -0400 From: Ran Atkinson Message-Id: <9408291534.ZM7652@sundance.itd.nrl.navy.mil> Date: Mon, 29 Aug 1994 15:34:10 -0500 In-Reply-To: Phil Karn "Re: IVs and IDENTs" (Aug 29, 10:27) References: <199408291727.KAA21198@servo.qualcomm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: Phil Karn Subject: Re: IVs and IDENTs Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Phil, ACK. Ok fine. Glad you're looking out for my 2.4Kbps HF radio links. :-) Ran who is worried about IPv6 over those same radio links... :-( From ipsec-request@ans.net Mon Aug 29 20:01:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15258 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 16:35:25 -0400 Received: by interlock.ans.net id AA08609 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 16:07:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 16:07:02 -0400 Message-Id: <199408292007.AA30621@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: IVs and IDENTs In-Reply-To: Your message of Mon, 29 Aug 94 14:37:28 -0400. <9408291837.AA11522@snark.imsi.com> Date: Mon, 29 Aug 94 16:01:19 -0400 From: Steve Kent Perry, I explicitly included compression (for whatever is encapsulated by IPSP) in my list of SA parameters. I agree that it is an important feature to include in an effort to overcome the compression that is lost on dialup links due to the use of encryption. Steve From ipsec-request@ans.net Mon Aug 29 20:30:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15210 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 17:07:37 -0400 Received: by interlock.ans.net id AA32405 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 16:29:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 16:29:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 16:29:52 -0400 Date: Mon, 29 Aug 1994 13:30:23 -0700 From: Phil Karn Message-Id: <199408292030.NAA21469@servo.qualcomm.com> To: kent@BBN.COM Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199408291534.AA09011@interlock.ans.net> (message from Steve Kent on Mon, 29 Aug 94 11:31:45 -0400) Subject: Re: IVs, summary of discussion There is a basic question here: how much are we willing to rely on encryption algorithms to also provide authentication, vs using separate mechanisms designed specifically for the purpose? Any authentication scheme requires redundancy (i.e., overhead) to work. Different users are likely to make different overhead/security tradeoffs depending on their particular threats and the cost of the added overhead. So how about if we state that authentication is specifically *not* a requirement of an encryption algorithm? This is not to say that we can't provide a little integrity checking as long as it's "free", e.g., by making consistency checks on padding information required by various block chaining schemes. But I see no reason to disallow some particular encryption scheme just because its ciphertext is more vulnerable to modification than some other scheme. If integrity is a requirement, then use a scheme like keyed MD5 that is specifically designed for that purpose. Phil From ipsec-request@ans.net Mon Aug 29 20:34:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14549 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 17:13:49 -0400 Received: by interlock.ans.net id AA30420 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 16:34:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 16:34:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 16:34:07 -0400 Date: Mon, 29 Aug 1994 13:34:19 -0700 From: Phil Karn Message-Id: <199408292034.NAA21481@servo.qualcomm.com> To: perry@imsi.com Cc: atkinson@itd.nrl.navy.mil, kasten@ftp.com, ipsec@ans.net In-Reply-To: <9408291837.AA11522@snark.imsi.com> (perry@imsi.com) Subject: Re: IVs and IDENTs >I've been wondering if there isn't some way we could put in header >compression in such instances -- after all, the two ends of the >encrypting tunnel are effectively a point to point link. Not really. Tunneled packets are susceptible to out of order delivery or outright loss when they are carried over the Internet. VJ header compression can tolerate a little of the latter, but it breaks completely when it encounters the former. And yes, you could tunnel across a TCP connection. But now that TCP connection is vulnerable to all sorts of active attacks that we're trying to guard against with IPSEC in the first place. Phil From ipsec-request@ans.net Mon Aug 29 20:42:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17107 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 17:13:42 -0400 Received: by interlock.ans.net id AA26931 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 16:42:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 16:42:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 16:42:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 16:42:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 16:42:21 -0400 Message-Id: <9408292042.AA11840@snark.imsi.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Mon, 29 Aug 1994 13:30:23 PDT." <199408292030.NAA21469@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 29 Aug 1994 16:42:05 -0400 From: "Perry E. Metzger" Phil Karn says: > There is a basic question here: how much are we willing to rely on > encryption algorithms to also provide authentication, vs using > separate mechanisms designed specifically for the purpose? I don't think we should rely on the encryption algorithms, but neither should we gratuitiously use ones that make authentication more problematic. I don't think OFB would buy us anything (other than a slight decrease in performance) and it would certainly make encryption only packets more vulnerable to various sorts of attacks. > Any authentication scheme requires redundancy (i.e., overhead) to > work. Different users are likely to make different overhead/security > tradeoffs depending on their particular threats and the cost of the > added overhead. > > So how about if we state that authentication is specifically *not* a > requirement of an encryption algorithm? I would agree that this should be placed in the document. However, I think that encryption algorithms that make the spoofer's job harder even without authentication are a plus, all other things being equal. > But I see no reason to disallow some particular encryption scheme > just because its ciphertext is more vulnerable to modification than > some other scheme. Well, if it has no particular advantage over a similar method that doesn't have this bad property, I see no reason to adopt such an algorithm. If it has other advantages, I would agree with you. Perry From ipsec-request@ans.net Mon Aug 29 21:29:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18623 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 17:57:28 -0400 Received: by interlock.ans.net id AA04831 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 17:31:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 17:31:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 17:31:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 17:31:42 -0400 Message-Id: <9408292129.AA10823@tis.com> To: Phil Karn Cc: kent@bbn.com, perry@imsi.com, ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Mon, 29 Aug 94 13:30:23 PDT." <199408292030.NAA21469@servo.qualcomm.com> Date: Mon, 29 Aug 94 17:29:10 -0400 From: Stephen D Crocker I'm a big fan of separation of function, and I think it's important in contexts like PEM for there to be separate encryption and signature operations. In the IP context, the situation is not so simple. So far, we've been proceeding as if the encryption and authentication were going to be completely separate. Efficiency issues at the IP level are often seen as more important than similar issues at the mail level, so it doesn't surprise me there is pressure to combine these. Let's compare the cost of combined versus separate designs. I don't have the data or the time handy, but perhaps someone else does. Can someone fill out the following table? Separate encryption Combined encryption and authentication and authentication Packet size Ss(n) Sc(n) Processing time Ts(n) Tc(n) Where S is the length of the packet in bits given a payload of n bits and T is the time it takes to process a packet with a payload of n bits. The times will be parameterized according to machine speed, of course. Steve From ipsec-request@ans.net Mon Aug 29 21:52:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13336 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 18:14:32 -0400 Received: by interlock.ans.net id AA08097 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 17:52:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 17:52:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 17:52:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 17:52:19 -0400 Date: Mon, 29 Aug 1994 14:52:12 -0700 From: Hilarie Orman Message-Id: <199408292152.OAA15679@umbra.CS.Arizona.EDU> To: ipsec@ans.net In-Reply-To: Mymessage <199408292030.NAA21469@servo.qualcomm.com> Subject: Re: IVs, summary of discussion I'd like to vote against two trends here: violating protocol layering and analyzing privacy and authentication as if they were totally orthogonal. Using the IP ID in IPSEC seems like a hack of such micro advantage in its context as to approach silliness. And with regard to the mix-n-match approach to encryption and authentication/integrity. I understand the goals, but I think it is dangerous to treat the issues as separable; one has to look at the entire protocol with all options, including the keying protocol, to do a meaningful analysis. This becomes increasingly difficult to do if there are options that permit vulnerable encryption algorithms and/or re-use too much information. In my opinion, IPSEC should not be allowed to flounder on such a spiky bed. Maybe one spike, but not a whole generic set. From ipsec-request@ans.net Mon Aug 29 22:15:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16723 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 18:41:04 -0400 Received: by interlock.ans.net id AA32490 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 18:18:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 18:18:19 -0400 Message-Id: <199408292218.AA21734@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Mon, 29 Aug 94 13:30:23 -0700. <199408292030.NAA21469@servo.qualcomm.com> Date: Mon, 29 Aug 94 18:15:49 -0400 From: Steve Kent Phil, In principle, I agree with your observations, i.e., encryption need not confer authentication nor even be designed to support authentication. The two are separable services (confidentiality and integrity, really, with authentication a side effect of key management for integrity). However, I do worry about users who don't appreciate the difference selecting encryption only (because of a performance concern) and being vulnerable to attacks that they didn't understand. Authentication/integrity imposes a bandwidth burden in terms of redundant information, and the computational burden of copmuting a very good integrity check value is also a valid concern. One tradeoff is that one can use a simplier integrity check value, maybe one that is already in place such as the TCP checksum, with an encryption mode that has very good error extension, like CBC, to avoid the computational burden and to avoid adding additional, redundant information. This is the approach I proposed in the early 80s when I was trying to add security to the Internet protocols. It is not as secure as an explicit integrity check such as MD5, but it doesn't take up any more space nor does it require extra computation for the integrity check. The primary downside, relative to use of OFB, is an inability to precompute key stream for XORing with the data. However, the default level of integrity provided (but checked at a higher layer) is not bad. Steve From ipsec-request@ans.net Mon Aug 29 22:34:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17858 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:02:18 -0400 Received: by interlock.ans.net id AA13247 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 18:38:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 18:38:05 -0400 Message-Id: <199408292238.AA21435@interlock.ans.net> To: Stephen D Crocker Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Mon, 29 Aug 94 17:29:10 -0400. <9408292129.AA10823@tis.com> Date: Mon, 29 Aug 94 18:34:22 -0400 From: Steve Kent Steve, The table is a bit more complicated than your 4 entry matrix might suggest. Assuming 64-bit wide encryption (OFB-64 or CBC or CFB-64), the data rates are all the same for these modes. The only advantage to OFB is the option to precompute key stream, but on a single processor machine that may not be much of an advantage. Next, one has to compare is the computation speed for different integrity algorithms, with one-way hashes being the most secure and least efficient, CRCs being more efficient and less secure, and simple checksums being the fastest and least secure. One could use a simple checksum or CRC with CBC mode and get a certain level of protection, or you could use a hash algorithm with OFB and get very high protection. Among hash functions, MD4 is faster than MD5 which is somewhat faster than SHS. When being used for integrity, vs. non-repduiation or forwardable authentication, I suspect even MD4 is quite adequate. I'd like to hear from Stu Stubblebine about the relataive vulnerability of a longitudinal parity check or a CRC with CBC mode, to get a better feeling for how hard it is to modify ciphertext undetectably. (Of course, CRCs and LPCs tend to be shorter than one-way hash functions, so there is already a different level of security there, but one could truncate the hash value to save transmission space and make the comparison simplier.) Finally, there is the approach I suggested in a recent message, which relies on the existing TCP checksum and calls for a mode like CBC, to take advantage of existing integrity check processing and space, but with a fixed (and not so great) integrity algorithm with a limited size. So, the comparison is a fairly complex one. Steve From ipsec-request@ans.net Mon Aug 29 23:53:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06950 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:15:49 -0400 Received: by interlock.ans.net id AA20286 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 18:53:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 29 Aug 1994 18:53:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 18:53:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 18:53:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 18:53:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 18:53:38 -0400 From: uri@watson.ibm.com Message-Id: <9408292253.AA20619@buoy.watson.ibm.com> Subject: Re: IVs and IDENTs To: kasten@ftp.com Date: Mon, 29 Aug 1994 18:53:34 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <9408291418.AA08201@mailserv-D.ftp.com> from "Frank Kastenholz" at Aug 29, 94 10:18:08 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 505 Frank Kastenholz says: > > IPv6 doesn't have the IDENT field of IPv4 in its base header. Using > > the IDENT field won't work for IPv6. > This has come up a couple of times. If the bits are needed, why not > add a couple of bytes to the IP6 security header to hold an > equivalent field (used just in the security role)? I'm not sure couple of bytes would be enough - more likely 4 bytes at least... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 30 00:06:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15953 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:24:23 -0400 Received: by interlock.ans.net id AA22455 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 19:06:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 29 Aug 1994 19:06:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 19:06:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 19:06:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 19:06:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 19:06:05 -0400 From: uri@watson.ibm.com Message-Id: <9408292306.AA20643@buoy.watson.ibm.com> Subject: Re: IVs, summary of discussion To: karn@qualcomm.com (Phil Karn) Date: Mon, 29 Aug 1994 19:06:01 -0500 (EDT) Cc: kent@BBN.COM, perry@imsi.com, ipsec@ans.net In-Reply-To: <199408292030.NAA21469@servo.qualcomm.com> from "Phil Karn" at Aug 29, 94 01:30:23 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 999 Phil Karn says: > There is a basic question here: how much are we willing to rely on > encryption algorithms to also provide authentication, vs using > separate mechanisms designed specifically for the purpose? I suggest - very little! > So how about if we state that authentication is specifically *not* a > requirement of an encryption algorithm? This is not to say that we > can't provide a little integrity checking as long as it's "free", > e.g., by making consistency checks on padding information required by > various block chaining schemes. But I see no reason to disallow some > particular encryption scheme just because its ciphertext is more > vulnerable to modification than some other scheme. If integrity is a > requirement, then use a scheme like keyed MD5 that is specifically > designed for that purpose. Yes, please "divorce" authentication/integrity checking from encryption! -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 30 00:12:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16820 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:34:59 -0400 Received: by interlock.ans.net id AA12042 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 19:12:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 29 Aug 1994 19:12:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 19:12:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 19:12:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 19:12:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 19:12:34 -0400 From: uri@watson.ibm.com Message-Id: <9408292312.AA18379@buoy.watson.ibm.com> Subject: Re: IVs, summary of discussion To: ho@cs.arizona.edu (Hilarie Orman) Date: Mon, 29 Aug 1994 19:12:25 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <199408292152.OAA15679@umbra.CS.Arizona.EDU> from "Hilarie Orman" at Aug 29, 94 02:52:12 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 358 Hilarie Orman says: > I'd like to vote against two trends here: ................. > and analyzing privacy and authentication as if they were totally > orthogonal. A quick example - one-time pad: perfect privacy, zero authentication. Need I say more? (:-) -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 30 00:15:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13513 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:38:43 -0400 Received: by interlock.ans.net id AA07202 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 19:15:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 29 Aug 1994 19:15:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 19:15:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 19:15:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 19:15:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 19:15:31 -0400 From: uri@watson.ibm.com Message-Id: <9408292315.AA18398@buoy.watson.ibm.com> Subject: Re: IVs, summary of discussion To: kent@BBN.COM (Steve Kent) Date: Mon, 29 Aug 1994 19:15:26 -0500 (EDT) Cc: karn@qualcomm.com, ipsec@ans.net In-Reply-To: <199408292218.AA21734@interlock.ans.net> from "Steve Kent" at Aug 29, 94 06:15:49 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 749 Steve Kent says: > In principle, I agree with your observations, i.e., encryption > need not confer authentication nor even be designed to support > authentication. The two are separable services (confidentiality and > integrity, really, with authentication a side effect of key management > for integrity). However, I do worry about users who don't appreciate > the difference selecting encryption only (because of a performance > concern) and being vulnerable to attacks that they didn't understand. Well, how about users whose applications are inherently resistent to integrity-violation attacks, and who consciously care only about privacy? -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 30 00:18:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16346 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 19:42:09 -0400 Received: by interlock.ans.net id AA15409 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 19:18:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 29 Aug 1994 19:18:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 29 Aug 1994 19:18:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 19:18:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 19:18:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 19:18:50 -0400 From: uri@watson.ibm.com Message-Id: <9408292318.AA17383@buoy.watson.ibm.com> Subject: Re: IVs, summary of discussion To: kent@BBN.COM (Steve Kent) Date: Mon, 29 Aug 1994 19:18:41 -0500 (EDT) Cc: crocker@tis.com, ipsec@ans.net In-Reply-To: <199408292238.AA21435@interlock.ans.net> from "Steve Kent" at Aug 29, 94 06:34:22 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 452 Steve Kent says: > The only > advantage to OFB is the option to precompute key stream, but on a > single processor machine that may not be much of an advantage. My experience with OFB on single-processor machine says the difference is noticeable, and definitely is enough of advantage to consider it. Note, that OFB was used on application level... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Tue Aug 30 01:40:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16806 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 22:03:32 -0400 Received: by interlock.ans.net id AA20310 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 21:39:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 21:39:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 21:39:55 -0400 Date: Mon, 29 Aug 1994 18:40:22 -0700 From: Phil Karn Message-Id: <199408300140.SAA22077@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: ipsec@ans.net In-Reply-To: <199408292152.OAA15679@umbra.CS.Arizona.EDU> (message from Hilarie Orman on Mon, 29 Aug 1994 14:52:12 -0700) Subject: Re: IVs, summary of discussion >I'd like to vote against two trends here: violating protocol layering >and analyzing privacy and authentication as if they were totally >orthogonal. Using the IP ID in IPSEC seems like a hack of such micro >advantage in its context as to approach silliness. And with regard to >the mix-n-match approach to encryption and authentication/integrity. I A similar but well-established layer-violating hack is the "pseudo-header" used to compute TCP and UDP checksums. An IPSEC that uses the ID field as an IV would hardly be unique -- existing transport protocols have the same property, and solutions will already have to be found to the IPv6 porting problem. Even if IPSEC didn't use the ID field, it would still need to know the sender's IP address since it is logically part of the security association identifier, just as the sender's IP address is part of a TCP or UDP connection identifier. Passing up IP addresses is arguably just as much a "layering violation" as passing up the IP ID for use as an IV. The only way around it would be to extend the 4-byte SAID field to make it globally unique, which is really not necessary. The "micro advantage" you speak of is the saving of overhead -- up to 8 bytes for DES depending on alignment considerations -- that would otherwise be needed to carry an explicit IV. This may not matter to some of you, but it does matter a lot to people like Ran and me who want to run this stuff over slow radio links -- where security is probably more urgent than on any other medium. I'm willing to add overhead if that's the only way I can get some sort of benefit, but not if there's another way to do the same exact thing for free. On the mix-and-match issue, nothing says we can't define each IPSEC "mode" as a combination of an encryption algorithm (e.g., DES CBC) and an authentication algorithm (e.g., keyed MD5). One of the nice things about the latter algorithm as opposed to relying on side effects of an encryption algorithm is that we can "tune" the authentication strength (and overhead) by simply sending as much or as little of the MD5 hash as desired. If you want something comparable to the 16-bit TCP header checksum, then you only need send and verify 2 bytes of the hash; if you want maximum protection, send all 16 bytes, or switch to SHA and send 20. Then the next question is whether we can agree on a "default" size for the authentication field that would satisfy enough users to make changing it (either bigger or smaller) a relatively unusual thing. Comments? Phil From ipsec-request@ans.net Tue Aug 30 02:52:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17706 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 23:13:00 -0400 Received: by interlock.ans.net id AA12666 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 22:52:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 29 Aug 1994 22:52:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 22:52:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 22:52:52 -0400 Date: Mon, 29 Aug 1994 19:52:45 -0700 From: Hilarie Orman Message-Id: <199408300252.TAA00993@umbra.CS.Arizona.EDU> To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Mymessage <199408300140.SAA22077@servo.qualcomm.com> Subject: Re: IVs, summary of discussion The IP pseudo hdr is unique and was always a bad idea. Perhaps I'm not considering the right set of numbers, but it seems that the 8 byte savings in transmission cost is swamped by the cost of security algorithms. I'm not arguing that privacy and authentication cannot be orthogonal, but I am saying that one cannot guarantee that they are without considering the entire protocol, including key management. From ipsec-request@ans.net Tue Aug 30 02:52:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14639 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 23:13:36 -0400 Received: by interlock.ans.net id AA07825 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 22:55:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 22:55:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 22:55:41 -0400 Date: Mon, 29 Aug 1994 19:52:39 -0700 From: Phil Karn Message-Id: <199408300252.TAA22181@servo.qualcomm.com> To: kent@BBN.COM Cc: crocker@tis.com, ipsec@ans.net In-Reply-To: <199408292238.AA21435@interlock.ans.net> (message from Steve Kent on Mon, 29 Aug 94 18:34:22 -0400) Subject: Re: IVs, summary of discussion >CFB-64), the data rates are all the same for these modes. The only >advantage to OFB is the option to precompute key stream, but on a >single processor machine that may not be much of an advantage. Next, Actually, my original reason for proposing the precomputed key stream was to reduce encryption latency on bursty, delay sensitive traffic like interactive telnet sessions. This would be an advantage on an underpowered, single processor machine. Hilarie Orman dissented, saying that the speed of encryption algorithms like DES should not be an issue. After bumming lots of cycles from my own DES code, I now pretty much agree with her -- DES speed may still be an issue for high speed file transfers, but it's not really a problem for interactive traffic, at least not on reasonably modern machines. But I wouldn't object to an option to support an OFB (or counter mode) encryption mode for those situations where latency (not throughput) is unusually critical. Phil From ipsec-request@ans.net Tue Aug 30 03:23:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14656 (5.65c/IDA-1.4.4 for ); Mon, 29 Aug 1994 23:43:43 -0400 Received: by interlock.ans.net id AA12429 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 29 Aug 1994 23:22:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Aug 1994 23:22:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Aug 1994 23:22:40 -0400 Date: Mon, 29 Aug 1994 20:23:19 -0700 From: Phil Karn Message-Id: <199408300323.UAA22235@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: ipsec@ans.net In-Reply-To: <199408300252.TAA00993@umbra.CS.Arizona.EDU> (message from Hilarie Orman on Mon, 29 Aug 1994 19:52:45 -0700) Subject: Re: IVs, summary of discussion >The IP pseudo hdr is unique and was always a bad idea. Perhaps it wasn't really necessary, but it hasn't really caused any damage either. Even without it you'd still have to pass the IP header addresses (and length, for TCP) up to the transport layer. The only thing missing from this set to form a pseudoheader is the IP protocol field, which is a well-known constant anyway. So the inter-layer communication requirements would be the same. >Perhaps I'm not considering the right set of numbers, but it seems >that the 8 byte savings in transmission cost is swamped by the cost of >security algorithms. Well, there's no "right" set of numbers, there are lots of different numbers, some of which are more important to some people than to others. Here are the numbers for me: DES encryption speed: 43,459 encryptions/sec (2.8 microseconds/byte) on a 486-50 in real mode Line transmission speed: 960 bytes/sec (1.04 ms/byte) over an IS-95 CDMA digital cellular channel. That's a 371:1 ratio between encryption speed and transmission speed. Sure, if you use a slow laptop instead of a desktop PC and a V.34 modem instead of a digital cell phone the ratio may decrease to, say, 50:1. And for Ran's channels I wouldn't be surprised if the ratio hit 1000:1. But I think you get my point. For me at least, encryption is cheap and transmission is expensive (I thought you were the one trying to convince me of this!) >I'm not arguing that privacy and authentication cannot be orthogonal, but >I am saying that one cannot guarantee that they are without considering >the entire protocol, including key management. On this point we agree. Phil From ipsec-request@ans.net Tue Aug 30 10:31:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15509 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 06:47:04 -0400 Received: by interlock.ans.net id AA21680 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 06:33:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 30 Aug 1994 06:33:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 06:33:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 06:33:01 -0400 Message-Id: <9408301031.AA26390@tis.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Mon, 29 Aug 94 18:34:22 EDT." <9408292245.AA09932@relay.tis.com> Date: Tue, 30 Aug 94 06:31:12 -0400 From: Stephen D Crocker With respect to using the TCP checksum, there's a possibility of confusion when an error occurs. Most TCP error handling code is likely tuned to treat checksum errors as acts of nature and not potential acts of malicious tampering. Steve From ipsec-request@ans.net Tue Aug 30 03:17:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16041 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 07:32:18 -0400 Received: by interlock.ans.net id AA20361 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 07:18:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 07:18:12 -0400 Message-Id: <199408301118.AA20357@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 07:18:12 -0400 To: Stephen D Crocker Cc: Steve Kent , ipsec@ans.net Subject: Re: IVs, summary of discussion Date: Tue, 30 Aug 94 07:17:09 EDT With respect to using the TCP checksum, there's a possibility of confusion when an error occurs. Most TCP error handling code is likely tuned to treat checksum errors as acts of nature and not potential acts of malicious tampering. But how would a cryptographic integrity check routine distinguish between enemy action and line noise? From ipsec-request@ans.net Tue Aug 30 09:46:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17515 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 09:46:12 -0400 Received: by interlock.ans.net id AA32858 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 09:31:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 30 Aug 1994 09:31:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 09:31:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 09:31:24 -0400 Date: Tue, 30 Aug 94 06:01:55 From: "Housley, Russ" Encoding: 1065 Text Message-Id: <9407307782.AA778251715@uu0892.spyrus.com> To: ipsec@ans.net Subject: Re: IVs, summary of discussion IPSECers: > So I take it that there's general agreement that Mode 1 encryption > (single key DES/CBC, as we've already discussed) can use the IPv4 ID > field as the IV? Remember that we intend this mode to be mandatory in > all IPSEC implementations to provide basic interoperability (only the > implementation is mandatory, not its actual use). So it's really > important that it not be too difficult to add to existing > implementations. > > Except, of course, that IPv6 doesn't have the id field. I would prefer one protocol data unit format that is appropriate for the use with IPv4 and IPv6. I understand Phil's overhead concerns, but I think that the mandatory option set must work in both IPv4 and IPv6. That said, I would prefer that the mandatory option set include the best possible security principles. After all, we are designing a security protocol. In some environments, less security may be traded off for improved performance, but in my opinion, less security should not be the default. Russ From ipsec-request@ans.net Tue Aug 30 13:56:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16738 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 10:12:14 -0400 Received: by interlock.ans.net id AA14164 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 09:57:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 09:57:35 -0400 Message-Id: <199408301357.AA20048@interlock.ans.net> To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Mon, 29 Aug 94 19:15:26 -0500. <9408292315.AA18398@buoy.watson.ibm.com> Date: Tue, 30 Aug 94 09:56:59 -0400 From: Steve Kent Uri, I agree that providing integrity protection along with encryption at layer 3 may be redundant for some applications. The concern is that users in general, and even many application developers, may not be well prepared to determine how well the interaction between lower layer crypto and their application layer integrity mechanisms serve to protect them. Steve From ipsec-request@ans.net Tue Aug 30 13:54:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05479 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 10:13:21 -0400 Received: by interlock.ans.net id AA03918 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 09:57:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 09:57:30 -0400 Message-Id: <199408301357.AA17994@interlock.ans.net> To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Mon, 29 Aug 94 19:18:41 -0500. <9408292318.AA17383@buoy.watson.ibm.com> Date: Tue, 30 Aug 94 09:54:19 -0400 From: Steve Kent Uri, Can you provide some more details about why OFB was faster (and how much so) in your experience on a single processor machine (vs. CBC)? Steve From ipsec-request@ans.net Tue Aug 30 14:28:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05463 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 10:53:26 -0400 Received: by interlock.ans.net id AA28287 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 10:32:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 10:32:50 -0400 Message-Id: <199408301432.AA13179@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Mon, 29 Aug 94 20:23:19 -0700. <199408300323.UAA22235@servo.qualcomm.com> Date: Tue, 30 Aug 94 10:28:36 -0400 From: Steve Kent Phil, I agree with your observation about the relative costs of encryption and header space, in the context of slow links. However, I agree with Hillarie about the IP pseudo header being a hack that, in hindsight, was a bad idea. One needs to pass up to higher layers the IP address, and option info relevant to those layers, and the offset into the buffer for the start of the next layer. But the pseudo checksum poses undue problems for the transition from IPv4 to v6. (Also, the IP address info is relevent PCI all the way up the stack, and does not constitute a layering violation.) Steve From ipsec-request@ans.net Tue Aug 30 14:32:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18416 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 10:56:20 -0400 Received: by interlock.ans.net id AA26780 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 10:34:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 10:34:44 -0400 Message-Id: <199408301434.AA04760@interlock.ans.net> To: Stephen D Crocker Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Tue, 30 Aug 94 06:31:12 -0400. <9408301031.AA26390@tis.com> Date: Tue, 30 Aug 94 10:32:43 -0400 From: Steve Kent Steve, You're right that a TCP checksum error is not viewed as a security violation per se. However, detecting an integrity check violation in IPSP only inducates the presence of an error, and doesn't say whether it's malicious or benign. The open question is whether someone who is concerned about responding differently to (or auditing) errors is willing to spend the extra overhead in space and the computational overhead rerquired to incorporate a separate integrity check. Steve From ipsec-request@ans.net Tue Aug 30 14:39:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05436 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 10:57:48 -0400 Received: by interlock.ans.net id AA13522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 10:41:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 30 Aug 1994 10:41:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 10:41:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 10:41:07 -0400 Message-Id: <9408301439.AA09599@tis.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Tue, 30 Aug 94 10:32:43 EDT." <9408301435.AA19693@relay.tis.com> Date: Tue, 30 Aug 94 10:39:27 -0400 From: Stephen D Crocker Steve K and Steve B, I agree with both of you. I was speculating that it's likely that present day implementations of TCP do not treat checksum errors as potentially caused by malice. Therefore, if we intend to depend on the TCP checksum to protect us against malicious errors, we probably have to review and perhaps modify the error handling. There's also a question of whether the checksum is strong enough. Steve From ipsec-request@ans.net Tue Aug 30 20:02:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18341 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 16:23:40 -0400 Received: by interlock.ans.net id AA17473 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 16:03:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 30 Aug 1994 16:03:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 30 Aug 1994 16:03:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 16:03:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 16:03:06 -0400 Date: Tue, 30 Aug 1994 13:02:40 -0700 From: Kelly.Goen@eng.sun.com (Kelly Goen [CONTRACTOR]) Message-Id: <199408302002.NAA01221@jurassic.Eng.Sun.COM> To: ipsec@ans.net Subject: subscribe X-Sun-Charset: US-ASCII subscribe From ipsec-request@ans.net Wed Aug 31 00:11:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17494 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 20:37:50 -0400 Received: by interlock.ans.net id AA28107 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 20:10:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 20:10:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 20:10:47 -0400 Date: Tue, 30 Aug 1994 17:11:28 -0700 From: Phil Karn Message-Id: <199408310011.RAA28937@servo.qualcomm.com> To: smb@research.att.com Cc: crocker@tis.com, kent@bbn.com, ipsec@ans.net In-Reply-To: <199408301118.AA20357@interlock.ans.net> (smb@research.att.com) Subject: Re: IVs, summary of discussion >But how would a cryptographic integrity check routine distinguish >between enemy action and line noise? Ideally, once strong authentication is deployed, integrity checks will fail only due to line noise because the enemy will be deterred from even trying. He would succeed only in revealing his presence. Ideally. Phil From ipsec-request@ans.net Wed Aug 31 00:28:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13326 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 20:49:57 -0400 Received: by interlock.ans.net id AA12102 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 20:27:33 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 20:27:33 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 20:27:33 -0400 Date: Tue, 30 Aug 1994 17:28:17 -0700 From: Phil Karn Message-Id: <199408310028.RAA28943@servo.qualcomm.com> To: housley@spyrus.com Cc: ipsec@ans.net In-Reply-To: <9407307782.AA778251715@uu0892.spyrus.com> (housley@spyrus.com) Subject: Re: IVs, summary of discussion >I would prefer one protocol data unit format that is appropriate for the >use with IPv4 and IPv6. I understand Phil's overhead concerns, but I think >that the mandatory option set must work in both IPv4 and IPv6. Once again, I don't know of any IPv4 transport protocol, existing or proposed, that won't require *some* changes to operate over IPv6. IPSEC won't be any worse. A totally interchangeable IPSEC is a chimera. >That said, I would prefer that the mandatory option set include the best >possible security principles. After all, we are designing a security >protocol. In some environments, less security may be traded off for >improved performance, but in my opinion, less security should not be the >default. "Best possible?" *Everything* in security is a tradeoff between security and performance, because security is never "perfect", nor is it ever "free". Example: all other things being equal, the longer an authentication sequence, the stronger the security provided. Keyed MD5 provides a 16 byte MAC. SHA provides 20. Why stop there? Why not 100-byte MACs? 200 bytes? Maybe this example is a little extreme, but it still supports my point. *Some* balance has to be struck between these mutually conflicting goals in any given situation, and I think it unlikely that any particular default we happen to pick in IPSEC is going to satisfy everybody. That's why things *must* be negotiable. That said, remember we are discussing one particular scheme that, although not perfect, should satisfy enough of the user population that we want to make it a mandatory part of the standard to guarantee at least some minimum degree of interoperability. Those who consider it inadequate can always negotiate something more to their liking. But for now I'd be happy if we can solve 90% of the need with 10% of the effort while leaving the door open for future improvements once we have some real experience. That philosophy has served the Internet very well in the past and I think it's just as applicable here. Phil From ipsec-request@ans.net Wed Aug 31 02:16:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17032 (5.65c/IDA-1.4.4 for ); Tue, 30 Aug 1994 21:32:36 -0400 Received: by interlock.ans.net id AA27987 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 21:17:58 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 21:17:58 -0400 From: Ran Atkinson Message-Id: <9408302116.ZM1407@sundance.itd.nrl.navy.mil> Date: Tue, 30 Aug 1994 21:16:23 -0500 In-Reply-To: Phil Karn "Re: IVs, summary of discussion" (Aug 30, 17:28) References: <199408310028.RAA28943@servo.qualcomm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: Re: IPsecv4 and IPsecv6 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil I think that it is completely unrealistic to think that a single packet format will work well for both IPv4 and IPv6. I don't think it is important if the two bit formats differ somewhat. I think it is important that the the services provided and external hooks (e.g. to key management) be the same. This is based on having a prototype IPv6 implementation that has been moving packets across an Ethernet since July. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Aug 30 03:21:30 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16949 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 00:15:42 -0400 Received: by interlock.ans.net id AA21696 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 30 Aug 1994 23:56:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 30 Aug 1994 23:56:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 30 Aug 1994 23:56:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 30 Aug 1994 23:56:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 30 Aug 1994 23:56:08 -0400 Date: Tue, 30 Aug 94 10:21:30 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408301721.AA06681@miraj.Eng.Sun.COM> To: uri@watson.ibm.com, kent@BBN.COM Subject: Re: IVs, summary of discussion Cc: ipsec@ans.net Content-Length: 781 >From: Steve Kent > >Uri, > > I agree that providing integrity protection along with >encryption at layer 3 may be redundant for some applications. The >concern is that users in general, and even many application >developers, may not be well prepared to determine how well the >interaction between lower layer crypto and their application layer >integrity mechanisms serve to protect them. Steve, Integrity protection may be worse than just redundant for some applications. It may actually be quite harmful to the useability of the application. Encrypted video is one example where the extra cost of computing an integrity check may well degrade the performance to below acceptable levels. Integrity protection on video is of extremely dubious value. Ashar. From ipsec-request@ans.net Wed Aug 31 12:04:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17885 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 08:21:58 -0400 Received: by interlock.ans.net id AA27370 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 08:05:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 08:05:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 08:05:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 08:05:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 08:05:36 -0400 Message-Id: <9408311204.AA14863@snark.imsi.com> To: Phil Karn Cc: housley@spyrus.com, ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of "Tue, 30 Aug 1994 17:28:17 PDT." <199408310028.RAA28943@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 31 Aug 1994 08:04:56 -0400 From: "Perry E. Metzger" Phil Karn says: > Once again, I don't know of any IPv4 transport protocol, existing or > proposed, that won't require *some* changes to operate over IPv6. > IPSEC won't be any worse. A totally interchangeable IPSEC is a > chimera. Perhaps true, but at the very least I'd like to specify both versions of the protocol from the start so that IPv6 implementation authors can get to work. It would be nice if there were no gratuitous differences, although differences based on real need are of course a different matter. Perry From ipsec-request@ans.net Wed Aug 31 14:04:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17756 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 10:11:45 -0400 Received: by interlock.ans.net id AA27253 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 09:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 09:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 09:57:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 09:57:47 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408310904.ZM17850@hughes.network.com> Date: Wed, 31 Aug 1994 09:04:21 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: IPsec@ans.net Subject: (Fwd) Authentication and encryption. Cc: Ken.Hardwick@nsco.network.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 To: Steve Kent , uri@watson.ibm.com I agree that encryption by itself does not create authentication. I agree that strong authentication is necessary for things like contract and other -non-reputable- applications. What I am curious about is the combination of -strong encryption is used over -some form of message integrity check to detect garbage being sent in. (Something much simpler than MD5.) If the encryption is strong and the probability of garbage passing the integrity check is low enough (2^-64 or less), then the knowledge of the shared secret should be authentication of the source. If one can prove that to create a valid integrity check one must calculate it against the data in the clear and prove that the attacker must know the key. If you know only the sender (and you) know the key, then authentication is proven. Why would this not be acceptable for general traffic authentication when the traffic is already being encrypted? jim From ipsec-request@ans.net Wed Aug 31 13:51:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16977 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 10:20:36 -0400 Received: by interlock.ans.net id AA22602 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 10:07:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 10:07:47 -0400 Message-Id: <199408311407.AA22850@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Tue, 30 Aug 94 17:11:28 -0700. <199408310011.RAA28937@servo.qualcomm.com> Date: Wed, 31 Aug 94 09:51:47 -0400 From: Steve Kent Phil, An attacker might still engage in modification attacks, depending on the response of the protocols (IPSP and higher layer protocols), to such attacks. In the ideal case, the protocols respond in a fashion that requires the attacker to continue the attack in order to effect denial of service. In that way, one can use fault isolation techniques to track down the attacks. However, protocols that "give up" too easily or that are unstable in terms of retransmission behavior may still be attractive targets for denial of service purposes. Steve From ipsec-request@ans.net Wed Aug 31 15:30:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15382 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 10:47:26 -0400 Received: by interlock.ans.net id AA13169 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 10:30:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 31 Aug 1994 10:30:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 10:30:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 10:30:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 10:30:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 10:30:16 -0400 From: uri@watson.ibm.com Message-Id: <9408311430.AA16317@buoy.watson.ibm.com> Subject: Re: (Fwd) Authentication and encryption. To: hughes@hughes.network.com (James P. Hughes) Date: Wed, 31 Aug 1994 10:30:13 -0500 (EDT) Cc: IPsec@ans.net, Ken.Hardwick@nsco.network.com In-Reply-To: <9408310904.ZM17850@hughes.network.com> from "James P. Hughes" at Aug 31, 94 09:04:21 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1213 James P. Hughes says: > I agree that encryption by itself does not create authentication. Good! Makes two of us (:-). > If the encryption is strong and the probability of garbage passing the > integrity check is low enough (2^-64 or less), > then the knowledge of the shared > secret should be authentication of the source. If one can prove > that to create > a valid integrity check one must calculate it against the data > in the clear and > prove that the attacker must know the key. If you know only the > sender (and > you) know the key, then authentication is proven. I don't think so, because smart attacker could devise methods to tamper with the data without disturbing a "normal" integrity check, designed to stop garbage (i.e. not a malicious attack). So it all boils back again to the issue of how smart an integrity check should be, and then - whether an application is wiling to accept that extra burden... > Why would this not be acceptable for general traffic authentication > when the traffic is already being encrypted? Because you don't know what the "real" data should decrypt into. -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Wed Aug 31 06:45:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17894 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 11:01:50 -0400 Received: by interlock.ans.net id AA13121 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 10:47:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 10:47:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 10:47:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 10:47:31 -0400 Date: Wed, 31 Aug 94 10:45:24 EDT From: Marcus J Ranum Message-Id: <9408311445.AA15860@tis.com> To: IPsec@ans.net, hughes@hughes.network.com Subject: Re: (Fwd) Authentication and encryption. Cc: Ken.Hardwick@nsco.network.com >I agree that strong authentication is necessary for things like contract and >other -non-reputable- applications. This kind of thing doesn't need to be at an IP layer, though. Contracts and whatnot are generally transactions that you're going to safe-store someplace. Once they're off the network, they'll still need signatures and integrity checks -- putting that stuff in the network for non-repudiation is a waste of time. From (loosely) following this discussion, it seems like there is a bit of a conflict over what is being intended to provide security, and where. Application level stuff is going to still be necessary. The network level stuff is nice also, but it's not possible to completely eliminate the need for application level signature and encryption. Trying to build network level security into something like PGP is not going to work; they're different animals. Perhaps I came into the picture too late, but it'd be nice to see a clear statement (is there one?) of the goals of this project. What is the level and type of threat that IPSEC is intended to protect against? Where does it fit within the complete spectrum of security solutions? From the discussion, I'd expect that the answers would range from something very completely engineered to something like simple link layer encryption. Anyone care to concisely state the security goals of this effort, and the threats it is being designed to resist? I suspect if we actually agree on what we're trying to do, the rest becomes a matter of implementation details. If we're agreed on the objective, then the number of bytes it takes to implement it becomes an implementation detail -- from the mail here, it seems like we're talking at 2 levels (grand design && implementation) and neither is showing any sympathy for the issues at the other. That's a recipe for disaster. mjr. From ipsec-request@ans.net Wed Aug 31 14:59:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15258 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 11:21:58 -0400 Received: by interlock.ans.net id AA06981 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 11:06:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 11:06:11 -0400 Message-Id: <199408311506.AA17985@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Tue, 30 Aug 94 17:28:17 -0700. <199408310028.RAA28943@servo.qualcomm.com> Date: Wed, 31 Aug 94 10:59:25 -0400 From: Steve Kent Phil, I agree that security is a matter of tradeoffs and, as you point out, the debate topic here is what constitutes "good enough" for most situations so as to make it the default operational mode for IPSP. Nonetheless, since what we are debating involves hard to quantify tradeoffs, it is reasonable for different folks to have different views abotu what constitutes the right balance. Your position is colored by a strong desire to reduce per-packet overhead so that low speed links are minimally affected. Others emphasize commonality of function between IPv4 and v6, protocol layering, or functional modularity. We need a list of the tradeoffs so that we can develop some concensus on relative importance, to guide these deliberations. Steve P.S. The Internet did not, in the good ole' days, adopt the philosophy you cited, and which seems to be cited fairly often these days. TCP, for example, goes to great lengths to support simultaneous opens by communicating peers, rather than adopting the X.25 approach of simultaneous calls setups failing. In practice, I suspect very, very few such opens every occur, especially because of the widespread use of well known ports and a client-server approach to application design. TCP also works hard to manage the sequence number space to reject duplicate packets in the face of late arrivals (though not malicious replays) and half-open connection attempts, another robustness feature that might not be needed to meet the 90% success criteria you and others cite. I think we should avoid the trap of possibily being "lazy" in addressing problems under the ruberic of "good enough for the Internet." From ipsec-request@ans.net Wed Aug 31 15:14:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05570 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 11:37:05 -0400 Received: by interlock.ans.net id AA22991 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 11:20:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 11:20:53 -0400 Message-Id: <199408311520.AA07883@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: IVs, summary of discussion In-Reply-To: Your message of Tue, 30 Aug 94 10:21:30 -0700. <9408301721.AA06681@miraj.Eng.Sun.COM> Date: Wed, 31 Aug 94 11:14:47 -0400 From: Steve Kent Ashar, The quote you cite from me is a bit out of context. We were discussing the use of error-propogating encryption modes as a basis for integrity checking, perhaps using whatever error detection facilities are already present in the transport protocol. I suspect the sort of integrity checks you are referring to arte ones that have relatively high per-bye costs, e.g., a one-way hash functions. One might argue that a suitable encryption mode will provide enough unpredictable error propogation as to allow existing integrityu checks to operate in an environment that is pretty much equivalent to the benign environment for which these integrity checks were designed. I gave the use of the existing TCP chceksum as an example. This is clearly not as effective as using a larger and more powerful integrity check algorithm, but it might represent a reasonable compromise. You have made a good point of why an application such a broadcast packet video may be one where the use of a stream cipher is critical for performance. If the cipher has good error propogation qualities, then the criteria I noted above is met. Alternatively, if this packet format and compression algorithm are presumed to be immune to effective, real-time manipulation by an attacker with an ability to modify individual bits of the underlying plaintext in a controlled fashion, then you're OK anyway. Steve From ipsec-request@ans.net Wed Aug 31 15:44:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16154 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 11:55:15 -0400 Received: by interlock.ans.net id AA02995 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 11:38:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 11:38:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 11:38:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 11:38:11 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408311044.ZM18109@hughes.network.com> Date: Wed, 31 Aug 1994 10:44:38 -0500 In-Reply-To: uri@watson.ibm.com "Re: (Fwd) Authentication and encryption." (Aug 31, 10:30am) References: <9408311430.AA16317@buoy.watson.ibm.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: uri@watson.ibm.com Subject: Re: (Fwd) Authentication and encryption. Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 > I don't think so because smart attacker could devise methods to > tamper with the data without disturbing a "normal" integrity check, > designed to stop garbage (i.e. not a malicious attack). The CRC under the encryption is not a "normal" integrity check. "Normal" integrity checks are over the entire encrypted packet and protect the data from random noise. i.e. CRC32 on Ethernet. Is it your assertion that "that the attacker must know the key" to reliabily change the data can not be proven? jim From ipsec-request@ans.net Wed Aug 31 12:20:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15377 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 12:20:18 -0400 Received: by interlock.ans.net id AA23083 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 12:06:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-6); Wed, 31 Aug 1994 12:06:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 31 Aug 1994 12:06:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 12:06:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 12:06:17 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 12:06:17 -0400 Message-Id: <9408311858.AA0908@watlny03.watson.ibm.com> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 12:06:17 -0400 To: ipsec From: Mark H Linehan/Watson/IBM Research Date: 31 Aug 94 11:52:38 ES Subject: IPSEC requirements Mime-Version: 1.0 Content-Type: Text/Plain I agree that we need a real statement of requirements for IP level security. Here's my attempt: - We need authentication of message sources (i.e. of the IP source address & related information) so that firewall routers can filter packets based on source addresses. I think this is the only requirement that really MUST be addressed at the IP level. - We need message confidentiality (encryption) for those situations where the communicating parties want to keep their messages private. Examples are many corporate environments. This function can be provided at the application level (e.g. by PEM, etc.) with the advantage that applications can selectively apply encryption where it's really needed. The reason for providing confidentiality at the IP level is that many apps don't implement any kind of encryption. Performing encryption at the IP level gives a blanket guarantee that all packets are private. - We need message integrity (i.e. a guarantee that no bits in a packet have been changed) for the same reasons that we need message confidentiality. The three requirements are orthogonal. Since each function involves some cost, there should be some way to configure which functions are implemented for each communicating pair of hosts. From ipsec-request@ans.net Wed Aug 31 16:23:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16807 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 12:40:21 -0400 Received: by interlock.ans.net id AA20239 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 12:28:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 12:28:03 -0400 Message-Id: <199408311628.AA20235@interlock.ans.net> To: "James P. Hughes" Cc: ipsec@ans.net Subject: Re: (Fwd) Authentication and encryption. In-Reply-To: Your message of Wed, 31 Aug 94 10:44:38 -0500. <9408311044.ZM18109@hughes.network.com> Date: Wed, 31 Aug 94 12:23:12 -0400 From: Steve Kent Jim, I think what Uri may have had in mind was someting like the TCP checksum. In the IPSP model, that checksum would be computed on plaintext and then the checksum and the plaintext on which it was computed would be encrypted. If one used OFB encryption, an attacker could easily modify the ciphertext in a fashion that the resulting plaintext changes would be invarient under the checksum. However, use of an encryption mode such as CBC makes this sort of attack more diffcult (if the attacker doesn't posses the key). Steve From ipsec-request@ans.net Wed Aug 31 18:12:37 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15360 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 13:27:14 -0400 Received: by interlock.ans.net id AA19375 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 13:12:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 31 Aug 1994 13:12:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 13:12:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 13:12:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 13:12:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 13:12:41 -0400 From: uri@watson.ibm.com Message-Id: <9408311712.AA20849@buoy.watson.ibm.com> Subject: Re: (Fwd) Authentication and encryption. To: hughes@hughes.network.com (James P. Hughes) Date: Wed, 31 Aug 1994 13:12:37 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <9408311044.ZM18109@hughes.network.com> from "James P. Hughes" at Aug 31, 94 10:44:38 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1227 James P. Hughes says: > The CRC under the encryption is not a "normal" integrity check. "Normal" > integrity checks are over the entire encrypted packet and protect the > data from random noise. i.e. CRC32 on Ethernet. Again, I don't want to spend too much time/efforts on exploring this. My "feeling" is - that without ASSumptions about method and mode of encryption one can't reliably ASSume anything about integrity checks done even on cleartext prior to encryption, because there can be ways to modify the data without it being detected by that integrity check (and without disturbing the encryption, of course :-). > Is it your assertion that "that the attacker must know the key" to reliabily > change the data can not be proven? I'm not sure I understand what you mean - but I'll answer anyway (:-). Not only it can't be proven, but I think it's outright wrong in general. There are integrity checks that are expensive and secure, and there are ones that are cheap and "breakable". Some encryption modes/methods can vouch for data integrity (to some extent - I don't want to dive into this now) and some can NOT... -- Regards, Uri uri@watson.ibm.com acheron!angmar!uri N2RIU ----------- From ipsec-request@ans.net Wed Aug 31 19:06:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14505 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 15:35:34 -0400 Received: by interlock.ans.net id AA16227 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 15:10:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 15:10:49 -0400 Message-Id: <199408311910.AA16219@interlock.ans.net> To: Mark H Linehan/Watson/IBM Research Cc: ipsec Subject: Re: IPSEC requirements In-Reply-To: Your message of 31 Aug 94 11:52:38 +0600. <9408311858.AA0908@watlny03.watson.ibm.com> Date: Wed, 31 Aug 94 15:06:08 -0400 From: Steve Kent Mark, Although one can provide confidentiality at the application layer, there are many good reasons for providing it at the network layer, not just its lack of availability in current applications, which motivate development of IPSP. Similar arguments apply for integrity. Autehntication may be a various levels of granularity, not just IP addresses, and is needed not just for firewalls, but implicitly for applications/users who want to know with whom they are communicating. One might provide authentication at the granularity of individual IP addresses, subnets, protocol type, TCP port pairs (ouch, layer violation!), etc. Steve From ipsec-request@ans.net Wed Aug 31 16:49:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05623 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 16:49:11 -0400 Received: by interlock.ans.net id AA02952 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 16:33:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-6); Wed, 31 Aug 1994 16:33:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 31 Aug 1994 16:33:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 16:33:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 16:33:15 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 16:33:15 -0400 Message-Id: <9408312326.AA1115@watlny03.watson.ibm.com> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 16:33:15 -0400 To: Steve Kent Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 31 Aug 94 16:06:50 ES Subject: IPSEC requirements Mime-Version: 1.0 Content-Type: Text/Plain I agree with your additional reasons; I stand by my belief that there are 3 basic and orthogonal requirements. I think IPSEC should provide a way to mix & match solutions to these three requirements. I think IPSEC should specify one mandatory mechanism for each of the three requirements (to support interoperability) and should allow implementations to add other mechanisms (to allow implementors to search for good balances between cost, performance, and function). From ipsec-request@ans.net Wed Aug 31 07:05:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15595 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 17:18:09 -0400 Received: by interlock.ans.net id AA32058 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 17:05:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 31 Aug 1994 17:05:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 17:05:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 17:05:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 17:05:24 -0400 Date: Wed, 31 Aug 94 14:05:43 PDT From: ashar@firstperson.com (Ashar Aziz) Message-Id: <9408312105.AA07500@miraj.Eng.Sun.COM> To: kent@BBN.COM Subject: Re: IVs, summary of discussion Cc: ipsec@ans.net Content-Length: 837 >From ipsec-request@ans.net Wed Aug 31 08:40:34 1994 > You have made a good point of why an application such a >broadcast packet video may be one where the use of a stream cipher is >critical for performance. If the cipher has good error propogation >qualities, then the criteria I noted above is met. Alternatively, if >this packet format and compression algorithm are presumed to be immune >to effective, real-time manipulation by an attacker with an ability to >modify individual bits of the underlying plaintext in a controlled >fashion, then you're OK anyway. Yes, I think we are in agreement. I want to be able to use a stream cipher, which has no error propagation, for encrypted video and I dont want to have to compute separate integrity checks like one-way hash functions, for precisely the reason you cite above. Ashar. From ipsec-request@ans.net Wed Aug 31 23:28:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07530 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 19:29:09 -0400 Received: by interlock.ans.net id AA22946 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 31 Aug 1994 19:21:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 31 Aug 1994 19:21:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 31 Aug 1994 19:21:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 31 Aug 1994 19:21:31 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9408311828.ZM757@hughes.network.com> Date: Wed, 31 Aug 1994 18:28:00 -0500 In-Reply-To: uri@watson.ibm.com "Re: (Fwd) Authentication and encryption." (Aug 31, 1:12pm) References: <9408311712.AA20849@buoy.watson.ibm.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: uri@watson.ibm.com, hughes@hughes.network.com (James P. Hughes) Subject: Re: (Fwd) Authentication and encryption. Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 31, 1:12pm, uri@watson.ibm.com wrote: > Some encryption modes/methods can vouch for data integrity (to some > extent - I don't want to dive into this now) and some can NOT... We are in agreement. Thank you. jim