From ipsec-request@ans.net Wed Feb 1 02:05:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21739 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 21:15:55 -0500 Received: by interlock.ans.net id AA58586 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 21:05:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 31 Jan 1995 21:05:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 31 Jan 1995 21:05:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 21:05:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 21:05:33 -0500 Message-Id: <9502010205.AA25932@snark.imsi.com> To: smb@research.att.com Cc: ipsec@ans.net Subject: How to authenticate ESP (was risks of MACs) In-Reply-To: Your message of "Tue, 31 Jan 1995 20:05:32 EST." <199502010109.AA28305@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 31 Jan 1995 21:05:20 -0500 From: "Perry E. Metzger" smb@research.att.com says: > But even if computation is the same, unencyrpting and then > authenticating is at least a factor of two more work. > > That's far from clear to me. If both the plaintext and the checksum are > encrypted, you can probably use a much weaker algorithm than a cryptographic > hash function, I'd think. Or am I missing some attacks? Yes; Colin noted that you can do bit-flipping attacks against CRCs, for instance, that are quite effective if you have access to a DES IV or if the cipher is something like DES-OFB or RC4. Right now, I'm still wondering which of two approaches to take in my next draft: 1) compress the AH and ESP together under a single ESP SAID; you end up with something like (using MD5 and 3DES for example)... [IP Header][SAID][keyed MD5 of whole (encrypted) packet][3DES protected area] 2) place an ordinary cryptographic hash of the invariant parts pre-encryption packet (unkeyed or keyed? unkeyed means brute force attackers get an automated way to know when they are right, but the TCP/UCP checksum probably gives them that anyway) inside the protected area, i.e. [IP Header][SAID][[MD5 Hash] 3DES Protected Area] Opinions, folks? Speed is pretty similar in both cases, the first does a keyed checksum which is (very slightly) slower; the second has more to DES. If the second is done unkeyed, the first requires more keying material. The second may save some bytes of padding in architectures that need padding when SHA or similar algorithms are in use. Frankly, I don't have enough of a reason to pick one over the other to write a document immediately without some comment. Any ideas, folks? PLEASE? (Yes, I know we came up with some answers in San Jose, but we had virtually no discussion about it or thought on the matter... I think the question is harder than we made it out to be.) Perry From ipsec-request@ans.net Tue Jan 31 18:44:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17722 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 06:03:42 -0500 Received: by interlock.ans.net id AA54359 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 05:46:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 05:46:59 -0500 To: perry@imsi.com Cc: smb@research.att.com, ipsec@ans.net In-Reply-To: <9502010205.AA25932@snark.imsi.com> (perry@imsi.com) Subject: Re: How to authenticate ESP (was risks of MACs) X-Signed: PGP-Detached-2-3, iQBXAwUBLy9mBNC3U5sdKpFdAQG5eAIMCuFGp/QGEyV160Yb+zkDA2lusYQVDpnl QKWF9MpDAKYcdoW4D6BgaRBckTub4t7wUAg+ocJyrWaDxk1xluNUP4Gl Date: Wed, 1 Feb 95 2:44:36 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9502010244.aa00668@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. : Date: Tue, 31 Jan 1995 21:05:20 -0500 : From: "Perry E. Metzger" : : Right now, I'm still wondering which of two approaches to take in my : next draft: : : 1) [IP Header][SAID][keyed MD5 of whole (encrypted) packet][3DES protected] : : 2) [IP Header][SAID][[MD5 Hash] 3DES Protected] : : Opinions, folks? : Perry Since both aproaches are 'generic' the time till all the documents are done is about the same. But the second has the potential advantage of being faster. (Only for carefully chosen pairs like .). It has the potential disadvantage of being in-effective (Bit flipping attacks on ). j' From ipsec-request@ans.net Wed Feb 1 14:03:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22681 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 10:04:05 -0500 Received: by interlock.ans.net id AA43198 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 09:53:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 09:53:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 09:53:25 -0500 Date: Wed, 1 Feb 95 14:03:34 GMT From: "William Allen Simpson" Message-Id: <3845.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: How to authenticate ESP > From: jpp@markv.com > : From: "Perry E. Metzger" > : > : Right now, I'm still wondering which of two approaches to take in my > : next draft: > : > : 1) [IP Header][SAID][keyed MD5 of whole (encrypted) packet][3DES protected] > : > : 2) [IP Header][SAID][[MD5 Hash] 3DES Protected] > : > But the second has the potential advantage of being faster. (Only for > carefully chosen pairs like > .). It has the potential disadvantage of > being in-effective (Bit flipping attacks on ). > I read the comments about the bit flipping, and as I said, that scenario is not particularly valid. A CRC will always detect bit changes if you stay within its Hamming distance. The difficulty of doing this is practically the same as the likelihood of doing it with a cryptographic hash. The algorithm is known for both. An encrypted CRC (covering the plaintext) at the _end_ will not even be findable by the attacker to decide if s/he was successful. No, the only concern that I have is Phil's desire to have a "lightweight" method of tossing packets before going to the trouble of decrypting. I don't hear anyone else who wants to do that. Seems people want to do authentication and encryption in parallel. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Feb 1 15:33:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12558 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 10:48:25 -0500 Received: by interlock.ans.net id AA29067 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 10:36:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 10:36:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 10:36:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 10:36:42 -0500 Message-Id: <9502011533.AA05798@skidrow.tay.dec.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: How to authenticate ESP (was risks of MACs) In-Reply-To: Your message of "Tue, 31 Jan 95 21:05:20 EST." <9502010205.AA25932@snark.imsi.com> Date: Wed, 01 Feb 95 10:33:54 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I'm in favor of approach 1. It may require more key material in the case where the hash in unkeyed in approach 2 but it is at least some faster and permits the possibility of entities that can authenticate but read read packets. (Yes, for keyed MD5 that means they can forge authentic packets but can't set the unencrypted data from them. But this is not true for some other possible authentication means and, in any case, their might be entities you would trust that far.) Donald From: "Perry E. Metzger" To: smb@research.att.com Cc: ipsec@ans.net In-Reply-To: Your message of "Tue, 31 Jan 1995 20:05:32 EST." <199502010109.AA28305@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission > >smb@research.att.com says: >> But even if computation is the same, unencyrpting and then >> authenticating is at least a factor of two more work. >> >> That's far from clear to me. If both the plaintext and the checksum are >> encrypted, you can probably use a much weaker algorithm than a cryptographic >> hash function, I'd think. Or am I missing some attacks? > >Yes; Colin noted that you can do bit-flipping attacks against CRCs, >for instance, that are quite effective if you have access to a DES IV >or if the cipher is something like DES-OFB or RC4. > >Right now, I'm still wondering which of two approaches to take in my >next draft: > >1) compress the AH and ESP together under a single ESP SAID; you end > up with something like (using MD5 and 3DES for example)... > >[IP Header][SAID][keyed MD5 of whole (encrypted) packet][3DES protected area] > >2) place an ordinary cryptographic hash of the invariant parts > pre-encryption packet (unkeyed or keyed? unkeyed means brute force > attackers get an automated way to know when they are right, but the > TCP/UCP checksum probably gives them that anyway) inside the protected > area, i.e. > >[IP Header][SAID][[MD5 Hash] 3DES Protected Area] > >Opinions, folks? Speed is pretty similar in both cases, the first does >a keyed checksum which is (very slightly) slower; the second has more >to DES. If the second is done unkeyed, the first requires more keying >material. The second may save some bytes of padding in architectures >that need padding when SHA or similar algorithms are in use. > >Frankly, I don't have enough of a reason to pick one over the other to >write a document immediately without some comment. > >Any ideas, folks? PLEASE? > >(Yes, I know we came up with some answers in San Jose, but we had >virtually no discussion about it or thought on the matter... I think >the question is harder than we made it out to be.) > >Perry From ipsec-request@ans.net Wed Feb 1 18:48:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23430 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 15:38:28 -0500 Received: by interlock.ans.net id AA23551 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 15:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 15:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 15:23:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 15:23:14 -0500 Message-Id: <199502011848.NAA00085@dolphin.zoo.att.com> From: Steve Bellovin To: ipsec@ans.net Subject: a missing piece Date: Wed, 01 Feb 1995 13:48:12 -0500 Sender: smb@research.att.com The IPv6 security protocols are supposed to work host to host or gateway to gateway. But we haven't specified a protocol for hosts to use to specify to their security gateways (by which do not necessarily mean firewalls) what security services are desired. Similarly, we need a protocol -- an IPv6 header, to be more precise -- by which the security gateway can (over a nominally-trusted wire) what security services were in effect for received packets. The former is rather reminiscent of the IP security label option, though I won't call it such for fear of reopening a can of worms; the latter has some tricky aspects, such as stripping out bogus incoming security service headers and dealing with IP within IP. --Steve Bellovin From ipsec-request@ans.net Wed Feb 1 16:16:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19588 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 15:38:27 -0500 Received: by interlock.ans.net id AA08455 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 15:23:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 15:23:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 15:23:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 15:23:31 -0500 Message-Id: <199502011616.LAA00121@dolphin.zoo.att.com> From: Steve Bellovin To: danmcd@itd.nrl.navy.mil Subject: Draft IPv6 Security API for BSD Sockets Cc: ipsec@ans.net Date: Wed, 01 Feb 1995 11:16:37 -0500 Sender: smb@research.att.com I'm not very happy with some aspects of the draft. My two main areas of concern are the nature of the interface and the error-reporting mechanisms proposed. The latter is easier to explain. I don't think that, in general, it's at all a good idea to send errors to a security-aware application simply because bogus (or damaged) packets are received. If nothing else, it opens us up to easy denial of service attacks -- an attacker can spew out bogus packets, he or she can cause these sessions to abort. While security error statistics should be maintained, certainly on a system- wide basis and probably on a per-SAID or per-connection basis, it isn't at all clear to me that most applications -- even security-aware ones -- need to be told about these at all times. I'd suggest a more tunable approach -- the process specifies a threshold, which defaults to infinity, for errors; when the the threshold is exceeded, a process-specified signal (or maybe SIGSECURITY or SIGHACK) could be raised. My problem with the mechanisms for specifying security levels is that I think the proposal is too low-level. It isn't clear to me that setsockopt() is the best way to proceed. I'd rather see a more POSIX-like approach, where a subroutine interface is used. Thus, instead of saying setsockopt(fd, IP_SECLEVEL, ...), a process would say setsecuritylevel(fd, ...). There are two advantages to this approach. First, it's more portable to other architectures than a straight 4.2bsd-like socket interface. A streams-based TCP would have more trouble with a setsockopt, since stream modules are much more isolated than is a monolithic Berkeley- type kernel. This becomes more apparent when we look at the next requirement, which is mentioned in the draft: per-user SAIDs. My mental model for this function is a Kerberos-like interface. (There's a lot more involved in doing it right than just Kerberos, but I won't go into that now.) The user process obtains some credentials for a connection; these credentials are bound to a pair of SAIDs, one for each end. These credentials must then be passed to the kernel for use with one or more IP connections. But obtaining these authorizations is not something that's easily done in the kernel. A Berkeley-like kernel could, in principle, contact a credentials daemon on behalf of the current user, if no explicit credentials are supplied; that's much harder with streams, since a streams module does not have access to the user's u. or proc structures, and cannot easily sleep(). Note that my model supports host-pair SAID granularity as well. When the setsecuritylevel() call is done, if no suitable SAID exists, the subroutine can initiate negotiations, using whatever privileged components are available. If the system supports user-level granularity, then the existing user-level Kerberos tickets are used. But that's transparent to the user, though we'd probably want a getpeerprincipal() call. I'm rambling a bit, and I'm probably not being very clear. I'd like to hear other comments. --Steve Bellovin From ipsec-request@ans.net Wed Feb 1 21:45:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21008 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 17:01:10 -0500 Received: by interlock.ans.net id AA56504 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 16:46:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Feb 1995 16:46:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 16:46:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 16:46:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 16:46:26 -0500 Message-Id: <9502012145.AA27613@snark.imsi.com> To: Steve Bellovin Cc: danmcd@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: Draft IPv6 Security API for BSD Sockets In-Reply-To: Your message of "Wed, 01 Feb 1995 11:16:37 EST." <199502011616.LAA00121@dolphin.zoo.att.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 01 Feb 1995 16:45:11 -0500 From: "Perry E. Metzger" Steve Bellovin says: > I'm not very happy with some aspects of the draft. Nor am I, as an implementer, frankly. At this point, I've been ignoring the suggested API for my IPv4 code and I'm still experimenting with what seems right. > The latter is easier to explain. I don't think that, in general, > it's at all a good idea to send errors to a security-aware application > simply because bogus (or damaged) packets are received. Nor do I; my current design makes reporting of such things the responsibility of system-wide security services and takes away the task of dealing with them from applications entirely. > I'd suggest a more tunable approach -- the > process specifies a threshold, which defaults to infinity, for > errors; when the the threshold is exceeded, a process-specified > signal (or maybe SIGSECURITY or SIGHACK) could be raised. Frankly, I'd prefer to leave this to a security daemon and (indirectly) to the syslog facility. Applications are rarely if ever in a good position to deal with such things, and its rare that such a thing is something that the application cares about more intimately than system administration. Also, putting this in application-land means that you end up with dozens of different tuning mechanisms for such reporting. I'd rather have it in just one place so the system administrator might actually be able to make use of the data! > My problem with the mechanisms for specifying security levels is that > I think the proposal is too low-level. It isn't clear to me that > setsockopt() is the best way to proceed. At the moment, I'm still experimenting with what seems best for this. Whatever I choose is going to end up wrapped inside a library call anyway, so I'm somewhat agnostic as to the specific method. Beyond this, however... > This becomes more apparent when we look at the next > requirement, which is mentioned in the draft: per-user SAIDs. > > My mental model for this function is a Kerberos-like interface. (There's > a lot more involved in doing it right than just Kerberos, but I won't > go into that now.) The user process obtains some credentials for > a connection; these credentials are bound to a pair of SAIDs, one for > each end. These credentials must then be passed to the kernel for > use with one or more IP connections. But obtaining these authorizations > is not something that's easily done in the kernel. A Berkeley-like > kernel could, in principle, contact a credentials daemon on behalf > of the current user, if no explicit credentials are supplied; that's > much harder with streams, since a streams module does not have access > to the user's u. or proc structures, and cannot easily sleep(). My design uses a credentials & key negotiation daemon that establishes kernel security association structures at the request of an application -- it then passes these structures to the application via the same mechanism currently used to pass file descriptors among unrelated processes. This allows the mechanism to leave the structure completely opaque to the normal user process but allows the key daemon to arbitrarily fiddle with the innards of the association. My objective is quite explicitly to permit IPSP to be used in a very kerberos-like manner. > Note that my model supports host-pair SAID granularity as well. Same here. > I'm rambling a bit, and I'm probably not being very clear. I'd like > to hear other comments. The stuff you are discussing thus far is very reminiscent in certain ways of what I've already decided on for my prototype, so I'm obviously not going to argue too strenuously. The need to support per-socket SAIDs is clear; it is also necessary to permit the tagging of routes with SAIDs to set up secure tunnels. Perry From ipsec-request@ans.net Wed Feb 1 17:29:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14645 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 17:29:47 -0500 Received: by interlock.ans.net id AA32991 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 17:11:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 17:11:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 17:11:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 17:11:47 -0500 Date: Wed, 01 Feb 95 13:42:18 From: "Housley, Russ" Encoding: 330 Text Message-Id: <9501017916.AA791674938@spysouth.spyrus.com> To: ipsec@ans.net Subject: SHA-1 IPSECers: We just ran some independent tests with our SHA-1 implemntation. We ran 10,000,000 bytes through the hash function. On a 486/66 PC, we got around 160,000 bytes/sec. On a Sun SPARC20 (single CPU), we got around 2,070,000 bytes/sec. In both cases, the code was compiled with speed optimization on. Russ From ipsec-request@ans.net Wed Feb 1 22:34:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18265 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 17:56:10 -0500 Received: by interlock.ans.net id AA09671 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 17:35:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 17:35:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 17:35:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 17:35:36 -0500 Message-Id: <9502012234.AA14748@skidrow.tay.dec.com> To: Steve Bellovin Cc: ipsec@ans.net Subject: Re: a missing piece In-Reply-To: Your message of "Wed, 01 Feb 95 13:48:12 EST." <199502011848.NAA00085@dolphin.zoo.att.com> Date: Wed, 01 Feb 95 17:34:32 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Steve Bellovin To: ipsec@ans.net Sender: smb@research.att.com >The IPv6 security protocols are supposed to work host to host or >gateway to gateway. But we haven't specified a protocol for hosts >to use to specify to their security gateways (by which do not necessarily >mean firewalls) what security services are desired. Similarly, we I think that if an end node is trusted to request security when it is needed, then it could almost always provide the security. The vast majority of gateway to gateway cases will be imposed by administrative policy rather than trusted an end node to request services, although there should certainly be provivison for that. There is also the case of end and gateway talking to each other... >need a protocol -- an IPv6 header, to be more precise -- by which >the security gateway can (over a nominally-trusted wire) what security >services were in effect for received packets. The former is rather >reminiscent of the IP security label option, though I won't call it >such for fear of reopening a can of worms; the latter has some tricky >aspects, such as stripping out bogus incoming security service headers >and dealing with IP within IP. I agree here. > --Steve Bellovin Donald From ipsec-request@ans.net Wed Feb 1 23:42:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18665 (5.65c/IDA-1.4.4 for ); Wed, 1 Feb 1995 18:53:00 -0500 Received: by interlock.ans.net id AA49234 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Feb 1995 18:42:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 1 Feb 1995 18:42:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Feb 1995 18:42:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Feb 1995 18:42:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Feb 1995 18:42:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Feb 1995 18:42:17 -0500 From: uri@watson.ibm.com Message-Id: <9502012342.AA23670@buoy.watson.ibm.com> Subject: Re: SHA-1 To: rhousley@spyrus.com (Housley, Russ) Date: Wed, 1 Feb 1995 18:42:11 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9501017916.AA791674938@spysouth.spyrus.com> from "Housley, Russ" at Feb 1, 95 01:42:18 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: 796 Housley, Russ says: > We just ran some independent tests with our SHA-1 implemntation. We ran > 10,000,000 bytes through the hash function. On a 486/66 PC, we got around > 160,000 bytes/sec. On a Sun SPARC20 (single CPU), we got around 2,070,000 > bytes/sec. In both cases, the code was compiled with speed optimization on. How did you measure the time, if I may ask? I measured CPU time (tms_utime, as a matter of fact) and got about 940,000 bytes/sec on 486DX2/50. Using GCC with "-O6 -m486 -fomit-frame-pointer". Obviously our results don't match - I'd like to find out whether my numbers are goofed, or yours. Oh, and I ran SHS-1 over 1,000 blocks of 10,000 bytes, which should be similar to what you did. -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Thu Feb 2 18:19:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14488 (5.65c/IDA-1.4.4 for ); Thu, 2 Feb 1995 13:25:26 -0500 Received: by interlock.ans.net id AA37572 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Feb 1995 13:19:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Feb 1995 13:19:29 -0500 Message-Id: Date: Thu, 2 Feb 95 18:19 GMT From: iialan@iifeak.swan.ac.uk (Alan Cox) To: ipsec@ans.net Subject: draft-metzger-ah-00.txt IPv4 Authentication Header (4AH) draft-metzger-ah-00.txt The Authentication Header (AH) seeks to provide security by adding authentication information to an IP datagram. The authentication information is calculated using all of the fields in the IP datagram which do not change in transit. This includes portions of the IP Header, transport headers, and the user data. This isn't clear about IP options. Clearly some options are not invariant and some are. Should this be read as including IP options that are invariant but not those which are not (time stamp). Second comment: Its probably worth noting with respect to packet filtering firewalls that most of them will need additional code to understand the extra header. What is good is that it can be done easily without performing the authentication, or can be done including the authentication if one side of the firewall is a 'trusted' net. Third: I'm told Novell now have a patent on packet signing. Does it cover this area and if so what now ? In the meantime I've started a Linux implementation of the draft. Alan From ipsec-request@ans.net Thu Feb 2 19:05:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22868 (5.65c/IDA-1.4.4 for ); Thu, 2 Feb 1995 14:11:43 -0500 Received: by interlock.ans.net id AA13022 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Feb 1995 14:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 2 Feb 1995 14:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Feb 1995 14:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Feb 1995 14:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Feb 1995 14:07:40 -0500 Message-Id: <9502021905.AA29275@snark.imsi.com> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: ipsec@ans.net Subject: Re: draft-metzger-ah-00.txt In-Reply-To: Your message of "Thu, 02 Feb 1995 18:19:00 GMT." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 02 Feb 1995 14:05:47 -0500 From: "Perry E. Metzger" Alan Cox says: > Third: > I'm told Novell now have a patent on packet signing. Does it cover > this area and if so what now ? They have an invalid patent -- a clearly, obviously, and completely invalid patent. There is plenty of prior art that is in writing from over one year before the date of their application. They did not, not, not invent the idea of keyed hashes, which existed for a very long time. I intend to ignore the patent, as do others that I have spoken to. If Novell wishes to, they may contact my attorneys. This is perhaps an agressive stance to take, but I'm very confident in my position. Perry From ipsec-request@ans.net Thu Feb 2 21:34:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24011 (5.65c/IDA-1.4.4 for ); Thu, 2 Feb 1995 16:41:35 -0500 Received: by interlock.ans.net id AA53470 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Feb 1995 16:36:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 2 Feb 1995 16:36:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Feb 1995 16:36:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Feb 1995 16:36:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Feb 1995 16:36:18 -0500 Date: Thu, 2 Feb 1995 13:34:10 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502022134.AA28042@miraj.> To: ipsec@ans.net Subject: comments on Photuris X-Sun-Charset: US-ASCII Here are some comments on the key-management aspects of Photuris. Phil and I have already discussed, but it's probably useful to present these comments to the list. Although it is possible to easily deal with some of the issues that are raised, section B is probably the greatest concern. Regards, Ashar. ---------------------------------------------------------------- Photuris uses the "sign your own exponential only" version of authenticated DH exchange. Presumably this was done in order to allow the signatures to be precomputed, thereby speeding up the realtime aspects of the protocol. This message is focused on the potential vulnerabilities of such a scheme. These are as follows. A - Insecure combination of signature and hash algorithm If the signature scheme is RSA, and the signature hash function is the identity function then an intruder can mount an impersonation attack as follows; The intruder chooses as her secret DH exponent the value 0, therefore the intruder's public DH value is g^0 = 1. The exchanged key is g^(0*y), which is 1, independent of y. In order to pass the authentication phase the intruder needs the signed value of the sender's public DH exponent, encrypted in the current session key, call it Ks. We represent this as, {Sender_Signed(Sender's DH exponent)}Ks where Ks is g^xy If the signing function is the primitive RSA signature (P^d mod n), then the intruder can calculate this encrypted signature without knowing the impersonated party's secret RSA exponent d as follows; {Sender_Signed(Sender's DH exponent)}Ks = {Sender_Signed(1)}1 = {1^d mod n}1 = {1}1 Since (1^d mod n) is 1 independent of d, then all the intruder needs to do is compute the encryption of 1 using the key 1 to pass the authentication phase, which she can do. Note that since the size of the signed quantity is approximately the same as the size of an RSA signature block, it's not obvious that non-identity hashing is required. Choosing a non-indentity hash function or non RSA signature for signing can defeat this attack. B - Knowing combination of {x, g^x, Signed(g^x)} allows impersonation This illustrates a general weakness of the "sign only your own exponential" approach. If the intruder can compute (or obtain) a valid signature of a quantity whose discrete log it can compute (or obtain) in advance, then she can mount an impersonation attack. A seemingly inocuous way of doing this might be: Intruder asks the party she wants to impersonate to sign the value g (the generator of GF(p)) so that she can be sure of what the generator is. This might seem harmless enough that a party may actually sign g. However, by obtaining signed g the intruder has now obtained the following tuple {1, g^1, Signed(g^1)}. The intruder can now impersonate the party who signed g by choosing 1 as her secret exponent when participating in a key-exchange. There may also be other (harder to detect) ways of obtaining signatures in advance over quantities whose discrete logs are known. Once a signature is obtained, it can used and reused (forever) to impersonate the party whose signature was obtained. This attack is independent of the signature algorithm used. Also, this does not require obtaining a signature on some unpredictable quantity in real time, which is much harder. This can all be done in advance. C - Known key attacks Should a party ever learn the other side's secret DH exponent after a successful key exchange, she can then impersonate that party because she now knows {x, g^x, Signed(g^x)}. It's not immediately obvious that one should never reveal the secret DH exponent in an exchange even to an authorized party, because it may appear that all the secret exponent allows one to do is compute g^xy which the connecting party already knows. However, in this case, knowing x and the other information one learns in a succesful run of the protocol allows an intruder to later impersonate who she connected to. The above vulnerability is described in "Authentication and Authenticated Key Exchanges", by Diffie, Van Oorschot and Wiener, in "Designs, Codes and Cryptography", 1992, Kluwer Academic Publishers. The STS protocol described in this paper shows how to remove this vulnerability by including in the signature the other party's public DH value, which makes all these attacks infeasible. This is because now an adversary has to produce in realtime a signature over an unpredictable quantity (because the other party's public DH value is unpredictable). Unfortunately, this modification to the protocol also makes signature precomputation infeasible. D - Requirement for Authentication-Only version of protocol If one is not performing encryption, but instead is doing authentication only, then it is a requirement to check the authenticity of the IP packet that contains the signed DH public value. Checking the signature of the signed DH value alone is not enough, as both the public DH value and its signed version may be played back from an earlier run with the real party. Assuming that the intruder did not learn the other side's secret exponent in the earlier run would mean that the intruder cannot actually compute the session key, and therefore would not be able to authenticate the IP packets, even though she can provide a properly signed public DH value. Failing to check the authenticity of the packet would mean that the authentication phase would pass with the intruder. (Although the intruder would not be able to produce authenticated IP packets). From ipsec-request@ans.net Thu Feb 2 12:26:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05606 (5.65c/IDA-1.4.4 for ); Thu, 2 Feb 1995 17:31:14 -0500 Received: by interlock.ans.net id AA58809 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Feb 1995 17:27:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Feb 1995 17:27:01 -0500 Message-Id: <199502022226.AA15797@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Feb 1995 17:27:01 -0500 Date: Thu, 2 Feb 95 17:26:54 EST From: hugo@watson.ibm.com To: perry@imsi.com, smb@research.att.com Cc: ipsec@ans.net Subject: How to authenticate ESP (was risks of MACs) >1)[IP Header][SAID][keyed MD5 of whole (encrypted) packet][3DES protected area] > >2)[IP Header][SAID][[MD5 Hash] 3DES Protected Area] I, too, vote for option 1. Few reasons: * Security. Option 1 is more secure (modulo unknown weaknesses of key-ed MD5). Using independent keys for authentication and encryption is the right approach as learned from many failures caused by trying to "save" the authentication key (See, e.g., the papers by Jueneman, Matyas and Meyer, "Message Authentication", IEEE Comm. Magazine, Vol 23, No.9, 9/85, pp. 29-40, and the more recent by Stubblebine and Gligor in Oakland Conference, 1992.) * Independence of functions. One can independently change the specific encryption and authentication functions in option 1, while in option 2 it requires a re-analysis of interaction between the two functions (e.g. if one changes the CBC to stream-cipher mode, the authentication in option 1 is completely lost, at least, against known plaintext; BTW, even if you encrypt your payload there may be somebody that legitimately knows the contents but is still interested to attack the authentication). Moreover, * Dependence of authentication on encryption strength. WHile in the above particular proposal (example?) by Perry strong encryption is used, 3DES, people may use the same scheme (for compatibility) even when applying less secure ciphers (for efficiency, export restrictions, etc). It is not a good idea to reduce the strength of the authentication (e.g. 128 bits) to that of encryption (e.g., 56 bits) as it happens in option 2. * Option 1 is more robust. In option 2 (regular MD5 hash encrypted), if the authenticator is moved to the end of the information (which is desirable if you can perform encryption and authentication in parallel, e.g. in h/w), then the scheme is susceptible to attacks that do not (necessarily) apply when the authenticator is positioned at the beginning. * Option 1 has the advantage, if MD5 applied to the ciphertext, of checking integrity before doing decryption (as noticed by many before). On the other hand, by applying the authentication to the plaintext one gets assurance of correct decryption. Hugo From ipsec-request@ans.net Thu Feb 2 12:36:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14707 (5.65c/IDA-1.4.4 for ); Thu, 2 Feb 1995 17:39:25 -0500 Received: by interlock.ans.net id AA48871 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Feb 1995 17:36:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Feb 1995 17:36:29 -0500 Message-Id: <199502022236.AA43491@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Feb 1995 17:36:29 -0500 Date: Thu, 2 Feb 95 17:36:25 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: 64 vs 80 bit strength Several messages in the last days suggested the need for SHA instead of MD5 based on the arguments of 128 vs. 160 length (or 64 vs. 80 bit strength), as well as for recent works (most notably, van Oorschot and Wiener in Fairfax'94) attacking MD5 with better success than SHA. These considerations are important for judging these functions as collision-free (or collision intractable) hash functions, for which these functions were designed. However, they are mostly irrelevant for the use of these functions as keyed-authenticators (when used with PREpended key) as is the case in IPSP. In particular, the (straightforward) birthday attack that gives a strength of 80 bits to SHA and 64 to MD5 is irrelevant. As authentication functions the finding of collisions via birthday attacks is immaterial. Same as for buliding Van-OOrshot/Weiner machine. This is not to suggest that, for example, MD5 is better than SHA. It is just to emphasize that we lack any good analysis of these functions as keyed-authentication, and their quality as collision-intactable is not the right measure to accept any of them, or to prefer one to the other. (True, is the only measure cryptanalysts have seriously studied). Hugo From ipsec-request@ans.net Sat Feb 4 10:14:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15839 (5.65c/IDA-1.4.4 for ); Sat, 4 Feb 1995 08:49:19 -0500 Received: by interlock.ans.net id AA27285 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 4 Feb 1995 08:44:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 4 Feb 1995 08:44:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 4 Feb 1995 08:44:26 -0500 Date: Sat, 4 Feb 95 10:14:42 GMT From: "William Allen Simpson" Message-Id: <3871.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: comments on Photuris > From: ashar@osmosys.incog.com (Ashar Aziz) > Photuris uses the "sign your own exponential only" version of > authenticated DH exchange. Presumably this was done in order to > allow the signatures to be precomputed, thereby speeding up the > realtime aspects of the protocol. This message is focused on > the potential vulnerabilities of such a scheme. > Pre-computation is an important feature of Photuris. > Although it is possible to easily deal with some of the issues > that are raised, section B is probably the greatest concern. > > A - Insecure combination of signature and hash algorithm > > The intruder chooses as her secret DH exponent the value 0, therefore > the intruder's public DH value is g^0 = 1. The exchanged key is > g^(0*y), which is 1, independent of y. > So? Value 0 is simply disallowed. A pretty easy check. A good thing to add to the proposal. > B - Knowing combination of {x, g^x, Signed(g^x)} allows impersonation > > This might seem harmless enough that a party may actually sign > g. However, by obtaining signed g the intruder has now obtained the > following tuple {1, g^1, Signed(g^1)}. The intruder can now > impersonate the party who signed g by choosing 1 as her > secret exponent when participating in a key-exchange. > OK. Value 1 is also disallowed. Straight-forward arithmetic so far. > C - Known key attacks > > Should a party ever learn the other side's secret DH exponent > after a successful key exchange, she can then impersonate that party > because she now knows {x, g^x, Signed(g^x)}. > > It's not immediately obvious that one should never reveal the > secret DH exponent in an exchange even to an authorized party, > because it may appear that all the secret exponent allows one to > do is compute g^xy which the connecting party already knows. > Seems obvious enough to me. And Photuris explicitly periodically destroys old secrets. That perfect forward secrecy that we've been talking about for some time.... > D - Requirement for Authentication-Only version of protocol > > If one is not performing encryption, but instead is doing authentication > only, then it is a requirement to check the authenticity of the IP > packet that contains the signed DH public value. Checking the signature > of the signed DH value alone is not enough, as both the public DH value > and its signed version may be played back from an earlier run with > the real party. > This one makes no sense to me. How do you "check" the authenticity of the IP packet? Moreover, the current draft _requires_ encryption in the final step. Since this is encryption for authentication purposes, there is no export restriction, hence no "requirement for Authentication-Only". Anyway, these are all pretty trivial, but probably should be included in the next draft. Thanks. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Feb 4 05:25:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14891 (5.65c/IDA-1.4.4 for ); Sat, 4 Feb 1995 14:28:33 -0500 Received: by interlock.ans.net id AA20895 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 4 Feb 1995 14:25:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 4 Feb 1995 14:25:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 4 Feb 1995 14:25:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 4 Feb 1995 14:25:30 -0500 Date: Sat, 4 Feb 95 12:25:15 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9502041925.AA26174@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: ipsec@ans.net Subject: Re: risks of MACs associated with packets wrote: > That's far from clear to me. If both the plaintext and the checksum are > encrypted, you can probably use a much weaker algorithm than a cryptographic > hash function, I'd think. Or am I missing some attacks? If the check is a CRC, the patterns which can be XORed into a valid message to produce a valid message are easily derivable. If using a stream cipher, you can XOR a known pattern into the (unknown) plaintext easily. It can even be done to some degree with CBC and CFB chaining. (You can do a controlled XOR for one cipher block.) It can be done, but you need to be careful. -- -Colin From ipsec-request@ans.net Mon Feb 6 23:04:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15321 (5.65c/IDA-1.4.4 for ); Mon, 6 Feb 1995 18:39:40 -0500 Received: by interlock.ans.net id AA21264 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Feb 1995 18:07:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Feb 1995 18:07:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Feb 1995 18:07:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Feb 1995 18:07:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Feb 1995 18:07:01 -0500 Date: Mon, 6 Feb 1995 15:04:42 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502062304.AA29895@miraj.> To: bill.simpson@um.cc.umich.edu Subject: Re: comments on Photuris Cc: ipsec@ans.net X-Sun-Charset: US-ASCII >From: "William Allen Simpson" > So? Value 0 is simply disallowed. A pretty easy check. > ... > OK. Value 1 is also disallowed. Straight-forward arithmetic so far. While special purpose checks may prevent some of the scenarios I described, I think it is a bad idea to proceed with a protocol that permits the kinds of scenarios that were described in my message. Here are two examples of why special purpose checks may not always work. First. Suppose adversary picks random x, computes g^x enough times so that it looks like the format of an RSA public key. She then presents this g^x to the party she wishes to impersonate, requesting that that the party act as "introducer" for her "RSA public key" (read g^x) by signing it. The introducer may ask for identification etc. and check the hash of the key, as may be the norm for that party. Once party signs the "RSA public key", intruder now has the tuple {x, g^x, Signed(g^x)} and can therefore impersonate the introducer. This now is a completely random x, and cannot be special purpose checked. Second. Intruder picks as her personal prime a Pohlig-Hellman-weak prime for which discrete logs are feasible. She presents this to party she wishes to impersonate by initiating a Photuris key exchange, along with a public DH value computed using the weak prime. The responding party then provides its public DH value g^x computed using the same weak prime, and then follows by providing Signed(g^x) value over the encrypted channel. All intruder now needs to do afterwards (at her leisure) is to compute the discrete log of the responding party's public DH value to know x and thereby {x, g^x, Signed(g^x)}, after which she can safely impersonate the responding party. This is possible because PH-weak primes were used. This points to another problem with the protocol. It is unwise to allow the use of unauthenticated primes, which may not have the property one requires for a DH exchange. Photuris allows the initiator to pick her own primes. In order to rely on the believed intractability of the DH problem, it must be ensured that suitable DH parameters are in fact used. This is especially unwise when one is relying on the party who picks the prime not to be able to compute discrete logs over that prime field. (Real time checking of strong primality is not practical). Fundamentally, the notion that an adversary can plan successful attacks in advance (as shown above) is disturbing. A widely used protocol must not allow such freedom to the adversary where it becomes increasingly difficult to safeguard against all such attacks. Kind regards, Ashar. From ipsec-request@ans.net Tue Feb 7 00:40:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16793 (5.65c/IDA-1.4.4 for ); Mon, 6 Feb 1995 19:44:31 -0500 Received: by interlock.ans.net id AA15303 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Feb 1995 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Feb 1995 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Feb 1995 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Feb 1995 19:41:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Feb 1995 19:41:42 -0500 Message-Id: <9502070040.AA06229@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: comments on Photuris In-Reply-To: Your message of "Mon, 06 Feb 1995 15:04:42 PST." <9502062304.AA29895@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 06 Feb 1995 19:40:06 -0500 From: "Perry E. Metzger" Ashar Aziz says: > >From: "William Allen Simpson" > > So? Value 0 is simply disallowed. A pretty easy check. > > ... > > OK. Value 1 is also disallowed. Straight-forward arithmetic so far. > > While special purpose checks may prevent some of the scenarios I > described, I think it is a bad idea to proceed with a protocol that > permits the kinds of scenarios that were described in my message. DES, 3DES, IDEA and most other conventional ciphers I know of have weak keys. I say we abandon conventional ciphers! Seriously, though, bounds checking is needed almost whatever one does. > Here are two examples of why special purpose checks may > not always work. > > First. Suppose adversary picks random x, computes g^x enough times > so that it looks like the format of an RSA public key. It can't. The magic numbers on the data won't be the same in practice. No one was proposing "naked" keys and g^xes you know. > She then presents this g^x to the party she wishes to impersonate, > requesting that that the party act as "introducer" for her "RSA > public key" (read g^x) by signing it. What they could get you to sign would be a formatted data structure containing an RSA key, not just some raw RSA key, so the attack isn't feasable. > Second. Intruder picks as her personal prime a Pohlig-Hellman-weak prime for > which discrete logs are feasible. She presents this to party she > wishes to impersonate by initiating a Photuris key exchange, along > with a public DH value computed using the weak prime. The responding > party then provides its public DH value g^x computed using the same weak > prime, and then follows by providing Signed(g^x) value over the encrypted > channel. > > All intruder now needs to do afterwards (at her leisure) is to compute > the discrete log of the responding party's public DH value to know x > and thereby {x, g^x, Signed(g^x)}, after which she can safely impersonate the > responding party. This is a more serious objection. I would suggest that we can avoid this either by specifying the primes used in the algorithm or by making the protocol more interactive. Perry From ipsec-request@ans.net Tue Feb 7 06:59:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20060 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 02:08:18 -0500 Received: by interlock.ans.net id AA27337 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 02:00:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 02:00:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 02:00:52 -0500 Date: Mon, 6 Feb 1995 22:59:20 -0800 From: Phil Karn Message-Id: <199502070659.WAA13113@servo.qualcomm.com> To: dee@skidrow.tay.dec.com Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <9502011533.AA05798@skidrow.tay.dec.com> (dee@skidrow.tay.dec.com) Subject: Re: How to authenticate ESP (was risks of MACs) >I'm in favor of approach 1. It may require more key material in the >case where the hash in unkeyed in approach 2 but it is at least some >faster and permits the possibility of entities that can authenticate >but read read packets. (Yes, for keyed MD5 that means they can forge >authentic packets but can't set the unencrypted data from them. But >this is not true for some other possible authentication means and, in >any case, their might be entities you would trust that far.) If you wanted an entity that could verify the authenticity of a packet without being able to read the contents, wouldn't it make more sense to run two nested IPSP associations, one for encryption that runs end-to-end and another for authentication only that runs, e.g, between two routers? My original reason for this approach is just as Bill stated. I wanted to make it as difficult as possible to sabotage with bogus traffic, and I can't think of any other reasons other than to make the code more modular. Doing authentication outside of encryption does assume things about the relative CPU complexity of authentication and encryption, and these can change over time. But it does seem likely that MD5-like functions will remain faster than DES-like functions for some time. Phil From ipsec-request@ans.net Tue Feb 7 13:04:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14634 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 08:10:31 -0500 Received: by interlock.ans.net id AA40004 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 08:04:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 7 Feb 1995 08:04:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Feb 1995 08:04:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 08:04:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 08:04:37 -0500 Message-Id: <9502071304.AA06876@snark.imsi.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re: How to authenticate ESP (was risks of MACs) In-Reply-To: Your message of "Mon, 06 Feb 1995 22:59:20 PST." <199502070659.WAA13113@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Feb 1995 08:04:28 -0500 From: "Perry E. Metzger" Phil Karn says: > If you wanted an entity that could verify the authenticity of a packet > without being able to read the contents, wouldn't it make more sense > to run two nested IPSP associations, one for encryption that runs > end-to-end and another for authentication only that runs, e.g, between > two routers? Of course -- but thats a different problem. I'm just trying to define transforms for combining authentication and encryption from one endpoint to the other. Perry From ipsec-request@ans.net Tue Feb 7 18:29:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05444 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 13:39:52 -0500 Received: by interlock.ans.net id AA28872 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 7 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 13:31:39 -0500 Date: Tue, 7 Feb 1995 10:29:24 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502071829.AA00288@miraj.> To: perry@imsi.com Subject: Re: comments on Photuris Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Mon Feb 6 17:17 PST 1995 > >While special purpose checks may prevent some of the scenarios I > >described, I think it is a bad idea to proceed with a protocol that > >permits the kinds of scenarios that were described in my message. > > DES, 3DES, IDEA and most other conventional ciphers I know of have weak > keys. I say we abandon conventional ciphers! > > Seriously, though, bounds checking is needed almost whatever one does. I think you misunderstood my intent. What I was trying to say was that these special cases were the symptom of a larger problem. The larger problem is that if an adversary can steal one single signature over a quantity whose discrete log it knows or can compute, (in the format that the protocol expects) then this is catastrophic to the protocol, because it allows umlimited impersonation thereafter. This is a very dangerous edge to be sitting on. Regards, Ashar. From ipsec-request@ans.net Tue Feb 7 18:40:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14499 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 13:46:20 -0500 Received: by interlock.ans.net id AA59014 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 13:41:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 7 Feb 1995 13:41:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Feb 1995 13:41:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 13:41:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 13:41:57 -0500 Message-Id: <9502071840.AA08654@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: comments on Photuris In-Reply-To: Your message of "Tue, 07 Feb 1995 10:29:24 PST." <9502071829.AA00288@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Feb 1995 13:40:16 -0500 From: "Perry E. Metzger" Ashar Aziz says: > I think you misunderstood my intent. What I was trying to say was that > these special cases were the symptom of a larger problem. The larger > problem is that if an adversary can steal one single signature > over a quantity whose discrete log it knows or can compute, (in > the format that the protocol expects) then this is catastrophic to > the protocol, because it allows umlimited impersonation thereafter. I think I've solved this problem. Here is my strawman: In Phil's algorithm, instead of signing the D-H components g^x'es directly, all that is needed is to sign a hash of the g^x concatenated with the "name" (to be defined in a moment) of the entity that I intend to authenticate with. The "name" should be a unique identifier of the party I anticipate communicating with. By hashing the two together, I prevent the replay of the signed g^x with another counterparty -- at most I can impersonate the signer in communicating with myself, which is useless. Perry From ipsec-request@ans.net Tue Feb 7 10:37:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19996 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 15:49:39 -0500 Received: by interlock.ans.net id AA57121 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 15:37:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 15:37:44 -0500 Message-Id: <199502072037.AA03357@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 15:37:44 -0500 Date: Tue, 7 Feb 95 15:37:39 EST From: hugo@watson.ibm.com To: perry@imsi.com, karn@qualcomm.com, IPSEC@ans.net, ashar@osmosys.incog.com Subject: comments on Photuris Ref: Your note of Tue, 07 Feb 1995 13:40:16 -0500 (attached) Perry, Phil, Ashar and others: I completely support the concerns expressed by Ashar about the potential vulnerabilities of "replayable signatures" as appear in the current Photuris draft. I hope Phil agrees with this and will reflect it in the next version. Indeed, freshness of authentication is a basic principle for sound cryptographic protocols and its absence a great invitation to trouble. Beyond the scenarios presented by Ashar, Photuris itself indirectly presents a similar concern when saying that: A background process can periodically destroy the old values, generate a new random secret, and recalculate the public DH part and the RSA signature. This limits the exposure of the secret, as past secrets are not kept for possible discovery by a future intrusion, protecting earlier communications. Also, the secret currently in use is less likely to be anticipated, as the element of random timing is introduced. Phil here is concerned about secrecy and then is careful enough to destroy values that live for too long by fear of intrusion. However, for replaying a signature the intruder does not care if the triple (x,g^x,sig(g^x)) is used or not by the legal guy. Once she found these values the adversary can use them as much as she wants to impersonate the attacked party. (Even if the private key is perfectly protected!). As for Perry's comment: > > I think I've solved this problem. Here is my strawman: > > In Phil's algorithm, instead of signing the D-H components g^x'es > directly, all that is needed is to sign a hash of the g^x concatenated > with the "name" (to be defined in a moment) of the entity that I > intend to authenticate with. > > The "name" should be a unique identifier of the party I anticipate > communicating with. By hashing the two together, I prevent the replay > of the signed g^x with another counterparty -- at most I can > impersonate the signer in communicating with myself, which is useless. > > Perry This is a step in the right direction. Now the exposure of this signature will only allow the intruder to impersonate that particular party whose name appears in the signature. But not a good enough solution. The right way to guarantee freshness is by nonces (challenge/response). In the case of Photuris the challenges could be exchanged with the cookies. Unfortunately, this prevents pre-computation. Nonetheless, notice that when you communicate to somebody with whom you already have communicated before and can keep a state for this party, then the nonces can be exchanged at the end of the previous key exchange round. This is especially suitable when the parties periodically exchange a new key. This approach is used in MKMP and very applicable here. In this way the parties have the time between two exchanges to prepare their exponentiations and signatures. BTW, the solution suggested by Perry has another problem. You shouldn't be signing the identity of the party you talk to. This could be used later to *prove* that you talked to that party. This unintentonal (or enforced) use of non-repudiation is a severe privacy concern (in some cases even more significant that anonymity protection a la Photuris). The last remark needs to be considered in Photuris and any other design that uses (non-repudable) signatures. Hugo From ipsec-request@ans.net Tue Feb 7 20:44:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14414 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 15:53:10 -0500 Received: by interlock.ans.net id AA40870 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 15:45:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 7 Feb 1995 15:45:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Feb 1995 15:45:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 15:45:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 15:45:27 -0500 Message-Id: <9502072044.AA08844@snark.imsi.com> To: hugo@watson.ibm.com Cc: karn@qualcomm.com, ipsec@ans.net Subject: Re: comments on Photuris In-Reply-To: Your message of "Tue, 07 Feb 1995 15:37:39 EST." <199502072037.PAA08516@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Feb 1995 15:44:57 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > This is a step in the right direction. Now the exposure of this signature > will only allow the intruder to impersonate that particular party whose name > appears in the signature. No -- it only allows the exposure to impersonate the party TO the party who's name appears in the signature, which means that at best that party can impersonate the other party to themselves -- a dubious accomplishment at best. > The right way to guarantee freshness is by nonces (challenge/response). Well, this is certainly *a* way to guarantee it. I'll point out, though, that if you aren't careful you can use nonces to play man-in-the-middle; you have to compound the nonce with the D-H key. > Nonetheless, notice that when you communicate to somebody with whom > you already have communicated before and can keep a state for this > party, then the nonces can be exchanged at the end of the previous > key exchange round. True enough; rekeying can make use of such mechanisms. > BTW, the solution suggested by Perry has another problem. You shouldn't be > signing the identity of the party you talk to. This could be used later > to *prove* that you talked to that party. That is certainly true as well. Perhaps another possibility is simply somehow setting the protocol up to help to guarantee that the D-H primes are strong. Perry From ipsec-request@ans.net Tue Feb 7 10:55:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22860 (5.65c/IDA-1.4.4 for ); Tue, 7 Feb 1995 16:11:05 -0500 Received: by interlock.ans.net id AA57251 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Feb 1995 15:56:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Feb 1995 15:56:21 -0500 Message-Id: <199502072055.AA22685@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Feb 1995 15:56:21 -0500 Date: Tue, 7 Feb 95 15:55:48 EST From: hugo@watson.ibm.com To: perry@imsi.com Cc: karn@qualcomm.com, ipsec@ans.net Subject: comments on Photuris Ref: Your note of Tue, 07 Feb 1995 15:44:57 -0500 (attached) > No -- it only allows the exposure to impersonate the party TO the > party who's name appears in the signature, which means that at best Of course. This is what I meant (and not what I wrote - sorry). This attack looks bad enough to me. > Well, this is certainly *a* way to guarantee it. I'll point out, > though, that if you aren't careful you can use nonces to play > man-in-the-middle; you have to compound the nonce with the D-H key. I definitely mean that. The signature will contain both the nonce AND the g^x (btw, the g^x sent from A to B can also be used as a challenge from A to B). > > > Nonetheless, notice that when you communicate to somebody with whom > > you already have communicated before and can keep a state for this > > party, then the nonces can be exchanged at the end of the previous > > key exchange round. > > True enough; rekeying can make use of such mechanisms. > > > BTW, the solution suggested by Perry has another problem. You shouldn't be > > signing the identity of the party you talk to. This couldrrepused later > > to *prove* that you talked to that party. > > That is certainly true as well. > > Perhaps another possibility is simply somehow setting the protocol up > to help to guarantee that the D-H primes are strong. > This only helps with some of the attacks outlined by Ashar but not against occasional intruders (which are motivated to break-in depending on the potential gain. A good protocol minimizes such a gain). Hugo From ipsec-request@ans.net Wed Feb 8 19:53:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20256 (5.65c/IDA-1.4.4 for ); Wed, 8 Feb 1995 15:19:22 -0500 Received: by interlock.ans.net id AA16659 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 8 Feb 1995 14:55:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 8 Feb 1995 14:55:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 8 Feb 1995 14:55:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 8 Feb 1995 14:55:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 8 Feb 1995 14:55:49 -0500 Date: Wed, 8 Feb 1995 11:53:34 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502081953.AA00731@miraj.> To: ipsec@ans.net Subject: Re: comments on Photuris X-Sun-Charset: US-ASCII >From: "Perry E. Metzger" > No -- it only allows the exposure to impersonate the party TO the > party who's name appears in the signature, which means that at best > that party can impersonate the other party to themselves -- a dubious > accomplishment at best. I am not convinced that this is the case. You haven't really described how the protocol would ensure that the party attempting to connect to you is really who they claim to be, *prior* to providing the signature of g^x and the name of the connecting party. That is, what prevents me from claiming to be the party who I intend to attack as you, getting your signature on g^x and that party's name, and then later providing the site under attack with (x, g^x, Signed(g^x, attack site's name))? (Where x is obtained by one of the several scenarios outlined earlier). Furthermore, including in the signature the name of the party makes precomputation far less feasible, since you dont know in advance all the parties you are going to talk to. (By contrast g^x and Signed(g^x) are all purely random, and dont bear any relationship with who you might communicate with in the future). Regards, Ashar. From ipsec-request@ans.net Thu Feb 9 12:34:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15673 (5.65c/IDA-1.4.4 for ); Thu, 9 Feb 1995 06:41:17 -0500 Received: by interlock.ans.net id AA08328 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 9 Feb 1995 06:34:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 9 Feb 1995 06:34:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 9 Feb 1995 06:34:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 9 Feb 1995 06:34:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 9 Feb 1995 06:34:57 -0500 Message-Id: <9502091149.AB06576@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Feb 1995 06:34:37 -0600 To: ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Hello? I sent a subscription to this list back on 1/31. I have not received a registration notification or any messages from the list. Is the list totally quite or did the list operator drop my subscription in a bit bucket somewhere. I have some questions on the IPSP drafts and would like to understand the difference between DES and DES-CBC, ie do they require different hardware engines? So in any messages, please include my EMail in a CC until I get this access straightened out! Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Feb 9 11:36:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13627 (5.65c/IDA-1.4.4 for ); Thu, 9 Feb 1995 06:41:17 -0500 Received: by interlock.ans.net id AA31874 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 9 Feb 1995 06:34:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 9 Feb 1995 06:34:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 9 Feb 1995 06:34:50 -0500 Date: Thu, 9 Feb 1995 03:36:41 -0800 From: Phil Karn Message-Id: <199502091136.DAA05394@unix.ka9q.ampr.org> To: perry@imsi.com Cc: ashar@osmosys.incog.com, ipsec@ans.net In-Reply-To: <9502071840.AA08654@snark.imsi.com> (perry@imsi.com) Reply-To: karn@qualcomm.com Subject: Re: comments on Photuris I was out sick last week and am now catching up on the discussion. Although Ashar does have some valid points, several of his arguments are against straw men in my opinion. For example, his assumption of the identity function as the hash when signing. Tricking people into signing arbitrary things of the attacker's choosing is a well-known vulnerability of RSA and other digital signature algorithms. And this is easily avoided: you never sign anything directly, you always sign its crypto hash instead. Ashar's most valid objection involves the provision for arbitrary values of g and p in the protocol. I put that feature in because it seems to fit the well-accepted Internet practice of always leaving yourself an escape hatch. One countermeasure is to require that if you do accept an arbitrary {g,p} tuple from someone else, you generate a unique random exponent just for that transaction. But the vulnerability is serious enough that I would now recommend that we limit ourselves to a pre-published list of {g,p} tuples. We could start by standardizing a single value of p that's 1024 bits long and add other lengths (e.g., 512 or 768 bits) later as desired. All standard published p's would be strong primes, which everyone would be free to verify for him/herself. Of course, limiting the protocol to a small, standard list of generators and moduli also simplifies the protocol considerably and increases the opportunity to precompute stuff, which I still think has considerable practical appeal. And I still think that the best countermeasure to all of the attacks that Amir has talked about is to keep generating new random exponents early and often to limit the exposure of any one exponent. Again, precomputation of the public component and the signature helps make this tolerable in practice. More later when I've caught up some more. Phil From ipsec-request@ans.net Thu Feb 9 16:10:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20717 (5.65c/IDA-1.4.4 for ); Thu, 9 Feb 1995 11:27:39 -0500 Received: by interlock.ans.net id AA49505 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 9 Feb 1995 11:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 9 Feb 1995 11:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 9 Feb 1995 11:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 9 Feb 1995 11:14:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 9 Feb 1995 11:14:05 -0500 Message-Id: <9502091610.AA11726@snark.imsi.com> To: rgm3@is.chrysler.com (Robert Moskowitz) Cc: ipsec@ans.net Subject: Re: Hello? In-Reply-To: Your message of "Thu, 09 Feb 1995 06:34:37 CST." <9502091149.AB06576@clncrdv1.is.chrysler.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 09 Feb 1995 11:10:50 -0500 From: "Perry E. Metzger" Robert Moskowitz says: > Is the list totally quite or did the list operator drop my subscription in a > bit bucket somewhere. The list is not quiet so it is unlikely that you were subscribed. > I have some questions on the IPSP drafts and would like to understand the > difference between DES and DES-CBC, ie do they require different hardware > engines? Block ciphers can be used in various different modes to assure security. When a block cipher is simply used to encode each block in turn, it is being used in ECB, or Electronic Code Book, mode. This mode is dangerous because the same plaintext will always encrypt as the same cyphertext, thus giving information to the attacker about the underlying plaintext. CBC is the Cipher Block Chaining mode -- in it, the ciphertext of each block is XORed with the plaintext of the next block before encryption. There are other modes -- Cipher Feedback Mode, Output Feedback Mode, etc. Any hardware that supports DES should probably handle DES in CBC mode. Perry From ipsec-request@ans.net Thu Feb 9 20:20:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23021 (5.65c/IDA-1.4.4 for ); Thu, 9 Feb 1995 14:36:39 -0500 Received: by interlock.ans.net id AA53281 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 9 Feb 1995 14:21:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 9 Feb 1995 14:21:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 9 Feb 1995 14:21:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 9 Feb 1995 14:21:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 9 Feb 1995 14:21:39 -0500 Message-Id: <9502091935.AA10360@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Feb 1995 14:20:34 -0600 To: perry@imsi.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Hello? Cc: ipsec@ans.net At 11:10 AM 2/9/95 -0500, Perry E. Metzger wrote: > >Robert Moskowitz says: >> Is the list totally quite or did the list operator drop my subscription in a >> bit bucket somewhere. > >The list is not quiet so it is unlikely that you were subscribed. Thanks to all that responded to me and explained the various modes of DES. I think I've got it and can leverage this for some actual implementations of IPSP. My note was sent to the list at 6:34 this morning and at 7:45 I received a message that I was now subscribed to the list. So all is cool. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Feb 9 19:31:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16156 (5.65c/IDA-1.4.4 for ); Thu, 9 Feb 1995 14:44:40 -0500 Received: by interlock.ans.net id AA49666 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 9 Feb 1995 14:33:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 9 Feb 1995 14:33:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 9 Feb 1995 14:33:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 9 Feb 1995 14:33:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 9 Feb 1995 14:33:45 -0500 Date: Thu, 9 Feb 1995 11:31:12 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502091931.AA01188@miraj.> To: ipsec@ans.net Subject: Re: comments on Photuris X-Sun-Charset: US-ASCII > From karn@unix.ka9q.ampr.org Thu Feb 9 03:36 PST 1995 > Although Ashar does have some valid points, several of his arguments > are against straw men in my opinion. For example, his assumption of > the identity function as the hash when signing. Tricking people into > signing arbitrary things of the attacker's choosing is a well-known > vulnerability of RSA and other digital signature algorithms. And this > is easily avoided: you never sign anything directly, you always sign > its crypto hash instead. I disagree. Not all of the arguments on stealing signatures involve the use of identity hash functions. I mentioned that one simply for the sake of completeness. There are many scenarios by means of which real signatures (on hashes not the actual quantities) can be obtained, even though the private keys may be perfectly secure. This is because signatures are not physically protected, even though keys usually are or can be. Consider the case whereby, e.g., through OS deficiencies one can steal a signature on a quantity from a smart card or token device, even though there is no possibility of stealing the private key from the device. With Photuris, stealing a single signature on a quantity whose discrete log is known is equivalent to stealing the long term private key (in the sense that it allows unlimited impersonation thereafter). This is the real problem. Then there is also the scenario that Hugo mentioned about the intruder simply stealing the fatal triple {x,g^x,Sig(g^x)} from the precompute table. This is also fatal, even if the triple was never used and the private key is perfectly protected. Stealing one signature should not be equivalent to stealing the long term private key, because the latter can be heavily protected whereas the former simply cannot be. Regards, Ashar. From ipsec-request@ans.net Mon Feb 13 02:29:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17129 (5.65c/IDA-1.4.4 for ); Sun, 12 Feb 1995 21:35:53 -0500 Received: by interlock.ans.net id AA33002 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 12 Feb 1995 21:31:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 12 Feb 1995 21:31:12 -0500 Message-Id: <199502130231.AA32997@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 12 Feb 1995 21:31:12 -0500 From: Darren Reed Subject: Re: Draft IPv6 Security API for BSD Sockets To: smb@research.att.com (Steve Bellovin) Date: Mon, 13 Feb 1995 13:29:51 +1100 (EDT) Cc: danmcd@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <199502011616.LAA00121@dolphin.zoo.att.com> from "Steve Bellovin" at Feb 1, 95 11:16:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1571 > > I'm not very happy with some aspects of the draft. My two main > areas of concern are the nature of the interface and the error-reporting > mechanisms proposed. > > The latter is easier to explain. I don't think that, in general, > it's at all a good idea to send errors to a security-aware application > simply because bogus (or damaged) packets are received. If nothing > else, it opens us up to easy denial of service attacks -- an attacker > can spew out bogus packets, he or she can cause these sessions to > abort. While security error statistics should be maintained, > certainly on a system- wide basis and probably on a per-SAID or > per-connection basis, it isn't at all clear to me that most > applications -- even security-aware ones -- need to be told about > these at all times. I'd suggest a more tunable approach -- the > process specifies a threshold, which defaults to infinity, for > errors; when the the threshold is exceeded, a process-specified > signal (or maybe SIGSECURITY or SIGHACK) could be raised. [...] Signals are only going to be useful when a process a single socket open. There needs to be either assistance to the signal to distinguish it, else saying "OI! Security Alert on *A* network connection!" isn't much help, as a socket need not be actively doing IO for the condition to be arise. That is, unless there is a restriction in the spec which says a process may not open more than 1 network connection which requires security to be observed (or only one can be monitored), the signal doesn't really help much. darren From ipsec-request@ans.net Tue Feb 14 04:22:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16381 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 09:33:58 -0500 Received: by interlock.ans.net id AA33319 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 09:26:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 09:26:21 -0500 Message-Id: <199502141426.AA48160@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 09:26:21 -0500 To: ipsec@ans.net Subject: Naming 1: granularity Date: Tue, 14 Feb 95 09:22:24 EST This is the first of two related messages that I don't want to send -- or rather, that I probably don't want to see the end of the threat that they may generate, since I've *never* seen a naming discussion that was at all pleasant. That said, the issue has to be raised... The basic question is this: when we do a key management exchange -- and I realize that we haven't yet agreed on how to -- the two negotiators have to know names for the parties involved. In the case of two end hosts negotiating, the name should (but see the next message) refer to the hosts themselves. Should these names be IP addresses or domain names? But that's not the hard case. The hard case is when one party's cryptographic functions are performed by a crypto gateway, which protects a whole group of machines. Should this gateway use its own name? Then how does the remote end know it speaks for the real destination? Should the certificate for the crypto gateway contain a list of addresses? A list of address/mask pairs? A list of names? We cannot do gateway-to-host or gateway-to-gateway encryption till we settle these and related issues. --Steve Bellovin From ipsec-request@ans.net Tue Feb 14 04:40:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15837 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 09:47:35 -0500 Received: by interlock.ans.net id AA30043 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 09:42:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 09:42:37 -0500 Message-Id: <199502141442.AA11095@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 09:42:37 -0500 To: ipsec@ans.net Subject: Naming 2: untrustable hosts Date: Tue, 14 Feb 95 09:40:13 EST The IPv6 specs say that the potential for authentication is mandatory. The draft API spec (in a concept I didn't challenge...) stated that both services and systems could impose a mandatory minimum security level. Presumably, these services or hosts would not talk to a peer if it could not negotiate a key with that level of security. What happens with inherently untrustable machines, such as shared PCs in a university lab? Are these machines to be barred from some class of Internet services? One reason for demanding authentication, even at the coarse granularity of a host, is so that you know who should be held accountable. It seems, then, that such machines could have a key if the key was bound to the person using it at the time. In other words, a Kerberos-like (or more precisely, an Athena-like, since it fits the Athena philosophy of whom you authenticate) name of ``user@domain'' might be used here, whereas a timesharing machine or a PC used by just one person would have a key bound to ``domain'' or maybe ``@domain''. And this in turn imposes some requirements on the forms of names that the key management protocol must deal with. I realize that one objection to this proposal is the notion that that user-granularity security is (to quote the response to a previous message of mine) ``an explicit non-goal''. But I don't see any other way to handle inherently untrustable machines. --Steve Bellovin From ipsec-request@ans.net Tue Feb 14 19:10:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14842 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 14:17:31 -0500 Received: by interlock.ans.net id AA45985 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 14:12:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 14:12:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 14:12:34 -0500 Date: Tue, 14 Feb 1995 14:10:20 -0500 (EST) From: "Donald E. Eastlake 3rd" To: smb@research.att.com Cc: ipsec@ans.net, dnssec@tis.com Subject: Re: Naming 1: granularity In-Reply-To: <199502141426.AA48160@interlock.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Feb 1995 smb@research.att.com wrote: > Date: Tue, 14 Feb 95 09:22:24 EST > From: smb@research.att.com > To: ipsec@ans.net >... > The basic question is this: when we do a key management exchange -- and > I realize that we haven't yet agreed on how to -- the two negotiators > have to know names for the parties involved. In the case of two end hosts > negotiating, the name should (but see the next message) refer to the > hosts themselves. Should these names be IP addresses or domain names? I don't think any one kind of name will satisfy everyone. Personally, I believe we should emphasize domain names as much as possible. Certainly if domain names are accepted, there is no need for iPv4 or IPv6 addresses, as they have a simple mappiing into domain names via in-addr.arpa for iPv4 and whatever is settled on for IPv6. There has always been a mapping for user accounts into domain names, there is now a mapping for all the world's telephone numbers into *.tpc.int, there is a draft out mapping Autonomous System numbers into domain names, etc. Still, there will be people who want a secure connection to an entity defined only by its public key and there may even be people who will want to communicate with an entity identified by a (shudder) Distinguished Name... > But that's not the hard case. The hard case is when one party's > cryptographic functions are performed by a crypto gateway, which protects > a whole group of machines. Should this gateway use its own name? Then > how does the remote end know it speaks for the real destination? Should > the certificate for the crypto gateway contain a list of addresses? A > list of address/mask pairs? A list of names? We cannot do gateway-to-host > or gateway-to-gateway encryption till we settle these and related issues. I think that, like they say, it depends. There will be gateway to gateway cases which are essentially tunnels where the gateways have their own name and just recongize each other and its transparent to everyone else. There will be cases where a gateway tries to transparently act for a bunch of machines and has keys to act for them all. If a gateway is for a whole Class C net, then I guess its name could be *.x.y.z.in-addr.arpa. Maybe this should be looked at operationally. If you try to send a packet to host w.x.y.z and this gateway is in the way, you presumably get back some sort of error. If the error says that, to talk to w.x.y.z (whose name we will suppose is foo.bar.zz) you need to be secure to this gateway then I guess the gateway could have any name. You might have a bit more confidence if the gateway seems to be called x.t.z.in-addr.arpa or perhaps bar.zz but, a long as you don't get any response from your original packet, you might try being secure to this claimed gateway even if its name seemed a bit odd... If you were trying to communicate securly with a particular host for NTP or routing or something else that is machine wide or trying to communicate as a particular user account for ftp or something that can depend on user identity and protections, then presumably you had a key for the host or user entity you were trying to communciate with. Either the gateway has that key aand everything looks great from your point of view, or it doesn't in which case you can super-ipsec to the gateway as well but I can't see why you would ever not use the correct key for an ipsec to the end entity you really want. > --Steve Bellovin Donald ===================================================================== Donald E. Eastlake 3rd 1-508-287-4877(tel) dee@cybercash.com 318 Acton Street 1-508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA From ipsec-request@ans.net Tue Feb 14 19:17:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18227 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 14:23:13 -0500 Received: by interlock.ans.net id AA47666 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 14:20:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 14:20:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 14:20:12 -0500 Date: Tue, 14 Feb 1995 14:17:56 -0500 (EST) From: "Donald E. Eastlake 3rd" To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: Naming 2: untrustable hosts In-Reply-To: <199502141442.AA11095@interlock.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Feb 1995 smb@research.att.com wrote: > Date: Tue, 14 Feb 95 09:40:13 EST > From: smb@research.att.com > To: ipsec@ans.net > The IPv6 specs say that the potential for authentication is mandatory. > The draft API spec (in a concept I didn't challenge...) stated that > both services and systems could impose a mandatory minimum security > level. Presumably, these services or hosts would not talk to a peer if > it could not negotiate a key with that level of security. What happens > with inherently untrustable machines, such as shared PCs in a > university lab? Are these machines to be barred from some class of > Internet services? The way most people view this as happening is that the person using the machine ideally pluggs in their smart card which has in it the key for person.lab.course.university.edu or something and this key is used to dynamically update the DNS so the A (&AAAA) records for that name now point to the machine. The PC then requests that the inverse DNS be changed and some router or gateway has a key that lets it do that dynamic update based on this request and the fact that it can see that the forward listing has already been changed. > One reason for demanding authentication, even at the coarse granularity > of a host, is so that you know who should be held accountable. It > seems, then, that such machines could have a key if the key was bound > to the person using it at the time. In other words, a Kerberos-like > (or more precisely, an Athena-like, since it fits the Athena philosophy > of whom you authenticate) name of ``user@domain'' might be used here, > whereas a timesharing machine or a PC used by just one person would > have a key bound to ``domain'' or maybe ``@domain''. And this in turn > imposes some requirements on the forms of names that the key management > protocol must deal with. > > I realize that one objection to this proposal is the notion that that > user-granularity security is (to quote the response to a previous message > of mine) ``an explicit non-goal''. But I don't see any other way to > handle inherently untrustable machines. Have I missed something? Security granularity at less than the host level was always an IPv6 requirement. I'm not saying that the availability of granularity down to the user account was ever made a goal for ipsec, but when in the world was it ever decided to be avoided in the ipsec effort??? > --Steve Bellovin Donald ===================================================================== Donald E. Eastlake 3rd 1-508-287-4877(tel) dee@cybercash.com 318 Acton Street 1-508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA From ipsec-request@ans.net Tue Feb 14 17:11:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15667 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 17:11:07 -0500 Received: by interlock.ans.net id AA26547 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 17:07:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Feb 1995 17:07:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 17:07:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 17:07:06 -0500 Date: Tue, 14 Feb 95 13:54:35 From: "Housley, Russ" Encoding: 590 Text Message-Id: <9501147927.AA792798875@spysouth.spyrus.com> To: ipsec@ans.net, smb@research.att.com Subject: Re: Naming 1: granularity Steve: Even the simple case is not simple. You said: The basic question is this: when we do a key management exchange -- and I realize that we haven't yet agreed on how to -- the two negotiators have to know names for the parties involved. In the case of two end hosts negotiating, the name should (but see the next message) refer to the hosts themselves. Should these names be IP addresses or domain names? If a host is multi-homed, it may have more than one IP address. So even when there is one host, the decision gets difficult. Russ From ipsec-request@ans.net Tue Feb 14 22:27:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05569 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 18:04:45 -0500 Received: by interlock.ans.net id AA60548 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 17:56:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 17:56:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 17:56:17 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net, ipng@sunroof.eng.sun.com Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-karn-photuris-00.txt Date: Tue, 14 Feb 95 17:27:19 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9502141727.aa10773@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Photuris Key Management Protocol Author(s) : P. Karn Filename : draft-karn-photuris-00.txt Pages : 13 Date : 02/13/1995 Photuris is a proposed key management protocol that is derived in part from the Diffie-Hellman work. It is being considered for use as a key management protocol for use with IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-karn-photuris-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-karn-photuris-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-karn-photuris-00.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: <19950213114407.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-karn-photuris-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-karn-photuris-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950213114407.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Feb 14 11:23:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23928 (5.65c/IDA-1.4.4 for ); Tue, 14 Feb 1995 20:29:51 -0500 Received: by interlock.ans.net id AA09199 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Feb 1995 20:24:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Feb 1995 20:24:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Feb 1995 20:24:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Feb 1995 20:24:52 -0500 Date: Tue, 14 Feb 95 18:23:39 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9502150123.AA06668@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: smb@research.att.com Subject: Re: Naming 1: granularity Cc: ipsec@ans.net > This is the first of two related messages that I don't want to send -- > or rather, that I probably don't want to see the end of the threat that > they may generate, since I've *never* seen a naming discussion that was > at all pleasant. That said, the issue has to be raised... > > The basic question is this: when we do a key management exchange -- and > I realize that we haven't yet agreed on how to -- the two negotiators > have to know names for the parties involved. In the case of two end hosts > negotiating, the name should (but see the next message) refer to the > hosts themselves. Should these names be IP addresses or domain names? In My HuMble Opinion, they should be both. That is, a host should have a certificate with its IP address and its hostname. In the case of multiple IP addresses or hostnames, multiple certificates. E.g. if I talk to "ftp.cdrom.com", I should use the "ftp.cdrom.com" certificate, AND not the wcarchive.cdrom.com or the 192.216.191.11 certificate. There was a paper in the IPv6 discussion advocating separate IP addresses for the various aliases of a machine, which seems reasonable to me for similar reasons. Computers have multiple personalities, and it seems reasonable to give them each a different key. (Indeed, it's also reasonable for "LabmdaMOO" to have a key, independent of the host it's running on.) > But that's not the hard case. The hard case is when one party's > cryptographic functions are performed by a crypto gateway, which protects > a whole group of machines. Should this gateway use its own name? Then > how does the remote end know it speaks for the real destination? Should > the certificate for the crypto gateway contain a list of addresses? A > list of address/mask pairs? A list of names? We cannot do gateway-to-host > or gateway-to-gateway encryption till we settle these and related issues. Because the gateway has the real destination's key. The destination, by giving the gateway its key, is trusting the gateway to do right by it. Are there big performance wins for having the gateway have just one key? You could put multiple names (like all the hosts it protects) on the one key, I guess. It does maean that a gateway has to know about the domain names of each of the machines it guards. (Or you could have a ".cdrom.com" key, maybe?) -- -Colin From ipsec-request@ans.net Wed Feb 15 09:23:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07057 (5.65c/IDA-1.4.4 for ); Wed, 15 Feb 1995 04:30:33 -0500 Received: by interlock.ans.net id AA33572 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Feb 1995 04:25:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Feb 1995 04:25:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Feb 1995 04:25:54 -0500 Date: Wed, 15 Feb 1995 01:23:25 -0800 From: Phil Karn Message-Id: <199502150923.BAA01599@unix.ka9q.ampr.org> To: ashar@osmosys.incog.com Cc: ipsec@ans.net In-Reply-To: <9502091931.AA01188@miraj.> (ashar@osmosys.incog.com) Subject: Re: comments on Photuris Consider the case whereby, e.g., through OS deficiencies one can steal a signature on a quantity from a smart card or token device, even though there is no possibility of stealing the private key from the device. With Photuris, stealing a single signature on a quantity whose discrete log is known is equivalent to stealing the long term private key (in the sense that it allows unlimited impersonation thereafter). This is the real problem. What do you mean by "steal a signature"? Trick the device to sign an arbitrary value of your own choosing, such as the hash on a g^x for which you know x? If this is the case, then of *course* you can impersonate the user. This just underscores the importance of being careful about what you sign. The problem is really one of engineering, not protocol design. But I see an addition to the protocol to at least limit the damage if this were to happen. Simply append an expiration time to the precomputed DH public part before you sign it. Choosing an expiration time is easy - just set it to when you plan to precompute a new x,g^x pair. Note that this doesn't really require everyone to have synchronized clocks. You're free to ignore expiration times at your own risk. Then there is also the scenario that Hugo mentioned about the intruder simply stealing the fatal triple {x,g^x,Sig(g^x)} from the precompute table. This is also fatal, even if the triple was never used and the private key is perfectly protected. This is just a superset of the previous attack. It's not really fair to posit that x is compromised since DH has always assumed it to be secret. But the timestamp feature could again limit the duration of the breach if it were to occur. I would suspect that in many practical implementations, any particular x is better protected than the secret key used to sign g^x for the simple reason that x is ephemeral and never leaves the system where it is automatically generated. On the other hand, the signature key is a long-lived item that will probably be generated offline and backed up in places beyond the control of the IPSP implementation. Now I have been assuming that the entire IPSP is software running on general purpose computers, i.e., there is no special tamper resistant hardware for the signing operation. If you do assume such hardware, especially if the rest of the protocol remains on hackable general purpose computers, then your point starts to carry some real weight. Phil From ipsec-request@ans.net Wed Feb 15 05:04:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14936 (5.65c/IDA-1.4.4 for ); Wed, 15 Feb 1995 10:40:54 -0500 Received: by interlock.ans.net id AA15645 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Feb 1995 10:34:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Feb 1995 10:34:13 -0500 Message-Id: <199502151534.AA10009@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Feb 1995 10:34:13 -0500 Date: Wed, 15 Feb 95 10:04:22 EST From: hugo@watson.ibm.com To: karn@unix.ka9q.ampr.org Cc: ipsec@ans.net Subject: comments on Photuris Ref: Your note of Wed, 15 Feb 1995 01:23:25 -0800 (attached) > > But I see an addition to the protocol to at least limit the damage if > this were to happen. Simply append an expiration time to the > precomputed DH public part before you sign it. > Well, that's already significantly better! I still prefer the option of signing nonces chosen by the other party. It is more secure (time sync considerations, granularity of frshness, etc.) Clearly, using nonces is less efficient as for pre-computation. However, for parties that periodically refresh their keys there is no reason not to maintain a nonce sent in the previous refreshment round; in that case the signature can be performed at the convenience of the signer at any time between the two refreshment rounds. > Then there is also the scenario that Hugo mentioned about > the intruder simply stealing the fatal triple {x,g^x,Sig(g^x)} > from the precompute table. This is also fatal, even if the > triple was never used and the private key is perfectly protected. > > This is just a superset of the previous attack. It's not really fair > to posit that x is compromised since DH has always assumed it to be > secret. But the timestamp feature could again limit the duration of > the breach if it were to occur. What does it mean "not fair"?? Is being attacked ever fair? Isn't your own proposal defending against possible stealing of x (by intrusion) by distroying pairs (x,g^x) some time after its creation? See your draft sections 1.3 and 4.5. Even if your concerns are motivated by secrecy and not authentication, the fact of a possible intrusion does not change. (And, needless to say, strong secrecy also requires strong authentication. In the words of the famous Decryptes: "impersonatum ergo eavesdropum"). Hugo From ipsec-request@ans.net Wed Feb 15 20:05:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15494 (5.65c/IDA-1.4.4 for ); Wed, 15 Feb 1995 15:23:11 -0500 Received: by interlock.ans.net id AA60760 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Feb 1995 15:11:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 15 Feb 1995 15:11:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Feb 1995 15:11:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Feb 1995 15:11:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Feb 1995 15:11:38 -0500 Date: Wed, 15 Feb 1995 12:05:31 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502152005.AA03816@miraj.> To: karn@unix.ka9q.ampr.org Subject: Re: comments on Photuris Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Feb 15 02:03 PST 1995 >> What do you mean by "steal a signature"? Trick the device to sign an > arbitrary value of your own choosing, such as the hash on a g^x > for which you know x? Yes. > If this is the case, then of *course* you can impersonate the user. > This just underscores the importance of being careful about what you > sign. The problem is really one of engineering, not protocol design. No, the problem bears directly on protocol design, because some protocols minimize the damage of this sort of compromise, whereas for others (e.g. Photuris) this is catastrophic. For example, the STS protocol in the Diffie et al reference I cited earlier allows an adversary to gain *no* impersonation advantage from stealing signatures in advance from smart cards because you don't know in advance what you will be expected to sign in real time in order to be authenticated. And if you replaced the signatures in the STS protocol design with ICVs computed with cached pairwise SKIP master keys, then this too would allow no advantage from smart cards being tricked into signing/encrypting various quantities. Furthermore, this would alleviate the need to precompute the signature because realtime computation of ICVs is a very efficient operation in comparison with RSA signatures. This would have the same realtime computational overhead of, e.g., Photuris without some of the catastrophic failure modes. > But I see an addition to the protocol to at least limit the damage if > this were to happen. Simply append an expiration time to the > precomputed DH public part before you sign it. This doesn't help a whole lot when the intruder is picking the signature to be stolen, because she can simply pick the expiration date that suits her. Not unless you modify the smart card to always append dates to all signatures, which would make the smart card not very useful for other protocols which cannot handle dates in signatures (e.g PEM/PGP etc.) And no smart card I know of does this. > This is just a superset of the previous attack. It's not really fair > to posit that x is compromised since DH has always assumed it to be > secret. But the timestamp feature could again limit the duration of > the breach if it were to occur. As Hugo mentioned, attacks are not about fairness. One could make the same argument about protocols that dont support perfect forward secrecy, i.e, it is not fair to assume that the keys will ever be compromised. > Now I have been assuming that the entire IPSP is software running on > general purpose computers, i.e., there is no special tamper resistant > hardware for the signing operation. If you do assume such hardware, > especially if the rest of the protocol remains on hackable general > purpose computers, then your point starts to carry some real weight. Assuming the lack of special purpose crypto-hardware when considering IPSP system/protocol design issues is not a good idea. I expect a very large proportion of commercial IPSP products to support crypto hardware like smart cards, PCMCIA devices etc. Kind regards, Ashar. From ipsec-request@ans.net Thu Feb 16 06:02:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21861 (5.65c/IDA-1.4.4 for ); Thu, 16 Feb 1995 01:20:23 -0500 Received: by interlock.ans.net id AA48428 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Feb 1995 01:03:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Feb 1995 01:03:20 -0500 Message-Id: <199502160603.AA18728@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Feb 1995 01:03:20 -0500 From: Darren Reed Subject: Re: Naming 2: untrustable hosts To: smb@research.att.com Date: Thu, 16 Feb 1995 17:02:36 +1100 (EDT) Cc: ipsec@ans.net In-Reply-To: <199502141442.AA11095@interlock.ans.net> from "smb@research.att.com" at Feb 14, 95 09:40:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3544 > > The IPv6 specs say that the potential for authentication is mandatory. > The draft API spec (in a concept I didn't challenge...) stated that > both services and systems could impose a mandatory minimum security > level. Presumably, these services or hosts would not talk to a peer if > it could not negotiate a key with that level of security. What happens > with inherently untrustable machines, such as shared PCs in a > university lab? Are these machines to be barred from some class of > Internet services? > > One reason for demanding authentication, even at the coarse granularity > of a host, is so that you know who should be held accountable. It > seems, then, that such machines could have a key if the key was bound > to the person using it at the time. In other words, a Kerberos-like > (or more precisely, an Athena-like, since it fits the Athena philosophy > of whom you authenticate) name of ``user@domain'' might be used here, > whereas a timesharing machine or a PC used by just one person would > have a key bound to ``domain'' or maybe ``@domain''. And this in turn > imposes some requirements on the forms of names that the key management > protocol must deal with. > > I realize that one objection to this proposal is the notion that that > user-granularity security is (to quote the response to a previous message > of mine) ``an explicit non-goal''. But I don't see any other way to > handle inherently untrustable machines. I'd go for untrustable machines be allowed to access only on what name/ IP# it has, and not anything finer than this, unless it had already been authenticated by a more sophisticated means by the server as having a user@host attribute. So if that meant it were otherwise barred from doing rsh, rlogin, rexec, sending mail, I'd accept it and I can't see why there would be much opposition. I think the problem then would be ensuring such services enforced the appropriate policy (;) and (maybe) even demand different levels of authentication depending on "network location", etc. If someone is telnetting from a PC in a general access lab, then I'm not really concerned about if they have a valid login on the PC (if I were I'd probably want video camera's in the lab along with a way to handle access to the area). In my experience, it is the nature of students to share passwords (no matter how much you say "NO, YOU CAN'T DO THAT") and presumably trhis happens elsewhere too. I might add that this is not the same as crackers "breaking in". Heck, even if we issued secure-id cards to students, I'm sure there'd be "can I borrow yours to print this out, I left mine at home" type of situation. Hmm, I seem to have wandered a bit here...To sum up my comfort level with PC's and security, we don't allow PC's using NFS to write to any drives except those with home accounts which are the nosuid, etc, type, regardless of who is logged into them. I like the idea of a system requiring a minimum security level, with services being able to demand that minimum. If one of the levels happens to be, or equivalent to, user authentication, then so much the better for those serives which can _reliably_ provide such. On this, maybe it is worth mentioning the requirements for each level of authentication, so that the traditional password sent in clear text over the network isn't and can't be given the same level of trust as a challenge-response system and that a "claimed username" not be trusted just because of some arbitary number in the IP header(s) being right. darren From ipsec-request@ans.net Sun Feb 19 16:47:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14124 (5.65c/IDA-1.4.4 for ); Sun, 19 Feb 1995 22:08:43 -0500 Received: by interlock.ans.net id AA32486 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 19 Feb 1995 21:49:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 19 Feb 1995 21:49:00 -0500 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 19 Feb 1995 21:49:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 19 Feb 1995 21:49:00 -0500 Date: Sun, 19 Feb 95 21:47:46 EST X-Sender: shirey@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: psrg@isi.edu, pem-dev@tis.edu, ipsec@ans.net, secdir@tis.com, p1363@RSA.COM From: shirey@mitre.org (Robert W. Shirey) Subject: Triple DES passed ANSI X9 Thought you might be interested in this.... Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS From: jseiger@cdt.org (Jonah Seiger) ------------------------------------------------------------------------ ****** ******** ************* ******** ********* ************* ** ** ** *** POLICY POST ** ** ** *** ** ** ** *** February 13, 1995 ** ** ** *** Number 2 ******** ********* *** ****** ******** *** CENTER FOR DEMOCRACY AND TECHNOLOGY ------------------------------------------------------------------------ A briefing on public policy issues affecting civil liberties online ------------------------------------------------------------------------ CDT POLICY POST 2/13/95 Number 2 CONTENTS: (1) X9 Committee Agrees to Develop 3x DES Encryption Standard (2) About the Center for Democracy and Technology This document may be re-distributed freely providing it remains in its entirety. ------------------------------------------------------------------------ X9 COMMITTEE AGREES TO DEVELOP 3x DES ENCRYPTION STANDARD Major Setback for NSA The NSA's efforts to push the adoption the Clipper/Skipjack government-escrowed encryption scheme encountered a major setback earlier this month with the decision by the Accredited Standards Committee X9 to proceed with the development of a data security standard based on triple-DES. The ASC X9 committee is responsible for setting data security standards for the US banking and financial services industries. These industries are heavy users of commercial cryptography, and standards developed for this community tend to drive the development of applications for the entire market. As a result, the committee's decision to proceed with a triple-DES standard has important implications for future cryptographic standards and US cryptography policy generally. The NSA, a voting member of the X9 committee, had lobbied hard against the proposal. In a November letter to committee members, the NSA threatened to prevent the export of triple- DES, citing existing US law and potential threats to national security (see attached NSA letter). The decision sets the stage for the development of a next generation of security standards based on publicly available, non-escrowed encryption schemes. A battle over the exportability of triple-DES applications is also on the horizon. Through export controls on cryptography, the proposed Clipper initiative, and interference in the standards setting processes, US government policies have consistently sought to make strong encryption and other privacy protecting technologies unavailable to the general public. The X9 decision and development of triple-DES and other alternatives to government-escrowed cryptography is an important victory in that it will increase the public's access to strong, privacy enhancing technologies. BACKGROUND Banks and other financial institutions use encryption to protect the billions of dollars in transactions and fund transfers which flow every day across the world's communications networks. The current encryption standard used by the banking industry is based on DES, which has been available since the early 1970's. DES is widely trusted because it has been repeatedly tested and is considered by experts to be unbreakable except by brute force (trying every possible key combination). The US government has also allowed the limited export of DES. Despite its popularity, DES is considered to be reaching the end of its useful life. The increasing speed and sophistication of computer processing power has begun to render DES vulnerable to brute force attacks. Cryptographers have recently demonstrated that DES codes can be cracked in as little as three hours with $1 million worth of currently available equipment. As a result, the banking and financial services industries have begun to explore alternatives to DES. Although there are many potential alternatives to DES, triple-DES is widely seen as the most practical solution. Triple-DES is based on DES, but has been enhanced by increasing the key length and by encrypting through multiple iterations. These enhancements make triple-DES less vulnerable to brute force attacks. Triple-DES is also popular because it can be easily incorporated into existing DES systems and is based on standards and procedures familiar to most users. NSA SETBACK IS A VICTORY FOR CLIPPER OPPONENTS In their November letter to X9 committee members, the NSA attempted to undermine the attractiveness of triple-DES by arguing that it is cryptographically unsound, a potential threat to national security, and would not be exportable under US law. The NSA, while offering no specific alternative to triple-DES, seemed to be attempting to push the committee to adopt the only currently available option -- Clipper. Privacy advocates also lobbied the X9 committee. In a letter sent in advance of the December 1994 ballot, CDT Deputy Director Daniel Weitzner (then EFF Deputy Policy Director) and EFF board member John Gilmore, an expert in this field, sent a letter to X9 committee members urging them to adopt the triple-DES standard. A copy of the letter is appended at the end of this post. By agreeing to develop a triple-DES standard, the X9 committee has clearly and decisively rejected Clipper as a solution. This vote thus represents a further repudiation to Clipper and yet another victory for opponents of government efforts to establish Clipper or other government-escrowed solutions as a national standard. NEXT STEPS X9F, a subcommittee of the X9 committee, will now develop technical standards for implementing triple-DES based applications. This process is expected to take one or two years to complete. Once technical standards are developed, the full X9 committee will vote as to whether to implement the subcommittee's technical recommendations. The availability of triple-DES applications received a further boost recently with the announcement by AT&T and VLSI Technologies that they were developing new data security products based on triple-DES. This will presumably provide additional options for X9 committee members, but the exportability of these products is still in doubt. The stage is thus set for a further battle between the NSA and the X9 committee over the exportability of triple-DES and final approval of the X9 standard. As a sitting member of the committee, NSA will presumably continue to lobby against efforts by the committee to develop triple-DES applications. Furthermore, the banking and financial services industries must still persuade the government to allow for the export of triple-DES. As an opponent of government-escrowed cryptography, CDT applauds the recent actions of the X9 committee. While CDT supports the development of a variety of security standards and alternatives to DES, we recognize the need of the banking and financial services industries to develop temporary stop- gap solution. CDT will continue to work towards the relaxation of export controls on cryptography and will support X9 committee members in their efforts to gain the ability to export triple-DES applications. For more information contact: Daniel J. Weitzner, Deputy Director Jonah Seiger, Policy Analyst +1.202.637.9800 ---------------------------------------------------------- GILMORE/WEITZNER LETTER TO X9 COMMITTEE MEMBERS November 18, 1994 Dear Accredited Standards Committee-X9 Member: The X9 Committee is currently voting as to whether to recommend the development of a standard for triple-DES (ballot number X9/94-LB#28). The Electronic Frontier Foundation (EFF) strongly urges you to vote in favor of the triple-DES standard. EFF supports the development of a variety of new data security standards and alternatives to DES. We believe the triple-DES standard provides the best immediate short term alternative because: * The basic algorithm, DES, is strong and has been tested repeatedly. * There are no known attacks that succeed against triple-DES. * It is clearly no less secure than DES. * It eliminates the brute-force problem completely by tripling the key length. * It runs at high speeds in easy-to-build chips. * It can be easily incorporated into existing systems. NSA's opposition to triple-DES appears to be an indirect attempt to push Clipper by eliminating credible alternatives. Clipper is not a viable alternative to triple-DES, and carries substantial liabilities. There has been no evidence of foreign acceptance of the standard and the Skipjack algorithm is classified. The likelihood of any government accepting secret standards developed by a foreign security agency is slim. Clinton Administration efforts, through the NSA, to push Clipper as a domestic standard over the past two years have failed. We urge you to carefully consider the alternatives before you cast your ballot. We believe that the triple-DES issue should be decided on its own merits. Sincerely, John Gilmore Board of Directors Electronic Frontier Foundation Daniel J. Weitzner Deputy Policy Director Electronic Frontier Foundation ------------------------------------------------------------- NSA LETTER TO X9 COMMITTEE MEMBERS X9 Member: I will be casting a NO vote on the NWI for triple-DES, Letter Ballot X9/94-LB#28. The reasons are set forth below. You may find these useful as you determine your position. Jerry Rainville NSA REASONS FOR A NEGATIVE VOTE While NSA supports the use of DES in the global financial sector, we believe that standardization of triple-DES is ill- advised for a number of reasons. The financial community should be planning to transition to a new generation of cryptographic algorithms. When DES was first introduced, it represented the "only game in town". It supported encryption, authentication, key management, and secure hashing applications. With a broader interest in security, the market can now support optimized algorithms by application. Going through the expense of installing a stop- gap can only serve to delay progress in achieving interoperable universal appropriate solutions. While we understand the appeal of a snap-in upgrade, our experience has been that any change is expensive, especially one where the requirements on the key management system change. We do not agree that replacing DES with triple-DES is significantly less expensive than upgrading to more appropriate technology. Tripling of any algorithm is cryptographically unsound. Notice that tripling DES, at best, only doubles the length of the cryptovariable (key). Phrased another way, the DES was optimized for security at 56 bits. We cannot vouch that any of the schemes for doubling the cryptovariable length of DES truly squares security. We understand the financial community has concerns with current key escrow based encryption, however, we are committed to searching for answers to those concerns. But the government is also committed to key escrow encryption, and we do not believe that the proposal for triple DES is consistent with this objective. US export control policy does not allow for general export of DES for encryption, let alone triple-DES. Proceeding with this NWI would place X9 at odds with this long standing policy. It also violates the newly accepted X9 cryptographic policy. The US government has not endorsed triple-DES; manufacturers and users may be reluctant to use triple-DES products for fear of possible liability. Finally, further proliferation of triple-DES is counter to national security and economic objectives. We would welcome the opportunity to discuss these concerns with an appropriate executive of your institution. --------------------------------------------------------------------- ABOUT THE CENTER FOR DEMOCRACY AND TECHNOLOGY The Center for Democracy and Technology is a non-profit public interest organization. The Center's mission is to develop and advocate public policies that advance constitutional civil liberties and democratic values in new computer and communications technologies. Contacting us: General information on CDT can be obtained by sending mail to www/ftp/gopher archives are currently under construction, and should be up and running by the middle of March. ### From ipsec-request@ans.net Mon Feb 20 13:40:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12732 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 09:06:29 -0500 Received: by interlock.ans.net id AA19034 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 08:52:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Feb 1995 08:52:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 08:52:19 -0500 Date: Mon, 20 Feb 95 13:40:56 GMT From: "William Allen Simpson" Message-Id: <3934.bsimpson@morningstar.com> To: ipsec@ans.net Subject: WG last call for IPv4 AH and ESP Things have quieted down on this list about AH and ESP, so I have to assume we are ready to implement. I'm working on integrating Ran's IPv6 changes into the text. Are there any other issues still unresolved? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 20 04:31:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20707 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 09:49:02 -0500 Received: by interlock.ans.net id AA19031 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 09:35:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Feb 1995 09:35:24 -0500 Message-Id: <199502201435.AA46419@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 09:35:24 -0500 To: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP Date: Mon, 20 Feb 95 09:31:28 EST I have no new issues about AH and ESP, but I do have some input on authentication-only mode. There's been a lot of discussion about whether or not keyed MD5 or SHA are too expensive. I was discussing the question with Jim Reeds, a cryptographic mathematician here. He suggests that an approach of that sort is overkill. A better idea, in his opinion, is to use a comparatively weak but fast encryption algorithm (though not an XOR-based stream cipher such as RC4 or OFB-mode DES) in conjunction with a fast checksum algorithm. The authentication value would be the checksum of the ciphertext -- but you'd never send the ciphertext, only the plaintext. To deal with potential export issues for the source code, modify the cipher so that was a (possibly weak) one-way function. For example, a permuation could be replaced by a table look-up that lost information. The result wouldn't be decryptable short of (possibly easy) cryptanalysis, and hence would not be readily usable as a cipher. I should note, by the way, that in my opinion Jim Reeds' hunches on cryptography are generally better than my careful analysis... --Steve Bellovin From ipsec-request@ans.net Mon Feb 20 14:49:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21966 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 10:12:04 -0500 Received: by interlock.ans.net id AA19195 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 09:49:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 20 Feb 1995 09:49:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Feb 1995 09:49:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Feb 1995 09:49:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 09:49:24 -0500 Message-Id: <9502201449.AA11058@snark.imsi.com> To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Mon, 20 Feb 1995 13:40:56 GMT." <3934.bsimpson@morningstar.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 20 Feb 1995 09:49:08 -0500 From: "Perry E. Metzger" "William Allen Simpson" says: > Things have quieted down on this list about AH and ESP, so I have to > assume we are ready to implement. I'm working on integrating Ran's IPv6 > changes into the text. Are there any other issues still unresolved? I think there are two important things still unresolved; one fairly small, one a bunch bigger. The question of the proper way to combine authentication and encryption is still outstanding; several people have excellent arguments on why the keyed hash (or whatever) should be outside of the encrypted area and several people have excellent arguments on why it should be inside. I've avoided thinking about it for a couple of weeks. There is also the question of ICMP messages, which I'm worrying about right now; part of the reason I've been putting this off is to see what turns up while I implement. Other than that, I think that the AH and ESP stuff are pretty much done with. Perry From ipsec-request@ans.net Mon Feb 20 15:29:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14606 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 10:54:15 -0500 Received: by interlock.ans.net id AA38945 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 10:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Feb 1995 10:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Feb 1995 10:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 10:25:57 -0500 Message-Id: <9502201525.AA22506@anubis.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Feb 1995 09:29:34 -0600 To: smb@research.att.com From: hughes@hughes.network.com (James P Hughes) Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net >I have no new issues about AH and ESP, but I do have some input on >authentication-only mode. There's been a lot of discussion about whether >or not keyed MD5 or SHA are too expensive. I was discussing the question >with Jim Reeds, a cryptographic mathematician here. He suggests that >an approach of that sort is overkill. A better idea, in his opinion, >is to use a comparatively weak but fast encryption algorithm (though >not an XOR-based stream cipher such as RC4 or OFB-mode DES) in conjunction >with a fast checksum algorithm. The authentication value would be the >checksum of the ciphertext -- but you'd never send the ciphertext, only >the plaintext. To deal with potential export issues for the source >code, modify the cipher so that was a (possibly weak) one-way function. >For example, a permuation could be replaced by a table look-up that lost >information. The result wouldn't be decryptable short of (possibly >easy) cryptanalysis, and hence would not be readily usable as a cipher. I agree and made the same comments to Ran Atkinson several months ago although I have not come up with such an algorithm. I think this idea is a good one. I would also add that the tables for the encryption could be calculated at key exchange time and kept so that the per packet time would be reduced. This would also be used to create a greater than or equal to 128 bit hash. Maybe 160 bits or more... Anyway, the inability to get the key -and- inability to find a collision would be enough. I would suggest that for signing contracts or key exchanges, keyed MD5 would be required, but, as an option, individual packets could be signed by something less computationally intensive. >I should note, by the way, that in my opinion Jim Reeds' hunches on >cryptography are generally better than my careful analysis... Lastly, given the short fuse to the AH document, and the time necessary for public review of such algorithms, I would suggest that we leave the documents go through as they are now and expect to add other AH algorithms later. I for one would like to help design such an algorithm. > --Steve Bellovin Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Feb 20 16:46:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06390 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 12:12:36 -0500 Received: by interlock.ans.net id AA17512 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 11:49:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 11:49:19 -0500 From: Ran Atkinson Message-Id: <9502201146.ZM5125@bodhi> Date: Mon, 20 Feb 1995 11:46:10 -0500 In-Reply-To: "Perry E. Metzger" "Re: WG last call for IPv4 AH and ESP" (Feb 20, 9:49) References: <9502201449.AA11058@snark.imsi.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: perry@imsi.com, William Allen Simpson Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Perry, I believe it would be a mistake to mandate that users must use one of (auth inside encryption) or (auth outside encryption). There is no need to create such restrictions. Permit folks to do it either way by leaving the flexibility in the specification. Then users can choose the security service that they desire. We should be focusing on defining mechanisms and try to leave policy matters open to users. Regards, Ran From ipsec-request@ans.net Mon Feb 20 17:00:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20300 (5.65c/IDA-1.4.4 for ); Mon, 20 Feb 1995 12:19:32 -0500 Received: by interlock.ans.net id AA12371 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Feb 1995 12:00:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 20 Feb 1995 12:00:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Feb 1995 12:00:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Feb 1995 12:00:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Feb 1995 12:00:42 -0500 Message-Id: <9502201700.AA11221@snark.imsi.com> To: atkinson@itd.nrl.navy.mil Cc: William Allen Simpson , ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Mon, 20 Feb 1995 11:46:10 EST." <9502201146.ZM5125@bodhi> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 20 Feb 1995 12:00:20 -0500 From: "Perry E. Metzger" Ran Atkinson says: > I believe it would be a mistake to mandate that users must use > one of (auth inside encryption) or (auth outside encryption). I had no such intentions; this was only for purposes of a base security transform for encryption plus authentication. I agree that people can and will come up with better mechanisms in the future and since the architecture we stole from you is flexible enough to permit that we have no cause to try to lower the functionality. However, for the sake of interoperability, we DO need a set of base transforms, and I'm trying to define one here. Perry From ipsec-request@ans.net Tue Feb 21 10:08:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23842 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 05:19:11 -0500 Received: by interlock.ans.net id AA13655 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 05:06:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 05:06:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 05:06:47 -0500 Date: Tue, 21 Feb 1995 02:08:36 -0800 From: Phil Karn Message-Id: <199502211008.CAA08051@unix.ka9q.ampr.org> To: hugo@watson.ibm.com Cc: ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <199502151534.AA10009@interlock.ans.net> (hugo@watson.ibm.com) Subject: Re: comments on Photuris >I still prefer the option of signing nonces chosen by the other party. >It is more secure (time sync considerations, granularity of frshness, etc.) >However, for parties that periodically refresh their keys there is no reason >not to maintain a nonce sent in the previous refreshment round; in that case Suppose I add a rule to Photuris that says you should use an existing SAID whenever possible to encrypt the exchanges that create a new SAID. Would this give you some of the same sort of protection against partial compromises that you get with explicit key refreshment? Phil From ipsec-request@ans.net Tue Feb 21 09:28:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16932 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 05:19:12 -0500 Received: by interlock.ans.net id AA22652 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 05:10:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 05:10:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 05:10:14 -0500 Date: Tue, 21 Feb 1995 01:28:23 -0800 From: Phil Karn Message-Id: <199502210928.BAA07913@unix.ka9q.ampr.org> To: ashar@osmosys.incog.com Cc: ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <9502152005.AA03816@miraj.> (ashar@osmosys.incog.com) Subject: Re: comments on Photuris >And if you replaced the signatures in the STS protocol design with >ICVs computed with cached pairwise SKIP master keys, then this >too would allow no advantage from smart cards being tricked >into signing/encrypting various quantities. Furthermore, this Thanks BTW for explaining this to me in person at the ISOC conference. But after thinking about it for a while, despite its seeming differences what you proposed is almost equivalent to Photuris! (I tried to find you Friday afternoon to talk about this more but you seem to have left early). You said that you could sign the DH public key in your protocol with, say, PGP. But how does this really differ from Photuris, where I also sign a DH public part with RSA? The main difference is that I regularly generate new DH public/private pairs while you consider them to be fairly static. This may admittedly be a *practical* advantage in that your DH public keys can be signed offline in a presumably more secure fashion than my ephemeral DH keys, which have to be signed online because they change frequently. This may make the signature function somewhat more vulnerable to compromise. You suggested that I then do an ephemeral DH exchange (for perfect forward secrecy) and sign the result of this exchange with the static DH pairwise key in a fast keyed hash function. But I already do essentially the same thing in Photuris. Remember that in Photuris the RSA signature exchange is encrypted in the session key that was just generated with DH. Unless the attacker knows the secret DH value that goes with the (stolen) signed public DH value, he won't be able to generate the session key and therefore won't be able to encrypt the signature properly. The recipient will decrypt it to garbage and notice that it doesn't verify. (Although my original reason for encrypting the signature exchange was to protect the identities of the parties, it now seems to have other uses.) So this puts your protocol in the same boat as Photuris: if the DH secret component is compromised then the protocol is broken. This is the crux of the problem. There seems to be no way to reconcile my desire to minimize online delay by computing signatures in advance with the stated need to sign something in real time with a well-protected secret. Comments? >As Hugo mentioned, attacks are not about fairness. One could make the same >argument about protocols that dont support perfect forward secrecy, i.e, I know, I know, I typed hastily. Attacks are never "fair" in the sense that your opponent will always try anything that's possible. I was trying to make the point that *any* cryptographic system has to rely on *something* being secret, i.e., a key. Sure, you can design it to minimize the damage done if a key leaks out, but you can't eliminate it entirely. I don't care how good your protocol is; if I know it, your crypto algorithms and *all* your keys (long and short term), I think I can break it. :-) Once again, we have to consider the threat model. In the real world, which threats are credible and which aren't? Comments? Phil From ipsec-request@ans.net Tue Feb 21 12:54:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19295 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 09:14:35 -0500 Received: by interlock.ans.net id AA26384 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 09:00:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Feb 1995 09:00:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 09:00:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 09:00:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 09:00:50 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 09:00:50 -0500 Date: 21 Feb 95 06:54:00 -0600 To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP Message-Id: >Things have quieted down on this list about AH and ESP, so I have to >assume we are ready to implement. I'm working on integrating Ran's IPv6 >changes into the text. Are there any other issues still unresolved? > >Bill.Simpson@um.cc.umich.edu There is no reason to have two IPv4 security protocols! There should only be one protocol (per San JOse discussions) that provides confidentiality, integrity (a.k.a. authentication), or confidentiality and authentication. The IPv6 Authentication only protocol already meets the proposed needs of IPv6. Paul From ipsec-request@ans.net Tue Feb 21 15:31:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18897 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 10:44:53 -0500 Received: by interlock.ans.net id AA38991 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 10:31:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 10:31:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 10:31:33 -0500 Date: Tue, 21 Feb 1995 10:31:12 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Paul_Lambert-P15452@email.mot.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Paul, While I am far from agreeing with everything that Bill Simpson writes, even on the limited topic of ipsec, I think it would be a fine idea to have a couple of complete documented proposals to debate. While there are pros and cons of this, I think the positive aspects of the development of each proposal sparking ideas and energy in both itself and the other proposal and the posibilities for such things as deciding on a final protocol mostly from column A with a few items from column B outweigh the problems. Donald On 21 Feb 1995 Paul_Lambert-P15452@email.mot.com wrote: > Date: 21 Feb 95 06:54:00 -0600 > From: Paul_Lambert-P15452@email.mot.com > To: bsimpson@morningstar.com, ipsec@ans.net > Subject: Re: WG last call for IPv4 AH and ESP > > > >Things have quieted down on this list about AH and ESP, so I have to > >assume we are ready to implement. I'm working on integrating Ran's IPv6 > >changes into the text. Are there any other issues still unresolved? > > > >Bill.Simpson@um.cc.umich.edu > > > There is no reason to have two IPv4 security protocols! > > There should only be one protocol (per San JOse discussions) that provides > confidentiality, integrity (a.k.a. authentication), or confidentiality and > authentication. > > The IPv6 Authentication only protocol already meets the proposed needs of IPv6. > > > Paul > ===================================================================== Donald E. Eastlake 3rd 1-508-287-4877(tel) dee@cybercash.com 318 Acton Street 1-508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA From ipsec-request@ans.net Tue Feb 21 16:06:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14866 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 11:21:40 -0500 Received: by interlock.ans.net id AA63257 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 11:06:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 11:06:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 11:06:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 11:06:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 11:06:52 -0500 Message-Id: <9502211606.AA00954@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "21 Feb 1995 06:54:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Feb 1995 11:06:18 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > >Things have quieted down on this list about AH and ESP, so I have to > >assume we are ready to implement. I'm working on integrating Ran's IPv6 > >changes into the text. Are there any other issues still unresolved? > > There is no reason to have two IPv4 security protocols! > There should only be one protocol (per San JOse discussions) that provides > confidentiality, integrity (a.k.a. authentication), or confidentiality and > authentication. There is just one protocol. The ESP and AH headers are two different headers, but they function in substantially identical ways. There is a need for a transparent authentication only header which the AH provides -- ESP provides for either confidentiality or confidentiality and authentication. This was all decided on a long time ago. Steve Bellovin explained in detail in Toronto why we needed both. Other people agreed with him. Both headers were present in the IPv6 specification. After about a day of detailed discussion in Toronto, the various members of the working group, both in and out of formal session, ended up re-deriving the IPv6 protocols and decided to simply adopt a functional equivalent for IPv4. This is the recollection of substantially everyone from Toronto I have spoken to. I will repeat -- this was all decided on a long time ago, in Toronto. The drafts Bill Simpson and I produced substantially follow the consensus on protocols derived in Toronto and the consensus on security transforms from San Jose. (There is still a combined Auth-Confidentiality transform draft missing, but we intend to produce it.) There has been no discussion or dispute concerning the underpinnings of the protocol for the last two months since these drafts came out, until your last message. There was substantial agreement, in fact. There have been disputes concerning details like whether the key should be both pre and postpended in the MD5 keyed auth case and the like, but there has been no public dispute concerning the basics of the drafts. I will note that the IPSEC working group is viewed with disdain by the IETF for its inability to come to consensus. There has been talk of disolving the group because of this inability. We now have a consensus, and I would say that the notion of attempting to alter it at this late a date, with several implementations pending and with the next IETF meeting only a month or so away, is contentious and dangerous. If you wish to make this into a sufficiently big issue to prevent the committee from completing its work, you doubtless can find ways to do so -- in your privileged position as chair there are no end of dilatory tactics you could employ -- but this would be manifestly against the interests and desires of the community. Perry From ipsec-request@ans.net Tue Feb 21 16:18:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18852 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 12:45:51 -0500 Received: by interlock.ans.net id AA21212 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 12:26:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Feb 1995 12:26:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 12:26:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 12:26:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 12:26:22 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 12:26:22 -0500 Date: 21 Feb 95 10:18:00 -0600 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[2]: WG last call for IPv4 AH and ESP Message-Id: >> There is no reason to have two IPv4 security protocols! > >> There should only be one protocol (per San JOse discussions) that provides >> confidentiality, integrity (a.k.a. authentication), or confidentiality and >> authentication. > >There is just one protocol. The ESP and AH headers are two different >headers, but they function in substantially identical ways. There is >a need for a transparent authentication only header which the AH >provides -- ESP provides for either confidentiality or confidentiality >and authentication. Do these two header formats share the same protocol number? The IPv4-AH header that you propose meets the basic format requirements of the IPv6-AH protocol. There is no need for both! Other than this minor point the encapsulation formats still should directly correspond to our last meeting. We are not in that far off on technical issues. < acrimonious maledictions skipped > >If you wish to make this into a sufficiently big issue to prevent the >committee from completing its work, you doubtless can find ways to do >so -- in your privileged position as chair there are no end of >dilatory tactics you could employ -- but this would be manifestly >against the interests and desires of the community. Please Perry, no need to get personal. As chair I have been exceedingly quiet in pressing any personal opinions. Your vitriolic ramblings do the group a disservice. Paul From ipsec-request@ans.net Tue Feb 21 18:44:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23394 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 13:58:29 -0500 Received: by interlock.ans.net id AA59861 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 13:45:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 13:45:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 13:45:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 13:45:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 13:45:49 -0500 Message-Id: <9502211844.AA01228@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[2]: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "21 Feb 1995 10:18:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Feb 1995 13:44:15 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > >There is just one protocol. The ESP and AH headers are two different > >headers, but they function in substantially identical ways. There is > >a need for a transparent authentication only header which the AH > >provides -- ESP provides for either confidentiality or confidentiality > >and authentication. > > Do these two header formats share the same protocol number? If you have read the drafts, then this is obviously a rhetorical question. > The IPv4-AH header that you propose meets the basic format > requirements of the IPv6-AH protocol. There is no need for both! Yes there is. The AH header is transparent, the ESP header is non-transparent. The need for both was discussed in enormous detail by Steve Bellovin in Toronto. It also follows our general attempts to be as reasonably compatible with the IPv6 formats as possible, which was also part of the Toronto consensus. > Other than this minor point the encapsulation formats still should directly > correspond to our last meeting. We are not in that far off on technical > issues. No, we aren't. However, you refused repeatedly to discuss the matter with me. > < acrimonious maledictions skipped > > > Please Perry, no need to get personal. As chair I have been > exceedingly quiet in pressing any personal opinions. Your vitriolic > ramblings do the group a disservice. My "vitriolic ramblings" are not without cause. I have attempted to discuss our "small technical differences" many times, both in public and in private. I include the dinner I invited you to in San Jose where you said nothing, forcing the rest of the people at dinner to chit chat rather than discuss anything subtantive. I include the three attempts I made to meet with you in the San Jose terminal room, where you very diplomatically stated only that our differences were small but refused to say anything substantive.I also include the electronic mail I've sent you on these matters in the two and a half months since which you have not seen fit to reply to. (I am happy in retrospect that I cc'ed that mail to Jeff Schiller.) You are correct that you've been very quiet in pressing your opinions -- but that doesn't mean you haven't been obdurate in them as well. If, however, you would like to discuss the matter now, let us do so. I have had an open door for nearly three months. I will note, though, that there is very little time. To quote Jeff Schiller, "The internet is bleeding." There is a need to deploy this system within months -- a real need, given the active attacks in use on the internet today. There are to my knowledge several implementation efforts already in progress. I do not think that there is much time for a redesign. I will further note that no one other than you has thus far stated an objection to the use of the IPv6 formats, which was the consensus in Toronto. No one has stated any serious objection to the proposed security transforms other than the prefix vs. suffix hash keying dispute -- which along with some other algorithm discussion remains one of our few legitimately open issues. Perry From ipsec-request@ans.net Tue Feb 21 20:31:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20324 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 17:22:57 -0500 Received: by interlock.ans.net id AA07928 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 16:28:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 16:28:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 16:28:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 16:28:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 16:28:59 -0500 Date: Tue, 21 Feb 1995 12:31:41 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502212031.AA06344@miraj.> To: ipsec@ans.net, bsimpson@morningstar.com Subject: Re: WG last call for IPv4 AH and ESP X-Sun-Charset: US-ASCII > From: "William Allen Simpson" > > Things have quieted down on this list about AH and ESP, so I have to > assume we are ready to implement. I'm working on integrating Ran's IPv6 > changes into the text. Are there any other issues still unresolved? I have an issue. I would like to be able to do in-band signalled keys. Does the draft preclude this? If not, then I believe that there is merit in detailing how to indicate in-band keys in the protocol. Note that SKIP is not the only protocol that employs this technique. The DEC work also used the same feature (albeit in a different manner). I wouldn't be too happy to see AH/ESP protocols preclude in-band keys, especially since we haven't yet come to a decision on what the key-management protocol will be. Regards, Ashar. From ipsec-request@ans.net Tue Feb 21 21:17:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13698 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 17:24:18 -0500 Received: by interlock.ans.net id AA08097 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 16:46:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 16:46:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 16:46:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 16:46:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 16:46:57 -0500 Date: Tue, 21 Feb 1995 13:17:54 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502212117.AA06374@miraj.> To: ipsec@ans.net Subject: Re: comments on Photuris X-Sun-Charset: US-ASCII > From karn@unix.ka9q.ampr.org Tue Feb 21 02:09 PST 1995 > You said that you could sign the DH public key in your protocol with, > say, PGP. But how does this really differ from Photuris, where I also > sign a DH public part with RSA? The main difference is that I > regularly generate new DH public/private pairs while you consider them > to be fairly static. This may admittedly be a *practical* advantage in > that your DH public keys can be signed offline in a presumably more > secure fashion than my ephemeral DH keys, which have to be signed > online because they change frequently. This may make the signature > function somewhat more vulnerable to compromise. Yes, I think the practical issues are substantial. The SKIP use of long-term DH is significantly different that the signing of ephemeral DH values. It is one single DH value you have to be sure about. As such, its integrity check is a bootstrap issue. This bootstrap operation can be augmented with whatever level of security one wishes to associate with bootstrapping in general. For example, just like one publishes (and communicates) the MD5 hash of one's long-term RSA key, one can publish and communicate (out-of-band) the MD5 hash of one's long-term DH key. Also, just like one can have multiple signers of people's long-term RSA keys (e.g. as in PGP's web-of-trust), one can have multiple signers of people's long-term DH keys. It is significantly harder to subvert all these mechanisms. Naturally, one cannot do all of this for the sake of every signed ephemeral DH key. Furthermore, when used with a conventional CA hierarchy, the CAs (who sign the DH values) can be offline. This is a significant level of protection for the private key of a CA, since it is never required to be in a machine that can be penetrated using network intrusion techniques. By contrast, the signing of ephemeral DH values (as e.g. in Photuris) is necessarily online and hence easier to subvert; especially since the subversion does not have to happen in real time and only needs to happen once to indefinitely spoof the protocol. I think the practicality of what an attacker has to do in both cases is a very significant consideration, beyond just the seeming equivalence of some mathematical operations. Regards, Ashar. From ipsec-request@ans.net Tue Feb 21 22:25:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22642 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 18:44:48 -0500 Received: by interlock.ans.net id AA06339 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 18:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 18:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 18:28:31 -0500 Date: Tue, 21 Feb 1995 15:25:18 -0700 (PDT) From: Derrell Piper Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message dated "Tue, 21 Feb 1995 12:31:41 -0800" <"9502212031.AA06344"@miraj> To: ashar@osmosys.incog.com Cc: ipsec@ans.net, bsimpson@morningstar.com Message-Id: <01HNBDX8JX3I00002N@BILBO.TGV.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I agree with this. I'd like to make sure that in-band keys are possible. Derrell Derrell Piper | piper@tgv.com | Tech Support: +1 408 457 5201 TGV, Inc. | 101 Cooper Street | Santa Cruz, CA 95060 USA From ipsec-request@ans.net Tue Feb 21 13:18:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24029 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 19:20:23 -0500 Received: by interlock.ans.net id AA10233 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 19:07:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 19:07:33 -0500 Message-Id: <199502220007.AA10485@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 19:07:33 -0500 Date: Tue, 21 Feb 95 18:18:42 EST From: hugo@watson.ibm.com To: ashar@osmosys.incog.com, ipsec@ans.net Subject: WG last call for IPv4 AH and ESP Ref: Your note of Tue, 21 Feb 1995 12:31:41 -0800 (attached) > I have an issue. I would like to be able to do in-band signalled > keys. Does the draft preclude this? If not, then I believe that I think Ashar is right about not precluding in-band keys. The one change I believe may help this is to define two kind of SAIDs: structured and unstructured. Unstructured SAIDs are the usual ones, i.e. chosen by the local implementation and transmitted to the other party; they are the perfect mechanism when keys are established interactively (as should be the prevalent case). Structured SAIDs are necessary in case of non-interactive establishment of keys (e.g., when establishing in-band keys as proposed in the SKIP draft). In this case, there should be some semantics to the SAID (e.g., pointer to specific transformations, possibly a seq number, etc) understandable by both sender and receiver. All what is needed to support both kinds of SAIDs is just one bit that determines whether the SAID is structured or not. For example, a least significant bit of 0 will mean unstructured and lsb of 1 means structured. In particular, the current range of "reserved SAIDs" would fall in the structured category. This still leaves 31 free bits for unstructured SAIDs which should be enough. In addition to the mentioned use for in-band signalled keys, structured SAIDs can be used for periodic non-interactive refreshment of shared keys. For example, two parties may decide that each two hours they refresh their keys by applying to the current key a one-way transformation. (This way a compromised key does not compromise past keys). For such a mechanism one may want to add some counter to the SAID structure in order to point to the correct key. Hugo From ipsec-request@ans.net Wed Feb 22 00:32:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22741 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 19:47:38 -0500 Received: by interlock.ans.net id AA24718 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 19:35:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 19:35:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 19:35:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 19:35:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 19:35:22 -0500 Date: Tue, 21 Feb 1995 16:32:54 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502220032.AA06440@miraj.> To: ipsec@ans.net, hugo@watson.ibm.com Subject: Re: WG last call for IPv4 AH and ESP X-Sun-Charset: US-ASCII > From hugo@watson.ibm.com Tue Feb 21 16:12 PST 1995 > I think Ashar is right about not precluding in-band keys. > The one change I believe may help this is to define two kind of > SAIDs: structured and unstructured. Yes, I agree completely that this is the right approach. This solves the problems of zero-message stepping the master key, as well as indicating the modes of operation. Regards, Ashar. From ipsec-request@ans.net Wed Feb 22 01:02:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18398 (5.65c/IDA-1.4.4 for ); Tue, 21 Feb 1995 20:11:37 -0500 Received: by interlock.ans.net id AA03017 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 20:02:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Feb 1995 20:02:58 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 20:02:58 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 20:02:58 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 20:02:58 -0500 X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 20:02:58 -0500 Date: Tue, 21 Feb 1995 20:02:11 -0500 X400-Originator: mleech@bcarh6dc.ott.bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.343:22.01.95.01.02.11] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: WG last c... From: "marcus (m.d.) leech" Message-Id: <"25349 Tue Feb 21 20:02:14 1995"@bnr.ca> To: PIPER@bilbo.tgv.com Cc: ipsec@ans.net In-Reply-To: <01HNBDX8JX3I00002N@BILBO.TGV.COM> Subject: Re: WG last call for IPv4 AH and ESP Organization: Bell-Northern Research, Information Technology Division X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1498 -----BEGIN PGP SIGNED MESSAGE----- > I agree with this. I'd like to make sure that in-band keys are possible. > > Derrell > > I'd like to put in my two-cents worth for avoiding further complication in the existing drafts. At the neither the Toronto, nor the San Jose meetings, did this issue come up. I have been under the assumption that there was an implicit understanding that a key-management protocol would eventually emerge, and that the "encapsulation" drafts should proceed with that assumption. I think that we would be doing a great dis-service to an already very-late process to introduce further complications like in-band key change to a pair of proposals that are seeming to solidify very rapidly. The beauty of the existing drafts (AH and ESP) is that they can operate in either a manual or automatically-managed key management environment. This is, in my opinion, a great step forward. I'm getting frustrated watching this process get derailed, frequently, by what to the casual observer seems like creeping featurism... -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBL0qNCKp9EtiCAjydAQF9ZAIAg9hab+1AAt5C08U2ycntvTPZ4kSiQZJO J3fbUNpAQt6eQhWJQvpIgesLT+xVl7GYHJ2n8vdYYhipjcd4OVwm/g== =EcgT -----END PGP SIGNATURE----- -- Marcus Leech |Any opinions expressed are mine. |+1 613 763 9145 VE3MDL | and not those of my employer |+1 613 567 5484 mleech@bnr.ca | | From ipsec-request@ans.net Wed Feb 22 12:51:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22666 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 08:03:44 -0500 Received: by interlock.ans.net id AA12660 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 07:52:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 07:52:39 -0500 From: Ran Atkinson Message-Id: <9502220751.ZM6453@bodhi> Date: Wed, 22 Feb 1995 07:51:53 -0500 In-Reply-To: ashar@osmosys.incog.com (Ashar Aziz) "Re: WG last call for IPv4 AH and ESP" (Feb 21, 12:31) References: <9502212031.AA06344@miraj.> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Ashar Aziz , ipsec@ans.net, bsimpson@morningstar.com Subject: Re: WG last call for IPv4 AH and ESP Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Ashar, Put your key mgmt stuff on its own UDP port and it will work fine. ESP and AH do not and have never been intended to include key mgmt data at the IP-layer. There is no need for such modifications and they would violate the design goal of keeping those specifications entirely independent of any specific key management protocol. Such independence is critical given the long history of key management protocol vulnerabilities discovered long after initial public review (for a well known example, trace the history of Needham & Schroeder 1978, then Denning & Sacco 1981, then Needham & Schroeder 1981, etc.) The IPv6 Security Architecture document makes it explicitly clear that support for in-band key management is not a design goal and that independence from any particular key management (i.e. couple them only via SAIDs) is an explicit design goal. I believe there is in fact rough consensus in this WG that Photuris is the direction to take for a 'mandatory to implement' standards-track key mgmt protocol. In any event, there can be "elective standards" which are not mandatory to implement or also non-standard but openly specified key management protocols, so folks wanting to use something else are certainly free to do so. Under IETF rules, we do not need unanimity and votes are considered anathema. NRL intends to make its implementation of Photuris (or another freely distributable one if someone has one that we can include) freely distributable as part of the NRL IPv6 distribution. We intend to use RSAREF to make sure the result is freely distributable. It is likely that NRL will have BSD-like license terms. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Feb 22 14:26:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17825 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 09:40:03 -0500 Received: by interlock.ans.net id AA21403 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 09:28:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 09:28:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 09:28:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 09:28:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 09:28:35 -0500 Message-Id: <9502221426.AA02326@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Tue, 21 Feb 1995 12:31:41 PST." <9502212031.AA06344@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Feb 1995 09:26:16 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > > From: "William Allen Simpson" > > > > Things have quieted down on this list about AH and ESP, so I have to > > assume we are ready to implement. I'm working on integrating Ran's IPv6 > > changes into the text. Are there any other issues still unresolved? > > I have an issue. I would like to be able to do in-band signalled > keys. Does the draft preclude this? I don't understand what you mean by in-band signaled keys. If you can explain precisely what you mean better I can answer better. Perry From ipsec-request@ans.net Wed Feb 22 05:01:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22813 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 10:29:38 -0500 Received: by interlock.ans.net id AA27051 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 10:16:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 10:16:59 -0500 Message-Id: <199502221516.AA26790@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 10:16:59 -0500 Date: Wed, 22 Feb 95 10:01:27 EST From: hugo@watson.ibm.com To: atkinson@itd.nrl.navy.mil, ashar@osmosys.incog.com, ipsec@ans.net, bsimpson@morningstar.com, mleech@bnr.ca Subject: WG last call for IPv4 AH and ESP Ref: Your note of Wed, 22 Feb 1995 07:51:53 -0500 (attached) Ran and Marcus, I can't agree more with you that IPSP needs to be independent from the specific key management protocols. It is the sole responsibility of SAIDs to provide the interface to key management. However this independence principle is not violated by what Ashar requested. As I said in a previous note, the only change you need to current draft is to specify one bit of the SAID as meaning "structured" and "non-structured". (Nothing else. Not even a single specification for the "structure" of structured SAIDs) Not only this provides for in-band keys but provides additional flexibilty to the potential key-management protocols (An example of such added flexibility was mentioned in my previous note on this issue; it allows improving perfect forward secrecy of session keys, a seemingly widely accepted goal of this group. I can explain more if needed). And it preserves 100% INDEPENDENCE! Hugo From ipsec-request@ans.net Wed Feb 22 15:27:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17654 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 10:42:12 -0500 Received: by interlock.ans.net id AA27990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 10:30:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 10:30:02 -0500 From: Ran Atkinson Message-Id: <9502221027.ZM6548@bodhi> Date: Wed, 22 Feb 1995 10:27:01 -0500 In-Reply-To: hugo@watson.ibm.com "WG last call for IPv4 AH and ESP" (Feb 22, 10:01) References: <9502221516.AA11025@itd.nrl.navy.mil> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Perfect forward secrecy can be achieved without having either in-band key mgmt or structured SAIDs. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Feb 22 16:24:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14801 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 11:37:08 -0500 Received: by interlock.ans.net id AA26333 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 11:25:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 22 Feb 1995 11:25:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 11:25:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 11:25:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 11:25:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 11:25:10 -0500 Date: Wed, 22 Feb 1995 08:24:22 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502221624.IAA22942@elrond.Eng.Sun.COM> To: ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ashar@jurassic.eng.sun.com, Danny.Nessett@eng.sun.com X-Sun-Charset: US-ASCII Ran, Please excuse the intrusion into an already existing conversation, but since I may have been the ultimate cause of Ashar's request about in-band signalling, I feel somewhat responsible to explain. I have been looking at the IPv6 security I-Ds and previous email on that list. In particular, some discussion seems to suggest that there is a requirement to protect ICMP messages, although it isn't clear which ICMP messages require it. I spoke with Bill Simpson at the last IPv6 meeting in Palo Alto and he believes only end-to-end ICMP messages are candidates (for IPv6). Whether this is true or not for IPv4 is unclear. Others may believe that ICMP messages from intermediate routers also should be protected. If that is true, then relying on pre-existing SAIDs isn't going to scale. A source cannot possibly know the identity of all the intermediate routers between itself and the destination of an IP packet. It is even less likely that it will have a pre-existing SAID with that router. Consequently, if ICMP messages from intermediate routers require protection and it is a requirement that ICMP messages be processed in a timely manner, some way must exist for the intermediate router to return keying material to the source of the IP packet, material that can be used to establish an SAID "on the fly." This is one reason why "in-band signalling" is important. There are other reasons, but I think this one is enough to motivate the discussion. Regards, Dan From ipsec-request@ans.net Wed Feb 22 06:00:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14706 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 12:25:29 -0500 Received: by interlock.ans.net id AA28245 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 12:10:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 12:10:27 -0500 Message-Id: <199502221710.AA36942@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 12:10:27 -0500 Date: Wed, 22 Feb 95 11:00:56 EST From: hugo@watson.ibm.com To: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: WG last call for IPv4 AH and ESP Ref: Your note of Wed, 22 Feb 1995 10:27:01 -0500 (attached) Ran, please read this. When you say that > Perfect forward secrecy can be achieved without having either > in-band key mgmt or structured SAIDs. you mean achieving it via Diffie-Hellman. Agreed. Also agreed by all (?) is that DH is not cheap. For example, Photuris, which you claim to have rough consensus, chooses to have "shortcuts" (replayable signatures, short exponents) only to alleviate that complexity. The meaning of DH being expensive is that you will do key refreshments less frequently. Let say each 12 hours. It means that stealing a key allows the adversary to decrypt 12 hours of communication (just by eavesdropping, no need for active impersonation). Wouldn't it be nice if you can somehow limit the damage to less time. Well, yes, depends on the cost. A very cheap way to achieve this is that each, say 2 hours (or 5 minutes if you want), both parties refresh their current key by applying to it a one-way function (i.e., with negligible computational cost). This requires no interaction. Now let say that the adversary breaks at 6:30 PM and the last DH was at 12 noon.The adversary will be able to decrypt information exchanged from 6pm to midnight, but not from before 6pm. Moreover, for algorithms that are weak or not well-proven to be secure (very efficient algorithms may be such) a frequent key exchange is a great idea. Now, if I change my key non-interactively from time to time I want a means to tell that to the other party to guarantee synchronization; a minimally structured SAID will do. Truth is that I prefer even these frequent changes to be done interactively, since these interactions can be very efficient (see MKMP). In that case no need for structured SAIDs, and security is even better (the above eavesdropper will learn only information from 6 to 8, and will have to mount an active attack if he wants to learn information transmitted from 8 to 12). But if some people will want to do the non-interactive refreshment, then why to prevent that from them? In a more general note, if one can add significant flexibility by "paying" with only 1 bit of SAID, why not to provide that? Do you see any "hidden cost" in requiring unstructured SAID to have one fixed bit? Hugo From ipsec-request@ans.net Wed Feb 22 07:26:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29622 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 12:39:43 -0500 Received: by interlock.ans.net id AA13385 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 12:26:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 12:26:19 -0500 Message-Id: <199502221726.AA33605@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 12:26:19 -0500 Date: Wed, 22 Feb 95 12:26:15 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: comments on Photuris Ref: Your note of Tue, 21 Feb 1995 02:08:36 -0800 (attached) >I still prefer the option of signing nonces chosen by the other party. >It is more secure (time sync considerations, granularity of frshness, etc.) >However, for parties that periodically refresh their keys there is no reason >not to maintain a nonce sent in the previous refreshment round; in that case Suppose I add a rule to Photuris that says you should use an existing SAID whenever possible to encrypt the exchanges that create a new SAID. Would this give you some of the same sort of protection against partial compromises that you get with explicit key refreshment? Phil Phil, Yes. It definitely adds protection. Let me be more explicit on this. Your suggestion brings up several issues that Amir and myself talked about in past notes with not much echo... ;-) If I understand correctly, what you mean is basically having two (simultaneous) ways to authenticate a key exchange. One is using signatures, the other using the previously shared key between the parties. (Notice that when you say "encryption" using the previous key what you really want to achieve is authentication, otherwise encrypting with the just exchanged key, as you do in the current draft, is good enough for anonymity). In my opinion doing both, i.e authentication with MAC_K (where K is the previously shared key and MAC a shared key authentication algorithm like keyed-MD5) and a signature using the private key is the best combination from the security point of view. It gives 1) defense against clogging: a simple MAC on the DH parts (e.g. MAC_K(g^x)) let you cheaply verify that the right guy is talking to you (Notice that in order to verify MAC_K(g^x) you need to know who is communiacting to you and this may seem to contradict your requirement for anonymity; this issue can be solved too but let's postpone it). 2) chaining: authentication requires knowing the previous (transient) key, thus even an adversary that stole a private key in the past needs a piece of current information for authentication. Even if an adversary has all the information to do a successful impersonation, a later intent to exchnage a key by the legitimate party will detect the intrusion. 3) Authentication is private-key dependent. If you keep your private key well protected there is no way to impersonate you 4) Even if the attacker breaks into A (but not into B) it cannot impersonate B to A. I believe this to be an important property of a good key management protocol. It is analogous to the approach to passwords in UNIX: an attacker breaking into the server that verifies your password cannot later impersonate you to the server. This is in sharp contrast to servers that keep a file with the passwords. In the latter case the attacker will learn the passwords and be able to impersonate *any* user to that server. Notice that properties 1 and 2 are achieved by the use of MAC, while 3 and 4 by use of signatures. Therefore the two mechanisms are complementary. Because of the cheap cost of MAC it is worthwhile doing it even if you do signatures too. A harder question is whether it is worthwhile doing the signature if you're already doing the MAC. The clear advantage of not doing the signature is one less exponentiation. The disadvantage is the loss of properties 3 and 4. There is no universal trade-off here. (For example, the signature exponentiation comes as a third exponentiation (after g^x and g^(xy)), which means that it adds at most 50% to the computation; this will be significant in some places and not at all in some other). I believe that what you propose is indeed to do both mechanisms. (We can discuss the issue of MAC vs encryption later). You deal with the above computational tradeoff by doing the signature off-line and giving up on the freshness of the signature itself. I must say that doing this, together with the off-line signatures containing an expiration time may represent the right trade-off in many cases. Finally, I want to argue that it is importnat that we come up with a scheme that, beyond its default mechanisms, will allow for tuning the level of security, freshness, etc depending on the specific parties and scenarios. This would be open to negotiation between the parties and may range from MAC-only authentication to MAC+signature+nonces. Comments? Hugo PS: all of the above does not say how you do your first exchange with a party. Such exchange is needed when you do not have a previous key with that party, or when you lose that transient key. The latter, can always be claimed to be the case by an adversary trying to bypass the chaining mechanism. But this still gives a good opportunity for logging and auditing these events. From ipsec-request@ans.net Wed Feb 22 18:29:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27253 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 13:43:11 -0500 Received: by interlock.ans.net id AA16699 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 13:30:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 13:30:50 -0500 From: Ran Atkinson Message-Id: <9502221329.ZM6722@bodhi> Date: Wed, 22 Feb 1995 13:29:41 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: WG last call for IPv4 AH and ESP" (Feb 22, 8:24) References: <199502221624.IAA22942@elrond.Eng.Sun.COM> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, For that particular case (intermediate router sending an ICMP message and desiring to authenticate the ICMP message back to the sender), if a Security Association does not exist the router could sign it using its private key that is associated with its Eastlake-Kaufman signed public key available from the DNS and an RSA signature. This scales as well as the DNS and hence as well as the Internet as a whole. This tends to confirm my prior existing belief that a non-mandatory, but openly specified RSA Signature type should be defined for use with AH. I have not created such a type yet for lack of time, but would be happy to include one as a non-mandatory to implement "Appendix B" in my IPv6 AH draft if someone supplied a spec that would be implementable using RSAREF. So I still do not believe that in-band key management is either necessary or desirable in this case. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Feb 22 02:47:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28512 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 14:03:42 -0500 Received: by interlock.ans.net id AA10047 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 13:48:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 13:48:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 13:48:54 -0500 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey SysAdm) Message-Id: <9502221847.AA22875@slced1> Subject: Re: Triple DES passed ANSI X9 To: shirey@mitre.org (Robert W. Shirey) Date: Wed, 22 Feb 95 10:47:47 PST Cc: psrg@isi.edu, pem-dev@tis.edu, ipsec@ans.net, secdir@tis.com, p1363@RSA.COM In-Reply-To: ; from "Robert W. Shirey" at Feb 19, 95 9:47 pm Reply-To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II ) X-Orgztn: PHD NSWC (NSWSES) 4A05 Port Hueneme, CA 93043 - Opinions: Only Mine X-Phones: 805.982.7180, DSN 551, VoiceMail 805.340.6471, DPage: 655.2017 X-Mailer: ELM [version 2.3 PL11] Re the EFF/CDT Letter on 3X DES vs NSA Alternative .. Is it reasonable to infer that the use of open encryption standards has to do with the free movement of commerce across international boundaries .. like EFTs of money and the ability to trade easily and cost effectively with our international neighbors VICE having a very costly and difficult process moving money to pay for goods/trade across international borders ? Think I saw some of that on recent travels and in conversations with folks who bank in other countries. It would almost seem ambiguous at best to interfere with free trade and exchange and at the same time claim to promote it. If this is a horribly naive notion, please, calibrate me. -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.cotdazr.org efb@gcpacix.uucp + + efb@nosc.mil efb@oxnardsd.org [EFB15] WA6CRE Gold Coast Sun Users + + The Genie is Out of the Bottle! :-) CANT Put it Back, Nor even Nuke It + + Opinions, MINE, NOT Uncle_s | WWW b-news innd postmaster XNTP3 DNS GNU + From ipsec-request@ans.net Wed Feb 22 19:39:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12984 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 14:53:05 -0500 Received: by interlock.ans.net id AA40115 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 14:42:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 14:42:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 14:42:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 14:42:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 14:42:00 -0500 Date: Wed, 22 Feb 1995 11:39:29 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502221939.AA06784@miraj.> To: atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Feb 22 05:41 PST 1995 > Ashar, > > Put your key mgmt stuff on its own UDP port and it will work fine. I am not sure how putting a zero-message key-management protocol on a separate UDP port helps. What will the port be used for? > ESP and AH do not and have never been intended to include key mgmt > data at the IP-layer. There is no need for such modifications and > they would violate the design goal of keeping those specifications > entirely independent of any specific key management protocol. Such > independence is critical given the long history of key management > protocol vulnerabilities discovered long after initial public review > (for a well known example, trace the history of Needham & Schroeder > 1978, then Denning & Sacco 1981, then Needham & Schroeder 1981, etc.) > The IPv6 Security Architecture document makes it explicitly clear that > support for in-band key management is not a design goal and that > independence from any particular key management (i.e. couple them only > via SAIDs) is an explicit design goal. As currently specified, the protocols are not independent of key-management. They assume a certain kind of key management and preclude other kinds. I am not saying that a particular kind of key-management should be mandated. I am saying that a particular kind of key-management should be *permitted*. > I believe there is in fact rough consensus in this WG that Photuris > is the direction to take for a 'mandatory to implement' standards-track > key mgmt protocol. Well I am not sure how to guage this, but this statement seems to be inconsistent with your statements above. Namely, if even after a long review key-management protocols can contain weaknesses, how can the WG be assured that given the short amount of time that Photuris has been reviewed that it doesn't contain serious flaws? As I recall, the Photuris draft was published the day the last IETF meeting began. Apart from people who may have looked at previews of it, the rest of the WG certainly could not have done an extensive analysis of it for the last IETF meeting. This only then leaves e-mail discussions, of which the only round I recall were those that discussed vulnerabilities of the Photuris approach. I think it would be a great disservice to this group to ramrod a particular approach without considering all the issues, and without a careful analysis of the various pros and cons. An example of the sort of issues that need to be considered is the example of protected ICMP messages that Dan Nessett raised. Based on what I have seen so far on this mailing list and the various IETF ipsec meetings, I dont believe that the required analysis has taken place; and it certainly hadn't taken place by the time of the last IETF meeting, which would've the only time a rough consensus could have been guaged. (As it turned out, the protocol that was presented at the IETF meeting did in fact contain serious weaknesses, as acknowledged by Phil). Regards, Ashar. From ipsec-request@ans.net Wed Feb 22 19:48:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23630 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 15:02:19 -0500 Received: by interlock.ans.net id AA41279 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 14:50:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 14:50:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 14:50:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 14:50:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 14:50:39 -0500 Date: Wed, 22 Feb 1995 11:48:06 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502221948.AA06792@miraj.> To: perry@imsi.com Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Feb 22 07:12 PST 1995 > > I have an issue. I would like to be able to do in-band signalled > > keys. Does the draft preclude this? > > I don't understand what you mean by in-band signaled keys. If you can > explain precisely what you mean better I can answer better. What I mean by in-band is that the traffic key comes encrypted in the IPSP header. This approach is used in SKIP, and also by the DEC network layer security work done by Charlie Kaufmann et al. Ashar. From ipsec-request@ans.net Wed Feb 22 19:45:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22547 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 15:32:34 -0500 Received: by interlock.ans.net id AA41306 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 15:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 22 Feb 1995 15:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 15:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 15:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 15:15:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 15:15:43 -0500 Date: Wed, 22 Feb 1995 11:45:34 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502221945.LAA23054@elrond.Eng.Sun.COM> To: atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net, Danny.Nessett@eng.sun.com X-Sun-Charset: US-ASCII Ran, I didn't quite follow your reply. Specifically : > For that particular case (intermediate router sending an ICMP > message and desiring to authenticate the ICMP message back to the > sender), if a Security Association does not exist the router > could sign it using its private key that is associated with its ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Eastlake-Kaufman signed public key available from the DNS and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > an RSA signature. This scales as well as the DNS and hence > as well as the Internet as a whole. Doesn't this introduce a dependency of the routing system on DNS? That is, aren't you assuming that all routers will have signed certificates in the DNS? If so, how do you bring up a routing system without having DNS on-line to begin with? Do you bring it up unsecure and then secure it? Does this mean you can't secure it without all routers having DNS certificates? In addition I think there are a number of proposals on the table that assume an IPv4 key distribution mechanism based on signed Diffie-Hellman certificates. Since Diffie-Hellman is a key exchange protocol, you can't sign messages with the Diffie-Hellman private key. ... > So I still do not believe that in-band key management is either > necessary or desirable in this case. Given the above observations, I would say the jury is out at this point on whether in-band signalling is useful or not. I'm not saying it is, but I think we shouldn't prevent it by not accomodating its use with either the IPv4 or IPv6 security I-Ds. Cheers, Dan From ipsec-request@ans.net Wed Feb 22 20:20:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12892 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 15:35:24 -0500 Received: by interlock.ans.net id AA45855 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 15:23:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 15:23:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 15:23:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 15:23:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 15:23:54 -0500 Date: Wed, 22 Feb 1995 12:20:17 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502222020.AA06812@miraj.> To: mleech@bnr.ca Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net X-Sun-Charset: US-ASCII >From: "marcus (m.d.) leech" >> At the neither the Toronto, nor the > San Jose meetings, did this issue come up. Since I was at both meetings, and since I did present the SKIP key-management protocol which uses in-band signalled keys at both meetings, and since I did give working demos of this kind of key-management at both meetings, I can safely say that this is not true. What is true is that at both meetings there was no IPv4 SP draft, so one could not comment on a draft that did not exist. However, there was a SKIP I-D (specifying in-band signalled keys) before there was ever any IPv4 ESP/AH drafts, and before there were any ietf-ipsec drafts, period. So saying that this issue was not brought up before and is too late to be brought up now is simply not a good reason. Regards, Ashar. From ipsec-request@ans.net Wed Feb 22 20:43:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22345 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 16:04:20 -0500 Received: by interlock.ans.net id AA15134 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 15:47:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 15:47:17 -0500 From: Ran Atkinson Message-Id: <9502221543.ZM6859@bodhi> Date: Wed, 22 Feb 1995 15:43:02 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: WG last call for IPv4 AH and ESP" (Feb 22, 11:45) References: <199502221945.LAA23054@elrond.Eng.Sun.COM> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, We disagree. Also, that does not introduce a dependence of routing upon DNS. It means that standard key mgmt depends on DNS. This is reasonable since DNS is required and if DNS is broken, then many things won't work. Ran From ipsec-request@ans.net Wed Feb 22 20:53:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28580 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 16:05:49 -0500 Received: by interlock.ans.net id AA51105 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 15:53:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 15:53:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 15:53:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 15:53:46 -0500 Date: Wed, 22 Feb 1995 13:53:38 -0700 From: Hilarie Orman Message-Id: <199502222053.NAA21482@umbra.CS.Arizona.EDU> To: ipsec@ans.net Subject: Speed of DH key exchange I'd like to mention work that has been done here recently by Richard Schroeppel in implementing Diffie-Hellman key exchange using elliptic curve methods. Using an EC over F[2^155], the exponentiations in DH can be done 6 to 7 times faster than the more common implementation using integers mod 2^512. The "time-to-crack" is slightly greater for the EC case. For a 175 MHz DEC Alpha, the EC compute time is only 30 msec. This makes a considerable difference in determining how often one can afford to set a new key. It would be worthwhile to keep space in the algorithm identifier for keys to indicate what flavor of DH is being used for the key. From ipsec-request@ans.net Wed Feb 22 21:12:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22379 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 16:26:19 -0500 Received: by interlock.ans.net id AA03899 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 16:12:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 16:12:42 -0500 From: Ran Atkinson Message-Id: <9502221612.ZM6890@bodhi> Date: Wed, 22 Feb 1995 16:12:27 -0500 In-Reply-To: ashar@osmosys.incog.com (Ashar Aziz) "Re: WG last call for IPv4 AH and ESP" (Feb 22, 11:39) References: <9502221939.AA06784@miraj.> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Ashar Aziz , atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Ashar, Because key mgmt is kept separate entirely from the AH and ESP specifications, it is easy to swap out one key mgmt protocol for another without having to alter the AH or ESP implementations. It is this kind of independence which is important. Given the history of the Needham-Schroeder key mgmt protocol, I do not believe it is reasonable to insist that we wait infinite time to convince ourselves that any particular protocol is perfect. It is most sensible, and no one has suggested otherwise, to work on refining and improving the key mgmt protocol until there is rough consensus that it is "good enough". There have been MONTHS of discussions about key mgmt approaches and there is rough (not smooth, but only rough is required by IETF rules) consensus that the direction of Photuris is the right direction. It is most productive to focus efforts on refining, analysing, and improving Photuris. It is not productive to continue in the current mode of operation of endless debates between proponents since there is rough consensus about using a hybrid Diffie-Hellman algorithm in conjunction with DNS signed keys. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Feb 22 21:23:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18688 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 16:40:41 -0500 Received: by interlock.ans.net id AA33265 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 16:25:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Feb 1995 16:25:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 16:25:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 16:25:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 16:25:23 -0500 Message-Id: <9502222123.AA00638@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Wed, 22 Feb 1995 12:20:17 PST." <9502222020.AA06812@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Feb 1995 16:23:45 -0500 From: "Perry E. Metzger" Ashar Aziz says: > >From: "marcus (m.d.) leech" > >> At the neither the Toronto, nor the > > San Jose meetings, did this issue come up. > > Since I was at both meetings, and since I did present the SKIP > key-management protocol which uses in-band signalled keys at both > meetings, and since I did give working demos of this kind of > key-management at both meetings, I can safely say that this > is not true. It was mentioned in Toronto that your model at the time wasn't entirely compatible with what had been discussed for IPv4. As I recall, you stated that you felt you could easily get things to work and had no problems with what we'd said. I must admit to not having examined the SKIP drafts since then -- you will note that I haven't been an active participant in the key management discussions lately because I've been working too much on IPSP implementation. I had assumed after you refered to your current formats as being "close to IPSP" at San Jose that your problems had been resolved. > What is true is that at both meetings there was no IPv4 SP draft, > so one could not comment on a draft that did not exist. The drafts have been out for a couple of months now, though. The model was discussed in detail at the meetings you attended. I distinctly remember explaining in Toronto that the model at that time was "receiver selects arbitrary SAID during negotation". I'm not saying that your concern isn't legitimate, but you should have read them a bit earlier on. You aren't the quiet type -- you have usually stated quite loudly when you had trouble with something -- and I, for one, had been operating under the assumption that there was no problem extant with the model. My off-the-cuff reaction would be to agree with Ran and Marcus on this subject. However, I must admit that I don't know enough about the current state of SKIP to render a reasonable judgement. I promise to go over the latest draft again (possibly even tonight) and get back on this. Perry From ipsec-request@ans.net Thu Feb 23 01:37:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24071 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 21:18:12 -0500 Received: by interlock.ans.net id AA23987 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 21:13:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 21:13:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 21:13:47 -0500 Date: Thu, 23 Feb 95 01:37:19 GMT From: "William Allen Simpson" Message-Id: <3942.bsimpson@morningstar.com> To: ipsec@ans.net Subject: SKIP re-keying not enough > From: ashar@osmosys.incog.com (Ashar Aziz) > >From: "marcus (m.d.) leech" > >> At the neither the Toronto, nor the > > San Jose meetings, did this issue come up. > > Since I was at both meetings, and since I did present the SKIP > key-management protocol which uses in-band signalled keys at both > meetings, and since I did give working demos of this kind of > key-management at both meetings, I can safely say that this > is not true. > Actually, it is quite correct. The term "in-band" did not arise on the overhead projector as an item which was a stated _requirement_ of the protocol. Nor did it show up in the minutes. While I thank you for showing us your demo, I do believe that many of the principles of SKIP were not well received. Particularly the key-management distribution, or lack thereof. What you demonstrated did not include what might be considered "management", since no management took place. I remember standing up and saying that while I found the concept of relatively rapid key change to be seductive, the management of initialization and distribution was not well conceived, requires a new type of certificate not found in current databases, and has other impediments to deployment. Photuris uses currently distributed information, is independent of security transform, and provides perfect forward secrecy. It can be re-keyed in 2 minute intervals with current hardware, which is sufficient. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Feb 23 01:51:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24076 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 21:18:21 -0500 Received: by interlock.ans.net id AA26297 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 21:13:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 21:13:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 21:13:49 -0500 Date: Thu, 23 Feb 95 01:51:06 GMT From: "William Allen Simpson" Message-Id: <3943.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Photuris re-keying I do wish people would chnage the suject line when they change the subject. > From: hugo@watson.ibm.com > When you say that > > Perfect forward secrecy can be achieved without having either > > in-band key mgmt or structured SAIDs. > you mean achieving it via Diffie-Hellman. Agreed. > > The meaning of DH being expensive is that you will do key refreshments > less frequently. Let say each 12 hours. Let us not! Current plans are 2 to 5 minutes on inexpensive (386-16) software and hardware. > A very cheap way to achieve this is that each, say 2 hours (or 5 minutes if you > want), both parties refresh their current key by applying to it a one-way > function (i.e., with negligible computational cost). This requires no > interaction. Actually, as Phil has already pointed out, Photuris can easily be extended with another message pair to re-key in such a way on the order of seconds. Do we need re-keying on the order of seconds? > Now, if I change my key non-interactively from time to time I want a means to > tell that to the other party to guarantee synchronization; a minimally > structured SAID will do. > But, as several people have pointed out, there is no need to "structure" the SAID. Merely sending the Photuris update packet exchange will do the same thing, in approximately the same bandwidth, and exactly the same number of exchanges as a "non-interactive" exchange. > Truth is that I prefer even these frequent changes to be done interactively, > since these interactions can be very efficient (see MKMP). In that > case no need for structured SAIDs, and security is even better Yes, this is probably the right thing to do. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Feb 23 01:21:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31758 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 21:18:22 -0500 Received: by interlock.ans.net id AA33197 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 21:13:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 21:13:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 21:13:43 -0500 Date: Thu, 23 Feb 95 01:21:02 GMT From: "William Allen Simpson" Message-Id: <3941.bsimpson@morningstar.com> To: ipsec@ans.net Subject: ICMP use of AH > From: Danny.Nessett@eng.sun.com (Dan Nessett) > I didn't quite follow your reply. Specifically : > > For that particular case (intermediate router sending an ICMP > > message and desiring to authenticate the ICMP message back to the > > sender), if a Security Association does not exist the router > > could sign it using its private key that is associated with its > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Eastlake-Kaufman signed public key available from the DNS and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > an RSA signature. This scales as well as the DNS and hence > > as well as the Internet as a whole. > > Doesn't this introduce a dependency of the routing system on DNS? No, it introduces a dependency of some ICMP security on DNS. This is a matter for later elucidation in the ICMP security draft which is currently being written. Ran was simply trying to help point you in the right direction, without being too specific at this time. > That is, > aren't you assuming that all routers will have signed certificates in the > DNS? No, he is assuming that the _subset_ of routers which provide authenticated ICMP messages -- without having established a security association -- have a DNS signed certificate. That is certainly a possibility, since Eastlake-Kaufman propose such DNS certificates. > If so, how do you bring up a routing system without having DNS on-line > to begin with? Do you bring it up unsecure and then secure it? Does this > mean you can't secure it without all routers having DNS certificates? > I believe these statements have to do with dynamic auto-configuration of routers. Since even auto-configuration of hosts is a matter of great debate, and outside the scope of this WG, perhaps we could dispense with the non-sequitors. > In addition I think there are a number of proposals on the table that assume > an IPv4 key distribution mechanism based on signed Diffie-Hellman certificates. No, only one: SKIP. Have you read Photuris? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Feb 23 00:57:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18198 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 21:18:28 -0500 Received: by interlock.ans.net id AA32167 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 21:13:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 21:13:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 21:13:41 -0500 Date: Thu, 23 Feb 95 00:57:12 GMT From: "William Allen Simpson" Message-Id: <3940.bsimpson@morningstar.com> To: ipsec@ans.net Subject: "in-band" is wrong idea/terminology > From: ashar@osmosys.incog.com (Ashar Aziz) > I have an issue. I would like to be able to do in-band signalled > keys. When I first read this, I thought I understood that you meant "using IP" by "in-band" (the usual use of the term). That is, no external non-internet technique is used. That is quite clearly correct, as a change of SAID signals a change in keys. Then, a later message says "zero-message". This makes no sense, as it is impossible to provide an information network without messages. Now, I perhaps understand that you mean to carry the key management protocol inside non-management protocol packets, as some parasitic influence swelling the size of the AH+ESP headers. > Does the draft preclude this? The AH and ESP separate key management from authentication and encryption. The SAID is negotiated and updated by the key management protocol, whatever that may be. However, it would certainly be reasonable for the key management protocol to negotiate the use of a security transform which carries these parasitic key changes. However, the MD5, SHA, DES and 3DES transforms currently described do not carry such information. > If not, then I believe that > there is merit in detailing how to indicate in-band keys in the protocol. You are certainly welcome to write up alternative security transforms for our enlightenment. > Note that SKIP is not the only protocol that employs this technique. > The DEC work also used the same feature (albeit in a different manner). > I wouldn't be too happy to see AH/ESP protocols preclude in-band keys, > As noted above, AH+ESP do not in themselves exclude parasitic key changes. However, it is fairly unlikely that parasitic key changes would work, since they would randomly make certain packets much bigger. This, in turn, would cause fragmentation of full-sized datagrams, which could result in misordering and duplication. This would cause failure of the key change, as well as possible confusion when fragmentation is done by intermediate routers. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Feb 23 03:18:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AB26183 (5.65c/IDA-1.4.4 for ); Wed, 22 Feb 1995 22:21:45 -0500 Received: by interlock.ans.net id AA31308 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Feb 1995 22:18:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Feb 1995 22:18:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Feb 1995 22:18:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Feb 1995 22:18:37 -0500 Date: Wed, 22 Feb 1995 20:18:30 -0700 From: Hilarie Orman Message-Id: <199502230318.UAA02657@umbra.CS.Arizona.EDU> To: ipsec@ans.net Subject: DH EC small correction When I said "mod 2^512" in my earlier note, I of course meant "mod p, where p is approximately 2^512". Sorry if for the sloppiness. From ipsec-request@ans.net Thu Feb 23 13:29:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18764 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 07:34:38 -0500 Received: by interlock.ans.net id AA17581 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 07:29:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 07:29:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 07:29:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 07:29:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 07:29:20 -0500 Message-Id: <9502231244.AA10460@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Feb 1995 07:29:07 -0600 To: ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: GRRRRR!!!! LISTEN UP!!!! I've a virtual enterprise to build this year. HECK!!! I was supposed to build it last year!!!! This afternoon, I will be in a fight of a lifetime to not do it on a private network because of security issues. I just hope I can LIE THROUGH MY TEETH and no one else at that meeting is lurking here!!!! I have all of Bill's and Perry's drafts on diskette, but still have to grab Phil's. I will tell my colleagues to go out and beat up their stack providers and firewall providers to include IPSP by end of Q2, 3 months to implement should be enough time ;-) BUT %$&^&*^R%^%*(&_(*&%$^%$ IT!!! Get us corporate creatures a working security protocol YESTERDAY! And key management soon after; given rollouts, soon is Q3. There are enough collective brain power here to VERY quickly determine if Aziz'z and Hugo's request for structured and unstructured SAIDs break anything. Perry, sowhat if Aziz appears to have been asleep? Give him the benefit of the doubt now that he has a generally defined change that might insure any type of key management for IPSP. But settle this NOW and get the official last call in. Danvers should be strickly Key management. IPSP had better be done by then, not just up for vote!!!!!!%^(&%$%^*&^*&^%!!! Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Feb 23 19:24:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20486 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 14:33:17 -0500 Received: by interlock.ans.net id AA49692 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 14:27:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 14:27:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 14:27:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 14:27:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 14:27:00 -0500 Date: Thu, 23 Feb 1995 11:24:21 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502231924.AA07236@miraj.> To: atkinson@itd.nrl.navy.mil Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From: Ran Atkinson > Ashar, > > Because key mgmt is kept separate entirely from the AH and ESP > specifications, it is easy to swap out one key mgmt protocol for > another without having to alter the AH or ESP implementations. > It is this kind of independence which is important. And nothing that I have suggested so far detracts from this. If anything, my suggestions give more options for the key-mgmt protocol, not less. Ashar. From ipsec-request@ans.net Thu Feb 23 19:37:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18305 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 14:46:35 -0500 Received: by interlock.ans.net id AA03680 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 14:40:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 14:40:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 14:40:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 14:40:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 14:40:27 -0500 Date: Thu, 23 Feb 1995 11:37:58 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502231937.AA07239@miraj.> To: ipsec@ans.net Subject: Re: "in-band" is wrong idea/terminology X-Sun-Charset: US-ASCII > From: "William Allen Simpson" > However, it would certainly be reasonable for the key management > protocol to negotiate the use of a security transform which carries > these parasitic key changes. Yes, this was my initial understanding as well. Perry, this is why I said at the Toronto meeting that I did not have problems with what had been discussed, because it did not strike me then that this had been precluded. However, I believe that parasitic is the wrong word. BTW, there are not going to be any more problems with fragmentation etc., as the effect of the keys is not random. It is just as predictable as the effect of the IVs that are in the packet, and which also causes the packets to increase in size. > > If not, then I believe that > > there is merit in detailing how to indicate in-band keys in the protocol. > > You are certainly welcome to write up alternative security transforms > for our enlightenment. I certainly dont have any problems with this. However, I believe that the base document needs to explicitly accommodate this case, and the 1 bit from the SAID field as Hugo suggested is the right way to do this. I can offer sample text for that as well. Ashar. From ipsec-request@ans.net Thu Feb 23 19:39:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23683 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 14:46:36 -0500 Received: by interlock.ans.net id AA22146 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 14:41:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 14:41:34 -0500 From: Ran Atkinson Message-Id: <9502231439.ZM7653@bodhi> Date: Thu, 23 Feb 1995 14:39:02 -0500 In-Reply-To: ashar@osmosys.incog.com (Ashar Aziz) "Re: WG last call for IPv4 AH and ESP" (Feb 23, 11:24) References: <9502231924.AA07236@miraj.> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Ashar Aziz Subject: Re: WG last call for IPv4 AH and ESP Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Ashar, By modifying the AH and ESP to include support for your key management method, it detracts from the independence of key management and security protocol. A modification to support one kind of in-band key mgmt would not necessarily support all kinds of in-band key mgmt and hence would not preserve independence of key mgmt and security protocols. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Feb 23 20:07:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31230 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 15:19:54 -0500 Received: by interlock.ans.net id AA41213 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 15:10:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 15:10:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 15:10:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 15:10:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 15:10:06 -0500 Date: Thu, 23 Feb 1995 12:07:33 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502232007.AA07251@miraj.> To: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP X-Sun-Charset: US-ASCII >From: Ran Atkinson > By modifying the AH and ESP to include support for your key management > method, it detracts from the independence of key management and > security protocol. A modification to support one kind of in-band > key mgmt would not necessarily support all kinds of in-band key mgmt > and hence would not preserve independence of key mgmt and security > protocols. This doesn't have to be the case. I believe that in-band keying can be generally accommodated without regard to methods. In particular, I believe both the DEC and the SKIP methods can be accommodated using generic language, where the specifics of how the keys were encrypted would be part of the key-mgmt drafts. Regards, Ashar. From ipsec-request@ans.net Thu Feb 23 19:58:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22708 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 15:54:54 -0500 Received: by interlock.ans.net id AA03865 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 15:50:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 15:50:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 15:50:29 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@internic.net, addrconf@cisco.com, ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-simpson-icmp-domain-name-00.txt Date: Thu, 23 Feb 95 14:58:27 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9502231458.aa08818@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ICMP Domain Name Messages Author(s) : W. Simpson Filename : draft-simpson-icmp-domain-name-00.txt Pages : 4 Date : 02/21/1995 This document specifies ICMP messages for learning the Fully Qualified Domain Name of a target, without laborious maintainance and searching of an "inverse" DNS tree. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-icmp-domain-name-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-icmp-domain-name-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-icmp-domain-name-00.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: <19950221142854.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-icmp-domain-name-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-icmp-domain-name-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950221142854.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Thu Feb 23 20:53:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06144 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 15:57:36 -0500 Received: by interlock.ans.net id AA53619 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 15:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 15:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 15:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 15:54:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 15:54:46 -0500 Message-Id: <9502232053.AA02756@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Thu, 23 Feb 1995 12:07:33 PST." <9502232007.AA07251@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 Feb 1995 15:53:13 -0500 From: "Perry E. Metzger" Ashar Aziz says: > This doesn't have to be the case. I believe that in-band keying > can be generally accommodated without regard to methods. I don't believe this is possible. The recipient is going to have to know how to interpret some sort of special signal to the effect that a particular method is in use. > In particular, > I believe both the DEC and the SKIP methods can be accommodated > using generic language, where the specifics of how the keys > were encrypted would be part of the key-mgmt drafts. Moving language out of a draft is not the same as providing clean seperation of function. In particular, I would have to hack the kernel implementation of IPSP to understand key management. Right now, my design has no kernel based key management at all and needs none. This is not to say that I have yet formed a solid opinion on what should be done here. I'm merely saying that things are not that clean. Perry From ipsec-request@ans.net Thu Feb 23 21:06:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20749 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 16:14:59 -0500 Received: by interlock.ans.net id AA27334 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 16:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 16:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 16:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 16:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 16:09:23 -0500 Date: Thu, 23 Feb 1995 13:06:53 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502232106.AA07281@miraj.> To: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP X-Sun-Charset: US-ASCII > From perry@imsi.com Thu Feb 23 12:54 PST 1995 > To: ashar@osmosys.incog.com (Ashar Aziz) >> > This doesn't have to be the case. I believe that in-band keying > > can be generally accommodated without regard to methods. > > I don't believe this is possible. The recipient is going to have to > know how to interpret some sort of special signal to the effect that a > particular method is in use. Well, the recipient has to know how to employ a particular key-mgmt protocol. But this is true in general. If they use different key-mgmt protocols than in general they cant communicate. Take a look at IEEE 802.10b. This is the equivalent of IPSP for IEEE 802.10. It accommodates in-band keying, although it was designed with the DEC approach in mind. (In particular, I believe a more generic description is possible). Regards, Ashar. From ipsec-request@ans.net Thu Feb 23 21:49:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22955 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 16:59:03 -0500 Received: by interlock.ans.net id AA10895 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 16:51:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 16:51:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 16:51:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 16:51:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 16:51:35 -0500 Message-Id: <9502232150.AA02887@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Thu, 23 Feb 1995 13:06:53 PST." <9502232106.AA07281@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 Feb 1995 16:49:59 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > I don't believe this is possible. The recipient is going to have to > > know how to interpret some sort of special signal to the effect that a > > particular method is in use. > > Well, the recipient has to know how to employ a particular > key-mgmt protocol. My point was that you would have to determine what key management protocol to employ based purely on the bits available in the IPSP packet. The other key management systems assume that this is done out of band and that by the time communications occur an SAID has already been selected. > But this is true in general. If they use different key-mgmt > protocols than in general they cant communicate. However, that communication doesn't have to be done via IPSP. .pm From ipsec-request@ans.net Thu Feb 23 21:34:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22730 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 17:19:54 -0500 Received: by interlock.ans.net id AA40578 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 17:13:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 17:13:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 17:13:47 -0500 Date: Thu, 23 Feb 95 21:34:04 GMT From: "William Allen Simpson" Message-Id: <3957.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP It seems the authors are still in agreement, and no parasitic SAID bit will be included. Thank you for the suggestion. Do you have any others? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Feb 23 21:22:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31692 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 17:19:54 -0500 Received: by interlock.ans.net id AA44412 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 17:13:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 17:13:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 17:13:46 -0500 Date: Thu, 23 Feb 95 21:22:09 GMT From: "William Allen Simpson" Message-Id: <3956.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: "in-band" is wrong idea/terminology > From: ashar@osmosys.incog.com (Ashar Aziz) > However, I believe that parasitic is the wrong word. That is the english word for a foreign animal which embeds itself into a host, without (immediately) killing the host. Seems appropriate for a key management feature that embeds itself in an encryption protocol. > BTW, there > are not going to be any more problems with fragmentation etc., as the > effect of the keys is not random. It is just as predictable as the > effect of the IVs that are in the packet, and which also causes the > packets to increase in size. > You are completely missing the point. The IV is in every packet. You would only be correct if the key changed on every packet. And you would only be correct if the decision as to the packet size, and inclusion of the key changes, were made at the transport layer (which makes the segmentation size decision). If either is true, then your proposal is completely unacceptable. > > You are certainly welcome to write up alternative security transforms > > for our enlightenment. > > I certainly dont have any problems with this. However, I believe that > the base document needs to explicitly accommodate this case, and the > 1 bit from the SAID field as Hugo suggested is the right way to do this. > I can offer sample text for that as well. > No, the base document does not need such transform specific information. You folks got us to move the hash calculation out of AH into MD5 and SHA, even though it's the same, so that it could be different for other "future" transforms. The same logic applies. And, there is no restriction on how you (in your other key-management protocol) encode your SAID. But, MD5 and DES do not use such a bit, so it does not go in the base document, nor in either of those. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Feb 24 01:05:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17208 (5.65c/IDA-1.4.4 for ); Thu, 23 Feb 1995 20:12:23 -0500 Received: by interlock.ans.net id AA37522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Feb 1995 20:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Feb 1995 20:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Feb 1995 20:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Feb 1995 20:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Feb 1995 20:07:31 -0500 Date: Thu, 23 Feb 1995 17:05:03 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502240105.AA00444@miraj.> To: ipsec@ans.net Subject: Re: "in-band" is wrong idea/terminology X-Sun-Charset: US-ASCII >From: "William Allen Simpson" > You are completely missing the point. The IV is in every packet. > > You would only be correct if the key changed on every packet. And you > would only be correct if the decision as to the packet size, and > inclusion of the key changes, were made at the transport layer (which > makes the segmentation size decision). In both the SKIP scheme, and the earlier DEC work, the key is in every packet as well. There is no difference between the effect of the key and the effect of the IV in both schemes. Regards, Ashar. From ipsec-request@ans.net Fri Feb 24 16:39:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16030 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 11:51:49 -0500 Received: by interlock.ans.net id AA08824 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 11:40:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 24 Feb 1995 11:40:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 11:40:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 11:40:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 11:40:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 11:40:11 -0500 Date: Fri, 24 Feb 1995 08:39:28 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502241639.IAA24123@elrond.Eng.Sun.COM> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII Folks, I think it might be useful to approach the in-band/out-of-band key management issue from another perspective. Out-of-band management assumes either that a synchronized security assocation already exists between the source and destination hosts or that when an IP packet is processed, the key management software is called to establish this context. Those familiar with X.25 will recognize this as a virtual circuit model of operation. In fact I think it is a fair characterization that out-of-band key management imposes a "security virtual circuit" model on IP security (both IPv4 and IPv6). In-band key management, on the other hand, is philosophically similar to dynamic connection management, which is the technique employed by TCP. When a connection is required, information is included within the TCP header (e.g., syn flag, isn) to allow the construction of a connection record at the destination. Similarly, the destination returns information (syn ack, its isn), to allow the source to complete the construction of its connection record. An important point that some may have overlooked is that the current draft of the IPv6 security Architecture I-D (I couldn't find an security architecture I-D for IPv4) encourages the use of user-to-user keying (by specifying that implementations MUST support user-to-user keying, but only MAY provide for host-to-host keying), rather than host-to-host keying. The implication is that everytime a new *user* communicates to a specific machine, the key management software will be required to establish a new security association. If out-of-band keying is used, this is going to mean, on average, very poor performance, since the key management protocol must use a separate communications stream to establish the keys for use before communications on the stream originating the key management activity can proceed. It is for these reasons, among others, that in-band signalling should be supported by both final IPSEC Proposed Standards and by the IPv6 Proposed Standards for security. Dan From ipsec-request@ans.net Fri Feb 24 17:13:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18901 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 12:20:47 -0500 Received: by interlock.ans.net id AA22587 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 12:15:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 12:15:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 12:15:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 12:15:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 12:15:56 -0500 Message-Id: <9502241713.AA03871@snark.imsi.com> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 08:39:28 PST." <199502241639.IAA24123@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 12:13:49 -0500 From: "Perry E. Metzger" Dan Nessett says: > Out-of-band management assumes either that > a synchronized security assocation already exists between the source and > destination hosts or that when an IP packet is processed, the key management > software is called to establish this context. Those familiar with X.25 will > recognize this as a virtual circuit model of operation. In fact I think it > is a fair characterization that out-of-band key management imposes a > "security virtual circuit" model on IP security (both IPv4 and IPv6). > > In-band key management, on the other hand, is philosophically similar to > dynamic connection management, which is the technique employed by TCP. Are you attempting to make an emotional argument here based on on the assumption that people will have a knee jerk reaction against things you label as being "X.25"ish? Unless that is your point, I cannot see why mentioning "X.25" vs. "TCP" would be important. You know, TCP connections require out of band mechanisms for determining mappings between host names and addresses. They also require out of band negotiation of IP routing and fixed preselection of communications ports. Somehow, we survive with all of this. > An important point that some may have overlooked is that the current > draft of the IPv6 security Architecture I-D (I couldn't find an > security architecture I-D for IPv4) encourages the use of > user-to-user keying (by specifying that implementations MUST support > user-to-user keying, but only MAY provide for host-to-host keying), > rather than host-to-host keying. The implication is that everytime a > new *user* communicates to a specific machine, the key management > software will be required to establish a new security > association. If out-of-band keying is used, this is going to mean, > on average, very poor performance, since the key management protocol > must use a separate communications stream to establish the keys for > use before communications on the stream originating the key > management activity can proceed. Is this based on your implementation experience? Could you please post some numbers describing how bad the performance is in practice? I was, in fact, unaware of your implementation. You know, horrors, virtually every time a TCP connection gets built on our network a DNS query has to be made. Performance is obviously impossibly low as a result of this. I say we get rid of DNS and put the queries in band somehow to increase performance. (The existing implementation work indicates that that crypto algorithms so dominate the costs of what we are doing that an extra packet exchange at the start of a connection is almost an invisible cost by comparison.) I don't think that even Ashar, who wants the in-band stuff to support SKIP, would argue that the out-of-bandness is per se a performance problem, especially given that his stuff is still going to require external communciation to look up keys and the like in databases. Perry From ipsec-request@ans.net Fri Feb 24 17:26:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18780 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 12:32:17 -0500 Received: by interlock.ans.net id AA44296 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 12:28:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 12:28:11 -0500 From: Ran Atkinson Message-Id: <9502241226.ZM8320@bodhi> Date: Fri, 24 Feb 1995 12:26:29 -0500 In-Reply-To: Danny.Nessett@eng.sun.com (Dan Nessett) "out-of-band key management is like virtual circuits" (Feb 24, 8:39) References: <199502241639.IAA24123@elrond.Eng.Sun.COM> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof2.eng.sun.com, ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, I find your analogy to be highly misleading. I strongly disagree with your assertion that in-band key mgmt is better for a datagram network. All of the capability that you assert is unique to in-band can be done by simply sending key mgmt packets at the same time one sends the datagrams. Since SAIDs are receiver-oriented, a sender can't force a key upon the receiver without the receiver's involvement in any case. If we remove that receiver-orientation, then IP multicasting will not work well with security (and multicasting is a 1st order service of IPv6). Out of band keying does NOT mean "on average, very poor performance". Your assertion just is not true. We should continue to avoid coupling key mgmt and the security mechanisms and hence should continue to avoid in-band key mgmt in standards-track specifications within the IETF. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Feb 24 17:49:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20502 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 12:55:22 -0500 Received: by interlock.ans.net id AA44420 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 12:49:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 24 Feb 1995 12:49:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 12:49:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 12:49:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 12:49:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 12:49:55 -0500 Date: Fri, 24 Feb 1995 09:49:18 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502241749.JAA24180@elrond.Eng.Sun.COM> To: atkinson@itd.nrl.navy.mil Subject: Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof2.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Ran, Your point : > All of the capability that you assert is unique to in-band > can be done by simply sending key mgmt packets at the same time one > sends the datagrams. is somewhat misleading. The key management protocol will require an exchange between the source and destination in order for the source to obtain the SAID that it will use in the IP packet, which processing started the whole process. This induces a considerable delay in delivering the original IP packet. In-band signalling allows the key management activity to be "piggy-backed" on the original IP packet, thus saving not only the cost of processing one or more additional key mgmt IP packets, but also the delay of at least a two packet exchange (which is actually four packets for Photuris, i.e., COOKIE_REQUEST, COOKIE_RESPONSE, DH_REQUEST, DH_RESPONSE), to obtain the SAID. > Since SAIDs are receiver-oriented, a sender can't > force a key upon the receiver without the receiver's involvement in > any case. If we remove that receiver-orientation, then IP multicasting > will not work well with security (and multicasting is a 1st order > service of IPv6). In-band signalling doesn't "force a key upon the receiver without the receiver's involvement," it just piggy-backs the key management information in the original IP packet. The receiver has the option of dropping the packet with the piggy-backed information, just as it can drop an out-of-band key mgmt packet. > We should continue to avoid coupling key mgmt and the security > mechanisms and hence should continue to avoid in-band key mgmt in > standards-track specifications within the IETF. I agree that key mgmt protocols should not be forced to use in-band techniques. I think all of us (and there have been at least 5 messages from different people on this list asking for in-band signalling) would like the *option* of using in-band signalling. Then we can let the market decide which is the best approach. Dan From ipsec-request@ans.net Fri Feb 24 18:20:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18831 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:33:41 -0500 Received: by interlock.ans.net id AA53578 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:26:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 13:26:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:26:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:26:09 -0500 Message-Id: <9502241820.AA04737@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 12:13:49 EST." <9502241713.AA03871@snark.imsi.com> Date: Fri, 24 Feb 95 13:20:31 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, Danny is right on the performance hit its obvious. How much I think is a a good question. But when you get IPv6 with the present security just doing a authentication with MD5 and no key management. Expect a 50% peformance loss. If Danny's suggestion saves 10% then I think we should take it. /jim From ipsec-request@ans.net Fri Feb 24 18:31:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27840 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:36:22 -0500 Received: by interlock.ans.net id AA49095 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:31:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:31:39 -0500 Message-Id: <9502241831.AA04008@snark.imsi.com> To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 09:49:18 PST." <199502241749.JAA24180@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 13:31:26 -0500 From: "Perry E. Metzger" Dan Nessett says: > Ran, > > Your point : > > > All of the capability that you assert is unique to in-band > > can be done by simply sending key mgmt packets at the same time one > > sends the datagrams. > > is somewhat misleading. So is yours. > The key management protocol will require an exchange > between the source and destination in order for the source to obtain the > SAID that it will use in the IP packet, which processing started the whole > process. This induces a considerable delay in delivering the original > IP packet. Any key management protocol will require one or more exchanges to key servers. This will induce delay. Any connection these days on the net requires an exchange with DNS servers. This induces delay. Any key management protocol based on public key techniques will require significant computation time -- probably more than several packet round trips on the current internet. This will induce delay. None of these delays can be avoided. .pm From ipsec-request@ans.net Fri Feb 24 18:33:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22777 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:42:08 -0500 Received: by interlock.ans.net id AA03918 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:37:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 13:37:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:37:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:37:27 -0500 Message-Id: <9502241833.AA05181@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: Dan Nessett , ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 12:26:29 EST." <9502241226.ZM8320@bodhi> Date: Fri, 24 Feb 95 13:33:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, I still await your response to my concerns in general the way the spec is written I sent out Monday Feb 20th. > I find your analogy to be highly misleading. I strongly disagree >with your assertion that in-band key mgmt is better for a datagram >network. All of the capability that you assert is unique to in-band >can be done by simply sending key mgmt packets at the same time one >sends the datagrams. Since SAIDs are receiver-oriented, a sender can't >force a key upon the receiver without the receiver's involvement in And where are these key mgmt packets in relation to the IPv6 packet? I can't parse what your thinking here? So far Danny has not been misleading and its obvious to me? You have not convinced me it is misleading, but I am sure Danny will reply too. >any case. If we remove that receiver-orientation, then IP multicasting >will not work well with security (and multicasting is a 1st order >service of IPv6). I don't agree with this is at all. Multicast for system discovery or autoconfiguration absolutely. Not for applications. The bulk of applications will still use unicast addresses for datagrams at least for the next 5 years. > Out of band keying does NOT mean "on average, very poor performance". >Your assertion just is not true. The assertion is intuitively true. > We should continue to avoid coupling key mgmt and the security >mechanisms and hence should continue to avoid in-band key mgmt in >standards-track specifications within the IETF. Better yet we need more people finally like Danny to come to IPNG and send us a wake up call before we make something a proposed standard that will cost so much in performance no one will use no matter how much security they need. Danny please continue your input on this we needed this kind of drilling of the security specs. /jim From ipsec-request@ans.net Fri Feb 24 18:38:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21778 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:46:23 -0500 Received: by interlock.ans.net id AA51596 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:42:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 13:42:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:42:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:42:36 -0500 Message-Id: <9502241838.AA05353@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 09:49:18 PST." <199502241749.JAA24180@elrond.Eng.Sun.COM> Date: Fri, 24 Feb 95 13:38:20 -0500 From: bound@zk3.dec.com X-Mts: smtp >I agree that key mgmt protocols should not be forced to use in-band techniques. >I think all of us (and there have been at least 5 messages from different >people on this list asking for in-band signalling) would like the *option* >of using in-band signalling. Then we can let the market decide which is >the best approach. 100% support on this. Let the option exist and let us who will build IPv6 security see if the market wants it. /jim From ipsec-request@ans.net Fri Feb 24 18:43:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15127 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:47:59 -0500 Received: by interlock.ans.net id AA24992 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:44:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 13:44:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 13:44:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:44:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:44:25 -0500 Message-Id: <9502241843.AA04035@snark.imsi.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 13:20:31 EST." <9502241820.AA04737@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 13:43:57 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > Danny is right on the performance hit its obvious. No it isn't, Jim. A round trip might be required in *some* key management techniques in the *worst case*, and in any case the time in question is swamped by other times required. As I noted, virtually every transport session on the net these days begins with a DNS round trip. No one complains about that. And no, we aren't going to do user level keying for random ICMP messages -- what would it mean? User level keying is going to end up being employed for long lived sessions where the setup time is invisible over the length of the connection. So far as I can tell, he has no figures to back up his claims. Had he phrased this as a question or a suggestion for something to try to measure I would prehaps not be disturbed by his comments -- saying we should be considering this sort of thing is perfectly reasonable -- but I really don't like pronouncements from on high from people who have no implementation experience. One would think that he'd built a complete system, deployed it, and had been conducting measurements from the way that he wrote. Perry From ipsec-request@ans.net Fri Feb 24 18:33:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17286 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:57:05 -0500 Received: by interlock.ans.net id AA27717 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:51:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:51:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:51:28 -0500 Date: Fri, 24 Feb 95 18:33:37 GMT From: "William Allen Simpson" Message-Id: <3989.bsimpson@morningstar.com> To: ipsec@ans.net Subject: WG last call for IPv4 MD5 Since we have had no new suggestions for IPv4 AH, it is time to move on to the required MD5 transform. The only recent suggestion is that the MD5 function be combined with the AH draft, so that it is clear that MD5 and no others are required to be implemented. This was a deliberate change from the original IPv6 text, which allowed us to separately consider the Header from the actual hashing function. SHA should remain a separate draft. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Feb 24 18:43:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27789 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:57:12 -0500 Received: by interlock.ans.net id AA48635 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:49:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:49:11 -0500 From: Ran Atkinson Message-Id: <9502241343.ZM8407@bodhi> Date: Fri, 24 Feb 1995 13:43:33 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) out-of-band key management is like virtual circuits" (Feb 24, 13:20) References: <9502241820.AA04737@xirtlu.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng) out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Jim, Dan's approach does not have the claimed performacen win. Hence is not sensible in our circumstance. Ran From ipsec-request@ans.net Fri Feb 24 18:38:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20885 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:57:36 -0500 Received: by interlock.ans.net id AA06982 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:51:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:51:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:51:28 -0500 Date: Fri, 24 Feb 95 18:38:48 GMT From: "William Allen Simpson" Message-Id: <3990.bsimpson@morningstar.com> To: ipsec@ans.net Subject: WG last call for IPv4 DES and 3DES Since we have had no new suggestions for IPv4 ESP, it is time to move on to the required DES transform. Two suggestions have been received. First, that the DES function be combined with the ESP draft, so that it is clear that DES and no others are required to be implemented. This was a deliberate change from the original IPv6 text, which allowed us to separately consider the Header from the actual transform. Second, that 3DES be required instead of DES. DES can always be generated using 3DES, and 3DES is more usable for the long term, noting that DES is already attacked with modest resources. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Feb 24 18:07:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27799 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 13:57:37 -0500 Received: by interlock.ans.net id AA45625 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 13:51:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 13:51:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 13:51:26 -0500 Date: Fri, 24 Feb 95 18:07:16 GMT From: "William Allen Simpson" Message-Id: <3988.bsimpson@morningstar.com> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: out-of-band key management is like virtual circuits Please reply on the IPSEC list, as those IPv6 members involved in security are already on that list. We have separate lists for separate IPng features, such as addrconf. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > I think it might be useful to approach the in-band/out-of-band key management > issue from another perspective. Out-of-band management assumes either that > a synchronized security assocation already exists between the source and > destination hosts or that when an IP packet is processed, the key management > software is called to establish this context. I've already noted (previous messages to the IPSEC list) that the term "in-band" is inappropriate. All proposed messages are using IP, not some other signalling channel. (It appears that we have an influx of CCITT telco folks, or maybe that's what they are teaching in grad schools nowadays.) > Those familiar with X.25 will > recognize this as a virtual circuit model of operation. In fact I think it > is a fair characterization that out-of-band key management imposes a > "security virtual circuit" model on IP security (both IPv4 and IPv6). > I'm familiar with X.25, and I see no resemblence. TCP provides an end-to-end connection. I know of nobody who would characterize it as being at all like X.25 or virtual-circuit. The proposed Photuris IP Security only uses UDP datagrams, not even TCP, in order to create less state. The only proposal which suggests a reliable virtual signalling channel embedded in and on every datagram is, well, the one from Sun, which we have rejected. > In-band key management, on the other hand, is philosophically similar to > dynamic connection management, which is the technique employed by TCP. > When a connection is required, information is included within the TCP > header (e.g., syn flag, isn) to allow the construction of a connection > record at the destination. Similarly, the destination returns information > (syn ack, its isn), to allow the source to complete the construction of > its connection record. > Yes, this is the model used by Photuris. It should be no surprise that the exchange bears a strong resemblence to a TCP handshake, as Phil Karn has been a long-time TCP implementor. > An important point that some may have overlooked is that the current draft of > the IPv6 security Architecture I-D (I couldn't find an security architecture I-D > for IPv4) encourages the use of user-to-user keying (by specifying that > implementations MUST support user-to-user keying, but only MAY provide > for host-to-host keying), rather than host-to-host keying. The implication > is that everytime a new *user* communicates to a specific machine, the > key management software will be required to establish a new security > association. Indeed, this is a very important feature! For the reasons which have been stated to this list on several occasions. I refer you to the archives. > If out-of-band keying is used, this is going to mean, on > average, very poor performance, since the key management protocol must > use a separate communications stream to establish the keys for use before > communications on the stream originating the key management activity > can proceed. > Since we do not have "streams", this makes no sense. Of course user UDP datagrams do not "flow" during IP Security datagrams, as datagrams use bandwidth. This will make no difference to the user, which does not see datagrams. Do you have a technique which involves no bandwidth or computation? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Feb 24 19:03:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31392 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 14:20:45 -0500 Received: by interlock.ans.net id AA54723 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 14:09:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 14:09:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 14:09:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 14:09:28 -0500 Message-Id: <9502241903.AA06454@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 13:43:33 EST." <9502241343.ZM8407@bodhi> Date: Fri, 24 Feb 95 14:03:28 -0500 From: bound@zk3.dec.com X-Mts: smtp Well you say this dan says the other. But my knowledge strictly of how the packet gets to a user interface and when your MD5 happens in my kernel and how the key mgmt will work it appears to me Dan is right. Piggybacking is always faster. I have seen this in other areas besides security. Please explain technically why this is not true for the key mgmt protocol that could be used with your security architecture. And even if you can do this why not leave it as an option. thanks /jim From ipsec-request@ans.net Fri Feb 24 19:19:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24528 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 14:30:00 -0500 Received: by interlock.ans.net id AA54732 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 14:26:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 14:26:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 14:26:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 14:26:20 -0500 Message-Id: <9502241919.AA06929@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 13:43:57 EST." <9502241843.AA04035@snark.imsi.com> Date: Fri, 24 Feb 95 14:19:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Look folks lets slow down here and go back to basic protocol of 1993 #101. You can gain performance in networks in various manners. Like reducing memory copies, avoiding fine granular timers, and piggybacking data and even packets. The in-band approach can possibly increase performance becuase of the latter strictly from a pure packet throughput and avoidance of signing the key out-of-band data which is going to cost extra. The cost is the extra communications to establish the user to user key. It appears to me in-band data with the users key can avoid that extra communications. The other basic is why cannot we have it as an option. How many of you have tested Rans architecture in your code? The Digital team has. And it will be very costly to your end systems. If Danny's idea can or may give us a performance gain then why not permit it as an option. I can't commit but maybe we will build it and test it in our implementation of IPv6. How can a group who could not even come to a bake-off to test what is to be a proposed standard be so all fired up to say that this will not improve security performance when they themselves it appears are also dealing completely in theory, abstractions, and some historical evidence. I am also reading Dannys mail as I write this and I honestly did not get the same impressions from Dannys mail as Perry did. What I got was an engineer who knows a hell of a lot about security giving us another technical perspective. One that raises questions about our present Security draft. I will not be "railroaded" into not listening to his suggestion and data. In addition its completely in line with my input to Ran on the issue of Key Mgmt and the Security architecture and how a particular MUST is worded. In fact this is a good LAST CALL I don't like this argument to the IESG if necessary. Look this whole area of key mgmt has lots of people outside of the IETF worried that we have not figured this out. Also I still await response from Ran on my issue of this being widely deployed but the specs say theY want to make MUST that which will not be widely deployed. /jim From ipsec-request@ans.net Fri Feb 24 19:29:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15882 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 14:35:52 -0500 Received: by interlock.ans.net id AA31304 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 14:32:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 14:32:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 14:32:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 14:32:49 -0500 Message-Id: <9502241929.AA07195@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 18:07:16 GMT." <3988.bsimpson@morningstar.com> Date: Fri, 24 Feb 95 14:29:01 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, NO I AM NOT ON IPSEC AND I DO NOT WANT TO BE. THIS MUST BE ON IPNG AND STOP BEING POLITICAL. IF THIS IS NOT DISCUSSED HERE I OBJECT TO YOUR STANDARD BEING SUGGESTED AS PROPOSED AT DANVERS. THIS MUST STAY ON THIS LIST OR YOU IMHO ARE JEOPARDIZING GETTING TO PROPOSED STANDARD. You build the standard in this group and then when there is a tough issue you take it to another groups mailing list. This is a foul and I will object to the IESG formally if this is what is to happen. I highly suggest to the chairs to get with Ran offline and fix this if he continues to pursue this course. He should have to justify why Dannys claims will not benefit a draft under this groups charter as of right now just like the rest of the drafts must do this. This is just the wrong thing to do. Also you consistently ask everyone else to prove their point in depth technically now its your turn. Do it or just give in. The principles of the IETF apply to all of us not just some of us. /jim From ipsec-request@ans.net Fri Feb 24 20:01:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06310 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:13:50 -0500 Received: by interlock.ans.net id AA33615 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:01:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 15:01:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 15:01:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 15:01:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:01:22 -0500 From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9502242001.AA02003@monster.incog.com> Subject: Re: (IPng) out-of-band key management is like virtual circuits To: perry@imsi.com Date: Fri, 24 Feb 1995 12:01:18 -0800 (PST) Cc: ipsec@ans.net In-Reply-To: <9502241843.AA04035@snark.imsi.com> from "Perry E. Metzger" at Feb 24, 95 01:43:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text > Any key management protocol will require one or more exchanges to key > servers. This will induce delay. On the in-band model, if the long term key is local or cached, no exchange with the key server is necessary. With out of band, this exchange and it's delay will always incurred. > Any connection these days on the net requires an exchange with DNS servers. > This induces delay. You can still use the IP address in which case is no DNS lookup. Furthermore, your DNS server may cache the names/addresses in which case there is no delay, as well. > Any key > management protocol based on public key techniques will require > significant computation time -- probably more than several packet > round trips on the current internet. This will induce delay. None of > these delays can be avoided. Some of them certainly can be avoided. With in-band keying, caching of long term keys eliminates exchanges with the key servers for every connection. In-band keying also eliminates the exchange required for every connection. Your argument appears to be: We have so many delays right now, why not incur more? I don't agree. The public key computation can't be avoided, but requiring handshakes for packet exchanges certainly can. By eliminating the structured SAID bit, you are also eliminating a particular flavor of key management. As I recall, IPSP is supposed to be independent of key management. In-band keying should at least be an option. --tom From ipsec-request@ans.net Fri Feb 24 20:02:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06336 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:15:12 -0500 Received: by interlock.ans.net id AA06655 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:07:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:07:35 -0500 From: Ran Atkinson Message-Id: <9502241502.ZM8535@bodhi> Date: Fri, 24 Feb 1995 15:02:46 -0500 In-Reply-To: "William Allen Simpson" "WG last call for IPv4 MD5" (Feb 24, 18:33) References: <3989.bsimpson@morningstar.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: William Allen Simpson , ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil The transform should be MD5(key,packet,key) for increased consensus, compatibility/consistency with IPv6, and consistency with Security Directorate consensus. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Feb 24 20:11:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22447 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:32:46 -0500 Received: by interlock.ans.net id AA52866 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:13:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:13:43 -0500 From: Ran Atkinson Message-Id: <9502241511.ZM8545@bodhi> Date: Fri, 24 Feb 1995 15:11:42 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) out-of-band key management is like virtual circuits" (Feb 24, 14:19) References: <9502241919.AA06929@xirtlu.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng) out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Jim, Your statement that "Digital has test and found it to be costly" is directly refuted by other folks who are employed by Digital and have been in regular contact with me for over a year now. I do not believe you. I do believe Perry and other who have been implementing. Perry has code. I have code. Phil Karn has code for a similar security mechanism (different bit formats, but similar) in KA9Q. There is NO "MUST use security" there is a "MUST implement and support security". This is consistent with direction to me from the IESG. That issue must be resolved with them directly as I am following their specific direction on this point. Manual key distribution is necessary to have even in the presence of a key management protocol, making it mandatory regardless. We can't mandate a key mgmt protocol that isn't yet a Proposed Standard so we say "implementations SHOULD" implement it when it becomes Proposed Standard. More comments will come when I have more time. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Feb 24 20:13:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13752 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:33:40 -0500 Received: by interlock.ans.net id AA45146 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:22:31 -0500 From: Ran Atkinson Message-Id: <9502241513.ZM8550@bodhi> Date: Fri, 24 Feb 1995 15:13:45 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) Re: out-of-band key management is like virtual circuits" (Feb 24, 14:29) References: <9502241929.AA07195@xirtlu.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Jim, You addressed this last note to me and you should not have. You are responding to a note from someone else, not me. I have never suggested moving IPv6 Security away from the IPng mailing list. Please pay more attention to the FROM line in email that you read. I will not be replying to any more flames from you. If/when you calm down, I will reply to normal email notes as my time permits. Thanks, Ran From ipsec-request@ans.net Fri Feb 24 20:18:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20964 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:35:29 -0500 Received: by interlock.ans.net id AA43062 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:20:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 15:20:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 15:20:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 15:20:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:20:50 -0500 Message-Id: <9502242018.AA04214@snark.imsi.com> To: markson@osmosys.incog.com (Tom Markson) Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 12:01:18 PST." <9502242001.AA02003@monster.incog.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 15:18:29 -0500 From: "Perry E. Metzger" Tom Markson says: > Your argument appears to be: We have so many delays right now, why not > incur more? No. My argument is "when you have figures demonstrating that there is a performance problem, please call back." I suspect that, with association caching and the like, the overall latency added by key handshakes will not be measurable. Others claim its going to be intolerable. There is an easy way to prove this one way or another, isn't there? >I don't agree. The public key computation can't > be avoided, but requiring handshakes for packet exchanges certainly can. I keep hearing Hugo asking for MORE handshakes to make sure that there are no holes in the authentication. > By eliminating the structured SAID bit, you are also eliminating a particular > flavor of key management. As I recall, IPSP is supposed to be independent > of key management. As soon as you have structured SAIDs, you have to start throwing lots of complexity into your kernel -- the kernel must not just have hooks for key negotiation but has to keep tables of key negotiation types and be an active participant in the key negotiation process. We are going to have to start having IANA handing out SAID ranges and the like. Furthermore, we've just conflated the layers -- something people keep accusing me of doing. I haven't even plotted out all the complexities yet. It certainly causes me to have to toss out user level key management stuff, which I don't like. Perry From ipsec-request@ans.net Fri Feb 24 20:49:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31737 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:58:57 -0500 Received: by interlock.ans.net id AA44243 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 15:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 15:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 15:53:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:53:52 -0500 Message-Id: <9502242049.AA04270@snark.imsi.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:19:48 EST." <9502241919.AA06929@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 15:49:11 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > Look folks lets slow down here and go back to basic protocol of 1993 > #101. You can gain performance in networks in various manners. Like > reducing memory copies, avoiding fine granular timers, and piggybacking > data and even packets. The in-band approach can possibly increase > performance becuase of the latter strictly from a pure packet throughput > and avoidance of signing the key out-of-band data which is going to cost > extra. Jim; 1) Over the life of a typical Telnet session or AFS file sharing session or whatever, the few extra milliseconds involved in a user level packet exchange won't be noticed. Note that needing a packet exchange is worst case. I don't think it will occur normally. 2) Typical ICMP and other "system" applications will not be using user level keying and average case will have their security associations in place at the time of a packet transmission -- in other words, they will almost always be "in cache" as it were. > The other basic is why cannot we have it as an option. How many of you > have tested Rans architecture in your code? The Digital team has. And > it will be very costly to your end systems. Are we talking about encrypting every packet? We know thats expensive. I don't think that has anything to do with Ran's architecture -- if you are encrypting all your data, it costs a huge amount. And yes, I've got code that does that sort of thing right now, and it is bloody expensive. Its unavoidable, however. The solution is to use fast ciphers or hardware cipher implementations. Just switching from DES to RC4 gives you a huge boost. However, this has nothing to do with performance hits from key management. To my knowledge, as it stands you are probably using manual keying. > If Danny's idea can or may give us a performance gain then why not > permit it as an option. If someone thinkgs rubbing chicken entrails on our chests will give us a performance gain, shall we specify that in an RFC as well? I fail to understand what sort of performance gain we are to expect here. We aren't even being given a model of the sort of traffic we are discussing. If we are talking about a Telnet session Danny's notion can't give us any observable performance gain. If we are talking about a random hit at a DNS server it might give us a gain -- but DNS is not being protected with this mechanism. Were we talking about some sort of file service arrangement it certainly wouldn't give us a gain. Could someone PLEASE tell me how gaining a few milliseconds in startup of relationships between hosts that last hours is going to be worthwhile? Remember, of course, that we are talking of "worst case" situations -- average case you aren't going to gain anything. > In addition its completely in line with my input to Ran on the issue of > Key Mgmt and the Security architecture and how a particular MUST is > worded. In fact this is a good LAST CALL I don't like this argument to > the IESG if necessary. I don't believe a last call has been issued. Could you explain what it is that you are speaking of? Perry From ipsec-request@ans.net Fri Feb 24 20:18:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31488 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 15:59:24 -0500 Received: by interlock.ans.net id AA04057 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 15:53:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 15:53:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 15:53:57 -0500 Date: Fri, 24 Feb 95 20:18:26 GMT From: "William Allen Simpson" Message-Id: <3994.bsimpson@morningstar.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits > From: bound@zk3.dec.com > > Ran, > > NO I AM NOT ON IPSEC AND I DO NOT WANT TO BE. > > THIS MUST BE ON IPNG AND STOP BEING POLITICAL. IF THIS IS NOT DISCUSSED > HERE I OBJECT TO YOUR STANDARD BEING SUGGESTED AS PROPOSED AT DANVERS. > > THIS MUST STAY ON THIS LIST OR YOU IMHO ARE JEOPARDIZING GETTING TO > PROPOSED STANDARD. > > You build the standard in this group and then when there is a tough > issue you take it to another groups mailing list. This is a foul and I > will object to the IESG formally if this is what is to happen. > Jim, you are way out of line here. Ran did not take anything from IPv6 to IPv4. I did. Many months ago. One of the IPv4 folks came complaining back to IPv6. There just wasn't enough support for SKIP in IPv4. He can see that IPv6 is where the action is. And _I_ was the one asking us to stay on one mailing list. Particularly, not the IPng list, where people reply, but it won't show up on the other list because of the reply-to field. If you are not interested in IP Security enough to at least join the mailing list, let alone read the archives, then I don't see where you think you have standing to criticize. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Feb 24 20:56:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28459 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 16:04:26 -0500 Received: by interlock.ans.net id AA27728 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 16:00:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 16:00:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 16:00:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 16:00:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 16:00:54 -0500 Message-Id: <9502242056.AA04287@snark.imsi.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:29:01 EST." <9502241929.AA07195@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 15:56:55 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > I highly suggest to the chairs to get with Ran offline and fix this if > he continues to pursue this course. He should have to justify why > Dannys claims will not benefit a draft under this groups charter as of > right now just like the rest of the drafts must do this. This is just > the wrong thing to do. "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would know if you were on the ipsec list which you feel you don't have to be on. However, Ashar isn't claiming it has anything to do with performance per se -- he wants it to make his life easier in promoting a particular key management system called SKIP, which was designed with in-band in mind. I don't know how Danny got into this. He wasn't involved in any of the discussions before we heard from him from on high -- and I must say that I rather resent someone making an absolutistic demand presented without evidence as their initial posting on a topic. Some of the rest of us have been building prototypes and testing them, you know. Perry From ipsec-request@ans.net Fri Feb 24 22:15:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15991 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:34:51 -0500 Received: by interlock.ans.net id AA52018 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:28:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 17:28:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:28:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:28:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:28:30 -0500 Date: Fri, 24 Feb 1995 14:15:39 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502242215.AA01000@miraj.> To: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net X-Sun-Charset: US-ASCII > >I agree that key mgmt protocols should not be forced to use in-band techniques. > >I think all of us (and there have been at least 5 messages from different > >people on this list asking for in-band signalling) would like the *option* > >of using in-band signalling. Then we can let the market decide which is > >the best approach. > > 100% support on this. Let the option exist and let us who will build > IPv6 security see if the market wants it. Jim and Danny are absolutely right. Let's leave the option in. Let's not close our options on in-band key-mgmt (or any kind of key-mgmt for that matter) when the operational experience of Internet-wide key-mgmt is very limited at best. Danny is absolutely correct about the IP-over-X.25 analogy. The TCP-is-also- connection-oriented isn't an appropriate analogy because TCP runs over IP, whereas IPSP is supposed to run underneath IP, at least in what will be one of the prevalent modes (IP encapsulation in IPSP). We have serious concerns about being limited to a cached-VC-like model with IPSP/IPv6. We anticipate this approach to be problematic on secure servers with a large number of clients, and firewalls with a large number of remote IP clients. The cached-security-session approach is even more problematic than your typical cached VC situation because of the problem of "half-open- connections". This is when one side crashes and loses the shared session state. Normally, one can simply blow away half-open connections when the side that has crashed detects them. This is not so trivial for a security session because this has to be done securely, otherwise denial-of-service attacks would be trivial. (Not to say that this can't be solved, but this at least presents another complication). With the approach that we have proposed, there are no half-open connections because there are no connections to begin with. Leaving in the option to do in-band key-mgmt let's people experiment with the connection-less approach. Finally, as they say, the proof is in the pudding. Let's build and deploy some of these approaches to gain operational experience. Towards this end, we will soon be making our key-mgmt/IPSP software freely available (subject to US export regulations, of course). Stay tuned. Regards, Ashar. From ipsec-request@ans.net Fri Feb 24 22:31:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16004 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:36:51 -0500 Received: by interlock.ans.net id AA44680 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 24 Feb 1995 17:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 17:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:31:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:31:58 -0500 Date: Fri, 24 Feb 1995 14:31:05 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502242231.OAA24279@elrond.Eng.Sun.COM> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Proposed Standard or no? X-Sun-Charset: US-ASCII Folks, I originally sent my email on in-band signalling of keying material to both the IPSEC and IPv6 mailing lists, since the issues are identical to each. Right now we have the following people who think in-band signalling should be allowed : IPSEC WG -------- hugo@watson.ibm.com rgm3@is.chrysler.com nessett@eng.sun.com markson@osmosys.incog.com ashar@osmosys.incog.com IPv6 WG ------- bound@zk3.dec.com markson@osmosys.incog.com ashar@osmosys.incog.com nessett@eng.sun.com The people opposed to in-band signalling are : IPSEC WG -------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com IPv6 WG ------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com Admittedly, neither group enjoys a clear majority (in fact most people probably aren't reading the email, due to the vituperation in many of the messages from certain of the participants). However, I think there are enough people who believe that in-band signalling should at least be *allowed* that the I-Ds as they currently stand should not be advanced to Proposed Draft status. Personally, I would like to hear from some of the others on these lists to find out what they think. [The views of those listed above have been thoroughly ventilated, I think]. Dan From ipsec-request@ans.net Fri Feb 24 22:27:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15239 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:36:53 -0500 Received: by interlock.ans.net id AA29816 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:31:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:31:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:31:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:31:38 -0500 Message-Id: <9502242227.AA13297@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:13:45 EST." <9502241513.ZM8550@bodhi> Date: Fri, 24 Feb 95 17:27:41 -0500 From: bound@zk3.dec.com X-Mts: smtp I addressed to you as author of the spec in the hope that you would support it staying on IPng, and it was not a flame. Bill already knows how I feel about moving discussions around. None of my mail has been a flame this is just more defensiveness on your part cause you have been asked some valid questions your not sure how to answer at this time, regarding the draft. /jim From ipsec-request@ans.net Fri Feb 24 22:24:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31880 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:36:53 -0500 Received: by interlock.ans.net id AA34176 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:31:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:31:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:31:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:31:49 -0500 Message-Id: <9502242224.AA13226@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:11:42 EST." <9502241511.ZM8545@bodhi> Date: Fri, 24 Feb 95 17:24:04 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, > Your statement that "Digital has test and found it to be >costly" is directly refuted by other folks who are employed >by Digital and have been in regular contact with me for >over a year now. I do not believe you. We gave you the figures for MD5 authentication at the Seattle IETF implementors meeting. Your wrong and whoever in Digital told you this does not have a clue or would know better. I will search this person out so I suggest you let them know that I am looking for them to clear this up. You have now resigned yourself to character assasination because you cannot defend yourself technically and or have a clue what your own specification would cost to implement. Cost is relative. If it cost 500K then most normal return on investment should be 5 million as one example. There is also maintenance and having experts in an area et al. By this mail I hope you know that I will read and study your mail more than anyother and you should also realize if that Digital person did not know what we have done you have opened yourself up to slander of my credibility. Fortuneately for you I don't care about that kind of stuff. But I never forget a public attack such as the one you have just made. Pretty dumb Ran. > I do believe Perry and other who have been implementing. >Perry has code. I have code. Phil Karn has code for a similar >security mechanism (different bit formats, but similar) in KA9Q. Well then why did you not want to do interoperability testing when we asked at the last IETF meeting? Or respond to the mail that went out. We could have done some testing of IPv6 security with you. Which should have also tested other parts of the protocol? > There is NO "MUST use security" there is a "MUST implement and support >security". This is consistent with direction to me from the IESG. >That issue must be resolved with them directly as I am following >their specific direction on this point. No one is arguing this anymore. > Manual key distribution is necessary to have even in the presence >of a key management protocol, making it mandatory regardless. We >can't mandate a key mgmt protocol that isn't yet a Proposed Standard >so we say "implementations SHOULD" implement it when it becomes >Proposed Standard. > More comments will come when I have more time. Just respond to my formal response to your drafts. You will get more input trust me. /jim From ipsec-request@ans.net Fri Feb 24 22:28:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15569 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:46:53 -0500 Received: by interlock.ans.net id AA32313 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:41:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 17:41:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:41:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:41:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:41:13 -0500 Date: Fri, 24 Feb 1995 14:28:29 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502242228.AA01003@miraj.> To: bound@zk3.dec.com, perry@imsi.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Fri Feb 24 14:12 PST 1995 > bound@zk3.dec.com says: > > I highly suggest to the chairs to get with Ran offline and fix this if > > he continues to pursue this course. He should have to justify why > > Dannys claims will not benefit a draft under this groups charter as of > > right now just like the rest of the drafts must do this. This is just > > the wrong thing to do. > > "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would > know if you were on the ipsec list which you feel you don't have to be > on. However, Ashar isn't claiming it has anything to do with > performance per se -- he wants it to make his life easier in promoting > a particular key management system called SKIP, which was designed > with in-band in mind. Perry, I have raised performance issues in the past (in fact you and I had that exchange). There are situations where you dont want to have to go through the overhead of establishing a session when all you want to do is send a few IP packets (e.g net mgmt, ICMP etc.). You suggested one could do this with cached security-connections, whereas I responded that this doesn't work well for servers, net managers or routers that may need to reach a very large destination set, because all of these connections would have to be re-established in case of crash/reboot scenarios. Regards, Ashar. From ipsec-request@ans.net Fri Feb 24 22:35:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05592 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:46:59 -0500 Received: by interlock.ans.net id AA44619 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:41:28 -0500 Message-Id: <9502242235.AA13525@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:49:11 EST." <9502242049.AA04270@snark.imsi.com> Date: Fri, 24 Feb 95 17:35:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, A core set of IPv6 drafts are going to be suggested for proposed standard. Ran has 3 of them, What I mean't on Last Call is that my issue with the sec (general architecture) draft were questions and logic regarding the statements concerning widely deployed. I would rather not issue the comments at an IESG last call when it goes out for proposed if Ran can satisfy my concerns or eliminate them on the mailing list. I need to think on your questions of performance and examples. But I am concerned about end to end commercial applications not the Internet ones right now (not that I am not concerned about the Internet ones). TCP/IP does not exist because of TELNET and DNS these are enablers and not robust applications that people bet their business on. /jim From ipsec-request@ans.net Fri Feb 24 22:42:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28671 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:50:40 -0500 Received: by interlock.ans.net id AA30897 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:46:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 17:46:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:46:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:46:53 -0500 Message-Id: <9502242242.AA13735@xirtlu.zk3.dec.com> To: "William Allen Simpson" Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 20:18:26 GMT." <3994.bsimpson@morningstar.com> Date: Fri, 24 Feb 95 17:42:07 -0500 From: bound@zk3.dec.com X-Mts: smtp >Jim, you are way out of line here. Ran did not take anything from IPv6 >to IPv4. I did. Many months ago. I don't agree and just responded why I sent the mail to Ran because I know you had made up your mind. >One of the IPv4 folks came complaining back to IPv6. There just wasn't >enough support for SKIP in IPv4. He can see that IPv6 is where the >action is. Fine. This has nothing to do with the issue at hand. >And _I_ was the one asking us to stay on one mailing list. Particularly, >not the IPng list, where people reply, but it won't show up on the other >list because of the reply-to field. I knew that and saw no point in debating this with you like I alluded to in my last mail. >If you are not interested in IP Security enough to at least join the >mailing list, let alone read the archives, then I don't see where you >think you have standing to criticize. Its the IPng group that is taking this to proposed standard. Its this group where the discussion should be. Once its in proposed standard then I will have to read ipsec if I still track it. I am focusing on IPv6 not IPv4 thats all. And Ran's draft is one of the drafts. /jim From ipsec-request@ans.net Fri Feb 24 22:47:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31290 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 17:57:20 -0500 Received: by interlock.ans.net id AA44562 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 17:51:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 17:51:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 17:51:33 -0500 Message-Id: <9502242246.AA26617@columbia.sparta.com> To: perry@imsi.com Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:49:11 EST." <9502242049.AA04270@snark.imsi.com> Date: Fri, 24 Feb 95 17:47:38 -0500 From: Carl Muckenhirn In message <9502242049.AA04270@snark.imsi.com> you wrote: Good points about context for measuring "overhead" elided > > Are we talking about encrypting every packet? We know thats > expensive. I don't think that has anything to do with Ran's > architecture -- if you are encrypting all your data, it costs a huge > amount. And yes, I've got code that does that sort of thing right now, > and it is bloody expensive. Its unavoidable, however. The solution is > to use fast ciphers or hardware cipher implementations. Just switching > from DES to RC4 gives you a huge boost. > I'd like to stop us from beating ourselves too hard about the "costs of encryption." While in the context of communications protocol execution "costs" encryption is expensive, but in the context of applications using these services we're (crypto) not really a problem. At the September ARPA Principal Investigators meeting, Van Jacobson pretty eloquently put this when he compared the "costs" of encryption with the "costs" of running a multi-media multicasting system. If encryption consumes 10% (real high) of the available processor, that's minor when compared to the 60, 70, or even 80% of the processor needed to support VAT at 30 fps. Yes, security should be "cheap", but there is value provided by the use of security so lets not worry too much about it. > However, this has nothing to do with performance hits from key > management. To my knowledge, as it stands you are probably using > manual keying. > > > If Danny's idea can or may give us a performance gain then why not > > permit it as an option. > > If someone thinkgs rubbing chicken entrails on our chests will give us > a performance gain, shall we specify that in an RFC as well? > I think that we should, and since Danvers is real close to the 91st day of 1995, I think that an ID or RFC on poultry enchanced security protocols would be quite appropriate. > I fail to understand what sort of performance gain we are to expect > here. We aren't even being given a model of the sort of traffic we are > discussing. If we are talking about a Telnet session Danny's notion > can't give us any observable performance gain. If we are talking about > a random hit at a DNS server it might give us a gain -- but DNS is not > being protected with this mechanism. Were we talking about some sort > of file service arrangement it certainly wouldn't give us a gain. > > Could someone PLEASE tell me how gaining a few milliseconds in startup > of relationships between hosts that last hours is going to be > worthwhile? Remember, of course, that we are talking of "worst case" > situations -- average case you aren't going to gain anything. > Well we wouldn't want to get the relationship off on the wrong foot, we all know how costly that can be in the long run. And we wouldn't wan to waste those precious milliseconds when we can replace them with "IVs" which have bloated to 2, or 3 times their normal length. (And need to be handled as exceptions in the code, I expect). > Perry carl. From ipsec-request@ans.net Fri Feb 24 23:06:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15552 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 18:12:01 -0500 Received: by interlock.ans.net id AA32862 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 18:06:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 18:06:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 18:06:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 18:06:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 18:06:44 -0500 Message-Id: <9502242306.AA04539@snark.imsi.com> To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: Proposed Standard or no? In-Reply-To: Your message of "Fri, 24 Feb 1995 14:31:05 PST." <199502242231.OAA24279@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 18:06:28 -0500 From: "Perry E. Metzger" Dan Nessett says: > I originally sent my email on in-band signalling of keying material to both > the IPSEC and IPv6 mailing lists, since the issues are identical to each. > > Right now we have the following people who think in-band signalling should be > allowed : This is the IETF. We don't vote. If we did vote, baseing it on who bothered to speak up on a mailing list wouldn't be appropriate. We certainly should not be voting on whether a particular technique causes a performance problem -- thats like voting on whether the gravitational constant has a particular value. If you have figures on this based on test implementation that support your contention, lets see them. Perry From ipsec-request@ans.net Fri Feb 24 23:14:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06158 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 18:20:01 -0500 Received: by interlock.ans.net id AA30965 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 18:15:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Feb 1995 18:15:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Feb 1995 18:15:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 18:15:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 18:15:35 -0500 Message-Id: <9502242314.AA04554@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:15:39 PST." <9502242215.AA01000@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 18:14:02 -0500 From: "Perry E. Metzger" Ashar Aziz says: > We have serious concerns about being limited to a cached-VC-like model > with IPSP/IPv6. We anticipate this approach to be problematic on secure > servers with a large number of clients, and firewalls with a large number > of remote IP clients. Under those circumstances, SKIP would display absolutely identical properties if it was to perform well. You would end up having to cache lots of keys in the kernel -- unless you were going to do server lookups on each, with several packet exchanges, which would obviate all claims of performance advantages. Now, as for firewalls with large numbers of clients, I have actually built and operated such firewalls. They all operate with application level relays which are far heavier weight, statewise, than security associations could ever be. These firewalls function just fine. > The cached-security-session approach is even more problematic than > your typical cached VC situation because of the problem of "half-open- > connections". This is when one side crashes and loses the shared session > state. Normally, one can simply blow away half-open connections when > the side that has crashed detects them. This is not so trivial for a > security session because this has to be done securely, otherwise > denial-of-service attacks would be trivial. (Not to say that this can't > be solved, but this at least presents another complication). I don't see why its a problem at all. The TCP connections to the dead machine will vanish on their own. The security associations will eventually time out and go away. New connections from the rebooted machine will form new security associations. > Finally, as they say, the proof is in the pudding. Let's build > and deploy some of these approaches to gain operational experience. Thats an excellent suggestion, and one that I heartily approve of. Perry From ipsec-request@ans.net Fri Feb 24 23:37:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31483 (5.65c/IDA-1.4.4 for ); Fri, 24 Feb 1995 18:51:12 -0500 Received: by interlock.ans.net id AA21675 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Feb 1995 18:42:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Feb 1995 18:42:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Feb 1995 18:42:20 -0500 Message-Id: <9502242335.AA26772@columbia.sparta.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: bound@zk3.dec.com, perry@imsi.com, ipng@sunroof.eng.sun.com, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 14:28:29 PST." <9502242228.AA01003@miraj.> Date: Fri, 24 Feb 95 18:37:19 -0500 From: Carl Muckenhirn In message <9502242228.AA01003@miraj.> you wrote: > > > From ipsec-request@ans.net Fri Feb 24 14:12 PST 1995 > > bound@zk3.dec.com says: > > > I highly suggest to the chairs to get with Ran offline and fix this if > > > he continues to pursue this course. He should have to justify why > > > Dannys claims will not benefit a draft under this groups charter as of > > > right now just like the rest of the drafts must do this. This is just > > > the wrong thing to do. > > > > "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would > > know if you were on the ipsec list which you feel you don't have to be > > on. However, Ashar isn't claiming it has anything to do with > > performance per se -- he wants it to make his life easier in promoting > > a particular key management system called SKIP, which was designed > > with in-band in mind. > > Perry, > > I have raised performance issues in the past (in fact you and I had that > exchange). There are situations where you dont want to have to go through > the overhead of establishing a session when all you want to do is send a > few IP packets (e.g net mgmt, ICMP etc.). You suggested one could do this > with cached security-connections, whereas I responded that this doesn't > work well for servers, net managers or routers that may need to reach a > very large destination set, because all of these connections would have > to be re-established in case of crash/reboot scenarios. > > Regards, > Ashar. Even with SKIP, there is some state kept around somewhere, maybe in the DNS (more messages), but it has to exist. In the case of crashes/reboot, you have to "re-establish" the context of all of those connections eventually anyways (not TCP connections per-se, but connections nevertheless). No one has said that the re-establishment was a synchronous event, just bring them back when you need them, you'll need them again in most cases. carl. From ipsec-request@ans.net Sat Feb 25 21:59:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24140 (5.65c/IDA-1.4.4 for ); Sat, 25 Feb 1995 17:19:49 -0500 Received: by interlock.ans.net id AA13226 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 25 Feb 1995 17:06:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 25 Feb 1995 17:06:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 25 Feb 1995 17:06:49 -0500 Date: Sat, 25 Feb 1995 16:59:05 -0500 From: *Hobbit* Message-Id: <199502252159.QAA11461@narq.avian.org> To: ipsec@ans.net Subject: connections these days delurk(); Many connection scenarios nowadays involve initial TCP request inverse DNS lookup forward DNS lookup IDENTD query [with an avg. 10 second timeout] FINALLY we get our connection. Even a second or two spent on key computations will give a helluva lot faster connection setups, especially after much of the above can finally GO AWAY. lurk(); _H* From ipsec-request@ans.net Sun Feb 26 03:20:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA32208 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 08:35:57 -0500 Received: by interlock.ans.net id AA46819 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 08:25:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 08:25:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 08:25:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 08:25:08 -0500 Date: Sun, 26 Feb 95 08:20:26 EST From: sharborth@hai-net.com Message-Id: <9501267938.AA793815959@houston_cc_smtp.hai-net.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? Allow both. Don't mandate the use of one over the other. In systems which are in use today we use both methods, I would suspect each equally (at least from my experience over the past 12 years in secure communications system design & implementation.) Admittedly each has it's good and bad points, but we are all in the process of trying to design a NEW protocol and this protocol, if it is to be widely accepted, must be able to be implemented by everyone. Some customers really are not concerned with the overhead, they just want a secure channel. It really depends on the application. Bottom line: Security has always had some overhead and it always will. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-= W.S. "Skip" Harborth Manager & Senior Engineer Information Systems Security Engineering Houston Associates, Incorporated 4601 North Fairfax Dr, Suite 1001 Arlington, Virginia 22203 USA (703) 284-8732 812-5099 (fax) INTERNET> sharborth@hai-net.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-= _______________________________________________________________________________ Subject: (IPng) Proposed Standard or no? From: ipng@sunroof.Eng.Sun.COM at internet Date: 24-02-95 19:43 Folks, I originally sent my email on in-band signalling of keying material to both the IPSEC and IPv6 mailing lists, since the issues are identical to each. Right now we have the following people who think in-band signalling should be allowed : IPSEC WG -------- hugo@watson.ibm.com rgm3@is.chrysler.com nessett@eng.sun.com markson@osmosys.incog.com ashar@osmosys.incog.com IPv6 WG ------- bound@zk3.dec.com markson@osmosys.incog.com ashar@osmosys.incog.com nessett@eng.sun.com The people opposed to in-band signalling are : IPSEC WG -------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com IPv6 WG ------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com Admittedly, neither group enjoys a clear majority (in fact most people probably aren't reading the email, due to the vituperation in many of the messages from certain of the participants). However, I think there are enough people who believe that in-band signalling should at least be *allowed* that the I-Ds as they currently stand should not be advanced to Proposed Draft status. Personally, I would like to hear from some of the others on these lists to find out what they think. [The views of those listed above have been thoroughly ventilated, I think]. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From ipsec-request@ans.net Sun Feb 26 18:10:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15488 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 13:25:32 -0500 Received: by interlock.ans.net id AA46664 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 13:12:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 26 Feb 1995 13:12:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 13:12:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 13:12:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 13:12:49 -0500 Message-Id: <9502261810.AA06080@snark.imsi.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Sun, 26 Feb 1995 08:20:26 EST." <9501267938.AA793815959@houston_cc_smtp.hai-net.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 13:10:53 -0500 From: "Perry E. Metzger" sharborth@hai-net.com says: > Allow both. Don't mandate the use of one over the other. In > systems which are in use today we use both methods, I would suspect > each equally (at least from my experience over the past 12 years in > secure communications system design & implementation.) I suspect that you don't understand what is being discussed -- I'm not trying to insult you here, its just that the conversation is being couched in very deceptive terms. You probably are not using either method today, and very likely not both. The terminology is very odd -- I suggest that you read all the drafts in question in order to really get a feel for what is being discussed. The topic boils down to this: do we want to permit for conveying key management information in IPSP packets instead of in, say, separate UDP packets. The argument being made on our side is "it won't give you any performance and messes up a very clean design, making it far harder to implement for negligible gain". The argument on their side boils down to "we get to save a whole packet at the beginning of each of your TCP sessions, and it means you get to rekey on every packet!" Neither of these particularly seem to be important to me. In the end, this comes down to whether you feel SKIP should be the key management protocol we use -- the changes are being requested purely to support SKIP, because Ashar seems to have painted himself into a corner in which he assured us all along that he could adapt SKIP to the proposed IPSP design and then realized only in the last week (it seems) that he needed functionality at the IPSP layer that wasn't available. One of the reasons a number of us have argued this discussion should be on the IPSEC list is because people on IPng lack the context of the discussion. Perry From ipsec-request@ans.net Sun Feb 26 22:58:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15336 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 18:14:53 -0500 Received: by interlock.ans.net id AA08555 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 26 Feb 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 18:01:08 -0500 Date: Sun, 26 Feb 1995 14:58:29 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502262258.AA01913@miraj.> To: perry@imsi.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII > From perry@imsi.com Fri Feb 24 15:15 PST 1995 > Under those circumstances, SKIP would display absolutely identical > properties if it was to perform well. You would end up having to cache > lots of keys in the kernel -- unless you were going to do server > lookups on each, with several packet exchanges, which would obviate > all claims of performance advantages. Perry, As I just explained in an earlier message to Carl, SKIP caching is quite different from caching stateful connections. It is very session-less, and with the right implementation, one can almost completely hide the overhead of expensive public-key operations; this cannot be achieved by caching traditional secure sessions. > Now, as for firewalls with large numbers of clients, I have actually > built and operated such firewalls. They all operate with application > level relays which are far heavier weight, statewise, than security > associations could ever be. These firewalls function just fine. We have several firewalls in-house as well. However, these firewalls with application-layer relays have never been used to establish entire virtual enterprises over a public net like the Internet. They typically give you a handful of Internet services, and connectivity through them is not as seamless as on a private net. I don't believe that to date, very large scale virtual enterprises have been built using the kind of firewall you are referring to (though I am open to correction). > > Normally, one can simply blow away half-open connections when > > the side that has crashed detects them. This is not so trivial for a > > security session because this has to be done securely, otherwise > > denial-of-service attacks would be trivial. (Not to say that this can't > > be solved, but this at least presents another complication). > > I don't see why its a problem at all. The TCP connections to the dead > machine will vanish on their own. The security associations will > eventually time out and go away. New connections from the rebooted > machine will form new security associations. Yes, but we are not talking about a security protocol just for TCP. We are talking about a security protocol for IP, and TCP is not the only thing that runs over IP. In particular, secure sessions running underneath session-less protocols (e.g. UDP based apps) will not time out and vanish. (As it so happens, the encrypted video demo using Sun's ShowMe application that I gave at the San Jose IETF is one such application.) Regards, Ashar. From ipsec-request@ans.net Sun Feb 26 23:18:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04985 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 18:32:05 -0500 Received: by interlock.ans.net id AA06341 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 18:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 26 Feb 1995 18:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 18:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 18:21:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 18:21:32 -0500 Message-Id: <9502262318.AA06459@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Sun, 26 Feb 1995 14:58:29 PST." <9502262258.AA01913@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 18:18:08 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > From perry@imsi.com Fri Feb 24 15:15 PST 1995 > > Under those circumstances, SKIP would display absolutely identical > > properties if it was to perform well. You would end up having to cache > > lots of keys in the kernel -- unless you were going to do server > > lookups on each, with several packet exchanges, which would obviate > > all claims of performance advantages. > > As I just explained in an earlier message to Carl, SKIP caching is quite > different from caching stateful connections. It is very session-less, Ashar; A session is a lump of data sitting in memory. It isn't a bunch of phone linemen with trucks. Our connections are "virtual"; they are just state. From what I can tell, SKIP forces you to cache a bunch of data, and other proposals do, too. As soon as you start having to keep track of data, you aren't stateless and thats all that counts. "Sessions" are a red herring. The question is state, and you have it just like all the other proposals. You can't avoid it. One reason people have to want to be stateless is that things like DNS get huge amounts of traffic from lots of sources -- but you would have just as bad a problem securing DNS traffic as anyone else, because you'd have to do lots of database lookups for your keys just like everyone else. IPSP isn't suitable for such applications -- only things like the Eastlake-Kaufman DNS proposal, which produce very low server overhead by pre-signing lots of data, will work for such applications. > and with the right implementation, one can almost completely hide the > overhead of expensive public-key operations; this cannot be achieved > by caching traditional secure sessions. Why not? So far as I can tell you are just labeling your data differently -- you are also involving state, you are just calling it something else. > > Now, as for firewalls with large numbers of clients, I have actually > > built and operated such firewalls. They all operate with application > > level relays which are far heavier weight, statewise, than security > > associations could ever be. These firewalls function just fine. > > We have several firewalls in-house as well. However, these firewalls > with application-layer relays have never been used to establish > entire virtual enterprises over a public net like the Internet. What is a "virtual enterprise", and why should we expect it to be any harder to establish than anything else? Anyway, the point was simply that existing systems that employ state are capable of handling fairly heavy loads -- loads similar, if not higher than, the ones we would expect to have to hit in machines dealing with the sort of state that SKIP or other protocols would induce in them. And yes, Ashar, you are not proposing a stateless protocol no matter what you would say. > > > Normally, one can simply blow away half-open connections when > > > the side that has crashed detects them. This is not so trivial for a > > > security session because this has to be done securely, otherwise > > > denial-of-service attacks would be trivial. (Not to say that this can't > > > be solved, but this at least presents another complication). > > > > I don't see why its a problem at all. The TCP connections to the dead > > machine will vanish on their own. The security associations will > > eventually time out and go away. New connections from the rebooted > > machine will form new security associations. > > Yes, but we are not talking about a security protocol just for TCP. Thats completely irrelevant. You just put an inactivity timer on your SA structures and they clean themselves up. Bit deal. > We are talking about a security protocol for IP, and TCP is not the > only thing that runs over IP. In particular, secure sessions running > underneath session-less protocols (e.g. UDP based apps) will not time out > and vanish. Yes they will. If you have no traffic for long enough a period, you can time out your state, and if new traffic arises, you can re-establish it. > (As it so happens, the encrypted video demo using Sun's ShowMe > application that I gave at the San Jose IETF is one such application.) ShowMe is a very heavyweight application -- you get data packets from it on a constant basis. I would expect, then, that the half-open state problem would not be a problem -- a two minute inactivity timer on your state would easily handle the problem. That was your original point, remember? In any case, I assume that you have to build such stuff into the cache of state that you have to have built into your SKIP implementation, because unless you are caching keys that you expect to be using soon, you will hit insanely bad performance problems -- like having to do an X.500 query to the X.500 database you are depending on to store your X.509 certificates on every packet for which you haven't already cached the keys. Perry From ipsec-request@ans.net Sun Feb 26 23:30:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05105 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 18:45:10 -0500 Received: by interlock.ans.net id AA06240 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 18:34:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 26 Feb 1995 18:34:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 18:34:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 18:34:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 18:34:44 -0500 Message-Id: <9502262330.AA06477@snark.imsi.com> To: ashar@miraj.incog.com (Ashar Aziz) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Sun, 26 Feb 1995 14:27:35 PST." <9502262227.AA01906@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 18:30:20 -0500 From: "Perry E. Metzger" Ashar Aziz says: > >From: Carl Muckenhirn > > Even with SKIP, there is some state kept around somewhere, maybe > > in the DNS (more messages), but it has to exist. In the case of > > crashes/reboot, you have to "re-establish" the context of all of > > those connections eventually anyways (not TCP connections per-se, > > but connections nevertheless). No one has said that the > > re-establishment was a synchronous event, just bring them back > > when you need them, you'll need them again in most cases. > > There may be state but is not connections and it is not shared-state > (a la session keys). A connection is not established in a modern network with wire, and solder, Ashar. Its, too, is just a bit of state sitting in memory. As soon as you have state, all you've done is renamed what we are talking about. Now, Photuris and other alternatives to your SKIP proposal aren't "connection oriented", either. They cache a security association. You cache data and call it something different. Big deal. You are also being extraordinarily deceptive in claiming not to have shared state. Of course you have shared state. If both sides didn't know what key to expect the data to be encrypted with, no communication could take place. The fact that you are being unusual in the way you deal with that data in no way changes the fact that you have state involved and shared information -- you've just renamed it. > SKIP caching is completely session-less > (because the SKIP master key is what needs to be cached) and does not > need to be re-established on both sides in case of a reboot. Of course it has to be re-established. If you don't have the data present again, you can't communicate again. You are being deceptive by renaming things. None of the other proposals claimed to have "sessions" by the way -- you just claim that you are "sessionless", but thats meaningless -- you are caching as much data as they are, and the key database lookups you do are just as expensive as the ones everyone else has to do. > Even this can be eliminated, if one can cache the master keys in > non-volatile secure memory (and we are examining several solutions > that will permit this in a very inexpensive way). This will permit > either side to crash/reboot and perform no public-key operations in > order to go back into secure mode. In what way is this different from anyone else? All the proposals I know of would recover from crashes transparently if you had some NV-RAM available. Big deal. In what way is this a contrast to anyone else? Perry From ipsec-request@ans.net Sun Feb 26 23:34:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13320 (5.65c/IDA-1.4.4 for ); Sun, 26 Feb 1995 18:47:35 -0500 Received: by interlock.ans.net id AA09079 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 26 Feb 1995 18:37:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 26 Feb 1995 18:37:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 26 Feb 1995 18:37:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 26 Feb 1995 18:37:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 26 Feb 1995 18:37:51 -0500 Message-Id: <9502262334.AA06487@snark.imsi.com> To: ashar@miraj.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Sun, 26 Feb 1995 13:51:04 PST." <9502262151.AA01894@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 18:34:38 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > > From ipsec-request@ans.net Fri Feb 24 13:45 PST 1995 > > As soon as you have structured SAIDs, you have to start throwing lots > > of complexity into your kernel -- the kernel must not just have hooks > > for key negotiation but has to keep tables of key negotiation types > > and be an active participant in the key negotiation process. We are > > going to have to start having IANA handing out SAID ranges and the > > like. Furthermore, we've just conflated the layers -- something people > > keep accusing me of doing. I haven't even plotted out all the > > complexities yet. It certainly causes me to have to toss out user > > level key management stuff, which I don't like. > > Our key-management (with structured SAIDs) *is* in fact done > in user space. The difference is that one uses the encrypted > key to aid in the lookup process in the kernel, and is in fact > quite similar to doing a lookup based on a key-id or a SAID from > an implementation perspective. You have to have upcalls from your kernel to deal with structured SAIDs, and you have to deal with different types of these structured SAIDs -- of course, you've only implemented the ones for SKIP, but what happens when someone else wants to use these structured SAIDs for some purpose? At which point, of course, the kernel has to distinguish between them and start building a switch table to decide where to do the upcall to. Of course it all can be done -- but its more complex. Its also less modular. Without this stuff, you can replace key management without any kernel manipulation at all. Perry From ipsec-request@ans.net Mon Feb 27 07:52:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07989 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 04:19:13 -0500 Received: by interlock.ans.net id AA06293 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 04:07:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 04:07:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 04:07:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 04:07:54 -0500 From: stefan@gandalf.artwise.de (Stefan Heiligensetzer) To: Danny.Nessett@eng.sun.com, ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: RE: out-of-band key management is like virtual circuits Reply-To: stefan@artwise.de Date: Mon, 27 Feb 95 07:52:10 GMT Message-Id: <9502270752.0A3A00@melkor.artwise.de> X-Mailer: SelectMAIL 1.2 please take me off the mailing list. kind regards Stefan ________________________________________________________________ Stefan Heiligensetzer Zeppelinstr.7 Tel. xx49 731 97443-21 Artwise GmbH 89231 Neu-Ulm Fax. xx49 731 97443-83 Software Solutions Germany email: stefan@artwise.de From ipsec-request@ans.net Mon Feb 27 09:44:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12794 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 06:22:35 -0500 Received: by interlock.ans.net id AA08260 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 06:11:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 06:11:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 06:11:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 06:11:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 06:11:40 -0500 From: Jon Jagger Organization: Sheffield Hallam University To: ipsec@ans.net Date: Mon, 27 Feb 1995 09:44:42 GMT0BST Subject: RE: unsubscribe me please Reply-To: J.R.Jagger@shu.ac.uk Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <8586A152DCF@oak.csv.shu.ac.uk> please take me off the mailing list. Please note my IP address below, as I believe my domain name has changed since I joined. Thanks JJ :: Jon Jagger, Computer Services, Sheffield Hallam University, S1 1WB, UK :: Internet J.R.Jagger@shu.ac.uk :: Tel +44 742 533802/432889 (work/home) :: Fax +44 742 533840 :: Roses are red, violets are blue, I'm schizophrenic, and so am I From ipsec-request@ans.net Mon Feb 27 15:33:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08297 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 11:42:43 -0500 Received: by interlock.ans.net id AA35348 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 11:28:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 11:28:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 11:28:41 -0500 Date: Mon, 27 Feb 95 15:33:07 GMT From: "William Allen Simpson" Message-Id: <4030.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 Over the weekend, I combined the AH and MD5 drafts, and added an option to calculate key,text,key. The parameter can be indicated by key management. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 15:35:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15979 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 11:42:44 -0500 Received: by interlock.ans.net id AA37653 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 11:28:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 11:28:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 11:28:41 -0500 Date: Mon, 27 Feb 95 15:35:49 GMT From: "William Allen Simpson" Message-Id: <4031.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 DES and 3DES Over the weekend, I combined the ESP and DES drafts. The suggestion to use 3DES as a requirement instead was strongly rejected. 3DES will remain a separate transform. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 15:33:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14863 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 12:26:55 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Mon, 27 Feb 1995 12:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Mon, 27 Feb 1995 12:20:07 -0500 Date: Mon, 27 Feb 95 15:33:07 GMT From: "William Allen Simpson" Message-Id: <4030.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 Over the weekend, I combined the AH and MD5 drafts, and added an option to calculate key,text,key. The parameter can be indicated by key management. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 07:15:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14918 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 12:31:50 -0500 Received: by interlock.ans.net id AA12228 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 12:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 12:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:20:37 -0500 Date: Mon, 27 Feb 95 12:15:58 EST From: sharborth@hai-net.com Message-Id: <9501277939.AA793916526@houston_cc_smtp.hai-net.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Return-Receipt-To: sharborth@hai-net.com Subject: Re[2]: (IPng) Proposed Standard or no? You are right I did not look at the all of the references before speaking. I was thinking along the lines of "out-of-band" negotiations being done via courier as Ran noted in his 2:03 pm message of 25 February. Also, I do currently use systems which use "out-of-band" couriers for distribution of keymat and the equipment also does in-band key management for distribution of key. Skip _______________________________________________________________________________ Subject: Re: (IPng) Proposed Standard or no? From: ipng@sunroof.Eng.Sun.COM at internet Date: 26-02-95 13:40 sharborth@hai-net.com says: > Allow both. Don't mandate the use of one over the other. In > systems which are in use today we use both methods, I would suspect > each equally (at least from my experience over the past 12 years in > secure communications system design & implementation.) I suspect that you don't understand what is being discussed -- I'm not trying to insult you here, its just that the conversation is being couched in very deceptive terms. You probably are not using either method today, and very likely not both. The terminology is very odd -- I suggest that you read all the drafts in question in order to really get a feel for what is being discussed. The topic boils down to this: do we want to permit for conveying key management information in IPSP packets instead of in, say, separate UDP packets. The argument being made on our side is "it won't give you any performance and messes up a very clean design, making it far harder to implement for negligible gain". The argument on their side boils down to "we get to save a whole packet at the beginning of each of your TCP sessions, and it means you get to rekey on every packet!" Neither of these particularly seem to be important to me. In the end, this comes down to whether you feel SKIP should be the key management protocol we use -- the changes are being requested purely to support SKIP, because Ashar seems to have painted himself into a corner in which he assured us all along that he could adapt SKIP to the proposed IPSP design and then realized only in the last week (it seems) that he needed functionality at the IPSP layer that wasn't available. One of the reasons a number of us have argued this discussion should be on the IPSEC list is because people on IPng lack the context of the discussion. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From ipsec-request@ans.net Mon Feb 27 15:35:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16371 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 12:45:58 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Mon, 27 Feb 1995 12:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Mon, 27 Feb 1995 12:39:51 -0500 Date: Mon, 27 Feb 95 15:35:49 GMT From: "William Allen Simpson" Message-Id: <4031.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 DES and 3DES Over the weekend, I combined the ESP and DES drafts. The suggestion to use 3DES as a requirement instead was strongly rejected. 3DES will remain a separate transform. Are there any other considerations? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 17:32:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16218 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 12:55:31 -0500 Received: by interlock.ans.net id AA16580 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 12:45:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:45:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:45:28 -0500 Date: Mon, 27 Feb 95 17:32:29 GMT From: "William Allen Simpson" Message-Id: <4037.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 Late breaking news! The {key,text,key} hash is the wrong way to go for MD5. Because of the way that MD5 is designed, MD5 dilutes the effect of the key over multiple blocks. (I remember Jim Hughes pointed this out, too.) According to reports from the PSRG meeting (two weeks ago), Kalisky says we should first hash the text without a key, then hash the {hash,key}. This gives the key greater strength in the final hash. If he had been designing MD5 for keying, he would have added the key in at each step of the block hashing. (I got this from Schiller over the phone, so any mistake in reporting is entirely mine, as this is a third hand report.) Any objections? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 13:10:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06827 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 13:10:54 -0500 Received: by interlock.ans.net id AA19846 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 12:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 12:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:57:09 -0500 Date: Mon, 27 Feb 95 09:17:42 From: "Housley, Russ" Encoding: 1076 Text Message-Id: <9501277939.AA793905462@spysouth.spyrus.com> To: Paul_Lambert-P15452@email.mot.com, perry@imsi.com Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP Perry & Paul: >> The IPv4-AH header that you propose meets the basic format >> requirements of the IPv6-AH protocol. There is no need for both! > >Yes there is. The AH header is transparent, the ESP header is >non-transparent. The need for both was discussed in enormous detail >by Steve Bellovin in Toronto. It also follows our general attempts to >be as reasonably compatible with the IPv6 formats as possible, which >was also part of the Toronto consensus. This topic was also discussed at great length in San Jose, but I do not recall consensus. I recall emphatic assertion by a few loud voices. Personally, I am not convinced that the Internet community is well served by four network layer security protocols. IPv4-ESP, IPv4-AH, IPv6-ESP, IPv6-AH is too much. Each of these specifies a different syntax for the protocol data unit, and thus, each will require a different parser. Clearly, the cryptographic routines can be common, but I do not think that we will see ubiquitous implementation with this kind of diversity. Russ From ipsec-request@ans.net Mon Feb 27 13:10:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18604 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 13:10:54 -0500 Received: by interlock.ans.net id AA19214 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 12:58:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 12:58:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 12:58:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 12:58:36 -0500 Date: Mon, 27 Feb 95 09:17:38 From: "Housley, Russ" Encoding: 1420 Text Message-Id: <9501277939.AA793905458@spysouth.spyrus.com> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net, Danny.Nessett@eng.sun.com (Dan Nessett) Subject: Re: out-of-band key management is like virtual circuits Hi Dan. In IEEE 802.10, when we were developing the Secure Data Exchange (SDE) Protocol, this same "in-line" key issue surfaced. It was resolved in a manner that has not been considered by the IETF. The solution has pros and cons, but I think that it should be considered before a decision is made. SDE has a 32-bit SAID that is followed by an optional field, called the Management Defined Field (MDF). DEC pushed very hard for this field because they wanted the SAID to identifiy a Master Key that would be used to decrypt the contents of the MDF. The MDF carried the key or keys to decrypt and/or check the integrity of the payload. SKIP is the same idea. SKIP sderives the Master Key using D-H key agreement instead of out-of-band master key distribution. This alternative would permit the approach advocated by DEC, and it would accompdate the SKIP approach. Using a bit in the SAID to indicate the presence/absence of the MDF (or whatever we call it for IPSP) would avoid the need for a key management protocol to negotiate the attributes for the security association. Perhaps a reserved SAID would indicate that the key management technique used by SKIP should be used to generate the key to decrypt the MDF. I just do not see why we cannot architect an IP layer security protocol that permits both types of key management. More food for thought.... Russ From ipsec-request@ans.net Mon Feb 27 18:15:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14242 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 13:27:26 -0500 Received: by interlock.ans.net id AA23514 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 13:16:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 13:16:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 13:16:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 13:16:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 13:16:32 -0500 Message-Id: <9502271815.AA07587@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 AH and ESP In-Reply-To: Your message of "Mon, 27 Feb 1995 09:17:42." <9501277939.AA793905462@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 13:15:32 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Personally, I am not convinced that the Internet community is well served > by four network layer security protocols. IPv4-ESP, IPv4-AH, IPv6-ESP, > IPv6-AH is too much. Each of these specifies a different syntax for the > protocol data unit, and thus, each will require a different parser. > Clearly, the cryptographic routines can be common, but I do not think that > we will see ubiquitous implementation with this kind of diversity. I agree. That is why Bill and I have specified the IPv4 protocol in a way that is indistinguishable from the IPv6 protocol. We are trying to merge the proposals. Paul keeps trying to prevent the merger of the protocols which the rest of us keep trying to move forward. You have stumbled upon one of the reasons that I'm upset with him. Even if the implementations of the protocols end up being separate, as Ran keeps pointing out, I feel that from an understandability point of view its best to reduce the number of different entities floating around. Thus far, Paul has been the only person to disagree. As it stands, the documents that we've produced are nearly identical to the v6 documents, and in fact we are trying to negotiate a merger at some point. On the question of why both AH and ESP versus simply ESP, the reason is simple -- some applications need to reveal the underlying protocol, and some need to conceal it. The two headers simply make it possible to do each. Other than this difference, the mechanisms are identical. As I noted, Steve Bellovin went into great detail as to why we needed the AH mechanism to make filtering possible on firewalls, and given that the v6 folks already had it it seemed like a very useful and important mechanism to specify. Perry From ipsec-request@ans.net Mon Feb 27 18:31:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15561 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 13:44:40 -0500 Received: by interlock.ans.net id AA22999 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 13:32:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 13:32:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 13:32:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 13:32:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 13:32:05 -0500 Message-Id: <9502271831.AA07644@snark.imsi.com> To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 In-Reply-To: Your message of "Mon, 27 Feb 1995 17:32:29 GMT." <4037.bsimpson@morningstar.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 13:31:09 -0500 From: "Perry E. Metzger" "William Allen Simpson" says: > According to reports from the PSRG meeting (two weeks ago), Kalisky says > we should first hash the text without a key, then hash the {hash,key}. > This gives the key greater strength in the final hash. > > If he had been designing MD5 for keying, he would have added the key in > at each step of the block hashing. > > (I got this from Schiller over the phone, so any mistake in reporting is > entirely mine, as this is a third hand report.) > > Any objections? Yes! I object to giving Burt credit for Ron Rivest's hash function, and I object to the misspelling of his last name! Other than that, no objections; if the commentary is true I'm not about to argue with Kaliski, although frankly having glanced at it I'm not sure why MD5(MD5(text),key) would be stronger than MD5(text+key) given MD5's way of folding in new text into a hash. It would be nice to get some comments straight from the horse's mouth, as it were. Anyone remember Burt Kaliski's email address? .pm From ipsec-request@ans.net Mon Feb 27 09:23:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14477 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 14:38:18 -0500 Received: by interlock.ans.net id AA07440 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 14:25:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 14:25:03 -0500 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 14:25:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 14:25:03 -0500 Date: Mon, 27 Feb 95 14:23:59 EST X-Sender: shirey@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@imsi.com From: shirey@mitre.org (Robert W. Shirey) Subject: Re: WG last call for IPv4 MD5 Cc: "William Allen Simpson" , ipsec@ans.net Burt Kaliski At 1:31 PM 2/27/95, Perry E. Metzger wrote: >"William Allen Simpson" says: >> According to reports from the PSRG meeting (two weeks ago), Kalisky says >> we should first hash the text without a key, then hash the {hash,key}. >> This gives the key greater strength in the final hash. >> >> If he had been designing MD5 for keying, he would have added the key in >> at each step of the block hashing. >> >> (I got this from Schiller over the phone, so any mistake in reporting is >> entirely mine, as this is a third hand report.) >> >> Any objections? > >Yes! I object to giving Burt credit for Ron Rivest's hash function, and >I object to the misspelling of his last name! > >Other than that, no objections; if the commentary is true I'm not >about to argue with Kaliski, although frankly having glanced at it I'm >not sure why MD5(MD5(text),key) would be stronger than MD5(text+key) >given MD5's way of folding in new text into a hash. It would be nice >to get some comments straight from the horse's mouth, as it >were. Anyone remember Burt Kaliski's email address? > >.pm From ipsec-request@ans.net Mon Feb 27 19:32:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12776 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 15:01:03 -0500 Received: by interlock.ans.net id AA19446 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 14:48:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 14:48:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 14:48:56 -0500 Date: Mon, 27 Feb 95 19:32:57 GMT From: "William Allen Simpson" Message-Id: <4045.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: WG last call for IPv4 MD5 > From: "Perry E. Metzger" > Yes! I object to giving Burt credit for Ron Rivest's hash function, and > I object to the misspelling of his last name! > Sorry, name spelling of an unfamiliar person as it passes from my ears to my fingers isn't one of my strong points. And, I could have screwed up the interpretation. Maybe Rivest was at the meeting, too. > Other than that, no objections; if the commentary is true I'm not > about to argue with Kaliski, although frankly having glanced at it I'm > not sure why MD5(MD5(text),key) would be stronger than MD5(text+key) > given MD5's way of folding in new text into a hash. It would be nice > to get some comments straight from the horse's mouth, as it > were. Anyone remember Burt Kaliski's email address? > Well, in his message last month (forwarded by Housley), where he talked about some of these issues, it was burt@rsa.com. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Feb 27 20:44:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14407 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 15:59:44 -0500 Received: by interlock.ans.net id AA22500 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 15:47:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 15:47:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 15:47:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 15:47:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 15:47:29 -0500 Date: Mon, 27 Feb 1995 12:44:48 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502272044.AA02314@miraj.> To: ipng@sunroof.eng.sun.com, ipsec@ans.net, perry@imsi.com Subject: Re: (IPng) Proposed Standard or no? X-Sun-Charset: US-ASCII > From: "Perry E. Metzger" > The topic boils down to this: do we want to permit for conveying key > management information in IPSP packets instead of in, say, separate > UDP packets. The argument being made on our side is "it won't give you > any performance and messes up a very clean design, making it far > harder to implement for negligible gain". The argument on their side > boils down to "we get to save a whole packet at the beginning of each > of your TCP sessions, and it means you get to rekey on every packet!" > Neither of these particularly seem to be important to me. > > In the end, this comes down to whether you feel SKIP should be the key > management protocol we use -- the changes are being requested purely > to support SKIP, because Ashar seems to have painted himself into a > corner in which he assured us all along that he could adapt SKIP to > the proposed IPSP design and then realized only in the last week (it > seems) that he needed functionality at the IPSP layer that wasn't > available. Perry, As I have mentioned repeatedly (and as others have also mentioned), SKIP is not the only approach that uses in-band communication of keys. The reason I asked if IPSP could support SKIP is because there was some ambiguity of what can and cannot be in IPSP. Ran and you believe that the current IPSP doesn't support it, whereas Bill Simpson though that it wasn't precluded. No, it doesn't in the end come down to whether you feel SKIP should be the key-management protocol we use. The changes accommodate key-management techniques that have nothing to do with SKIP. It comes down to whether SKIP (or, e.g. DEC style key-management) can be an *option* to consider later on. Precluding particular styles of key-mgmt when we haven't yet decided on which key-mgmt technique to use is not a good idea. I have since the Toronto meeting asked for in-band key-mgmt. It was in both my presentations (independent of SKIP) and this was on a slide that was put up on the projector in both talks (despite claims to the contrary). Check out the "Precursor to SKIP" slide that gives a picture of in-band key-mgmt, and states that IPSP should support this mode of operation. The Toronto slides should still be ftp available from ftp.network.com, and if you have hard copies from the San Jose talks it should be in there. This is not something that I came up with in the last few weeks, and it shouldn't be presented as such. This doesn't lock us into any one kind of key-mgmt and it shouldn't be presented as such. And please don't trivialize the argument to saving one packet in the beginning of a TCP connection. The DEC folks had sound engineering reasons for doing in-band key-mgmt and we had some real engineering concerns that led us to do something similar. These issues/concerns have been presented before, are in the slides, in the mail archives, and don't need be rehashed over and over. I agree with Russ, Dan, Jim, Tom, Piper, Bob Moskowitz and others who believe that we shouldn't be precluding any viable kind of key-mgmt option. Regards, Ashar. From ipsec-request@ans.net Mon Feb 27 21:04:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16706 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 16:19:30 -0500 Received: by interlock.ans.net id AB35977 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 16:07:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 16:07:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 16:07:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 16:07:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 16:07:41 -0500 Message-Id: <9502272104.AA07901@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Mon, 27 Feb 1995 12:44:48 PST." <9502272044.AA02314@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 16:04:14 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > As I have mentioned repeatedly (and as others have also mentioned), > SKIP is not the only approach that uses in-band communication > of keys. The reason I asked if IPSP could support SKIP is because > there was some ambiguity of what can and cannot be in IPSP. Ran > and you believe that the current IPSP doesn't support it, whereas > Bill Simpson though that it wasn't precluded. > Actually, I have no opinion on whether IPSP can or cannot support SKIP. At Toronto, you said that there was no problem in changing your packet format to match IPSP. At San Jose, you didn't indicate that you had a problem with the packet format. After Bill Simpson made it clear that the amount of time left for comments was limited a couple of weeks ago, you first mentioned this need to convey key management information inside IPSP packets and you asked if we could structure SAIDs. You never said you wanted that before. If you did say so, it isn't in the archives of the mailing list I just searched, and it isn't in any of my notes from the meetings. > I have since the Toronto meeting asked for in-band key-mgmt. "In Band" is an ambiguous term. What we are talking about is sending key management data in IPSP packets with special reserved SAIDs instead of in their own packets -- nothing more. My recollection is that you said that you had no problem with IPSP on several occassions. > And please don't trivialize the argument to saving one packet in > the beginning of a TCP connection. The DEC folks had sound engineering > reasons for doing in-band key-mgmt Yeah; they had a patented high speed hardware DES chip that took the key at the head of the data to be decrypted, so it gave them a nice market advantage. > and we had some real engineering concerns that led us to do > something similar. > I agree with Russ, Dan, Jim, Tom, Piper, Bob Moskowitz and > others who believe that we shouldn't be precluding any viable > kind of key-mgmt option. I'm not aware that we are precluding any viable option -- including a slightly modified SKIP. What we are precluding is pre-assigned SAIDs and all the kernel muck that would be associated with processing them. Perry From ipsec-request@ans.net Mon Feb 27 21:45:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15264 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 17:03:23 -0500 Received: by interlock.ans.net id AA38426 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 16:48:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 16:48:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 16:48:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 16:48:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 16:48:31 -0500 Date: Mon, 27 Feb 1995 13:45:53 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502272145.AA02352@miraj.> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII > From: "Perry E. Metzger" > A session is a lump of data sitting in memory. It isn't a bunch of > phone linemen with trucks. Our connections are "virtual"; they are > just state. From what I can tell, SKIP forces you to cache a bunch of > data, and other proposals do, too. As soon as you start having to keep > track of data, you aren't stateless and thats all that > counts. "Sessions" are a red herring. The question is state, and you > have it just like all the other proposals. You can't avoid it. Perry, I disagree (which by now shouldn't be a surprise). E-mail and IP are session-less. I can send you IP packets or e-mail regardless of whether your node is up or down (you may not receive them but that's a different story). I cannot establish a TCP or X.25 connection with you if your node is unavailable. Now, with SKIP I can establish and change keys, even if your node is down. With other session oriented key-mgmt schemes this cannot be done. It is in this sense that SKIP is stateless and session less and operates essentially like IP. The cache of information that SKIP maintains is similarly session less (as e.g. information about what the remote node's IP address is session-less, but per VCI X.25 information is not). SKIP cached information is good across reboots. The information that some of the other key-mgmt protocols maintain (e.g. session keys) is not good across reboots. This means public-key operations always have to be done after reboots, but with SKIP they only have to be done once. These are important distinctions. > > Yes, but we are not talking about a security protocol just for TCP. > > Thats completely irrelevant. You just put an inactivity timer on your > SA structures and they clean themselves up. Bit deal. > > ShowMe is a very heavyweight application -- you get data packets from > it on a constant basis. I would expect, then, that the half-open state > problem would not be a problem -- a two minute inactivity timer on > your state would easily handle the problem. No, it wouldn't. ShowMe will send video regardless of whether the remote node is up or down. There will be no inactivity, and so the inactivity timer will never go off. Regards, Ashar. From ipsec-request@ans.net Mon Feb 27 22:33:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16913 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 17:48:39 -0500 Received: by interlock.ans.net id AA12813 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 17:35:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 17:35:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 17:35:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 17:35:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 17:35:59 -0500 Message-Id: <9502272233.AA08013@snark.imsi.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Mon, 27 Feb 1995 13:45:53 PST." <9502272145.AA02352@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 17:33:07 -0500 From: "Perry E. Metzger" Ashar Aziz says: > Now, with SKIP I can establish and change keys, even if your > node is down. With other session oriented key-mgmt schemes > this cannot be done. One wonders of the utility of establishing a key for use with a host that isn't up. > It is in this sense that SKIP is stateless SKIP is emphatically NOT stateless -- at least not if it performs remotely well. As I've noted, unless you are going to do a key lookup in a key database for every packet that comes in, you are going to have to cache just as much state as everyone else. > SKIP cached information is good across reboots. > > The information that some of the other key-mgmt protocols maintain > (e.g. session keys) is not good across reboots. Why wouldn't it be? You say that if you have NVRAM you can do this miraculous preservation of SKIP cached information across reboots, but as I've noted, if you actually had nonvolitile ram to cache security association information in across reboots, there would be no reason any other key management protocol couldn't maintain state, too. Furthermore, reboots are an extremely unusual circumstance, and I don't think that maintaining associations across reboots is going to impact reboot times as much as, say, file system consistancy checks. (By the way, my routers typically are rebooted on the order of once a year or less.) > > > Yes, but we are not talking about a security protocol just for TCP. > > > > Thats completely irrelevant. You just put an inactivity timer on your > > SA structures and they clean themselves up. Bit deal. > > > > ShowMe is a very heavyweight application -- you get data packets from > > it on a constant basis. I would expect, then, that the half-open state > > problem would not be a problem -- a two minute inactivity timer on > > your state would easily handle the problem. > No, it wouldn't. ShowMe will send video regardless of whether > the remote node is up or down. There will be no inactivity, and so > the inactivity timer will never go off. The inactivity timer is at the RECEIVER, not at the SOURCE. Security associations are different in each direction. .pm From ipsec-request@ans.net Mon Feb 27 22:54:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17658 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 18:07:53 -0500 Received: by interlock.ans.net id AA09834 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 17:57:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 17:57:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 17:57:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 17:57:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 17:57:05 -0500 Date: Mon, 27 Feb 1995 14:54:30 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502272254.AA02374@miraj.> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII > From: "Perry E. Metzger" > You have to have upcalls from your kernel to deal with structured > SAIDs, and you have to deal with different types of these structured > SAIDs -- of course, you've only implemented the ones for SKIP, but > what happens when someone else wants to use these structured SAIDs for > some purpose? At which point, of course, the kernel has to distinguish > between them and start building a switch table to decide where to do > the upcall to. Of course it all can be done -- but its more > complex. Its also less modular. Without this stuff, you can replace > key management without any kernel manipulation at all. Perry, I don't understand this argument at all. Allowing the *possibility* for someone else to implement a particular kind of key-mgmt technique doesn't force you to do any kernel manipulations at all. The way the DEC scheme works, the key-manipulations happen in hardware, not even in the kernel. If someone implements that, then they have the hardware to do that. If not, then they don't do anything. Nobody is forcing you do implement any particular scheme in the kernel. Those of us who want to implement a particular scheme will have the right combination of software and hardware to do that. And it's really not as complex as you are making it out to be. Regards, Ashar. From ipsec-request@ans.net Mon Feb 27 23:14:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15779 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 18:26:04 -0500 Received: by interlock.ans.net id AA23186 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 18:14:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 18:14:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 18:14:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 18:14:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 18:14:17 -0500 From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9502272314.AA04067@monster.incog.com> Subject: Re: (IPng) Proposed Standard or no? To: perry@imsi.com Date: Mon, 27 Feb 1995 15:14:13 -0800 (PST) Cc: ashar@osmosys.incog.com, ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: <9502272104.AA07901@snark.imsi.com> from "Perry E. Metzger" at Feb 27, 95 04:04:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text >[Perry Metzger writes:] > I'm not aware that we are precluding any viable option -- including a > slightly modified SKIP. What we are precluding is pre-assigned SAIDs > and all the kernel muck that would be associated with processing them. I don't understand this argument. If the host implements in-band key management, then it will use the "structured" bit in the SAID. If it doesn't, it can safely ignore it. I don't understand how this will create muck in the kernel. --tom From ipsec-request@ans.net Mon Feb 27 23:39:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16859 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 18:52:21 -0500 Received: by interlock.ans.net id AA28389 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 18:41:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 18:41:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 18:41:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 18:41:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 18:41:56 -0500 Date: Mon, 27 Feb 1995 15:39:21 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502272339.AA02389@miraj.> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII > From: "Perry E. Metzger" > > No, it wouldn't. ShowMe will send video regardless of whether > > the remote node is up or down. There will be no inactivity, and so > > the inactivity timer will never go off. > > The inactivity timer is at the RECEIVER, not at the SOURCE. Security > associations are different in each direction. But the session key that needs to be blown away is at the source. The receiver has no state left of that association when it reboots, so how will inactivity timeouts on the receiver help? The receiver will simply be seeing encrypted traffic coming in over a SAID that it has no information on, and it will need to somehow tell the sender (securely) to blow that association away. The receiver will not have an inactivity timer for an association that it knows nothing about. Responding to the other parts of your message would entail rehashing arguments that have already been made, and I will spare the lists this rehash. Regards, Ashar. From ipsec-request@ans.net Tue Feb 28 01:38:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15075 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 20:49:31 -0500 Received: by interlock.ans.net id AA25189 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 20:38:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 27 Feb 1995 20:38:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 20:38:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 20:38:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 20:38:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 20:38:41 -0500 Date: Mon, 27 Feb 1995 17:38:20 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199502280138.RAA25744@elrond.Eng.Sun.COM> To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII Russ, Thanks for the information on SDE. It sounds like these issues have been thoroughly discused in other forums. Dan From ipsec-request@ans.net Tue Feb 28 01:44:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14864 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 20:55:39 -0500 Received: by interlock.ans.net id AA32430 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 20:46:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 20:46:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 20:46:14 -0500 X-Sender: cfm@bugs.columbia.sparta.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Feb 1995 20:44:27 -0500 To: ashar@osmosys.incog.com (Ashar Aziz), ipng@sunroof.eng.sun.com, ipsec@ans.net From: cfm@columbia.sparta.com (Carl F. Muckenhirn) Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits At 1:45 PM 2/27/95, Ashar Aziz wrote: >> From: "Perry E. Metzger" >> A session is a lump of data sitting in memory. It isn't a bunch of >> phone linemen with trucks. Our connections are "virtual"; they are >> just state. From what I can tell, SKIP forces you to cache a bunch of >> data, and other proposals do, too. As soon as you start having to keep >> track of data, you aren't stateless and thats all that >> counts. "Sessions" are a red herring. The question is state, and you >> have it just like all the other proposals. You can't avoid it. > >Perry, > >I disagree (which by now shouldn't be a surprise). E-mail and >IP are session-less. I can send you IP packets or e-mail regardless >of whether your node is up or down (you may not receive them >but that's a different story). I cannot establish a TCP or >X.25 connection with you if your node is unavailable. This is an interesting approach, session(connection)less e-mail (I assume not SMTP, POP, MMDF, X.400). Ignoring that, of what use it it sending IP datagrams to me if I can't recieve them. Who is sending them and why? A DNS query, well I believe that it will timeout (at the UDP level but it will still time-out), how about NTP, well same thing. In both of these cases there is no harm (that's how they're designed to work) but I can't see how this helps SKIP. > >Now, with SKIP I can establish and change keys, even if your >node is down. With other session oriented key-mgmt schemes >this cannot be done. It is in this sense that SKIP is stateless >and session less and operates essentially like IP. The cache of >information that SKIP maintains is similarly session less >(as e.g. information about what the remote node's IP address is >session-less, but per VCI X.25 information is not). SKIP >cached information is good across reboots. What good was it to change keys if I can't receive the packet? How do the "out-of-band" key management protocols suffer from not being able to change keys when their peer is unavailable? (other than that they will know with higher assurance that they peer is unavailable). And why is the SKIP information session-less? I believe that the master key needs to be rekeyed periodically (at least I hope it is), will this change at the same (spritely) pace as IP addresses? How frequent are the cases where one of the parties will be down when the other needs to send this (obviously) time critical information (we can't wait for the key to be set up), and if it is so critical that the information not be delayed, don't we want to know that the peer is down? > >The information that some of the other key-mgmt protocols maintain >(e.g. session keys) is not good across reboots. This means public-key >operations always have to be done after reboots, but with SKIP they >only have to be done once. These are important distinctions. > Why is it that SKIP can cache "security information" and other approaches can't? I don't believe that any of the other key mgmt protocols proposed to date actually specify volatile storage of keys, and if this is really such a problem we can always add that to the approach. >> > Yes, but we are not talking about a security protocol just for TCP. >> >> Thats completely irrelevant. You just put an inactivity timer on your >> SA structures and they clean themselves up. Bit deal. >> >> ShowMe is a very heavyweight application -- you get data packets from >> it on a constant basis. I would expect, then, that the half-open state >> problem would not be a problem -- a two minute inactivity timer on >> your state would easily handle the problem. > >No, it wouldn't. ShowMe will send video regardless of whether >the remote node is up or down. There will be no inactivity, and so >the inactivity timer will never go off. > This is good? I thought that bandwidth was a fairly precious resource. And it doesn't really apply in the case we are talking about. If ShowMe is running using Photuris (for example) as its key management protocol, and the distant end dies, it just dies. Phouris only comes to play when someone (daemon?) decides it is time to rekey, if that's 8 hours from now, well then we discover that foobar.mars.com is fubar and we stop clogging the Internet with videograms. With SKIP we go on until god knows when. >Regards, >Ashar. The more I think about SKIP, the more my initial impression is reinforced. Specifically, that SKIP addresses the easy part, I know something about the distant end and want to "securely" exchange a key with him. But it glosses over the hard part, how to get that "something" in place securely at both ends. If there is any real difference between "out-of-band" and "in-band" methods it is of degree and not kind. One thing that has somewhat troubled me about SKIP (and I'll admit I haven't implemented it yet) is with "in-band" traffic, I need to change the way IP works (it appears as a new option, functionally) which will incur some (admittedly small) overhead on each packet processed. How does this overhead compare with the "out-of-band" overhead of a separate "connection"? carl. From ipsec-request@ans.net Mon Feb 27 17:07:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15776 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 22:16:22 -0500 Received: by interlock.ans.net id AA21426 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 22:04:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 22:04:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 22:04:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 22:04:40 -0500 Date: Mon, 27 Feb 95 22:07:53 EST From: cmadson@wellfleet.com (Cheryl Madson) Message-Id: <9502280307.AA22788@wellfleet> To: ipsec@ans.net Subject: SAIDs and multicasting Cc: cmadson@wellfleet.com Sorry that I haven't been able to comment sooner; unfortunately my employer insisted that I get a product out the door first ;-). I've just been going through the past several weeks of the mailing list discussions, and am starting to read (or reread, as the case may be) some of the specs, so please bear with me. W.R.T. the issue of multicast traffic and security associations, I've now seen three possible "classes" of traffic for a given multicast group (e.g. where the traffic shares the same address), where each class has a different delivery scope. This is in the context of multicast traffic that can be originated by end systems, not in the context of multicast traffic originated by intermediate systems, e.g. route updates. In my opinion, this is a problem of more than the "classification", as it were, of the types of traffic between two individual systems. a. Local network only. If a host wants to become a member of a multicast group, a registration request is sent to the local multicast router, using the destination address of the desired multicast group. This information needs to be decrypted and retained by the local router. If the local router can't see these packets, the host systems can't see their multicast traffic. And, in the context of the protocol, the other hosts on that local network also need to be able to see these packets, in order for them to "listen before sending" to keep from bombarding the network with duplicate membership requests. [The protocol only cares about the existance of *someone* on the local network that wants the traffic, it doesn't care about whom or how many systems want it.] b. The group of "end systems". If a host wants to send traffic (e.g. application data) to the multicast group, the data is sent using the destination address of the desired multicast group. This information is eventually sent to the end systems throughout the multicast tree. [This traffic is commonly UDP traffic, but there are those implementors who actually *care* that someone or someones are out there listening and who choose to write something more robust (read proprietary) to sit on top of the IP multicast delivery service.] c. The intermediate network routers. In the case of resource reservation for a multicast "session" from a particular source system, the equivalent of a path setup message is sent from the source system throughout the multicast tree. The intervening routers that handle resource reservation must have the capability to intercept and read these flow descriptors (to use an RSVP term). As I work for a router vendor, the requirement to quickly distinguish between which packets need to be intercepted by the router for decryption (a and c above) and which need to be blindly forwarded (b above) is important. The fewer bits one has to look at, the better. I've been wrestling with how separate security associations could be *identified* and set up for these diverse classes of traffic, short of reserving SAIDs for certain types of traffic or forcing some sort of "scope of control" on the SAIDs. Apart from distingishing between types of traffic addressed to a single multicast address (which can be provided implicitly by the use of different SAIDs), I don't think there is a desire for everyone, *routers included*, to be a part of the same security association for the application-specific traffic between the end systems. It may also not be desirable for other end systems to be in the same security association as the intermediate routers for the resource reservation message distribution. [I say this while thinking about "limiting exposure", but I'm also not fully sure how to truly prevent excess exposure even if separate security associations were available.] How would a dynamic assignment of SAIDs come together? To visit a topic which has been mentioned in the past, this becomes an issue of "what party is responsible for the security association?" in the case of a multicast group. In the context of a router, multicast groups are dynamic and ownerless. "sd" is something that allows *people* to reserve group slots, but this is in the context of an application. If a router didn't have to worry about security, it would have no need to figure out who "owned" a group. Of course, all systems will have to go to some repository to obtain certain certificate/key information, but the management of that information in the context of a multicast group is important. [How would we name such things in a central repository?] Aside from that, the thought of having to decrypt and reencrypt these flow descriptor packets (or make copies of the encrypted packets) on a per-hop basis through a multicast tree gives me a headache ;-(. For serious environments, resource reservation will have to be integrated with multicasting. The Mbone may even need it before the next Stones' concert ;-). I'm doing some additional research on some related scoping issues, such as the administrative scoping of multicast groups, so this list isn't necessarily complete. [How does this scoping get identified and/or meshed with the key/certificate server?] However, I wanted to get this out on the table for discussion. Comments and suggestions are welcome. - C ================================================================= Cheryl Madson Senior Engineer, Router Protocol Development Bay Networks, Inc. 2 Federal St., Billerica, MA 01821 cmadson@baynetworks.com From ipsec-request@ans.net Tue Feb 28 03:44:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12562 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 22:56:45 -0500 Received: by interlock.ans.net id AA34949 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 22:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 22:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 22:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 22:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 22:46:27 -0500 Message-Id: <9502280344.AA08316@snark.imsi.com> To: markson@osmosys.incog.com (Tom Markson) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Mon, 27 Feb 1995 15:14:13 PST." <9502272314.AA04067@monster.incog.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 22:44:06 -0500 From: "Perry E. Metzger" Tom Markson says: > >[Perry Metzger writes:] > > I'm not aware that we are precluding any viable option -- including a > > slightly modified SKIP. What we are precluding is pre-assigned SAIDs > > and all the kernel muck that would be associated with processing them. > > I don't understand this argument. If the host implements in-band > key management, then it will use the "structured" bit in the SAID. If it > doesn't, it can safely ignore it. I don't understand how this will create > muck in the kernel. If you want to have the implementation of the bit be optional, that implies that SKIP is being proposed as an optional protocol. Does that imply that you guys are withdrawing from consideration as a SKIP as a proposed internet standard? Perry From ipsec-request@ans.net Tue Feb 28 03:55:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18066 (5.65c/IDA-1.4.4 for ); Mon, 27 Feb 1995 23:05:32 -0500 Received: by interlock.ans.net id AA18678 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Feb 1995 22:56:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 27 Feb 1995 22:56:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Feb 1995 22:56:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Feb 1995 22:56:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Feb 1995 22:56:27 -0500 Message-Id: <9502280355.AA08338@snark.imsi.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Mon, 27 Feb 1995 15:39:21 PST." <9502272339.AA02389@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 22:55:29 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > From: "Perry E. Metzger" > > > No, it wouldn't. ShowMe will send video regardless of whether > > > the remote node is up or down. There will be no inactivity, and so > > > the inactivity timer will never go off. > > > > The inactivity timer is at the RECEIVER, not at the SOURCE. Security > > associations are different in each direction. > > But the session key that needs to be blown away is at the source. > > The receiver has no state left of that association when it reboots, > so how will inactivity timeouts on the receiver help? It will help if the source goes away. If the receiver goes away, the source will get an ICMP message the next time it tries to send on an invalid SAID and the SAID will go away. (I'm contemplating a handshaking design to make denial of service attacks hard to mount by sending random ICMPs.) You have inactivity timers on both sides, by the way -- I was just addressing the ShowMe example. Perry From ipsec-request@ans.net Tue Feb 28 20:21:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14207 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 15:36:10 -0500 Received: by interlock.ans.net id AA09625 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 15:21:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 28 Feb 1995 15:21:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 15:21:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 15:21:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 15:21:23 -0500 From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9502282021.AA04573@monster.incog.com> Subject: Re: (IPng) Proposed Standard or no? To: perry@imsi.com Date: Tue, 28 Feb 1995 12:21:20 -0800 (PST) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: <9502280344.AA08316@snark.imsi.com> from "Perry E. Metzger" at Feb 27, 95 10:44:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text > > If you want to have the implementation of the bit be optional, that > implies that SKIP is being proposed as an optional protocol. Does that > imply that you guys are withdrawing from consideration as a SKIP as a > proposed internet standard? > > Perry Obviously not. What I am saying (and have been saying) is that key management needs to be independent from IPSP. If the Structured SAID bit is not in IPSP, you are eliminating possible key management schemes. But you still haven't answered my original question. How does the structured SAID bit create muck in the kernel? If you are using a key management scheme that uses it, great. If you are not, you can ignore it. --tom From ipsec-request@ans.net Tue Feb 28 22:18:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16010 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 17:34:20 -0500 Received: by interlock.ans.net id AA05544 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 17:23:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 28 Feb 1995 17:23:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 17:23:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 17:23:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 17:23:22 -0500 Message-Id: <9502282218.AA09757@snark.imsi.com> To: markson@osmosys.incog.com (Tom Markson) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 1995 12:21:20 PST." <9502282021.AA04573@monster.incog.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 28 Feb 1995 17:18:54 -0500 From: "Perry E. Metzger" Tom Markson says: > But you still haven't answered my original question. How does the > structured SAID bit create muck in the kernel? You have to detect it and switch on it. Given that you guys are claiming that several schemes could use it, we presumably start having to keep kernel tables of what the various structured SAIDs mean so we can process them, and we start needing either kernel level key management or upcalls of some sort to user code to handle them. > If you are using a key management scheme that uses it, great. If > you are not, you can ignore it. You can't ignore it. If the machine owner can say "gee, I'd like to use SKIP" then the kernel has to have the hooks, doesn't it? .pm From ipsec-request@ans.net Tue Feb 28 21:33:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13036 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 18:23:33 -0500 Received: by interlock.ans.net id AA15477 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 18:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 18:11:42 -0500 Date: Tue, 28 Feb 95 21:33:26 GMT From: "William Allen Simpson" Message-Id: <4061.bsimpson@morningstar.com> To: ipsec@ans.net Subject: the silly bit > From: markson@osmosys.incog.com (Tom Markson) > Obviously not. What I am saying (and have been saying) is that key > management needs to be independent from IPSP. If the Structured SAID > bit is not in IPSP, you are eliminating possible key management schemes. > Because key management must be independent of IPSP, it is up to you to show the independence. That is, any scheme you propose cannot require other key management proposals to understand any part of your proposal. A reserved bit is not "independent". It requires understanding by other management schemes. What is to prevent a 3rd .. 20th contender to need a bit of their own? I have suggested that you could write up a new transform draft showing how your key management proposal would use the common header in a new way. A reserved SAID number could be assigned for your proposal. 254 of them are available. (#0 means no key, and #1 is for RSA.) Instead, you have chosen to argue endlessly. Finally, we have eliminated _many_ possible key management schemes: - All key management schemes where the SAID is assigned by the Source are eliminated. Only Destination assigned SAIDs are used. This is a requirement for multicast. - All key management schemes which do not provide perfect forward secrecy are eliminated. - All key management schemes which are vulnerable to denial of service attack are eliminated. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Feb 28 23:26:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17567 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 18:39:08 -0500 Received: by interlock.ans.net id AA33405 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 18:28:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 28 Feb 1995 18:28:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 18:28:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 18:28:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 18:28:56 -0500 Date: Tue, 28 Feb 1995 15:26:18 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9502282326.AA02831@miraj.> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? X-Sun-Charset: US-ASCII > From: "Perry E. Metzger" > You can't ignore it. If the machine owner can say "gee, I'd like to > use SKIP" then the kernel has to have the hooks, doesn't it? No, it doesn't. If the machine owner wants to use the DEC scheme, and the protocol supports it (e.g. like IEEE 802.10b), this doesn't mean we all have to have a socket on our machines to plug in the DEC chip. In any case, I think this one's been beaten to death by now. Regards, Ashar.