From ipsec-request@ans.net Tue Jan 3 20:07:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35793 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 15:25:05 -0500 Received: by interlock.ans.net id AA08493 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 15:14:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 15:14:25 -0500 Message-Id: <199501032014.AA32553@interlock.ans.net> To: Carl Muckenhirn Cc: ipsec@ans.net Subject: Re: Size of IV field in DES-CBC mode In-Reply-To: Your message of Mon, 19 Dec 94 07:21:58 -0500. <9412191222.AA21960@columbia.sparta.com> Date: Tue, 03 Jan 95 15:07:47 -0500 From: Steve Kent Carl & Phil, If I remember correctly, FIPS 81 calls for an 8-byte IV for CBC mode. One might have compliant implementations of DES that do not allow the user to generate the IV and which require a full 8-byte IV. So, I'd recommend against trying to save 4 bytes. Steve From ipsec-request@ans.net Tue Jan 3 20:24:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31203 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 15:29:28 -0500 Received: by interlock.ans.net id AA08675 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 15:25:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 3 Jan 1995 15:25:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 15:25:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 15:25:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 15:25:45 -0500 Date: Tue, 3 Jan 1995 12:24:02 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501032024.AA09857@miraj.> To: amir@watson.ibm.com Subject: Re: Proposal: Perfect forward secrecy (on SKIP) Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > > As I have already confirmed offline with Hugo, this is the same > > proposal that I made at the San Jose IETF, (and which I also > > mentioned verbally at the Toronto IETF). So, is this the proposal > > that you are advocating for perfect forward secrecy? If so, > > we are at least coming closer to an agreement. > > Almost. However I think we can do better by authenticating the ephemeral DH > using the keys from the _previous_instance_ of the ephemeral DH. One can > either use just the previous shared ephemeral key or use the public > exponents from previous time by computing > > shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1} > > Therefore in each round we authenticate the DH keys for next round. > the result is that breaking req' breaking into both processors together > and then an active attack (rather than just message injection as is possible > in SKIP). I am happy to observe that we appear to be moving closer to agreement on at least the basic appearance of the protocol. This is good, because if the rest of WG members also agree, we can then talk about how other desirable goals such as anonymity etc. can be preserved with this approach. Now for comments on some of the details. In general, I like the notion of using key components from the last round to authenticate the next round. (If you read my paper on wireless network security, Feb 93, IEEE Personal Communications, essentially the same principle is used to authenticate the key-change protocol). However, if you would like to use the last round's key components to authenticate the next round, I suggest a better way might be to simply include the last round's ephemeral public DH values in the authenticated/encrypted SKIP message that is used to communicate the current round's ephemeral DH components. This serves to authenticate the messages (and thereby the key), as opposed to simply authenticating the key. i.e A->B (A, B, g^x_i, g^x_{i-1}, g^y_{i-1})Kab, where A knows x_i B->A (B, A, g^y_i, g^y_{i-1}, g^x_{i_1})Kab, where B knows y_i where Kab is the implicit SKIP master key. new key = g^{x_i*y_i} This has the following advantages. - If you happen to lose state and hence knowledge of the last round's public component, this doesn't affect coming up with the correct key. You can simply ignore the check on the last round's public components and still come up with the correct key. With your suggestion, if one side doesn't have the last round's public/secret components, it simply can't come up with the correct key for the current round, in the absence of a resynchronization protocol. - With your suggestion, for every round each node has to perform 3 exponentiations. This is as follows, 1) g^x_i, (because the other side needs the public value of this round) 2) g^y_{i-1}^x_i and 3) g^{y_i}^x_{i-1}. This adds 2 extra exponentiations to the basic protocol, both of which can be eliminated by my suggestion above. One of the advantages of the SKIP approach is that it cuts down on the number of exponentiations as compared to approaches that authenticate the DH exchange using RSA signatures. We should try and preserve this advantage. - With your suggestion each side has to maintain the *secrets* of the last round until the next round (in order to compute g^{y_i}^x_{i-1}). This runs contrary to the goals of perfect forward secrecy. In cases where there are medium to long-term gaps in communication (e.g a week or a month) the ephemeral *secrets* from the last round have to be maintained in long term memory somewhere, thereby increasing their vulnerability. With my suggestion, only the ephemeral *public* values from the last round need to be maintained, not the ephemeral secrets. This is in accordance with the goals of perfect forward secrecy, which requires that ephemeral secrets should be destroyed as soon as possible. - Message playback attacks are discovered directly by examining the messages. One doesn't have to compute an incorrect key, and then discover that keys are mismatched through a failure to communicate. - For the first round (i=0), null values can be subsituted for the last round's (-1) public components. Since the last round's components serve to protect against replays, leaving them as null for the first round is not a problem, because there are no valid messages to be played back when i= 0. Let me know if there were advantages you perceived using the approach in your suggestion, that are lost with my suggestion above. And also if these advantages outweigh the advantages that I listed above. > So my proposal is to have a protocol completely based on DH with a > non-interactive and interactive modes (we can later decide if one of them > is only optional). This protocol would have protection against clogging > (even from unknown addresses and even non-interactive), anonymity if we > desire (I'll explain how to do it non-interactively later - or ask Hugo), > and proactive security at least in the interactive modes. I agree completely. The only comment I would like to add is that we dont need to state the protocol in terms of DH. I made the mistake of specifying SKIP in terms of DH alone. This caused some WG members to (rightfully) raise the concern whether the protocol was being tied to a particular crypto algorithm. In fact, the entire protocol as we have discussed it so far is generalizable completely to any Public Key Agreement (PKA) algorithm. I'll observe that the distinction between a public key agreement algorithm and a public key cryptosystem (i.e with the trapdoor property) has existed since the inception of public key cryptography. Just to recall, The PKA function in this context is as follows, shared_secret_ab = pka(public_a, secret_b) = pka(public_b, secret_a) where pka() stands for the Public Key Agreement function. Note that this is no longer tied to any crypto algorithm. Any cryptographic construction that satisfies this property and the other obvious properties of not deducing either the individual or shared secrets through knowledge of public values (the public key property) and not being able to discover another shared secret, even if arbitrarily many shared secrets are known (collusion attack resistance) will work in this protocol. All we are saying is that we will use certified and ephemeral pka public secret values. The DH function satisfies this property, but so can other functions e.g elliptic curve based, or those that use composite moduli as opposed to prime moduli. There may also be other (as yet undiscovered) cryptographic constructions that satisfy the PKA property. Just to summarize the principal benefits of this approach. - A single Public Key Infrastructure (that of the PKA type) serves to allow both zero message session-less and session-oriented key-management with perfect forward secrecy. - The perfect forward secrecy protocols based on this approach are computationally more efficient than protocols that use signatures to authenticate the DH exchange. - Key Management messages are themselves encrypted. This means there is no need to require bypass channels for the key-management traffic. This is important, because real attacks in the field happen on systems that embody protocols, and not just on the theoretical protocols themselves. To the extent that we can plug up real systems against such attacks, we enhance security. - Encrypting the key-management traffic enhances security in other ways as well. One of the reasons Burmester's triangle attack works against the Yacobi, Goss, Gunther and other schemes is that the key-management traffic can be observed. Encrypting the key-management traffic completely foils this attack. (There are also other ways that our current construction foils this attack, but I dont want to go too deep on this one for now). That's it for this message. Looking forward to a cooperative and productive '95! Happy new year folks. Regards, Ashar. From ipsec-request@ans.net Tue Jan 3 21:26:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19698 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 16:32:26 -0500 Received: by interlock.ans.net id AA11887 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 16:26:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 3 Jan 1995 16:26:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 3 Jan 1995 16:26:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 16:26:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 16:26:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 16:26:26 -0500 Message-Id: <9501032126.AA26563@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Proposal: Perfect forward SECURITY In-Reply-To: Your message of "Tue, 03 Jan 1995 12:24:02 PST." <9501032024.AA09857@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Jan 1995 16:26:02 -0500 From: " " Ashar and all, > > Almost. However I think we can do better by authenticating the ephemeral DH > > using the keys from the _previous_instance_ of the ephemeral DH. One can > > either use just the previous shared ephemeral key or use the public > > exponents from previous time by computing > > > > shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1} > > > > Therefore in each round we authenticate the DH keys for next round. > > the result is that breaking req' breaking into both processors together > > and then an active attack (rather than just message injection as is possible > > in SKIP). > > I am happy to observe that we appear to be moving closer to agreement > on at least the basic appearance of the protocol. This is good, > because if the rest of WG members also agree, we can then talk > about how other desirable goals such as anonymity etc. can > be preserved with this approach. Yes. But, we should really talk about the goals at least as much as we do about how to achieve them... I propose that we want perfect forward security, not just secrecy, which means that a successful attack requires ALL of the following: 1. Breaking into BOTH parties at the same period $[T',T]$. 2. Active attack on the communication between the parties continuously after $T$. If the attacker loses either, the attack is defeated (at least detected). I think this is a very good goal security wise and not too expensive computation-wise. Do you agree it's a good goal (if not too expensive)? > > Now for comments on some of the details. > > In general, I like the notion of using key components from the last > round to authenticate the next round. (If you read my paper on wireless > network security, Feb 93, IEEE Personal Communications, essentially the > same principle is used to authenticate the key-change protocol). Please note the difference too! > > However, if you would like to use the last round's key components > to authenticate the next round, I suggest a better way might be > to simply include the last round's ephemeral public DH values in the > authenticated/encrypted SKIP message that is used to communicate the > current round's ephemeral DH components. This serves to authenticate the > messages (and thereby the key), as opposed to simply authenticating the > key. No, this is not as secure. I don't want to base the security on any long-lived secret key. Your proposal above requires that the SKIP keys would be secure `forever'. I'm saying, let's not make a distinction between ephemeral DH keys and long-lived, SKIPish DH keys. The DH keys we use may change periodically, period :-) Thereby, we achieve the stronger security property which I called above `perfect forward SECURITY'. Authenticating the messages, in addition to the key, is a simple addition to the protocol so I've omitted it (essentially you merge the protocol with a challenge-response mechanism such as 2PP). I agree that this cost three exponentiations which is painful... But considering this is a periodical procedure (and the frequency is tunable) I think this is not so terrible. What do you say? Happy new year to all, and I join Ashar in hoping for a cooperative -and hence productive - year for IPSEC. Best, Amir p.s. Yes, we can also achieve anonymity for this, and even for non-interactive SKIP so together this would be a nice protocol - I'll write about it soon... From ipsec-request@ans.net Tue Jan 3 21:47:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30375 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 17:01:51 -0500 Received: by interlock.ans.net id AA22527 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 16:47:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 3 Jan 1995 16:47:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 3 Jan 1995 16:47:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 16:47:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 16:47:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 16:47:20 -0500 Message-Id: <9501032147.AA25636@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Problem+fix in Zero Message Master Key update In-Reply-To: Your message of "Tue, 03 Jan 1995 12:24:02 PST." <9501032024.AA09857@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Jan 1995 16:47:14 -0500 From: " " Ashar and other ZKIP-interested IPSECers, A small comment on Ashar's proposal in the foils presented in the last IETF on master key update. Ashar proposed to use Kijn=g^n*i*j, where n=1,2,3,.... A problem with this is that Kijn may sometimes be deduced from Kijl, where l); Tue, 3 Jan 1995 17:26:35 -0500 Received: by interlock.ans.net id AA07262 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 17:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 3 Jan 1995 17:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 17:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 17:21:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 17:21:30 -0500 Date: Tue, 3 Jan 1995 14:19:53 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501032219.AA09900@miraj.> To: ashar@osmosys.incog.com, amir@watson.ibm.com Subject: Re: Proposal: Perfect forward SECURITY Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Amir, It seems that I didn't properly understand your suggestion. I thought you wanted to use SKIP to do an authenticated DH key-exchange, and then use the last round's components to come up with the current round's key. It seems that this is not what you want. So, now I need to understand your suggestion better than I do. How do you propose to authenticate the DH key-exchange a) to begin with and b) for each round thereafter. What kind of certified keys exist, if any? Rather than having me speculate what on what you intend, perhaps if you spell out the details, then we can have a more productive discussion on both the goals and means of achieving those goals. This would be in terms of certified keys, as well as message exchanges. Thanks, Ashar. From ipsec-request@ans.net Tue Jan 3 22:30:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13233 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 17:38:05 -0500 Received: by interlock.ans.net id AA38919 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 17:32:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 3 Jan 1995 17:32:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 17:32:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 17:32:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 17:32:19 -0500 Date: Tue, 3 Jan 1995 14:30:40 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501032230.AA09903@miraj.> To: ashar@osmosys.incog.com, amir@watson.ibm.com Subject: Re: Problem+fix in Zero Message Master Key update Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From amir@watson.ibm.com Tue Jan 3 13:47 PST 1995 > A problem with this is that Kijn may sometimes be deduced from Kijl, where > l It is simple to solve this (also more efficiently) by > > Kijn=h(g^ij,n) I dont have any serious objections to using a one-way hash function like MD5 as specified above. However, the same thing applies. Knowledge of g^ij, reveals all Kijn. It's principal advantage is that this is more efficient Ashar. From ipsec-request@ans.net Tue Jan 3 18:07:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30340 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 18:07:23 -0500 Received: by interlock.ans.net id AA17207 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 17:59:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 17:59:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 17:59:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 17:59:58 -0500 Date: Tue, 03 Jan 95 14:29:44 From: "Housley, Russ" Encoding: 1864 Text Message-Id: <9500037891.AA789172184@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: End to End integrity Perry: Before Christmas, you said: I'll point out something that we didn't discuss in sufficient detail in San Jose. For very good reasons (so that you can have guarantees about the integrity of the addresses) Ran's spec for v6 includes a pseudoheader consisting of the invariant parts of the header of the IP datagram in his authentication header. I strongly feel we should be specifying something similar. This is doubly important in the multicast case where a third party could simply re-label the origin of the packet without any knowledge at all of the contents or key and still have it check out just fine if the origin and destination addresses are changed. In a multicast environment, soure address is important, but destination address is not very important. The multicast SAID indicates that the datagram is protected for the group, but offers no information about the originator. If the datagram decrypts and integrity checks correctly, then the recipient can be confident that the datagram was sent by one of the multicast group members. Inclusion of the source address in the protected portion of the datagram will allow limitd authentication. It ensures that no one outside the multicast group could have modified a previous transmission by one of the multicast group members; however, it does not prohibit one of the multicast group members from playing the same trick since multicast group members have access to the appropriate keys. The IEEE 802.10b Secure Data Exchange (SDE) protocol allows the originator to include a source address in the protected header for the reasons that you cite. The standard also explains the concern that I express above, and we should do the same if we add a protected source address to our format. Russ From ipsec-request@ans.net Tue Jan 3 18:12:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35485 (5.65c/IDA-1.4.4 for ); Tue, 3 Jan 1995 18:12:49 -0500 Received: by interlock.ans.net id AA37861 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 3 Jan 1995 18:07:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 3 Jan 1995 18:07:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 3 Jan 1995 18:07:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 3 Jan 1995 18:07:30 -0500 Date: Tue, 03 Jan 95 14:29:52 From: "Housley, Russ" Encoding: 852 Text Message-Id: <9500037891.AA789172192@spysouth.spyrus.com> To: dee@skidrow.tay.dec.com, Carl Muckenhirn Cc: ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: Size of IV field in DES-CBC mode Carl Muckenhim said: I think that's a wonderful idea (always padding with source address). Using the bottom 4 bytes of an IPv6 address may also work, though there may be some IV-space clashes since they are not guaranteed to be different per-host as IPv4 addrs are. Alternatively use the Senders SAID (we might even be able to reduce the amount of bit shuffling if we put the SAID directly before the IV (with no intervening bits). In some hardware implementations, it is difficult to use IVs that are not generated by the hardware. While many (maybe even most) implementation of IPSP will use software, I would hate to prohibit hardware. For this reason, I would rather use random IVs and carry the source address in a protected header when data origin authentication requires an address. Russ From ipsec-request@ans.net Wed Jan 4 16:01:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35367 (5.65c/IDA-1.4.4 for ); Wed, 4 Jan 1995 11:12:28 -0500 Received: by interlock.ans.net id AA12777 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 4 Jan 1995 11:01:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 4 Jan 1995 11:01:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 4 Jan 1995 11:01:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 4 Jan 1995 11:01:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 4 Jan 1995 11:01:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Jan 1995 11:01:45 -0500 Message-Id: <9501041601.AA27468@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Problem+fix in Zero Message Master Key update In-Reply-To: Your message of "Tue, 03 Jan 1995 14:30:40 PST." <9501032230.AA09903@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Jan 1995 11:01:34 -0500 From: " " Ashar says: > > The intent of this proposal was to prevent playback of traffic > keys (Kp), under the assumption that traffic keys could be broken > but not master keys. But, what the proposal really did was to introduce another layer of keys. You'll have g^ij as the `long lived master key' and Kijn as the `medium lived master keys' (in addition to the short lived Kp). Therefore I thought the goal is to protect Kijn from exposure of Kijl where l > It is simple to solve this (also more efficiently) by > > > > Kijn=h(g^ij,n) > > I dont have any serious objections to using a one-way hash function > like MD5 as specified above. However, the same thing applies. Knowledge > of g^ij, reveals all Kijn. It's principal advantage is that this is > more efficient So, also more secure. Best, Amir From ipsec-request@ans.net Wed Jan 4 15:03:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06556 (5.65c/IDA-1.4.4 for ); Wed, 4 Jan 1995 15:03:52 -0500 Received: by interlock.ans.net id AA13351 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 4 Jan 1995 14:52:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 4 Jan 1995 14:52:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 4 Jan 1995 14:52:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Jan 1995 14:52:16 -0500 Date: Wed, 04 Jan 95 11:22:56 From: "Housley, Russ" Encoding: 359 Text Message-Id: <9500047892.AA789247376@spysouth.spyrus.com> To: ashar@osmosys.incog.com (Ashar Aziz), " " Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Problem+fix in Zero Message Master Key update Amir said: ... It is simple to solve this (also more efficiently) by Kijn=h(g^ij,n) where h is our favorite one way hash (i.e. MD5...) This is essentially the X9.42 variant of Diffie-Hellman. The biggest difference is that they include an identifier to name the hash function in the data that is hashed. Russ From ipsec-request@ans.net Wed Jan 4 21:39:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19579 (5.65c/IDA-1.4.4 for ); Wed, 4 Jan 1995 17:01:59 -0500 Received: by interlock.ans.net id AA28070 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 4 Jan 1995 16:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 4 Jan 1995 16:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 4 Jan 1995 16:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 4 Jan 1995 16:41:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Jan 1995 16:41:28 -0500 Date: Wed, 4 Jan 1995 13:39:48 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501042139.AA10360@miraj.> To: ashar@osmosys.incog.com, amir@watson.ibm.com Subject: Re: Problem+fix in Zero Message Master Key update Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Jan 4 09:07 PST 1995 > Therefore I thought the goal is to protect Kijn from exposure of Kijl where > l way, to protect against reuse of Kp. For this purpose, it is enough to > Have e.g. Kijn=MD5(Kij(n-1)) (formally, have Kijn the n^th output of > pseudo-random generator). There were also other variants of the g^nij exponentiation scheme, which I haven't yet described, which were intended to allow zero-message perfect forward secrecy. The reason I haven't described this approach is that it's not very practical, becuse it only works for closed groups of nodes. (It also was intended to eliminate long term keys, as you alluded to, but I didn't find a way to make such a scheme practical). Wrt to the repeated hashing i.e Kijn = h(Kij(n-1)), one of the advantages of the g^nij (and also the h(g^ij, n)) scheme is that it is easy to go to level n of the key (i.e giant stepping). By repeated hashing, one has to pay a greater computational cost for higher values of n, if one starts from the 0th level. > I think there is some added security in having Kijn=MD5(g^ij, n), (formally, > a pseudo-random function with key g^ij on operand n), since then Kijn is > secure as long as the long-lived, rarely used g^ij is not exposed. One of the disadvantages of MD5 is that you are limited to 128 bits. (Three key triple DES uses more than 128 bits). g^nij always gives 1024 bits, when using 1024 bit moduli. In theory this could be alleviated by using hash functions with larger block sizes (e.g SHA). Regards, Ashar. From ipsec-request@ans.net Wed Jan 4 22:48:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16692 (5.65c/IDA-1.4.4 for ); Wed, 4 Jan 1995 18:00:06 -0500 Received: by interlock.ans.net id AA09325 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 4 Jan 1995 17:50:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 4 Jan 1995 17:50:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 4 Jan 1995 17:50:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 4 Jan 1995 17:50:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Jan 1995 17:50:28 -0500 Date: Wed, 4 Jan 1995 14:48:42 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501042248.AA10380@miraj.> To: amir@watson.ibm.com Subject: Re: Clogging attacks on SKIP Cc: ipsec@ans.net, ashar@osmosys.incog.com X-Sun-Charset: US-ASCII Sorry, I missed this message in the pile of messages. > > The *worst* that can happen is that, only in case of wildcard > > ACLs, *unusual* access patterns *may* be denied service during > > a clogging attack. > > This is what I was refering to. It appears a very reasonable case for a > firewall which allows access to employees of large organization esp. if > they are allowed to use DHCP. DHCP doesn't contribute to non-uniform key patterns, since the premise of SKIP is that there are long-term certified keys. Whatever is used to bind the node public keys to node's is what will be used to precompute keys. If this is a DNS name, and EID etc., then that is fine. The point is that the certified information is not dynamic, and that is the basis of precompute caching. > > This isn't all that bad, especially since > > someone who desperately seeks service and is being denied, > > can be asked to put on the priority list and regain access, > > even if the clogging attack continues. (Note that administrators > > would always be on the priority list, and would always be > > able to take such action in a secure manner, even remotely). > > Of course such manual solutions would help (but even that should be noted > in the spec!). I'll be happy to mention this in the next revision of the spec. To be fair to my spec, I didn't a see detailed discussion of prevention of denial of service attacks in your spec either. The Photuris proposal deserves the credit for highlighting this issue. > My belief is that we can achieve almost all properties very similarly in the > interactive and non-interactive cases and therefore we can have one tunable > design which satisfies all of the goals in the exisiting proposals (inc non] > interactivity as in SKIP although I still think this should be an option since > it is less secure - see other note) We have agreed to defer the discussion of what should be optional and what should be default so I wont get into this. However, I'll note that the less or more secure should always be looked at in terms of a tradeoff. For example, 1000 bits moduli is less secure than 8000 bit moduli, but 1000 bits will probably be used for the following two reasons. a) 8000 bits is not necessary for many (or most) applications and b) we cant afford the overhead of a 8000 bit computation in many (or most) circumstances. This is the same principle we use for many other decisions, namely a) can we afford it?, and b) is it necessary? The "more secure is always better" is too simplistic an approach for deciding on the right tradeoffs in a key-management system. Rather we have to apply the two basic principles that are used by all of us in deciding which car, house, computer etc to acquire. Namely, can we afford it, and is it necessary. Only after evaluating this cost/benefit tradeoffs in terms of of some ordered list of requirements can we come to the right decisions. This requires some work, because different environments and applications have different requirements. > (I am still waiting for your response > > on this issue and the other issue on saving sender resources.) > > I"m not sure what this is, but I'll be away for a while (and was too busy > recently)... I was referring to your comment that with connection oriented key-management, the sender saves resources by not sending IP packets, in case the key doesn't get established. I pointed out that this doesn't work for IP, because IP doesn't contain a flow-control or disconnect protocol. Ashar. From ipsec-request@ans.net Wed Jan 4 22:58:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13219 (5.65c/IDA-1.4.4 for ); Wed, 4 Jan 1995 18:08:21 -0500 Received: by interlock.ans.net id AA10196 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 4 Jan 1995 17:59:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 4 Jan 1995 17:59:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 4 Jan 1995 17:59:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 4 Jan 1995 17:59:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 4 Jan 1995 17:59:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Jan 1995 17:59:01 -0500 Message-Id: <9501042258.AA19799@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: amir@watson.ibm.com, ipsec@ans.net Subject: Re: Problem+fix in Zero Message Master Key update In-Reply-To: Your message of "Wed, 04 Jan 1995 13:39:48 PST." <9501042139.AA10360@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Jan 1995 17:58:52 -0500 From: " " Hi Ashar and all, > > I think there is some added security in having Kijn=MD5(g^ij, n), (formally, > > a pseudo-random function with key g^ij on operand n), since then Kijn is > > secure as long as the long-lived, rarely used g^ij is not exposed. > > One of the disadvantages of MD5 is that you are limited to 128 bits. > (Three key triple DES uses more than 128 bits). g^nij always gives 1024 > bits, when using 1024 bit moduli. In theory this could be alleviated by > using hash functions with larger block sizes (e.g SHA). This is easy to resolve, by having Kijn=K'ijn1 || ... || K'ijnl (where l is selected to give you enough bits) and let K'ijnq=MD5(n, q, g^ij) While this may seem complicated at first sight, this is in reality both simple and very efficient. Give a second look. As usual, MD5 above is just a reasonable example and could be substituted by your favorite pseudo-random function (with key g^ij), e.g. SHA. (BTW, if using MD5, one should use the order above rather than as I originally wrote) Is there any disadvantage to this? Best, Amir From ipsec-request@ans.net Thu Jan 5 11:20:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37843 (5.65c/IDA-1.4.4 for ); Thu, 5 Jan 1995 06:31:19 -0500 Received: by interlock.ans.net id AA13952 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 5 Jan 1995 06:18:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 5 Jan 1995 06:18:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Jan 1995 06:18:09 -0500 Date: Thu, 5 Jan 1995 03:20:12 -0800 From: Phil Karn Message-Id: <199501051120.DAA08766@unix.ka9q.ampr.org> To: amir@watson.ibm.com Cc: ashar@osmosys.incog.com, Ashar.Aziz@eng.sun.com, ipsec@ans.net In-Reply-To: <9412232114.AA19105@gimili.watson.ibm.com> (amir@watson.ibm.com) Subject: Re: Clogging attacks on SKIP >Let me mention that if one really wants to, we _can_ give a complete solution >to clogging in the non-interactive (SKIP) framework. Namely, require each >request to be accompanied by > MD5(IPaddresses, time, counter, x) >where cnt is the counter of number of tries within the same `time' (which is >roughly synchronized), and x is any number such that the last $l$ bits of the >MD5 are zero. Amir, As I said when you described this to me in my office on your visit, this *is* a really neat trick. But I see a problem. We ideally want our KM protocol to be useable on a very wide range of CPUs, from palmtops up through Crays. Most mobile clients (where security is most important) are going to land near the bottom of this range, especially when you consider that MD5 is highly optimized for 32-bit machines and doesn't run nearly as fast on a 16-bit 8088 class palmtop. I.e., a hell of a lot slower than on the 486s and Sparc-class workstations that a typical attacker would probably use. So picking a value of $l$ that's sufficiently painful for the swamper may also prove to be too painful for the low end legitimate user. Phil From ipsec-request@ans.net Thu Jan 5 14:37:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17834 (5.65c/IDA-1.4.4 for ); Thu, 5 Jan 1995 09:47:35 -0500 Received: by interlock.ans.net id AA43359 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 5 Jan 1995 09:37:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 5 Jan 1995 09:37:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 5 Jan 1995 09:37:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 5 Jan 1995 09:37:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 5 Jan 1995 09:37:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Jan 1995 09:37:14 -0500 Message-Id: <9501051437.AA20271@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: Phil Karn Cc: amir@watson.ibm.com, ashar@osmosys.incog.com, Ashar.Aziz@eng.sun.com, ipsec@ans.net Subject: Re: Clogging attacks on SKIP In-Reply-To: Your message of "Thu, 05 Jan 1995 03:20:12 PST." <199501051120.DAA08766@unix.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Jan 1995 09:37:06 -0500 From: " " Phil, Ashar, others, I agree with Phil, the solution below is expensive. But it is one (and so far the only) possibility to provide (optional) anti-clogging protection even for the non-interactive case. The price is not so terrible as it seems, however, since the non-malicious user has to do this only once per establishment of a shared key, while the attacker has to do this many times in order to clog the system. Of course an alternative is that when attacked, a host would only allow connection set-ups from a pre-defined set, as Ashar have suggested. But this locks out ad-hoc connections. Best, Amir > >Let me mention that if one really wants to, we _can_ give a complete solution > >to clogging in the non-interactive (SKIP) framework. Namely, require each > >request to be accompanied by > > MD5(IPaddresses, time, counter, x) > >where cnt is the counter of number of tries within the same `time' (which is > >roughly synchronized), and x is any number such that the last $l$ bits of the > >MD5 are zero. > > Amir, > > As I said when you described this to me in my office on your visit, > this *is* a really neat trick. > > But I see a problem. We ideally want our KM protocol to be useable on > a very wide range of CPUs, from palmtops up through Crays. Most > mobile clients (where security is most important) are going to land > near the bottom of this range, especially when you consider that MD5 > is highly optimized for 32-bit machines and doesn't run nearly as fast > on a 16-bit 8088 class palmtop. I.e., a hell of a lot slower than on > the 486s and Sparc-class workstations that a typical attacker would > probably use. So picking a value of $l$ that's sufficiently painful > for the swamper may also prove to be too painful for the low end > legitimate user. > > Phil > From ipsec-request@ans.net Thu Jan 5 16:16:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19785 (5.65c/IDA-1.4.4 for ); Thu, 5 Jan 1995 11:20:57 -0500 Received: by interlock.ans.net id AA05395 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 5 Jan 1995 11:16:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 5 Jan 1995 11:16:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 5 Jan 1995 11:16:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 5 Jan 1995 11:16:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 5 Jan 1995 11:16:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Jan 1995 11:16:08 -0500 From: uri@watson.ibm.com Message-Id: <9501051616.AA19227@buoy.watson.ibm.com> Subject: Re: Clogging attacks on SKIP To: karn@unix.ka9q.ampr.org (Phil Karn) Date: Thu, 5 Jan 1995 11:16:03 -0500 (EST) Cc: amir@watson.ibm.com, ashar@osmosys.incog.com, Ashar.Aziz@eng.sun.com, ipsec@ans.net In-Reply-To: <199501051120.DAA08766@unix.ka9q.ampr.org> from "Phil Karn" at Jan 5, 95 03:20:12 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1153 Phil Karn says: > > MD5(IPaddresses, time, counter, x) > As I said when you described this to me in my office on your visit, > this *is* a really neat trick. > But I see a problem. We ideally want our KM protocol to be useable on > a very wide range of CPUs, from palmtops up through Crays......... > ...................especially when you consider that MD5 > is highly optimized for 32-bit machines and doesn't run nearly as fast > on a 16-bit 8088 class palmtop. Phil, you're perfecgly correct, but shouldn't we draw a line somewhere? Like there might be Z80 CPUs, but we don't really expect users to run the stuff on those... And there are Crays around, but we don't really plan everybody to upgrade to Crays in the near future? 8088 chips are nice, but aren't thy going away real fast? There are two ways, as far as I see. One is to use MD5, and if somebody insists on running the code on 8088 - tough. The other is - to define a choice of hash-functions, so users of the "challenged" CPUs will be able to select the one suitable for them (negotiable parameter). -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Thu Jan 5 19:59:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38627 (5.65c/IDA-1.4.4 for ); Thu, 5 Jan 1995 15:09:24 -0500 Received: by interlock.ans.net id AA35690 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 5 Jan 1995 14:56:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 5 Jan 1995 14:56:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Jan 1995 14:56:38 -0500 Date: Thu, 5 Jan 1995 11:59:38 -0800 From: Phil Karn Message-Id: <199501051959.LAA09088@unix.ka9q.ampr.org> To: uri@watson.ibm.com Cc: amir@watson.ibm.com, ashar@osmosys.incog.com, Ashar.Aziz@eng.sun.com, ipsec@ans.net In-Reply-To: <9501051616.AA19227@buoy.watson.ibm.com> (uri@watson.ibm.com) Subject: Re: Clogging attacks on SKIP >Phil, you're perfecgly correct, but shouldn't we draw a line somewhere? >Like there might be Z80 CPUs, but we don't really expect users to run I don't want to rule anything out if I don't have to. At IETF I see quite a few people walking around with HP100s, some of which are connected to RAM radio modems. They're prime candidates for IPSP. I believe the HP100 is comparable to the original IBM PC. I.e., almost hopelessly underpowered by today's standards. Phil From ipsec-request@ans.net Fri Jan 6 13:52:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30303 (5.65c/IDA-1.4.4 for ); Fri, 6 Jan 1995 18:56:45 -0500 Received: by interlock.ans.net id AA06393 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 6 Jan 1995 18:52:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 6 Jan 1995 18:52:28 -0500 Message-Id: <199501062352.AA36341@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 6 Jan 1995 18:52:28 -0500 Date: Fri, 6 Jan 95 18:52:24 EST From: hugo@watson.ibm.com To: karn@unix.ka9q.ampr.org Cc: IPSEC@ans.net Subject: weak devices Ref: Your note of Thu, 5 Jan 1995 11:59:38 -0800 (attached) > > >Phil, you're perfecgly correct, but shouldn't we draw a line somewhere? > >Like there might be Z80 CPUs, but we don't really expect users to run > > I don't want to rule anything out if I don't have to. At IETF I see > quite a few people walking around with HP100s, some of which are > connected to RAM radio modems. They're prime candidates for IPSP. I > believe the HP100 is comparable to the original IBM PC. I.e., almost > hopelessly underpowered by today's standards. > > Phil Phil, how well are these devices equipped to do modular exponentiations as required for the mechanisms we discuss? How long it will take to perform a single exponentiation? Hugo From ipsec-request@ans.net Fri Jan 6 13:51:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29540 (5.65c/IDA-1.4.4 for ); Fri, 6 Jan 1995 18:56:46 -0500 Received: by interlock.ans.net id AA08434 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 6 Jan 1995 18:51:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 6 Jan 1995 18:51:34 -0500 Message-Id: <199501062351.AA36334@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 6 Jan 1995 18:51:34 -0500 Date: Fri, 6 Jan 95 18:51:29 EST From: hugo@watson.ibm.com To: ashar@osmosys.incog.com Cc: ipsec@ans.net, amir@watson.ibm.com Subject: Clogging attacks Ref: Your note of Wed, 4 Jan 1995 14:48:42 -0800 (attached) From ashar@osmosys.incog.com to amir@watson.ibm.com > > To be fair to my spec, I didn't a see detailed discussion of prevention > of denial of service attacks in your spec either. The Photuris proposal > deserves the credit for highlighting this issue. > Ashar, Jim Hughes' initial proposal for key management (around 5/94) already mentioned and dealt with the issue of clogging attacks and denial of service. Our spec, MKMP, (to which you refer above), *does* talk about defenses against clogging attacks. In our proposal this defense was achieved in a very satisfactory way: just by taking advantage of the cheap signature verification in RSA, an attacked host only pays with two multiplications to test the validity of the incoming message. Moreover, there are *no additional* operations or flows that the (honest) parties need to pay in order to stand eventual clogging attacks. The other solutions we have discussed in this list (Photuris's and the one described by Amir) both have extra cost also for honest parties. Hugo From ipsec-request@ans.net Sat Jan 7 01:16:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04137 (5.65c/IDA-1.4.4 for ); Fri, 6 Jan 1995 20:21:28 -0500 Received: by interlock.ans.net id AA22210 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 6 Jan 1995 20:18:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 6 Jan 1995 20:18:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 6 Jan 1995 20:18:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 6 Jan 1995 20:18:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 6 Jan 1995 20:18:28 -0500 Date: Fri, 6 Jan 1995 17:16:50 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501070116.AA01674@miraj.> To: ashar@osmosys.incog.com, hugo@watson.ibm.com Subject: Re: Clogging attacks Cc: ipsec@ans.net, amir@watson.ibm.com X-Sun-Charset: US-ASCII > From hugo@watson.ibm.com Fri Jan 6 15:19 PST 1995 >> Jim Hughes' initial proposal for key management (around 5/94) already > mentioned and dealt with the issue of clogging attacks and denial of service. > > Our spec, MKMP, (to which you refer above), *does* talk about defenses > against clogging attacks. > In our proposal this defense was achieved in a very satisfactory way: > just by taking advantage of the cheap signature verification in RSA, > an attacked host only pays with two multiplications to test the validity > of the incoming message. Moreover, there are *no additional* operations or > flows that the (honest) parties need to pay in order to stand > eventual clogging attacks. > The other solutions we have discussed in this list (Photuris's and the one > described by Amir) both have extra cost also for honest parties. Whereas I sympathize with the goal of not paying additional operations or flows for honest parties, I think there are many who believe that RSA signature verification *is* susceptible to clogging attacks (much more so than hash function tests). This isn't all that important, really. Specs aren't perfect even when they go to standards status, and certainly not when they come out in -00.txt form. The whole point of the open review process is to find deficiencies in the proposals so they can be improved in future revisions. We need to get on with the task of identifying the correct solutions and not get stuck on whether first issue drafts were perfect. I thank you (and others) who have pointed out issues that need to be addressed in my draft. Regards, Ashar. From ipsec-request@ans.net Sat Jan 7 19:34:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12730 (5.65c/IDA-1.4.4 for ); Sat, 7 Jan 1995 19:34:50 -0500 Received: by interlock.ans.net id AA15194 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 7 Jan 1995 19:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 7 Jan 1995 19:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 7 Jan 1995 19:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 7 Jan 1995 19:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 7 Jan 1995 19:30:25 -0500 Date: Sat, 7 Jan 1995 16:28:42 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501080028.AA02095@miraj.> To: amir@watson.ibm.com Subject: Re: Proposal: Perfect forward SECURITY Cc: ipsec@ans.net, ashar@osmosys.incog.com X-Sun-Charset: US-ASCII From: " " > > However, if you would like to use the last round's key components > > to authenticate the next round, I suggest a better way might be > > to simply include the last round's ephemeral public DH values in the > > authenticated/encrypted SKIP message that is used to communicate the > > current round's ephemeral DH components. This serves to authenticate the > > messages (and thereby the key), as opposed to simply authenticating the > > key. > > No, this is not as secure. I don't want to base the security on any long-lived > secret key. Your proposal above requires that the SKIP keys would be secure > `forever'. I'm saying, let's not make a distinction between ephemeral DH > keys and long-lived, SKIPish DH keys. The DH keys we use may change > periodically, period :-) Thereby, we achieve the stronger security property > which I called above `perfect forward SECURITY'. While I await clarification on Amir's suggestion, I think a clarification on this response would probably be useful. While the security of the scheme does indeed rest on the secrecy of the long term DH secrets, in the sense that authentication failure will result by compromise of these long term keys, perfect forward secrecy is achieved by the protocol I suggested. That is, compromise of the long-term keys does not compromise past session (or master) keys, because the long term keys are only used to authenticate the ephemeral key exchange. I don't think Amir implied that perfect forward secrecy was not achieved, but I thought a clarification of this point may be useful for those not following this thread in great depth. I'll also observe that any scheme that uses long term keying material to authenticate key exchanges (and all the proposals that are fully spelled out and currently on the table fall in this category) would have the same failure mode. Regards, Ashar. From ipsec-request@ans.net Sun Jan 8 23:22:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14749 (5.65c/IDA-1.4.4 for ); Sun, 8 Jan 1995 18:24:31 -0500 Received: by interlock.ans.net id AA22708 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 8 Jan 1995 18:19:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 8 Jan 1995 18:19:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 8 Jan 1995 18:19:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 8 Jan 1995 18:19:39 -0500 Message-Id: <9501082322.AA00283@dun-dun-noodles.cam.ov.com> To: hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: weak devices In-Reply-To: hugo@watson.ibm.com's message of 7 Jan 1995 00:15:10 -0000 Date: Sun, 08 Jan 1995 18:22:08 -0500 From: Marc Horowitz >> Phil, how well are these devices equipped to do modular exponentiations >> as required for the mechanisms we discuss? How long it will take to >> perform a single exponentiation? I've got an hp100lx. if someone sends me some benchmarking code, I'll be happy to run it and post the results. I've also got PGP on it, so if you want me to do some tests with that, I can. Marc From ipsec-request@ans.net Mon Jan 9 17:06:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38727 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 13:38:29 -0500 Received: by interlock.ans.net id AA34667 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 13:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 13:22:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 13:22:40 -0500 Date: Mon, 9 Jan 95 17:06:25 GMT From: "William Allen Simpson" Message-Id: <3649.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Clogging attacks on SKIP > From: uri@watson.ibm.com > Phil, you're perfecgly correct, but shouldn't we draw a line somewhere? > Like there might be Z80 CPUs, but we don't really expect users to run > the stuff on those... And there are Crays around, but we don't really > plan everybody to upgrade to Crays in the near future? 8088 chips are > nice, but aren't thy going away real fast? > I expect to run the code on Z80 equivalents. One of my current contracts involves 186s. Expect tens of millions. The 386 just isn't available for embedded ASICs yet. > There are two ways, as far as I see. One is to use MD5, and if somebody > insists on running the code on 8088 - tough. The other is - to define a > choice of hash-functions, so users of the "challenged" CPUs will be > able to select the one suitable for them (negotiable parameter). > That makes interoperability very difficult. And involves an extra pair of messages to exchange the parameter, which was the whole point of the earlier message (eliminating the cookie exchange). So, there is no improvement. Let's just stick to the cheap Foturis exchange, thanks anyway. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Jan 9 19:08:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18574 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 14:14:41 -0500 Received: by interlock.ans.net id AA32548 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 14:08:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 9 Jan 1995 14:08:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 9 Jan 1995 14:08:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 9 Jan 1995 14:08:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 14:08:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 14:08:15 -0500 Message-Id: <9501091908.AA21573@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: Clogging attacks on SKIP In-Reply-To: Your message of "Mon, 09 Jan 1995 17:06:25 GMT." <3649.bill.simpson@um.cc.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Jan 1995 14:08:00 -0500 From: " " > > There are two ways, as far as I see. One is to use MD5, and if somebody > > insists on running the code on 8088 - tough. The other is - to define a > > choice of hash-functions, so users of the "challenged" CPUs will be > > able to select the one suitable for them (negotiable parameter). > > > That makes interoperability very difficult. And involves an extra pair > of messages to exchange the parameter, which was the whole point of the > earlier message (eliminating the cookie exchange). I agree, Exchanging another message doesn't make any sense. The whole idea is to enable a non-interactive version. > > So, there is no improvement. Let's just stick to the cheap Foturis > exchange, thanks anyway. But that requires interaction... In order to allow us to converge, I like to support the anti-clogging defense for non-interactive too. The solution is wasteful and a problem for weak devices, but it is the only one I know. One can use it only as a `last resort'. Let's just keep in mind that anti-clogging does not completely prevent a non-interactive solution. This should help to agree that anti-clogging and non-interactive options are both required (and not conflicting). Best, Amir From ipsec-request@ans.net Mon Jan 9 10:28:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34031 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 15:36:50 -0500 Received: by interlock.ans.net id AA37317 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 15:28:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 15:28:28 -0500 Message-Id: <199501092028.AA38081@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 15:28:28 -0500 Date: Mon, 9 Jan 95 15:28:23 EST From: hugo@watson.ibm.com To: ashar@osmosys.incog.com, IPSEC@ans.net Subject: Perfect forward SECURITY (uni- vs bi-directional impersonation)' Ref: Your note of Sat, 7 Jan 1995 16:28:42 -0800 (attached) An important issue about requirements: > > I'll also observe that any scheme that uses long term keying material > to authenticate key exchanges (and all the proposals that are fully > spelled out and currently on the table fall in this category) would > have the same failure mode. > > Regards, > Ashar. Ashar means that if we rely on the private key of a machine A to authenticate A's key exchanges with B (for example A signs, using its own private key, its value g^x in a DH exchange) then an adversary E that learns A's private key will be able to impersonate A in the key exchanges between A and B (and any other party). RIGHT! BUT... Is impersonation in the other direction possible? That is: Will the adversary E be able to impersonate B when exchanging a key with A (by just knowing A's private key but not B's private key)? Two answers: 1) In the case of DH authenticated with RSA (or any other digital) signature the answer is: NO! (When B sends g^y he authenticates it with B's private key). 2) In the case of DH authenticated with the SKIP master key a^ij the answer is: YES! No doubt that the first case has a (significant) advantage over the second. For example, if A's private key was exposed it does not mean that I want the adversary E to be able to impersonate myself to A. By doing that E could have A giving her information that A is supposed to release ONLY if I authenticated myself to A. (Notice that the knowledge of A's private key does not mean necessarily that the adversary has access to all information kept by A). Whether this is just an advantage or a requirement can be discussed. However, the cost of achieving this property is moderate enough to require it any way. Indeed number (1) above achieves that. Moreover, even using only SKIP keys there is a moderate-cost solution; actually a very elegant one that Amir proposed in a few notes ago. It uses a variant on Diffie-Hellman that requires only SKIP-like keys but ensure a-symmetric authentication in the sense of the above requirement. The price is only a semi-off-line exponentiation (comparable to the cost of an RSA signature). I'll let Amir further explain the technique. Hugo PS: there is another issue related to the damage of exposing a private key related to "chaining techniques" for key exchange. This is also the matter for a separate note. From ipsec-request@ans.net Mon Jan 9 20:57:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18676 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 16:01:30 -0500 Received: by interlock.ans.net id AA39783 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 15:55:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 9 Jan 1995 15:55:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 15:55:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 15:55:26 -0500 Message-Id: <9501092057.AA00914@dun-dun-noodles.cam.ov.com> To: hughes@hughes.network.com (James P Hughes) Cc: ipsec@ans.net Subject: Re: weak devices In-Reply-To: Your message of "Mon, 09 Jan 1995 12:06:46 CST." <9501091812.AA25409@hughes.network.com> Date: Mon, 09 Jan 1995 15:57:49 -0500 From: Marc Horowitz >> How long does it take to encapsulate a typical email message? That should >> be the average key establishment time. Ok, here's my non-scientific benchmarks, generated on my hp100lx, using pgp 2.6 with a 512 bit modulus on a 1k file. All times were taken manually with my wristwatch stopwatch, so assume +/- 10% sampling error or so. key generation (pgp -kg) takes 305 seconds. signing the file (pgp -s) takes 15 seconds. verifying the signature takes 3 seconds. encrypting the file (pgp -e) takes 5 seconds. decrypting the ciphertext takes 15 seconds. These times do not include the time to load the program, just my perception of how long it took to perform the operation, probably including disk (flash rom) I/O. I don't have any way to figure out how long a keyed MD5 would take, since PGP doesn't do this. Marc From ipsec-request@ans.net Mon Jan 9 13:02:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18479 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 18:10:26 -0500 Received: by interlock.ans.net id AA20181 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 18:02:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 18:02:28 -0500 Message-Id: <199501092302.AA32206@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 18:02:28 -0500 Date: Mon, 9 Jan 95 18:02:21 EST From: hugo@watson.ibm.com To: marc@cam.ov.com, IPSEC@ans.net Subject: weak devices Ref: Your note of Mon, 09 Jan 1995 15:57:49 -0500 (attached) > > Ok, here's my non-scientific benchmarks, generated on my hp100lx, > using pgp 2.6 with a 512 bit modulus on a 1k file. All times were > taken manually with my wristwatch stopwatch, so assume +/- 10% > sampling error or so. > > signing the file (pgp -s) takes 15 seconds. > verifying the signature takes 3 seconds. Thanks, Marc. These are not very encouraging times. Especially if they use Chinese reminder theorem in the RSA computation (PGP does RSA signatures) which means that a single DH exponentiation would take even more than 15 seconds. Hugo From ipsec-request@ans.net Mon Jan 9 22:34:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14396 (5.65c/IDA-1.4.4 for ); Mon, 9 Jan 1995 18:49:23 -0500 Received: by interlock.ans.net id AA14885 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 Jan 1995 18:43:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 9 Jan 1995 18:43:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 9 Jan 1995 18:43:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 9 Jan 1995 18:43:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 Jan 1995 18:43:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 Jan 1995 18:43:04 -0500 From: uri@watson.ibm.com Message-Id: <9501092234.AA22651@buoy.watson.ibm.com> Subject: Re: Clogging attacks on SKIP To: bsimpson@morningstar.com Date: Mon, 9 Jan 1995 17:34:09 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <3649.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jan 9, 95 05:06:25 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: 662 William Allen Simpson says: > I expect to run the code on Z80 equivalents. > One of my current contracts involves 186s. Expect tens of millions. > The 386 just isn't available for embedded ASICs yet. Well, repeating Hugo's question: OK, MD5 is slow on these oldies. How about RSA? How about DH? If you're concerned about MD5, what performance do you expect from exponentiation? > So, there is no improvement. Let's just stick to the cheap Foturis > exchange, thanks anyway. I'm not sure even Foturis is cheap enough for these. [Next you'll want IPSP to run on your player :-] -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Tue Jan 10 11:02:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14712 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 06:04:26 -0500 Received: by interlock.ans.net id AA08074 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 05:57:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 05:57:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 05:57:34 -0500 Date: Tue, 10 Jan 1995 03:02:09 -0800 From: Phil Karn Message-Id: <199501101102.DAA15057@unix.ka9q.ampr.org> To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199501062357.PAA05830@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: weak devices >Phil, how well are these devices equipped to do modular exponentiations >as required for the mechanisms we discuss? How long it will take to >perform a single exponentiation? Not very well, I'm afraid. But if you want the ultimate in security, you want to use a trusted machine even if it's slower than something else. Phil From ipsec-request@ans.net Wed Jan 11 00:18:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20631 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 19:24:50 -0500 Received: by interlock.ans.net id AA02846 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 19:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 10 Jan 1995 19:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 10 Jan 1995 19:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 10 Jan 1995 19:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 19:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 19:19:05 -0500 From: uri@watson.ibm.com Message-Id: <9501110018.AA22337@buoy.watson.ibm.com> Subject: Re: weak devices To: karn@unix.ka9q.ampr.org (Phil Karn) Date: Tue, 10 Jan 1995 19:18:58 -0500 (EST) Cc: hugo@watson.ibm.com, IPSEC@ans.net In-Reply-To: <199501101102.DAA15057@unix.ka9q.ampr.org> from "Phil Karn" at Jan 10, 95 03:02:09 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 Phil Karn says: > >Phil, how well are these devices equipped to do modular exponentiations > >as required for the mechanisms we discuss? > > Not very well, I'm afraid. But if you want the ultimate in security, > you want to use a trusted machine even if it's slower than something > else. OK, then why were we discussing how fast or slow MD5 is on those trusted but underpowered machines? -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Tue Jan 10 15:01:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14488 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 20:06:47 -0500 Received: by interlock.ans.net id AA16852 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 20:02:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 10 Jan 1995 20:02:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 10 Jan 1995 20:02:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 10 Jan 1995 20:02:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 20:02:08 -0500 Date: Tue, 10 Jan 95 20:01:48 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9501110101.AA27780@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 20:02:08 -0500 To: ipsec@ans.net Subject: MD5 performance limitations document Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission On the subject of MD5, has everyone read the draft on the problem with speeding up MD5 on high end machines? Its called draft-touch-md5-performance-00.txt. I'm suprised that no one here has commented on it yet. Perry From ipsec-request@ans.net Tue Jan 10 21:49:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38571 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 21:49:16 -0500 Received: by interlock.ans.net id AA31076 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 21:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 21:46:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 21:46:03 -0500 From: Masataka Ohta Return-Path: Message-Id: <9501110245.AA08633@necom830.cc.titech.ac.jp> Subject: Re: MD5 performance limitations document To: perry@imsi.com Date: Wed, 11 Jan 95 11:44:54 JST Cc: ipsec@ans.net In-Reply-To: <9501110101.AA27780@webster.imsi.com>; from "Perry E. Metzger" at Jan 10, 95 8:01 pm X-Mailer: ELM [version 2.3 PL11] > > On the subject of MD5, has everyone read the draft on the problem with > speeding up MD5 on high end machines? > > Its called draft-touch-md5-performance-00.txt. > > I'm suprised that no one here has commented on it yet. > > Perry The draft is fataly wrong to not to distinguish the off-chip and on-chip clock speed. Performance issues is in DES, not in MD5. Masataka Ohta From ipsec-request@ans.net Wed Jan 11 03:30:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16356 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 22:36:01 -0500 Received: by interlock.ans.net id AA35113 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 22:32:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 10 Jan 1995 22:32:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 10 Jan 1995 22:32:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 22:32:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 22:32:42 -0500 Date: Tue, 10 Jan 1995 19:30:53 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501110330.AA00675@miraj.> To: hugo@watson.ibm.com Subject: Re: Perfect forward SECURITY (uni- vs bi-directional impersonation)' Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From hugo@watson.ibm.com Mon Jan 9 12:33 PST 1995 > From: hugo@watson.ibm.com > Is impersonation in the other direction possible? That is: > Will the adversary E be able to impersonate B when exchanging a key with A > (by just knowing A's private key but not B's private key)? Two answers: > > 1) In the case of DH authenticated with RSA (or any other digital) signature > the answer is: NO! (When B sends g^y he authenticates it with B's private > key). > 2) In the case of DH authenticated with the SKIP master key a^ij the answer is: > YES! > > No doubt that the first case has a (significant) advantage over the second. > For example, if A's private key was exposed it does not mean that I > want the adversary E to be able to impersonate myself to A. By doing that > E could have A giving her information that A is supposed to release ONLY > if I authenticated myself to A. > (Notice that the knowledge of A's private key does not mean necessarily > that the adversary has access to all information kept by A). I disagree. In virtually any circumstance that IPSP is likely to be used in, E having A's long term authentication key will mean that to the network E *is* A, and therefore E can access any information that A can access. I cannot imagine an IPSP scenario (through any combination of operating system or security policy) where there is information that is under the legitimate control of A, that A will not provide to A (i.e to itself) but A will provide this information to B. The point is, rather than impersonating as B to break into A's resources, it will almost always suffice to become A to do the same thing (something that is clearly possible in case of compromise of A's signature key). Whereas I am having difficulty understanding a legitimate security concern based on the scenario you have outlined, I don't have any difficulty imagining the very real possibility that wily hackers will use the strategy of bypassing the system's security apparatus in order to break in. In attempting to do this, they will almost certainly try (sometimes with success) to subvert a channel that is invitingly named a "bypass" channel, something that you have just re-introduced using the signature approach. To summarize: a) your concern doesn't reflect a real security concern likely to be encountered in the context of IPSP b) it has additional computational overhead by introducing two signatures in the protocol (a significant overhead for underpowered devices as we have seen in the numbers even for the marginally secure 512 bit RSA operations) and c) to the extent it makes real attacks more likely to succeed it diminishes security (while adding overhead). Regards, Ashar. From ipsec-request@ans.net Tue Jan 10 17:55:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19527 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 22:59:08 -0500 Received: by interlock.ans.net id AA31208 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 22:55:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 10 Jan 1995 22:55:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 22:55:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 22:55:12 -0500 Date: Tue, 10 Jan 1995 22:55:01 +0500 From: Theodore Ts'o Message-Id: <9501110355.AA07865@dcl.MIT.EDU> To: Masataka Ohta Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: Masataka Ohta's message of Wed, 11 Jan 95 11:44:54 JST, <9501110245.AA08633@necom830.cc.titech.ac.jp> Subject: Re: MD5 performance limitations document Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1139 From: Masataka Ohta Date: Wed, 11 Jan 95 11:44:54 JST The draft is fataly wrong to not to distinguish the off-chip and on-chip clock speed. Performance issues is in DES, not in MD5. Well, the draft makes the assertion that if you're interested in speeds of 300-600 megabits per second, the maximum theoretical speed of MD5, even assuming that you used a specialized hardward chip implementation, wasn't going to cut it. That appeared to be the main thrust of the draft. It is certainly true that if you are using encryption and integrity protection, the speed of your encryption algorithm may very well swamp your MD5 calculations. However, if you're only doing keyed MD5 for integrity protection, you may very well run into the limits which this paper points out. Disclaimer: I've only looked at this paper in cursury fashion, and I am *not* enough of a hardware expert to evaluate the claims which they've made regarding how fast you could make an on-chip MD5 implementation. However, I don't think that we could say at this point that the draft is "fatally wrong". - Ted From ipsec-request@ans.net Tue Jan 10 17:56:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18533 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 23:00:41 -0500 Received: by interlock.ans.net id AA19208 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 22:58:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 10 Jan 1995 22:58:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 22:58:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 22:58:18 -0500 Date: Tue, 10 Jan 1995 22:56:56 +0500 From: Theodore Ts'o Message-Id: <9501110356.AA07868@dcl.MIT.EDU> To: uri@watson.ibm.com Cc: karn@unix.ka9q.ampr.org, hugo@watson.ibm.com, IPSEC@ans.net In-Reply-To: uri@watson.ibm.com's message of Tue, 10 Jan 1995 19:18:58 -0500 (EST), <9501110018.AA22337@buoy.watson.ibm.com> Subject: Re: weak devices Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 638 From: uri@watson.ibm.com Date: Tue, 10 Jan 1995 19:18:58 -0500 (EST) Phil Karn says: > >Phil, how well are these devices equipped to do modular exponentiations > >as required for the mechanisms we discuss? > > Not very well, I'm afraid. But if you want the ultimate in security, > you want to use a trusted machine even if it's slower than something > else. OK, then why were we discussing how fast or slow MD5 is on those trusted but underpowered machines? Because you only have to do the mdoular exponentiations once (or relatively rarely), so you can afford to wait for it to complete? - Ted From ipsec-request@ans.net Tue Jan 10 18:35:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06495 (5.65c/IDA-1.4.4 for ); Tue, 10 Jan 1995 23:42:27 -0500 Received: by interlock.ans.net id AA36245 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 10 Jan 1995 23:38:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 10 Jan 1995 23:38:43 -0500 Message-Id: <199501110438.AA36240@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 10 Jan 1995 23:38:43 -0500 To: Theodore Ts'o Cc: Masataka Ohta , perry@imsi.com, ipsec@ans.net Subject: Re: MD5 performance limitations document Date: Tue, 10 Jan 95 23:35:56 EST It is certainly true that if you are using encryption and integrity protection, the speed of your encryption algorithm may very well swamp your MD5 calculations. However, if you're only doing keyed MD5 for integrity protection, you may very well run into the limits which this paper points out. The ironic thing is that gigabit/second DES chips have actually been built -- meaning, if the analysis is correct, that encryption is faster than MD5... Someone should look for possible pipelines or space-time tradeoffs in MD5, much as has been done for DES. From ipsec-request@ans.net Wed Jan 11 05:27:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13228 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 05:27:45 -0500 Received: by interlock.ans.net id AA07111 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 05:18:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 05:18:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 05:18:16 -0500 From: Masataka Ohta Return-Path: Message-Id: <9501111016.AA10224@necom830.cc.titech.ac.jp> Subject: Re: MD5 performance limitations document To: smb@research.att.com Date: Wed, 11 Jan 95 19:16:17 JST Cc: tytso@MIT.EDU, perry@imsi.com, ipsec@ans.net In-Reply-To: <9501110438.AA09086@necom830.cc.titech.ac.jp>; from "smb@research.att.com" at Jan 10, 95 11:35 pm X-Mailer: ELM [version 2.3 PL11] > It is certainly true that if you are using encryption and integrity > protection, the speed of your encryption algorithm may very well swamp > your MD5 calculations. However, if you're only doing keyed MD5 for > integrity protection, you may very well run into the limits which this > paper points out. Don't mind. The draft reports 100Mbps with DEC Alpha, which is CMOS, which already exceed the THEORETICAL CMOS limit of 70Mbps. > The ironic thing is that gigabit/second DES chips have actually been > built -- meaning, if the analysis is correct, that encryption is faster > than MD5... While pipelined DES can be as fast as you want, CBC-DES can't be. CBC-DES needs feed back and can't be pipelined so efficiently. 16 way interleaving might be necessary. > Someone should look for possible pipelines or space-time tradeoffs in > MD5, much as has been done for DES. If MD5 or DES has any short cuts for computation, it's not secure. Masataka Ohta From ipsec-request@ans.net Wed Jan 11 11:48:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31096 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 08:33:11 -0500 Received: by interlock.ans.net id AA26064 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 08:29:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 08:29:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 08:29:27 -0500 Date: Wed, 11 Jan 95 11:48:58 GMT From: "William Allen Simpson" Message-Id: <3676.bill.simpson@um.cc.umich.edu> To: IPSEC@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: weak devices > From: uri@watson.ibm.com > Phil Karn says: > > >Phil, how well are these devices equipped to do modular exponentiations > > >as required for the mechanisms we discuss? > > > > Not very well, I'm afraid. But if you want the ultimate in security, > > you want to use a trusted machine even if it's slower than something > > else. > > OK, then why were we discussing how fast or slow MD5 is on those > trusted but underpowered machines? > Because the modular exponentiation is done only once every few hours or days. The MD5 (as opposed to Photuris cookies) is to prevent clogging attacks many times a second. You can't prevent clogging attacks with an algorithm that clogs the machine! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Jan 11 15:01:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18457 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 10:07:46 -0500 Received: by interlock.ans.net id AA21708 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 10:03:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 11 Jan 1995 10:03:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 10:03:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 10:03:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 10:03:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 10:03:51 -0500 Message-Id: <9501111501.AA32352@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: hugo@watson.ibm.com, ipsec@ans.net Subject: Re: Perfect forward SECURITY (uni- vs bi-directional impersonation)' In-Reply-To: Your message of "Tue, 10 Jan 1995 19:30:53 PST." <9501110330.AA00675@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 10:01:59 -0500 From: " " Ashar says: > I disagree. In virtually any circumstance that IPSP is likely to be > used in, E having A's long term authentication key will mean that > to the network E *is* A, and therefore E can access any information > that A can access. But E cannot impersonate as B!! For example, if A is a file server, E cannot continue reading/modifying B's files!! If E has A's keys it would be able to impersonate A, by definition. What we want is to prevent any FURTHER demage, e.g. to B. (There are more interesting applications where the impersonation of B could prevent from recovery of security after the break-in into A.) Of course, the fact that neither my fix nor the signatures as Hugo explained apply to non-interactive SKIP is not terrible. But, when this feature is easy to obtain, why not. Best, Amir From ipsec-request@ans.net Wed Jan 11 15:11:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20553 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 10:14:30 -0500 Received: by interlock.ans.net id AA14684 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 10:11:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 11 Jan 1995 10:11:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 10:11:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 10:11:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 10:11:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 10:11:46 -0500 Message-Id: <9501111511.AA23480@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: hugo@watson.ibm.com, ipsec@ans.net Subject: Re: Perfect forward SECURITY (bypass channel?) In-Reply-To: Your message of "Tue, 10 Jan 1995 19:30:53 PST." <9501110330.AA00675@miraj.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 10:11:38 -0500 From: " " Ashar, > ... I don't have any > difficulty imagining the very real possibility that wily hackers > will use the strategy of bypassing the system's security apparatus > in order to break in. In attempting to do this, they will almost > certainly try (sometimes with success) to subvert a channel that is > invitingly named a "bypass" channel, something that you have just > re-introduced using the signature approach. Could you explain this attack? Do you claim that both Photuris and Jim's proposal (and our PK protocol in MKMP) have such a weakness? Thanks, Amir From ipsec-request@ans.net Wed Jan 11 16:18:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19613 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 11:26:06 -0500 Received: by interlock.ans.net id AA10135 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 11:19:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 11:19:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 11:19:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 11:19:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 11:19:19 -0500 Message-Id: <9501111618.AA27526@snark.imsi.com> To: "Theodore Ts'o" Cc: ipsec@ans.net Subject: Re: MD5 performance limitations document In-Reply-To: Your message of "Tue, 10 Jan 1995 22:55:01 +0500." <9501110355.AA07865@dcl.MIT.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 11 Jan 1995 11:18:42 -0500 From: "Perry E. Metzger" "Theodore Ts'o" says: > From: Masataka Ohta > Date: Wed, 11 Jan 95 11:44:54 JST > > The draft is fataly wrong to not to distinguish the off-chip and > on-chip clock speed. > > Performance issues is in DES, not in MD5. > > Well, the draft makes the assertion that if you're interested in speeds > of 300-600 megabits per second, the maximum theoretical speed of MD5, > even assuming that you used a specialized hardward chip implementation, > wasn't going to cut it. That appeared to be the main thrust of the > draft. > > It is certainly true that if you are using encryption and integrity > protection, the speed of your encryption algorithm may very well swamp > your MD5 calculations. No, actually. He makes a very subtle point. I can arbitrarily speed up, say, DES, with parallelism. A defect in the design of MD5 keeps me from being able to do that. I know of DES chips that do over a gigabit per second in hardware. The claim here is that MD5 will melt your processor and still not give you that performance. I'm not yet sure that there isn't a trick he might not have missed, though, as I haven't examined the problem very hard. However, I would STRONGLY suggest that people look at this. Perry From ipsec-request@ans.net Wed Jan 11 18:50:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12679 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 13:55:58 -0500 Received: by interlock.ans.net id AA36322 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 13:50:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 13:50:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 13:50:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 13:50:54 -0500 Date: Wed, 11 Jan 1995 11:50:43 -0700 From: Hilarie Orman Message-Id: <199501111850.LAA20722@umbra.CS.Arizona.EDU> To: mohta@necom830.cc.titech.ac.jp Cc: ipsec@ans.net In-Reply-To: Yourmessage <9501111016.AA10224@necom830.cc.titech.ac.jp> Subject: Re: MD5 performance limitations document > Don't mind. The draft reports 100Mbps with DEC Alpha, which is CMOS, > which already exceed the THEORETICAL CMOS limit of 70Mbps. The 100Mbps number is probably bogus, but 70Mbps for aligned, ordered data is what I've measured on a 175 MHz Alpha. The standard implementation is about 35Mbps. > > Someone should look for possible pipelines or space-time tradeoffs in > > MD5, much as has been done for DES. > If MD5 or DES has any short cuts for computation, it's not secure. That's only a known theorem in the same sense that it's not as secure if the machines compute faster. MD5 doesn't seem to have many opportunities for optimization, having been designed to be highly sequential. But I'd be glad to hear of any improvements. For 64-bit machines there are opportunities to speed things up, but changing the algorithm might be a more fruitful path. From ipsec-request@ans.net Wed Jan 11 19:53:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38154 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 15:00:24 -0500 Received: by interlock.ans.net id AA40932 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 14:55:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 14:55:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 14:55:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 14:55:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 14:55:39 -0500 Date: Wed, 11 Jan 1995 11:53:56 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501111953.AA01023@miraj.> To: amir@watson.ibm.com Subject: Re: (bypass channel?) Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Jan 11 08:15 PST 1995 > > ... I don't have any > > difficulty imagining the very real possibility that wily hackers > > will use the strategy of bypassing the system's security apparatus > > in order to break in. In attempting to do this, they will almost > > certainly try (sometimes with success) to subvert a channel that is > > invitingly named a "bypass" channel, something that you have just > > re-introduced using the signature approach. > > Could you explain this attack? Certainly. Preventing attacks on bypass channels fall in the category of secure *system* design, as opposed to secure protocol design. To the extent that the security protocol enables or disables certain aspects of secure system design, then we as security designers need to be very concious of this, and should do everything we can to *enable* secure system design, as long as the costs are reasonable. Let's consider, as an example, the well understood notion of maintaining secret keys in hardware. Whereas, in theory, a secure operating system can prevent user data (and thereby secret keys) from falling into the wrong hands, we in the security community tend to prefer the simpler tamper resist hardware approach. The premise is this: a simple unavoidable hardware mechanism that does not depend on the security features of an operating system is preferable to performing exhaustive verifications of a complex object like an operating system. Anyone who has seen the security related bug lists of any major operating system can relate to this concept. Most modern operating systems are exceedingly complex (typically million lines plus) and ensuring there are no code paths that lead to security failures is a very difficult task. Let me give you an example of operating system failures from very recent memory. A prominent manufacturer of Internet firewall equipment (who shall remain unnamed) has a failure mode which in certain circumstances causes the firewall to go completely in the open, while administrative interfaces show the firewall to be implementing the security policies put into effect. It is not surprising that even a security device like a firewall can have unexpected code paths leading to failures like the one I mentioned above, because of the complexity of this problem. (This issue happens to be related to the way the operating system interacts with their software). Now, consider for a moment a rather attractive notion. A cryptographic processor sitting unavoidably in the hardware data path between the network and the system, that verifies the integrity of *every* packet that passes through it (which happens to be *every* packet that arrives at that node). This processor can refuse to pass packets that fail the integrity check, which is a cryptographic operation (and can also do normal audit operations like incrementing counters etc, if so configured). Disabling this crypto processor requires physically removing the chip, and potentially replacing this with a pass-through chip, if so desired. Now, this is entirely analagous to the notion of maintaining secret keys in hardware. A simple unavoidable hardware mechanism that ultra secure machines, which talk only to principals (nodes, users, etc.) that they are able to authenticate, can use. Back to protocols. Any protocol that *requires* unauthenticated clear text traffic for purposes of key-management (and yes, all non-SKIP public key approaches that I am aware of fall in this category) *precludes* such a system design. Other approaches then have to rely on the security of the operating system (ensuring which as I have said above is difficult) to ensure that bypass traffic required for key-management purposes can not be misdirected into the system, potentially to the advantage of the intruder. To summarize: the computational cost of this approach is actually less than the computational cost of comparable public key approaches. At the same time it enables a class of secure system designs that rely on the well understood principles of isolating security concerns into simpler (e.g. hardware) mechanisms. And the class of attacks this helps prevent, active break-ins into networks or systems, is probably of the highest concern to people responsible for Internet security. Hope this helps, Ashar. From ipsec-request@ans.net Wed Jan 11 20:47:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18460 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 15:55:47 -0500 Received: by interlock.ans.net id AA37205 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 15:49:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 15:49:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 15:49:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 15:49:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 15:49:18 -0500 Date: Wed, 11 Jan 1995 12:47:26 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501112047.AA01047@miraj.> To: amir@watson.ibm.com Subject: Re; (bypass channels)? Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Sorry for not properly making the distinction between unencrypted and unauthenticated traffic. All other public key proposals require unencrypted key-management traffic. SKIP has no key-management traffic so it naturally doesn't require unencrypted key-management traffic. (And if session oriented key-management traffic is layered on SKIP, it too can be encrypted). Wrt hardware tests on every packet into the system, then conceivably this can be signature based tests as well, and so key-management schemes that only exchange authenticated messages would probably be okay (although they risk exposing identification information etc. because this would be in the clear). The advantage of a SKIP like scheme is that every packet is encrypted so e.g user indentification information (and public keys etc.) are never revealed. So I take back my assertion that all non-SKIP key-management schemes require unauthenticated traffic (although some of the proposals on the table, e.g those that do a DH exchange first and then authenticate do). Ashar. From ipsec-request@ans.net Wed Jan 11 23:38:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35340 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 18:43:05 -0500 Received: by interlock.ans.net id AA21230 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 18:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 11 Jan 1995 18:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 18:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 18:39:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 18:39:51 -0500 Date: Wed, 11 Jan 1995 15:38:03 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501112338.AA01100@miraj.> To: amir@watson.ibm.com Subject: Re: Perfect forward SECURITY (uni- vs bi-directional impersonation)' Cc: hugo@watson.ibm.com, ipsec@ans.net X-Sun-Charset: US-ASCII > From amir@watson.ibm.com Wed Jan 11 07:38 PST 1995 > > I disagree. In virtually any circumstance that IPSP is likely to be > > used in, E having A's long term authentication key will mean that > > to the network E *is* A, and therefore E can access any information > > that A can access. > > But E cannot impersonate as B!! For example, if A is a file server, E cannot > continue reading/modifying B's files!! But... B's files are on A. And it is A's keys that have been compromised. In my view, if the file-server's (A's) keys have been compromised then the security of any data on that file server is pretty suspect. Two example scenarios. One, connect to A as A, and then since B's files are on A, and presumably A can do anything with them (since they reside on A), B's files still get compromised. Second. Assume A performs periodic archival backups to another online server (say C). That is, all of A's data is also on C. (Not an uncommon mode of operation). Obviously, since it is A's data, (which also contains B's files) then A can access that data on C. Therefore B's files still get compromised by compromise of A's signature keys. The point I am making is that there are so many failure scenarios that can occur in case of compromise of a principal's authentication key, especially to data that *belongs* to that principal, that the distinction between uni and bi-directional authentication doesn't seem worthwhile. > Of course, the fact that neither my fix nor the signatures as Hugo explained > apply to non-interactive SKIP is not terrible. But, when this feature is easy > to obtain, why not. I dont think this is terrible either. However, I dont consider adding two real-time signatures to the protocol as a small additional overhead. This adds potentially on the order of minutes to the key setup times on underpowered platforms, particularly if we use secure (1024 bit) RSA keys. And the gain in security is marginal, at best. Regards, Ashar. From ipsec-request@ans.net Thu Jan 12 01:33:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21206 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 20:37:13 -0500 Received: by interlock.ans.net id AA22212 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 11 Jan 1995 20:33:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 11 Jan 1995 20:33:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 20:33:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 20:33:35 -0500 Date: Wed, 11 Jan 1995 18:33:26 -0700 From: Hilarie Orman Message-Id: <199501120133.SAA04733@umbra.CS.Arizona.EDU> To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: Yourmessage <199501092302.AA32206@interlock.ans.net> Subject: Re: weak devices > which means that a single DH exponentiation would take even more than > 15 seconds. One can use elliptic curves and a F[2^n] field (where n = 155, e.g.) to cut down the time by at least a factor of 3. This is the method described some years ago by Neil Koblitz (and not the one patented by NeXT). From ipsec-request@ans.net Thu Jan 12 17:36:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12968 (5.65c/IDA-1.4.4 for ); Thu, 12 Jan 1995 12:45:34 -0500 Received: by interlock.ans.net id AA20273 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 12 Jan 1995 12:36:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 12 Jan 1995 12:36:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 12 Jan 1995 12:36:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 12 Jan 1995 12:36:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 12 Jan 1995 12:36:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 12 Jan 1995 12:36:50 -0500 Message-Id: <9501121736.AA29755@gimili.watson.ibm.com> X-Mailer: exmh version 1.5.1 12/2/94 To: bsimpson@morningstar.com Cc: IPSEC@ans.net Subject: Re: weak devices In-Reply-To: Your message of "Wed, 11 Jan 1995 11:48:58 GMT." <3676.bill.simpson@um.cc.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 1995 12:36:40 -0500 From: " " Bill, Are you concerned about the single MD5 operation req' to check against clogging attack? (the many MD5 operations are req' for the initiator of the communication so are not subject to clogging attacks) My belief is that doing an MD5, or a few multiplications as in MKMP and Jim's proposals, is something you should be able to do even under clogging, since they are comparable work to the processing of packets. Photuris cookies provide anti-clogging protection which does not expose anonymity. I think this is their plus. As usual, we have to consider the tradeoffs and decide. It is not black vs white. Best, Amir > > OK, then why were we discussing how fast or slow MD5 is on those > > trusted but underpowered machines? > > > Because the modular exponentiation is done only once every few hours or > days. > > The MD5 (as opposed to Photuris cookies) is to prevent clogging attacks > many times a second. You can't prevent clogging attacks with an > algorithm that clogs the machine! > > Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Jan 13 13:14:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21788 (5.65c/IDA-1.4.4 for ); Fri, 13 Jan 1995 08:19:37 -0500 Received: by interlock.ans.net id AA38478 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 13 Jan 1995 08:14:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 13 Jan 1995 08:14:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 13 Jan 1995 08:14:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 13 Jan 1995 08:14:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 13 Jan 1995 08:14:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 13 Jan 1995 08:14:12 -0500 Date: Fri, 13 Jan 1995 08:14:07 -0500 From: amir@watson.ibm.com (A.Herzberg) Message-Id: <9501131314.AA20411@gimili.watson.ibm.com> To: ipsec@ans.net Subject: Where is IPSP? Did I miss the posting of IPSP in the backlog of mail after the holidays? I begin to get worried. Last time, we were promised a draft in a week, and it took 4 months for the author to suggest we just use something else. This time, the promise was 2 weeks, and I really can't wait 8 months to hear it is not being written. We need IPSP NOW. It is a simple job. Please, if people do not have it as a priority, they should not volunteer to do it. We need IPSP to make products compatible with it. And we need it now. Best, Amir Herzberg From ipsec-request@ans.net Fri Jan 13 19:07:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15846 (5.65c/IDA-1.4.4 for ); Fri, 13 Jan 1995 14:24:03 -0500 Received: by interlock.ans.net id AA34515 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 13 Jan 1995 14:18:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 13 Jan 1995 14:18:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 13 Jan 1995 14:18:32 -0500 Date: Fri, 13 Jan 95 19:07:56 GMT From: "William Allen Simpson" Message-Id: <3710.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Where is IPSP? > From: amir@watson.ibm.com (A.Herzberg) > We need IPSP NOW. It is a simple job. Please, if people do not have it as > a priority, they should not volunteer to do it. We need IPSP to make products > compatible with it. And we need it now. > I'm tired of waiting, too. Perry and I will get something done by tomorrow or Monday. It is merely a re-write of Ran's drafts (for which I obtained his permission to plagerize a couple of days ago). People are implementing. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Jan 13 19:05:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17383 (5.65c/IDA-1.4.4 for ); Fri, 13 Jan 1995 14:24:03 -0500 Received: by interlock.ans.net id AA27854 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 13 Jan 1995 14:18:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 13 Jan 1995 14:18:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 13 Jan 1995 14:18:30 -0500 Date: Fri, 13 Jan 95 19:05:30 GMT From: "William Allen Simpson" Message-Id: <3709.bill.simpson@um.cc.umich.edu> To: IPSEC@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: weak devices > From: " " > Are you concerned about the single MD5 operation req' to > check against clogging attack? (the many MD5 operations > are req' for the initiator of the communication so are > not subject to clogging attacks) > yes. > My belief is that doing an MD5, or a few multiplications as in MKMP and Jim's > proposals, is something you should > be able to do even under clogging, since they are > comparable work to the processing of packets. > No. MD5 takes a lot more CPU than packet processing. > Photuris cookies provide anti-clogging protection which does not expose > anonymity. I think this is their plus. > As usual, we have to consider the tradeoffs and decide. > It is not black vs white. > We have considered the tradeoffs in rather a lot of messages. IMHO, Photuris cookies are the best proposal so far! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Jan 13 20:50:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12759 (5.65c/IDA-1.4.4 for ); Fri, 13 Jan 1995 17:08:19 -0500 Received: by interlock.ans.net id AA26251 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 13 Jan 1995 16:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 13 Jan 1995 16:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 13 Jan 1995 16:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 13 Jan 1995 16:58:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 13 Jan 1995 16:58:13 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 13 Jan 1995 16:58:13 -0500 Date: 13 Jan 95 14:50:00 -0600 To: bill.simpson@um.cc.umich.edu, ipsec@ans.net Cc: amir@watson.ibm.com Subject: Re[2]: Where is IPSP? Message-Id: Bill and Amir, Thanks for your patience. A draft is coalescing. It is currently in three parts being worked on by several volunteers. Much progress has been made in writing a draft after we chucked Perrys attempt. We lost some time in the last half of December (some of us have families and jobs), but will post the draft next week to the ipsec list. If you would like to contribute to the current editing effort please give me a call. I will find a section or two of the specification that you can directly work on. Paul (602-441-3646) From ipsec-request@ans.net Sat Jan 14 21:27:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17738 (5.65c/IDA-1.4.4 for ); Sat, 14 Jan 1995 16:45:19 -0500 Received: by interlock.ans.net id AA26530 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 14 Jan 1995 16:30:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 14 Jan 1995 16:30:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 14 Jan 1995 16:30:08 -0500 Date: Sat, 14 Jan 95 21:27:28 GMT From: "William Allen Simpson" Message-Id: <3730.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: draft-ietf-ipsec-esp-des-cbc-00.txt Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 The ESP DES-CBC Transform draft-ietf-ipsec-esp-des-cbc-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1. Introduction The Encapsulating Security Payload (ESP) [1] provides confidentiality and integrity by encrypting the data to be protected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm. DES is described is several US Government publications [2, 3, 4, 5]. A recent book also provides information on DES [6]. At least one hardware implementation of DES-CBC can encrypt or decrypt at about 1 Gbps [6, p. 231]. Conformance with ESP requires that this Security Transform MUST be implemented. 1.1. Keys The secret DES key shared between the communicating parties is 64 bits long. This key consists of a 56-bit quantity used by the DES algorithm, and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. 1.2. Initialization Vector This mode of DES requires an Initialization Vector (IV) that is 8 octets in length. Each datagram contains its own DES IV. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when other datagrams are dropped, or datagrams are re-ordered in transit. The method for selection of the IV values is implementation dependent. Note: A common technique is simply a counter, beginning with a randomly chosen value. Other implementations also exhibit unpredictability, usually through a pseudo-random number generator. Care should be taken that the periodicity of the number generator is long enough to prevent repetition during the lifetime of the session key. Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1.3. Data Size The DES algorithm operates on blocks of 8 octets. This often requires padding after the end of the unencrypted payload data. Both input and output result in the same number of octets, which facilitates in-place encryption and decryption. On receipt, if the length of the data to be decrypted is not an integral multiple of 8 octets, then an error is indicated. The datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. 2. Payload Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initialization Vector (IV) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Payload Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | Pad Length | Data Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Association Identifier (SAID) A 32-bit value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. Initialization Vector The size of this field is variable, though for any given Security Association it has a particular known size. Its position and size is constant for all DES-CBC datagrams of the same SAID and IP Destination. Troublemakers expires in six months [Page 2] DRAFT ESP DES-CBC January 1995 This field is considered to be transparent, though most users will not be able to make sense of its contents. The field may be longer or shorter than the 64-bits used by DES, in multiples of 32-bits. This allows alignment of the Encrypted Data for in-place decryption. All conformant implementations MUST correctly process a 64-bit field size. When the size is negotiated to 32-bits, the inverse of the 32-bits is appended to form a 64-bit value. When the size is negotiated to 96-bits or greater, the alignment of the 64-bit value within this field is negotiated by a variable parameter. Unused octets are filled with unspecified implementation dependent values. Payload Data The size of this field is variable. This field is opaque. Prior to encryption and after decryption, the contents of this field begins with an entire IP datagram (IP-Mode), or an IP Payload header (Transport-Mode). Padding The size of this field is variable. This field is opaque. Prior to encryption, it is filled with unspecified implementation dependent values. After decryption, it MUST be ignored. Pad Length This field indicates the size of the Padding field. It does not include the Pad Length and Data Type fields. The value typically ranges from 0 to 7, but may be up to 255 to permit hiding of that actual data length. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. Data Type This field indicates the contents of the Payload Data field, using Troublemakers expires in six months [Page 3] DRAFT ESP DES-CBC January 1995 the IP Protocol/Payload value. Up-to-date values of the IP Protocol/Payload are specified in the most recent "Assigned Numbers" RFC [7]. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. For example, when encrypting an entire IP datagram (IP-Mode), this field will contain the value 4, which indicates IP-in-IP encapsulation. Security Considerations Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [8], and upon the correctness of the ESP and IP implementations in all of the participating systems. It is known that DES is an algorithm approaching the end of its useful lifetime. As of the writing of this document, Biham and Shamir [9] have demonstrated a differential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, and Mitsuru Matsui [10] has demonstrated a linear cryptanalysis based known-plaintext attack requiring only 2^43 plaintext-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account. More disturbingly, Wiener [11] has shown the design of a DES cracking machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack, and it is suggested that DES is not a good encryption algorithm for the protection of even moderate value in the face of such equipment. Triple DES is probably a better choice for such purposes. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. The use of DES for confidentiality is closely modeled on the work done for SNMPv2 [12]. Troublemakers expires in six months [Page 4] DRAFT ESP DES-CBC January 1995 References [1] Randall Atkinson, Perry Metzger, William Simpson, "Encapsulating Security Protocol (ESP)", work in progress. [2] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [3] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46- 1, January 1988. [4] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [5] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [6] Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [7] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [8] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253- 280, July 1994. [9] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993. [10] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," Advances in cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994. [11] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. [12] Galvin, J., and McCloghrie, K., "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC- 1446, DDN Network Information Center, April 1993. Troublemakers expires in six months [Page 5] DRAFT ESP DES-CBC January 1995 Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 6] DRAFT ESP DES-CBC January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Keys ............................................ 1 1.2 Initialization Vector ........................... 1 1.3 Data Size ....................................... 2 2. Payload Format ........................................ 2 SECURITY CONSIDERATIONS ...................................... 4 ACKNOWLEDGEMENTS ............................................. 4 REFERENCES ................................................... 5 AUTHOR'S ADDRESS ............................................. 5 From ipsec-request@ans.net Sat Jan 14 23:27:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11254 (5.65c/IDA-1.4.4 for ); Sat, 14 Jan 1995 18:49:48 -0500 Received: by interlock.ans.net id AA08916 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 14 Jan 1995 18:30:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 14 Jan 1995 18:30:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 14 Jan 1995 18:30:02 -0500 Date: Sat, 14 Jan 95 23:27:35 GMT From: "William Allen Simpson" Message-Id: <3732.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: draft-ietf-ipsec-esp-00.txt Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 IPv4 Encapsulating Security Payload (4ESP) draft-ietf-ipsec-esp-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes a privacy mechanism for IPv4, encapsulating transport headers within an opaque envelope. Troublemakers expires in six months [Page 1] DRAFT 4ESP January 1995 1. Introduction The Encapsulating Security Payload (ESP) seeks to provide integrity and confidentiality to IP datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Users desiring integrity and authentication without confidentiality should use the Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv4 Security Overview" [RAsa], which defines the overall security plan for IPv4, and provides important background for this specification. 1.1. Overview The Encapsulating Security Payload (ESP) provides confidentiality and integrity by encrypting the data to be protected. Depending on the user's security requirements, only a transport-layer segment (such as UDP or TCP) is encrypted, or the entire IP datagram may be encrypted and tunneled to the destination. In order for ESP to work properly without changing the entire Internet infrastructure (particularly non-participating routers), the payload is placed within a datagram having unencrypted IP headers. The information in the unencrypted IP headers is used to route the secure datagram. Use of this specification will increase the protocol processing costs in participating systems, and will also increase the communications latency. The increased latency is primarily due to time required for encryption and decryption of each datagram containing an Encapsulating Security Payload. Encapsulating the protected data can be very expensive to implement. 1.2. Key Management Key management is an important part of the IP security architecture. A scalable standard Internet key management protocol is needed to make widespread use of ESP practical. However, in order to facilitate early adoption, manual key management is the only key management technique required by this specification. Troublemakers expires in six months [Page 1] DRAFT 4ESP January 1995 The only coupling between key management and ESP is the Security Association Identifier (SAID), which is described in more detail later. This permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. Thus, key management is specified in a separate specification [TBD]. Nota Bene: It is intended that the key management mechanisms being developed in other IETF Working Groups will be useful for both IPv4 and IPv6. 1.3. Security Associations The key management mechanism is used to negotiate a number of parameters for each Security Association between the communicating parties. This includes the key(s) used to encrypt and decrypt the opaque portion of the ESP payload, the sensitivity level (such as Secret or Unclassified) of the user data in the ESP payload, and the particular transform to be used. The key management implementation usually maintains a table containing the several parameters for each current Security Association. The ESP implementation needs to access that security parameter table to determine how to process each datagram. The Security Association Identifier (SAID) is assigned by the entity controlling the Destination IP address of the Security Association. The selection mechanism used for the SAID is implementation dependent. A given Destination is not necessarily in control of the negotiation process. In the case of multicast groups, a single node or cooperating subset of the multicast group may work on behalf of the entire group to set up a Security Association. A session between two nodes will normally have two SAID values (one in each direction). The nodes use the combination of SAID and IP Destination to distinguish the correct association. Senders to a multicast group may share a common Security Association, if all communications are authenticated using the same security configuration parameters. In this case, the receiver only knows that the message came from a node knowing the Security Association for the Troublemakers expires in six months [Page 2] DRAFT 4ESP January 1995 group, and cannot authenticate which member of the group sent the datagram when symmetric algorithms are in use. Multicast groups may also use a separate Security Association value for each Source. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also provided. 1.4. Transforms Encryption and authentication algorithms, and the precise format of opaque ESP data associated with them, are known as "transforms". It is intended that ESP should be sufficiently general to permit the specification of new transforms as new cryptographic algorithms are developed. Each SAID value indicates the encryption algorithm and mode used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronization or initialization vector field. These transforms are described in companion documents. Troublemakers expires in six months [Page 3] DRAFT 4ESP January 1995 2. Payload Format The Encapsulating Security Payload (ESP) may appear anywhere after the IP header. The header immediately preceding the ESP header will always contain the value in its Next Header (Protocol) field. <-- Transparent (not encrypted) --> <-- Opaque --> +-----------+-----------------+--------------+------------------+ | IP Header | Other Headers | ESP Header | encrypted data | +-----------+-----------------+--------------+------------------+ The Encapsulating Security Payload has two components. The transparent ESP header consists of the unencrypted field(s) of the payload. The transparent field(s) of the unencrypted ESP header inform the intended receiver how to properly decrypt and process the encrypted data. The opaque ESP component consists of encrypted data. The encrypted data includes protected fields for the ESP transform, and also the encapsulated IP datagram. 2.1. Header Fields A more detailed diagram of the ESP Header follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Association Identifier (SAID) A value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are reserved for future use. Troublemakers expires in six months [Page 4] DRAFT 4ESP January 1995 Transform Data The length of this field is variable, but is always at least 32- bits. An implementation will normally use the SAID to determine the field's size and use. It retains the same format for all datagrams of any given SAID and IP Destination. Refer to each Security Transform specification for more information regarding the contents of this field. 3. Payload Processing This chapter describes the steps taken when ESP is in use between two communicating parties. There are two modes of use for ESP. The first mode, which is herein called "IP-mode", encapsulates an entire IP datagram inside ESP. The second mode, which is herein called "Transport-Mode", encapsulates a transport-layer segment (such as UDP or TCP) inside ESP. In either case, the sender first determines if a Security Association has been established with the target receiver. If not, then the key management mechanism is used to establish the SAID for this communications session prior to the encryption. If cleartext datagram If a SAID is received which is not valid for a particular Destination, then the datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. Multicast is different from unicast only in the area of key management. 3.1. IP-mode The sender takes the entire original IP datagram, applies the encryption algorithm using the appropriate key for the receiving Troublemakers expires in six months [Page 5] DRAFT 4ESP January 1995 party, and encapsulates the result within an ESP header. Next, ESP is sent as the final payload of a cleartext IP datagram. This mode is used to send encrypted ICMP or IGMP messages. Such messages are often specific to the IP addressing and routing information. If strict red/black separation is being enforced, then the addressing and other information in the cleartext IP headers and payloads might be different from the values contained in the (now encrypted and encapsulated) original datagram. The receiver processes the cleartext IP header and other intervening headers (if any). It then decrypts the ESP using the session key that has been established for this SAID. The original datagram is extracted from the (now decrypted) ESP. This datagram is then processed as if received normally. In the case of a B1 or Compartmented Mode Workstation, additional mandatory access controls are applied, as appropriate. 3.2. Transport-mode The sender takes the original transport segment, applies the encryption algorithm using the appropriate key for the receiving party, and encapsulates the result within an ESP header. Next, ESP is sent as the final payload of a cleartext IP datagram. The receiver processes the cleartext IP header and other invervening IP headers (if any), and temporarily stores pertinent information (such as Source and Destination). It then decrypts the ESP using the session key that has been established for this SAID. The original transport header is extracted from the (now decrypted) ESP. The information from the cleartext IP header and the extracted transport header is jointly used to determine to which application the data belongs. In the case of a B1 or Compartmented Mode Workstation, additional mandatory access controls are applied, as appropriate. 3.3. Authentication Some Transforms provide authentication as well as encryption. When such a mechanism is not in use, the Authentication Header [RAah] Troublemakers expires in six months [Page 6] DRAFT 4ESP January 1995 might be used. There are several different approaches, depending on which part of the data is to be authenticated. The location of the Authentication Header makes it clear which set of data is being authenticated. In the first usage, the entire received datagram is authenticated, including both the encrypted and unencrypted portions, while only the data sent after the ESP Header is confidential. In this usage, the sender first applies ESP to the data being protected. Next, any intervening IP headers are added before the ESP header. Finally, the Authentication Header is calculated over the resulting datagram according to the normal method. Upon receipt, the receiver first verifies the authenticity of the entire datagram, using the normal Authentication Header process. If authentication succeeds, decryption using the normal ESP process occurs. If decryption is successful, the resulting data is passed to the higher protocol layers. If the authentication is to be applied only to the data protected by ESP, and the protected data is an entire IP datagram, then the Authentication Header is placed normally within that protected IP datagram. If the authentication is to be applied to less than an entire IP datagram, then the Authentication Header is placed within the encrypted payload, immediately after the ESP protected header, and before any other header. An Authentication Header may be present both preceding the ESP header, and also as a header within the encrypted ESP envelope. In such a case, the unencrypted Authentication Header is primarily used to provide protection for the contents of the unencrypted IP headers, and the encrypted Authentication Header is used to provide authentication for the encapsulated datagram. 3.4. Other Headers It is important that all routing information and other such internal headers be included within the encrypted datagram, even if the same information is in the unencrypted part of the datagram. The receiving system MUST ignore all routing information in the unencrypted portion of the received datagram, and strictly rely on the routing information from the protected payload instead. If this Troublemakers expires in six months [Page 7] DRAFT 4ESP January 1995 rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks. The original datagram may contain an explicit Sensitivity Label, but the encrypted datagram need not include any Sensitivity Label. The SAID indicates the Sensitivity Label for the encrypted datagram. Security Considerations This specification is principly concerned with a security mechanism for use with IP. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the ESP and IP implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Use of high assurance development techniques is recommended for the Encapsulating Security Payload. Note that it is possible, when some cryptographic algorithms are employed without an authentication mechanism, for a third party to alter the cleartext of a message, even though that party does not possess the key. It is important that applications requiring both confidentiality and authentication select a transform that prevents this. This mechanism alone does not provide complete immunity from traffic analysis. Users seeking further protection from traffic analysis might consider the use of appropriate link encryption. These details are outside the scope of this specification. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. Troublemakers expires in six months [Page 8] DRAFT 4ESP January 1995 Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification [SDN.301], the ISO/IEC's NLSP specification [ISO-11577], and the proposed swIPe security protocol [IBK93a, IBK93b]. Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful critiques of earlier versions of this draft. References [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. [IBK93a] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP Security Protocol", unpublished draft, 14 April 1993. [IBK93b] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", Presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [ISO-11577] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [RAsa] Randall Atkinson, et alia, IPv6 Security Architecture, work in progress. [RAah] Randall Atkinson, IPv6 Authentication Header, work in progress. [SDN.301]SDNS Secure Data Network System, Security Protocol 3 (SP3), Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. [14] Bruce Schneier, "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [15] Dan McDonald, "Security Extensions to the IPv6 Sockets API", work in progress. Troublemakers expires in six months [Page 9] DRAFT 4ESP January 1995 Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 10] DRAFT 4ESP January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Overview ........................................ 1 1.2 Key Management .................................. 1 1.3 Security Associations ........................... 2 1.4 Transforms ...................................... 3 2. Payload Format ........................................ 4 2.1 Header Fields ................................... 4 3. Payload Processing .................................... 5 3.1 IP-mode ......................................... 5 3.2 Transport-mode .................................. 6 3.3 Authentication .................................. 6 3.4 Other Headers ................................... 7 SECURITY CONSIDERATIONS ...................................... 8 ACKNOWLEDGEMENTS ............................................. 8 REFERENCES ................................................... 9 AUTHOR'S ADDRESS ............................................. 9 From ipsec-request@ans.net Sun Jan 15 21:05:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23477 (5.65c/IDA-1.4.4 for ); Sun, 15 Jan 1995 16:20:32 -0500 Received: by interlock.ans.net id AA21833 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 15 Jan 1995 16:09:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 15 Jan 1995 16:09:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 15 Jan 1995 16:09:15 -0500 Date: Sun, 15 Jan 95 21:05:43 GMT From: "William Allen Simpson" Message-Id: <3744.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: draft-ietf-ipsec-ah-md5-00.txt Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 Authentication with Keyed MD5 draft-ietf-ipsec-ah-md5-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes the use of MD5 with the IPv4 Authentication Header. Troublemakers expires in six months [Page 1] DRAFT AH MD5 January 1995 1. Introduction The Authentication Header (AH) [RAah] provides integrity and authentication for IP datagrams. This specification describes the AH use of Message Digest 5 (MD5) [RFC-1321]. A 128-bit digest is calculated over the invariant portions of the entire IP datagram and the result is included in the Authentication Data field of the Authentication Header. Implementations that claim conformance or compliance with the Authentication Header specification MUST implement the MD5 mechanism. Implementors should consult the most recent version of the IAB Standards [RFC-1610] for further guidance on the status of this document. 1.1. Keys The secret authentication key shared between the communicating parties MUST be 128 bits long. The key SHOULD be a pseudo-random number, not a guessable string of any sort. 1.2. Data Size Because MD5's 128-bit output is naturally 64-bit aligned, there is no wasted space in the Authentication Data field. 1.3. Performance MD5 reportedly has a throughput of about 60 Mbps on a fast 64-bit RISC processor with slightly tuned MD5 code [Touch94]. Nota Bene: This is possibly too slow to be used for a long period of time. Suggestions are sought on alternative authentication algorithms that would be acceptable to the IETF, have significantly faster throughput, are not patent-encumbered, and still retain adequate cryptographic strength. Troublemakers expires in six months [Page 1] DRAFT AH MD5 January 1995 2. Calculation The 128-bit digest is calculated as described in [RFC-1321]. The specification of MD5 includes a portable 'C' programming language description of the MD5 algorithm. The "b-bit message" shall consist of the 128-bit secret authentication key concatenated with (followed by) the entire IP datagram. All IP headers and payloads that are present MUST be included in the computation, with header fields whose value varies in transit (such as Hop Count) being assumed to contain zeros for the purpose of the authentication calculation. Also, the Authentication Data field of the Authentication Header is considered to contain all zeros. Security Considerations Users need to understand that the quality of the security provided by this specification depends completely on the strength of the MD5 hash function, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implementations in all of the participating systems. At the time of writing of this document, it is known to be possible to produce collisions in the compression function of MD5 [BdB93]. There is not yet a known method to exploit these collisions to attack MD5 in practice, but this fact is disturbing to some authors [Schneier94]. It has also recently been determined [OW94] that it is possible to build a machine for $10 Million that could find messages that hash to an arbitrary given MD5 hash. This attack requires approximately 24 days. Although this is not a substantial weakness for most IP security applications, it should be recognized that current technology is catching up to the 128 bit hash length used by MD5. Applications requiring extremely high levels of security may wish to move in the near future to algorithms with longer hash lengths. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. Troublemakers expires in six months [Page 2] DRAFT AH MD5 January 1995 The use of MD5 for authentication is closely modeled on the work done for SNMPv2 [RFC-1446]. References [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. [BdB93] B. den Boer and A. Bosselaers, "Collisions for the Compression function of MD5", Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994 [RAah] Randall Atkinson, "IPv6 Authentication Header", work in progress, 4 November 1994. [RFC-1321] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information Center, April 1992. [RFC-1446] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [RFC-1610] Postel, J., "Internet Official Protocol Standards", STD 1, RFC 1610, USC/Information Sciences Institute, July 1994. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [OW94] Paul C. van Oorschot & Michael J. Wiener, Unpublished Crypto '94 Rump Session. [Schneier94] Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [Touch94] Touch, J., "Report on MD5 Performance", work in progress, December 1994. Troublemakers expires in six months [Page 3] DRAFT AH MD5 January 1995 Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 4] DRAFT AH MD5 January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Keys ............................................ 1 1.2 Data Size ....................................... 1 1.3 Performance ..................................... 1 2. Calculation ........................................... 2 SECURITY CONSIDERATIONS ...................................... 2 ACKNOWLEDGEMENTS ............................................. 2 REFERENCES ................................................... 3 AUTHOR'S ADDRESS ............................................. 4 From ipsec-request@ans.net Sun Jan 15 21:04:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11191 (5.65c/IDA-1.4.4 for ); Sun, 15 Jan 1995 16:20:32 -0500 Received: by interlock.ans.net id AA16707 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 15 Jan 1995 16:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 15 Jan 1995 16:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 15 Jan 1995 16:09:11 -0500 Date: Sun, 15 Jan 95 21:04:27 GMT From: "William Allen Simpson" Message-Id: <3743.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: draft-ietf-ipsec-ah-00.txt Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 IPv4 Authentication Header (4AH) draft-ietf-ipsec-ah-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes an authentication mechanism for IPv4, by inserting an intervening header between the IPv4 Header and any transport headers. Troublemakers expires in six months [Page 1] DRAFT 4AH January 1995 1. Introduction The Authentication Header (AH) seeks to provide integrity and authentication for IP datagrams. It may also provide non- repudiation, depending on which algorithm is used. Users desiring confidentiality should consider using the Encapsulating Security Protocol (ESP) [RAesp], either in lieu of or in conjunction with the Authentication Header. This document assumes that the reader is familiar with the related document "IPv4 Security Overview" [RAsa], which defines the overall security plan for IPv4, and provides important background for this specification. 1.1. Overview 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. In order for the Authentication Header to work properly without changing the entire Internet infrastructure (particularly non- participating routers), the authentication data is carried in its own IP protocol payload. Nodes that aren't participating in the authentication ignore the Authentication Header. In some environments, intermediate routing authentication might be desirable [RFC-1636]. If an asymmetric authentication algorithm is used, then the routers performing such intermediate authentication would need to be aware of the appropriate public keys and authentication algorithm. The routers could authenticate the traffic being handled, without being able to forge or modify otherwise legitimate traffic. If a symmetric authentication algorithm is used, then the routers performing such intermediate authentication would need to be provided with the appropriate keys. Possession of those keys would permit any one of those systems to forge traffic claiming to be from the legitimate sender to the legitimate receiver, or to modify the contents of otherwise legitimate traffic. Use of this specification will increase the protocol processing costs in participating systems, and will also increase the communications Troublemakers expires in six months [Page 1] DRAFT 4AH January 1995 latency. The increased latency is primarily due to time required for calculation of the authentication data by the sender, and the calculation and comparison of the authentication data by the receiver, over each datagram containing an Authentication Header. The impact will vary with authentication algorithm used and other factors, but is expected to be relatively inexpensive to implement. 1.2. Key Management Key management is an important part of the IP security architecture. A scalable standard Internet key management protocol is needed to make widespread use of authentication practical. However, in order to facilitate early adoption, manual key management is the only key management technique required by this specification. The only coupling between key management and the AH is the Security Association Identifier (SAID), which is described in more detail later. This permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. Thus, key management is specified in a separate specification [TBD]. Nota Bene: It is intended that the key management mechanisms being developed in other IETF Working Groups will be useful for both IPv4 and IPv6. 1.3. Security Associations The key management mechanism is used to negotiate a number of parameters for each Security Association between the communicating parties. This includes the key(s) used to generate the authentication data, and also other parameters (such as the authentication algorithm and mode). The key management protocol implementation usually maintains a table containing the several parameters for each current Security Association. The AH implementation needs to access that security parameter table to determine how to process each datagram. The Security Association Identifier (SAID) is assigned by the entity Troublemakers expires in six months [Page 2] DRAFT 4AH January 1995 controlling the Destination IP address of the Security Association. The selection mechanism used for the SAID is implementation dependent. A given Destination is not necessarily in control of the negotiation process. In the case of multicast groups, a single node or cooperating subset of the multicast group may work on behalf of the entire group to set up a Security Association. A session between two nodes will normally have two SAID values (one in each direction). The nodes use the combination of SAID and IP Destination to distinguish the correct association. Senders to a multicast group may share a common Security Association, if all communications are authenticated using the same security configuration parameters. In this case, the receiver only knows that the message came from a node knowing the Security Association for the group, and cannot authenticate which member of the group sent the datagram when symmetric algorithms are in use. Multicast groups may also use a separate Security Association value for each Source. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also provided. 1.4. Mechanisms It is intended that the AH format should be sufficiently general to permit the specification of new mechanisms as new cryptographic algorithms are developed. Each SAID value indicates the algorithm and mode used, the block size (if any) of the algorithm, and the presence/absence and size of a cryptographic synchronization or initialization vector field. These parameters are described in companion mechanism documents. The authentication mechanism uses a message digest algorithm (such as MD5), either encrypting that message digest or keying the message digest directly. Because conventional checksums (such as CRC-16) are not cryptographically strong and can be easily reversed, they MUST NOT be used with the Authentication Header. Troublemakers expires in six months [Page 3] DRAFT 4AH January 1995 2. Payload Format The Authentication Header (AH) may appear after any other headers which are examined at each hop, and before any other headers which are not examined at an intermediate hop. The header immediately preceding the Authentication Header will always contain the value in its Next Header (Protocol) field. +-----------+-----------------+-----------+---------+-----------+ | IP Header | Routing/Hop-Hop | Auth Head | End-End | Transport | +-----------+-----------------+-----------+---------+-----------+ 2.1. Header Fields A more detailed diagram of the Authentication Header follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header Identifies the next header after the Authentication Header, using the IP Protocol/Payload value. Up-to-date values of the IP Protocol/Payload are specified in the most recent "Assigned Numbers" [RFC-1700]. Length The length of the Authentication Data field in 64-bit increments. Minimum value is 0, which is only used in the degenerate case of a "null" authentication algorithm. Security Association Identifier (SAID) A value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. Troublemakers expires in six months [Page 4] DRAFT 4AH January 1995 SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are reserved for future use. Authentication Data The length of this field is variable, but is always an integral number of 64-bits. An implementation will normally use the SAID to determine the field's size and use. It retains the same format for all datagrams of any given SAID and IP Destination. The Authentication Data fills the field beginning immediately after the SAID field. If the field is longer than necessary to store the actual authentication data, then the unused bit positions MUST be ignored by the receiver. Each mechanism will have such special processing instructions included in its specification. Refer to each Authentication Mechanism specification for more information regarding the contents of this field. 3. Processing This chapter describes the steps taken when the AH is in use between two communicating parties. The sender first determines if a Security Association has been established with the target Destination. If not, then the key management mechanism is used to establish the SAID for this communications session prior to the use of the AH. If an unauthenticated datagram arrives from a Source after a SAID has been established, or a SAID is received which is not valid, then an error is indicated. The datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. Multicast is different from unicast only in the area of key management. Troublemakers expires in six months [Page 5] DRAFT 4AH January 1995 3.1. Calculation The Authentication Data is the output of the authentication algorithm calculated over the invariant portions of the entire IPv4 datagram. The sender places this algorithm output into the Authentication Data field within the Authentication Header. When a keyed message digest algorithm is used (such as MD5), the secret key is fed into the algorithm first, followed by the invariant fields of the IP datagram in sequence. The secret key is fed in first, because that increases the work function for someone attempting to cryptanalyse the key from knowledge of the plaintext datagram. Feeding the secret key in first also permits implementations to precompute the start of the hash for a given destination, and possibly improve performance thereby. The key does not need to be fed in at the end. Including the IP Header's invariant Total Length field in the authentication calculation precludes appending attacks. Fields which will necessarily vary in transit from the sender to the receiver (such as the Hop Count), are included in the calculation, but the value zero is substituted for the actual value of such fields. The Authentication Data field itself is also zeroed during the calculation. All other Authentication Header fields are included. This substitution of zero is used instead of omitting those fields, because it preserves alignment of the data during calculation, which can significantly improve performance. If a block-oriented authentication algorithm is in use (such as MD2, MD4, MD5), and the IP datagram is not an integral number of blocks, the authentication data calculation is performed using zero bytes at the end of the datagram to pad the length out to an integral number of blocks. These block padding bytes are not included in the actual IP datagram, and are not sent over the link. Adding padding at that point in protocol processing could make implementation of MTU related calculations very difficult. The sender MUST compute the calculation over the datagram as it will appear at the receiver. This requirement allows for future intervening headers which are removed or altered during transit. The Troublemakers expires in six months [Page 6] DRAFT 4AH January 1995 sender needs to know the final values when including such headers in the datagram. Each such header will have special processing instructions included in its specification. Upon receipt of a datagram containing an Authentication Header, the receiver independently calculates the authentication data. It compares the received Authentication Data field contents with the calculated authentication value. If they differ, then the receiver SHOULD discard the received IP datagram, and return an appropriate ICMP message. The failure MUST be recorded in the system or audit log, as described earlier. Security Considerations This specification is principly concerned with a security mechanism for use with IP. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever cryptographic algorithm that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Implementers are encouraged to use high assurance development techniques to develop all of the security relevant parts of their products. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. The basic concept is derived in large part from the work done for SNMPv2 [RFC-1446]. Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques of earlier versions of this draft. Troublemakers expires in six months [Page 7] DRAFT 4AH January 1995 References [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. [RAsa] Randall Atkinson, IPv6 Security Architecture, work in progress, 4 November 1994. [RAesp] Randall Atkinson, IPv6 Encapsulating Security Payload, work in progress, 4 November 1994. [RFC-1446] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [RFC-1636] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, 9 June 1994, pp. 21-34. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [Bell89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Troublemakers expires in six months [Page 8] DRAFT 4AH January 1995 Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 9] DRAFT 4AH January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Overview ........................................ 1 1.2 Key Management .................................. 2 1.3 Security Associations ........................... 2 1.4 Mechanisms ...................................... 3 2. Payload Format ........................................ 4 2.1 Header Fields ................................... 4 3. Processing ............................................ 5 3.1 Calculation ..................................... 6 SECURITY CONSIDERATIONS ...................................... 7 ACKNOWLEDGEMENTS ............................................. 7 REFERENCES ................................................... 8 AUTHOR'S ADDRESS ............................................. 8 From ipsec-request@ans.net Mon Jan 16 15:19:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11121 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 15:19:50 -0500 Received: by interlock.ans.net id AA08672 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 15:09:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 15:09:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 15:09:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 15:09:46 -0500 Date: Mon, 16 Jan 95 11:56:23 From: "Housley, Russ" Encoding: 293 Text Message-Id: <9500167902.AA790286183@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt I am concerned about the direction taken in the four I-Ds that were posted. In particular, to provide both confidentiality and integrity, I need to use both encapsulation protocols. I thought that we would allow something similar to ESP for both confidentiality and integrity. Russ From ipsec-request@ans.net Mon Jan 16 15:19:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11635 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 15:19:52 -0500 Received: by interlock.ans.net id AA19173 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 15:10:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 15:10:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 15:10:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 15:10:00 -0500 Date: Mon, 16 Jan 95 11:56:17 From: "Housley, Russ" Encoding: 1231 Text Message-Id: <9500167902.AA790286177@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re: draft-ietf-ipsec-ah-md5-00.txt The draft says: 2. Calculation The 128-bit digest is calculated as described in [RFC-1321]. The specification of MD5 includes a portable 'C' programming language description of the MD5 algorithm. The "b-bit message" shall consist of the 128-bit secret authentication key concatenated with (followed by) the entire IP datagram. All IP headers and payloads that are present MUST be included in the computation, with header fields whose value varies in transit (such as Hop Count) being assumed to contain zeros for the purpose of the authentication calculation. Also, the Authentication Data field of the Authentication Header is considered to contain all zeros. Ron Rivest has stated that a shared secret at the front of a message is not sufficient for authentication. I thought that I remembered this being discussed ath the San Jose IETF. Further, I thought that we agreed that we would solve this weakness by puting the shared secret before and after the data payload. Does anyone else remember this? I seem to remember the discussion causing a tanget about "prepend" not being a word. Russ From ipsec-request@ans.net Mon Jan 16 20:56:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12887 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 16:06:24 -0500 Received: by interlock.ans.net id AA14285 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 15:56:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 16 Jan 1995 15:56:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 15:56:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 15:56:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 15:56:45 -0500 Message-Id: <9501162056.AA07319@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: draft-ietf-ipsec-ah-md5-00.txt In-Reply-To: Your message of "Mon, 16 Jan 1995 11:56:17." <9500167902.AA790286177@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 16 Jan 1995 15:56:27 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Ron Rivest has stated that a shared secret at the front of a message is not > sufficient for authentication. I thought that I remembered this being > discussed ath the San Jose IETF. If you read the spec, we address the issue. The length of total IP packet is authenticated, so appending attacks are not possible. Perry From ipsec-request@ans.net Mon Jan 16 21:00:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18780 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 16:08:28 -0500 Received: by interlock.ans.net id AA47890 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 16:00:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 16 Jan 1995 16:00:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 16:00:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 16:00:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 16:00:44 -0500 Message-Id: <9501162100.AA07329@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt In-Reply-To: Your message of "Mon, 16 Jan 1995 11:56:23." <9500167902.AA790286183@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 16 Jan 1995 16:00:21 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > I am concerned about the direction taken in the four I-Ds that were posted. > In particular, to provide both confidentiality and integrity, I need to use > both encapsulation protocols. No, thats not true either. Please read the documents carefully. They note that ESP protocols can provide both confidentiality and integrity. The documents provide for the possibility that one might want to combine AH and ESP -- they do *NOT* force you to combine them. The "DES-MD5" document is forthcoming -- its just a mechanical transformation of the DES document. Perry From ipsec-request@ans.net Mon Jan 16 19:57:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19297 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 16:08:43 -0500 Received: by interlock.ans.net id AA06945 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 16:01:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 16 Jan 1995 16:01:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 16 Jan 1995 16:01:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 16:01:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 16:01:23 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 16:01:23 -0500 Date: 16 Jan 95 13:57:00 -0600 To: housley@spyrus.com, ipsec@ans.net Subject: Re[2]: draft-ietf-ipsec-ah-md5-00.txt Message-Id: The group agreed at the San Jose meeting to use the same 128-bit secret at the front and back of the data payload. Paul _______________________________________________________________________________ Subject: Re: draft-ietf-ipsec-ah-md5-00.txt Author: housley@spyrus.com@INTERNET Date: 1/16/95 2:32 PM Encoding: 1231 Text The draft says: 2. Calculation The 128-bit digest is calculated as described in [RFC-1321]. The specification of MD5 includes a portable 'C' programming language description of the MD5 algorithm. The "b-bit message" shall consist of the 128-bit secret authentication key concatenated with (followed by) the entire IP datagram. All IP headers and payloads that are present MUST be included in the computation, with header fields whose value varies in transit (such as Hop Count) being assumed to contain zeros for the purpose of the authentication calculation. Also, the Authentication Data field of the Authentication Header is considered to contain all zeros. Ron Rivest has stated that a shared secret at the front of a message is not sufficient for authentication. I thought that I remembered this being discussed ath the San Jose IETF. Further, I thought that we agreed that we would solve this weakness by puting the shared secret before and after the data payload. Does anyone else remember this? I seem to remember the discussion causing a tanget about "prepend" not being a word. Russ From ipsec-request@ans.net Mon Jan 16 21:50:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17330 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 17:13:46 -0500 Received: by interlock.ans.net id AA39639 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 16:50:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 16 Jan 1995 16:50:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 Jan 1995 16:50:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 16:50:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 16:50:27 -0500 Message-Id: <9501162150.AA07424@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[2]: draft-ietf-ipsec-ah-md5-00.txt In-Reply-To: Your message of "16 Jan 1995 13:57:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 16 Jan 1995 16:50:12 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > The group agreed at the San Jose meeting to use the same 128-bit > secret at the front and back of the data payload. As I've just noted to the list, given the fact that the AH style authentication goes over all invariant parts of the packet, including the the total packet length, there is no danger of appending attacks. Perry From ipsec-request@ans.net Tue Jan 17 03:18:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18232 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 22:46:15 -0500 Received: by interlock.ans.net id AA46107 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 22:30:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 22:30:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 22:30:30 -0500 Date: Tue, 17 Jan 95 03:18:15 GMT From: "William Allen Simpson" Message-Id: <3767.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: draft-ietf-ipsec-ah-md5-00.txt > Ron Rivest has stated that a shared secret at the front of a message is not > sufficient for authentication. I thought that I remembered this being > discussed ath the San Jose IETF. Further, I thought that we agreed that we > would solve this weakness by puting the shared secret before and after the > data payload. > The appending attack is solved by including the IP Total Length field in the calculation. Ran explained this. > Does anyone else remember this? I seem to remember the discussion causing > a tanget about "prepend" not being a word. > That was me. I remember. The WG minutes do not suggest a decision was made. I have email from the Area Director recommending we only use the front, as that is compatible with what other WGs are doing. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Jan 17 03:21:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23097 (5.65c/IDA-1.4.4 for ); Mon, 16 Jan 1995 22:46:15 -0500 Received: by interlock.ans.net id AA14881 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 Jan 1995 22:30:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 Jan 1995 22:30:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 Jan 1995 22:30:32 -0500 Date: Tue, 17 Jan 95 03:21:08 GMT From: "William Allen Simpson" Message-Id: <3768.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: draft-ietf-ipsec--00.txt > From: "Housley, Russ" > In particular, to provide both confidentiality and integrity, I need to use > both encapsulation protocols. I thought that we would allow something > similar to ESP for both confidentiality and integrity. > Thanks for reading it, but you missed the few mentions. Perhaps they need to be longer? The Encapsulating Security Payload (ESP) seeks to provide integrity and confidentiality to IP datagrams. It may also provide = authentication, depending on which algorithm and algorithm mode are used. Each SAID value indicates the encryption algorithm and mode used, the = block size (if any) of the encryption algorithm, the authentication = algorithm being used (if separate from the encryption algorithm), the = block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronization or initialization vector field. These transforms are described in companion documents. = Some Transforms provide authentication as well as encryption. When such a mechanism is not in use, the Authentication Header [RAah] might be used. So, we covered all the bases. Now, we have to agree on which other transforms to write up! I favor triple DES, and DES-CBC with CRC. Perry likes MD5 instead of CRC, but I think that the CRC would improve speed, and be good enough when encrypted afterward. What do you think? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Jan 16 15:29:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20473 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 00:48:18 -0500 Received: by interlock.ans.net id AA22616 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 00:29:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 00:29:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 00:29:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 00:29:42 -0500 Date: Mon, 16 Jan 95 22:29:33 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501170529.AA15254@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: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt > Now, we have to agree on which other transforms to write up! I favor > triple DES, and DES-CBC with CRC. > Perry likes MD5 instead of CRC, but I think that the CRC would improve > speed, and be good enough when encrypted afterward. If you can XOR a specific pattern into the DES-CBC IV, on decrypting the resultant plaintext has that pattern XORed into the first data block. Since the IV is longer than the CRC and I know the CRC polynomial, I can choose an XOR pattern that is divisible by the polynomial, and thus undetected by it. Thus, I can make a large number of undetected changes (defined as XORs) to the first 8 bytes of a message. If I know what they are to start with, I can possibly change them to desired values. Is this a problem? CBC is ciphertext[i] = encrypt(plaintext[i] ^ ciphertext[i-1]), so plaintext[i] = ciphertext[i-1] ^ decrypt(ciphertext[i]), so plaintext[0] = decrypt(ciphertext[0]) ^ IV. -- -Colin From ipsec-request@ans.net Tue Jan 17 15:06:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20395 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 10:13:23 -0500 Received: by interlock.ans.net id AA03926 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 10:06:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 17 Jan 1995 10:06:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 10:06:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 10:06:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 10:06:59 -0500 Message-Id: <9501171506.AA08685@snark.imsi.com> To: colin@nyx10.cs.du.edu (Colin Plumb) Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt In-Reply-To: Your message of "Mon, 16 Jan 1995 22:29:33 MST." <9501170529.AA15254@nyx10.cs.du.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 17 Jan 1995 10:06:39 -0500 From: "Perry E. Metzger" Colin Plumb says: > Thus, I can make a large number of undetected changes (defined as XORs) > to the first 8 bytes of a message. If I know what they are to start > with, I can possibly change them to desired values. > > Is this a problem? Yup, it is. The working group pretty much felt comfortable with MD5, and I feel a whole lot better with MD5 myself. Overall, the drafts Bill and I are putting out on security transforms are following essentially the transforms discussed in San Jose modulo the question of whole-packet integrity checking rather than just payload integrity checking -- this is as per the IPv6 drafts done by Ran Atkinson. (The overall proposal itself a throwback to the unified proposal agreed to in Toronto, which to my mind is still what the group has consensus on. The security transforms were only discussed in San Jose, so we are following, more or less, the San Jose security transforms which follow Phil Karn's proposals). Anyway, Bill and I have a small disagreement here, but I personally favor writing up the MD5 format for the ESP security-plus-integrity baseline. One legitimate question, of course, might be whether or not we'd be better off with a DES MAC, on the premise that we could gain some performance that way since we are already DES walking the entire packet anyway... Perry From ipsec-request@ans.net Tue Jan 17 04:49:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20400 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 10:13:28 -0500 Received: by interlock.ans.net id AA18663 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 10:02:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 10:02:06 -0500 Message-Id: <199501171502.AA20195@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 10:02:06 -0500 Date: Tue, 17 Jan 95 09:49:45 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: draft-ietf-ipsec-ah-md5-00.txt Ref: Your note of Tue, 17 Jan 95 03:18:15 GMT (attached) From Bill.Simpson@um.cc.umich.edu: > Subject: Re: draft-ietf-ipsec-ah-md5-00.txt > > > Ron Rivest has stated that a shared secret at the front of a message is not > > sufficient for authentication. I thought that I remembered this being > > discussed ath the San Jose IETF. Further, I thought that we agreed that we > > would solve this weakness by puting the shared secret before and after the > > data payload. > > > The appending attack is solved by including the IP Total Length field > in the calculation. Ran explained this. > Just including the length as an authenticated field is NOT enough. To defeat the trivial appending attack on key-prepended MD5 one needs to specify that the length value appears in a FIXED OFFSET from the begining of the information being authenticated (e.g., it is the first value in that information, or appears starting in byte 8, etc.). Otherwise, the attack is still feasible (e.g., if I put the length at the end of the information I can add whatever I want to the authenticated information and at the end I append the *new* length). BTW, MD5 itself, by definition, adds the message length to the end of the authenticated information but as said this doesn't help here. Although prepending keys may have a slight advantage for computation (first block can be pre-processed), I recommend we use appended (or even better, prepended and appended keys). Let's not forget that MD5 was NOT designed as a key-ed authentication function, thus some extra care is advisable. > > > Does anyone else remember this? I seem to remember the discussion causing > > a tanget about "prepend" not being a word. > > > That was me. I remember. The WG minutes do not suggest a decision was > made. I have email from the Area Director recommending we only use > the front, as that is compatible with what other WGs are doing. I recommend other groups change what they are doing if it is not secure enough. Hugo From ipsec-request@ans.net Tue Jan 17 15:46:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06450 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 10:57:32 -0500 Received: by interlock.ans.net id AA16522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 10:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 17 Jan 1995 10:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 10:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 10:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 10:47:03 -0500 Message-Id: <9501171546.AA08821@snark.imsi.com> To: hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: draft-ietf-ipsec-ah-md5-00.txt In-Reply-To: Your message of "Tue, 17 Jan 1995 09:49:45 EST." <199501171502.AA20195@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 17 Jan 1995 10:46:47 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > Just including the length as an authenticated field is NOT enough. > To defeat the trivial appending attack on key-prepended MD5 one > needs to specify that the length value appears in a FIXED OFFSET > from the begining of the information being authenticated (e.g., > it is the first value in that information, or appears starting in > byte 8, etc.). It does. See rfc791 on IP. Total length always occupies the third and fourth octet of the IP header. Perry From ipsec-request@ans.net Tue Jan 17 05:53:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18668 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 11:09:50 -0500 Received: by interlock.ans.net id AA03866 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 10:57:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 10:57:14 -0500 Message-Id: <199501171557.AA44566@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 10:57:14 -0500 Date: Tue, 17 Jan 95 10:53:55 EST From: hugo@watson.ibm.com To: perry@imsi.com Cc: IPSEC@ans.net Subject: draft-ietf-ipsec-ah-md5-00.txt Ref: Your note of Tue, 17 Jan 1995 10:46:47 -0500 (attached) > Subject: Re: draft-ietf-ipsec-ah-md5-00.txt > In-Reply-To: Your message of "Tue, 17 Jan 1995 09:49:45 EST." > <199501171502.AA20195@interlock.ans.net> > Reply-To: perry@imsi.com > X-Reposting-Policy: redistribute only with permission > Date: Tue, 17 Jan 1995 10:46:47 -0500 > From: "Perry E. Metzger" > > > hugo@watson.ibm.com says: > > Just including the length as an authenticated field is NOT enough. > > To defeat the trivial appending attack on key-prepended MD5 one > > needs to specify that the length value appears in a FIXED OFFSET > > from the begining of the information being authenticated (e.g., > > it is the first value in that information, or appears starting in > > byte 8, etc.). > > It does. See rfc791 on IP. Total length always occupies the third and > fourth octet of the IP header. > The minimal thing is to explicitely write in the draft that one is relying on the fixed offset for security; a better thing is not to rely on that and append the key. Hugo From ipsec-request@ans.net Tue Jan 17 16:06:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06440 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 11:18:00 -0500 Received: by interlock.ans.net id AA09682 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 11:06:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 17 Jan 1995 11:06:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 11:06:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 11:06:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 11:06:29 -0500 Message-Id: <9501171606.AA08878@snark.imsi.com> To: hugo@watson.ibm.com Cc: perry@imsi.com, IPSEC@ans.net Subject: Re: draft-ietf-ipsec-ah-md5-00.txt In-Reply-To: Your message of "Tue, 17 Jan 1995 10:53:55 EST." <199501171557.KAA21461@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 17 Jan 1995 11:06:00 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > > It does. See rfc791 on IP. Total length always occupies the third and > > fourth octet of the IP header. > > The minimal thing is to explicitely write in the draft that one is relying > on the fixed offset for security; I have no objections to adding such a comment into our draft. > a better thing is not to rely on that and append the key. Do you think this would really provide a benefit given the specialized nature of the thing we are authenticating (that is, IP packets with explicit lengths)? If this is really a consideration for legitimate cryptographic reasons, I believe the IPv6 working group should also be convinced to alter their spec as they would be vulnerable for precisely the same reasons. What kind of attack do you think could be mounted on the scheme, given the existance of an explicit length? Perry From ipsec-request@ans.net Tue Jan 17 07:47:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23255 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 13:07:12 -0500 Received: by interlock.ans.net id AA42168 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 12:47:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 12:47:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 12:47:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 12:47:30 -0500 Date: Tue, 17 Jan 1995 12:47:25 +0500 From: Theodore Ts'o Message-Id: <9501171747.AA21844@dcl.MIT.EDU> To: perry@imsi.com Cc: hugo@watson.ibm.com, perry@imsi.com, IPSEC@ans.net In-Reply-To: Perry E. Metzger's message of Tue, 17 Jan 1995 11:06:00 -0500, <9501171606.AA08878@snark.imsi.com> Subject: Re: draft-ietf-ipsec-ah-md5-00.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 617 I think we should at the very least put a comment into the draft. I'm not a cryptographyer, so I don't know if there are any inherent advantages to putting the key at both the beginning and the end, as opposed to just simply putting length near the beginning --- however, one good thing about doing it "right" is that if someone ever lifts this code, or the assumptions change (I don't know enough about IPv6 to know whether or not this is likely), we won't need to rely on someone remember that we made this assumption, and that we now need to do something different now that this assumption is gone. - Ted From ipsec-request@ans.net Tue Jan 17 10:19:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23410 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 15:46:07 -0500 Received: by interlock.ans.net id AA49343 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 15:33:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 15:33:51 -0500 Message-Id: <199501172033.AA22971@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 15:33:51 -0500 Date: Tue, 17 Jan 95 15:19:55 EST From: hugo@watson.ibm.com To: perry@imsi.com Cc: IPSEC@ans.net Subject: draft-ietf-ipsec-ah-md5-00.txt Ref: Your note of Tue, 17 Jan 1995 11:06:00 -0500 (attached) To your question below: I do not know of any attack in prepended MD5 if you fix the position of the length parameter (relative to the begining of the information). However, I want to prevent what Ted Ts'o pointed to very clearly: I'm not a cryptographyer, so I don't know if there are any inherent advantages to putting the key at both the beginning and the end, as opposed to just simply putting length near the beginning --- however, one good thing about doing it "right" is that if someone ever lifts this code, or the assumptions change (I don't know enough about IPv6 to know whether or not this is likely), we won't need to rely on someone remember that we made this assumption, and that we now need to do something different now that this assumption is gone. THat is, the security being given by the length is somewhat fragile in the sense that the position of the length parameter is indpendent of the security function (it was chosen by IP not by IPSEC). This will let people forget/overlook its security role, and this invites troubles. The key appended to the end provides an explicit security mechanism. Beyond this let me stress that I do not know of any serious cryptanalysis work against MD5 as keyed authentication function. MD5 was created with a very different goal, namely, being a collision free (or one-way) hash function. The serious cryptanalysis efforts I am aware of were directed to find collisions. But that property says nothing about its quality as authentication function. Therefore, as I said in my original note: some extra care is advisable. > From: "Perry E. Metzger" > > > hugo@watson.ibm.com says: > > > It does. See rfc791 on IP. Total length always occupies the third and > > > fourth octet of the IP header. > > > > The minimal thing is to explicitely write in the draft that one is relying > > on the fixed offset for security; > > I have no objections to adding such a comment into our draft. > > > a better thing is not to rely on that and append the key. > > Do you think this would really provide a benefit given the specialized > nature of the thing we are authenticating (that is, IP packets with > explicit lengths)? If this is really a consideration for legitimate > cryptographic reasons, I believe the IPv6 working group should also be > convinced to alter their spec as they would be vulnerable for > precisely the same reasons. What kind of attack do you think could be > mounted on the scheme, given the existance of an explicit length? > > Perry From ipsec-request@ans.net Tue Jan 17 17:20:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18638 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 17:20:23 -0500 Received: by interlock.ans.net id AA07015 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 17:06:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 17:06:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 17:06:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 17:06:34 -0500 Date: Tue, 17 Jan 95 13:54:45 From: "Housley, Russ" Encoding: 883 Text Message-Id: <9500177903.AA790379685@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt Bill: > Now, we have to agree on which other transforms to write up! I favor > triple DES, and DES-CBC with CRC. > > Perry likes MD5 instead of CRC, but I think that the CRC would improve >speed, and be good enough when encrypted afterward. > > What do you think? Selecting a combined confidentiality and integrity function when trying to minimize the incremental work above the encryption function is very tricky. For this reason, we should be very careful, and I recommend following the lead of the GSS API folks. They are using sum64-DES-CBC. It is very similar to the CBCC that I discussed on this list a few months ago except that the XOR sum is replaced by the ((mod 2**64)-1) sum. This is trivial in software, but I do not know of any hardware that supports it. Have you looked at the new GSS API stuff produced by Northern Telecom? Russ From ipsec-request@ans.net Tue Jan 17 11:39:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13020 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 17:22:56 -0500 Received: by interlock.ans.net id AA24217 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 17:08:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 17:08:54 -0500 Message-Id: <199501172208.AA11925@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 17:08:54 -0500 Date: Tue, 17 Jan 95 16:39:33 EST From: hugo@watson.ibm.com To: perry@imsi.com, colin@nyx10.cs.du.edu Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: draft-ietf-ipsec--00.txt Ref: Your note of Tue, 17 Jan 1995 10:06:39 -0500 (attached) > > Colin Plumb says: > > Thus, I can make a large number of undetected changes (defined as XORs) > > to the first 8 bytes of a message. If I know what they are to start > > with, I can possibly change them to desired values. > > > > Is this a problem? > > Yup, it is. The working group pretty much felt comfortable with MD5, > and I feel a whole lot better with MD5 myself. > The paper "Message Authentication", by Jueneman, Matyas and Meyer, IEEE Comm. Magazine, Vol 23, No.9, 9/85, pp. 29-40 contains more examples of this type of attacks. In different variations (and different levels of relevance), these attacks apply to *all* methods of authentication that are based on computing a checksum using a *known* function (e.g., the CRC with known polynomial or MD5 without keys), appending that checksum to the transmitted information and finally encrypting everything together under a CBC mode. (See page 36 of the paper, column 2; these known checksum functions are referred to in the paper as "MDC".) Many of these attacks require chosen plaintext and other things to make the life of the adversary easier. However, as the paper states, a good authentication function shouldn't be suceptible to theses attacks. Even if in all specific scenarios we can think of today these attacks seem unrealistic, Murphy will create those scenarios tomorow (or yesterday). A simple example of an attack (not from the paper) is as follows. (I use CRC, but as said any un-keyed function will do). Let's say that A posts a file in some server that is to be retrieved by other people. When B asks for the file the servers authenticates it and sends to B. Now A (here for Adversary) is interested that when C asks for the file she gets only a prefix of it, say first 100 bytes. For that, before posting the file, A computes the value of the CRC on the first 100 bytes and adds this value to the file following these 100 bytes. After that A concatenates the rest of the file, and posts it to the server. Clearly, when the file is transmitted to C (encrypted under the key between C and the server which A does not know), A can intercept it, and relay to C only the 104 bytes prefix which is legally authenticated! Is this a problem??? Not necessarily. Who will want to do that? What about length parameters appended to the authentication? What about the meaning of the CRC in the middle of the file for somebody that get it all? A lot of valid questions; however, a good authentication function shouldn't allow for such weaknesses. As usual, we are in a business of trade-offs and we may decide that this is good enough for IPSEC, but we still have to be aware of the limitations of these techniques. And make notes of it in the proposals/drafts. Hugo PS: Perry, when you say MD5 you mean key-ed MD5 or regular MD5. From ipsec-request@ans.net Tue Jan 17 17:23:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13025 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 17:23:22 -0500 Received: by interlock.ans.net id AA27282 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 17:08:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 17:08:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 17:08:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 17:08:17 -0500 Date: Tue, 17 Jan 95 13:54:38 From: "Housley, Russ" Encoding: 534 Text Message-Id: <9500177903.AA790379678@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: draft-ietf-ipsec--00.txt Perry: > One legitimate question, of course, might be whether or not we'd be > better off with a DES MAC, on the premise that we could gain some > performance that way since we are already DES walking the entire packet > anyway... I do not recall the source, but my recollection is that it is not a good idea to use DES MAC and DES CBC with the same key. If you use two different keys, ont fro DES MAC and one for DES CBC, then there are no security concerns. Of couse, this raises some performance concerns. Russ From ipsec-request@ans.net Tue Jan 17 08:23:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17836 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 17:48:09 -0500 Received: by interlock.ans.net id AA03709 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 17:26:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 17:26:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 17:26:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 17:26:04 -0500 Date: Tue, 17 Jan 95 15:23:56 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501172223.AA29742@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: draft-ietf-ipsec-ah-md5-00.txt Theodore T'so wrote: > I think we should at the very least put a comment into the draft. > I'm not a cryptographyer, so I don't know if there are any inherent > advantages to putting the key at both the beginning and the end, as > opposed to just simply putting length near the beginning Well, I *am* a cryptographer (it's kind of scary that I've stopped hedging that statement - there's a second phase of skill development where one is no longer as scared of screwing up and so gets sloppy and... screws up more) and I'm not seeing wht prepend & append would have any value. My rule is that as long as the bit string being hashed is uniquely parseable (in theory, even if it's very difficult in practice), then the hash can be considered to apply to the parsed structure. Now, is there something about the bit string that is hashed that invokes this rule without the appending (i.e. it is *not* uniquely parseable), or is thre some other gotcha that was pointed out that I should be aware of? Enlightenment would be appreciated so I can contribute more. Oh, BTW... a CRC *is* a secure MAC if the polynomial and the MAC are unknown to an attacker. Given a few messages and MACs, it is easy to find the GCD, which is the polynomial, but without, it's guesswork. (This is from the folks who did the Strongbox secure loader at CMU - they needed a *fast* secure hash.) -- -Colin From ipsec-request@ans.net Tue Jan 17 22:48:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17678 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 18:03:14 -0500 Received: by interlock.ans.net id AA08078 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 17:48:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 Jan 1995 17:48:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 17:48:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 17:48:44 -0500 Date: Tue, 17 Jan 1995 15:48:31 -0700 From: Hilarie Orman Message-Id: <199501172248.PAA09309@umbra.CS.Arizona.EDU> To: housley@spyrus.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9500177903.AA790379678@spysouth.spyrus.com> Subject: Re: draft-ietf-ipsec--00.txt > I do not recall the source, but my recollection is that it is not a good idea to > use DES MAC and DES CBC with the same key. If you use two different keys, ont > fro DES MAC and one for DES CBC, then there are no security concerns. > this raises some performance concerns. You might be thinking of the papers by Stubblebine and Gligor in the Oakland Security and Privacy symposia. These should give great pause to anyone attempting to combine related algorithms with the same key. And to the idea of using CRC. From ipsec-request@ans.net Tue Jan 17 13:00:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06637 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 18:35:19 -0500 Received: by interlock.ans.net id AA41106 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 18:20:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 18:20:39 -0500 Message-Id: <199501172320.AA19852@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 18:20:39 -0500 Date: Tue, 17 Jan 95 18:00:16 EST From: hugo@watson.ibm.com To: colin@nyx10.cs.du.edu Cc: IPSEC@ans.net Subject: draft-ietf-ipsec-ah-md5-00.txt Ref: Your note of Tue, 17 Jan 95 15:23:56 MST (attached) > > Oh, BTW... a CRC *is* a secure MAC if the polynomial and the MAC are > unknown to an attacker. Given a few messages and MACs, it is easy to > find the GCD, which is the polynomial, but without, it's guesswork. > (This is from the folks who did the Strongbox secure loader at CMU - > they needed a *fast* secure hash.) > -- > -Colin Colin, This statement, even if true, may confuse people. As you said, the MAC (and polynomial) needs to be *unknown* to an attacker to be secure; and then this is irrelevant to the IPSEC scenario where one needs to transmit its value. MOREOVER, even if you encrypt under a perfect one-time pad the CRC value before transmitting (i.e., perfect encryption) then this authentication is *not* secure. To make it secure you must append a number of zeros to the message as the length of CRC before doing the polynomial division (or another equivalent shift operation). For details, see my paper "LFSR-based hashing and authentication" in Crypto'94. Hugo From ipsec-request@ans.net Tue Jan 17 13:22:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06484 (5.65c/IDA-1.4.4 for ); Tue, 17 Jan 1995 18:50:49 -0500 Received: by interlock.ans.net id AA08002 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 Jan 1995 18:36:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Jan 1995 18:36:43 -0500 Message-Id: <199501172336.AA07998@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Jan 1995 18:36:43 -0500 Date: Tue, 17 Jan 95 18:22:19 EST From: hugo@watson.ibm.com To: housley@spyrus.com, perry@imsi.com Cc: ipsec@ans.net Subject: draft-ietf-ipsec--00.txt Ref: Your note of Tue, 17 Jan 95 13:54:38 (attached) > > > One legitimate question, of course, might be whether or not we'd be > > better off with a DES MAC, on the premise that we could gain some > > performance that way since we are already DES walking the entire packet > > anyway... > > I do not recall the source, but my recollection is that it is not a good idea to > use DES MAC and DES CBC with the same key. If you use two different keys, ont > fro DES MAC and one for DES CBC, then there are no security concerns. Of couse, > this raises some performance concerns. > > Russ Using CBC and MAC with the same key is clearly insecure (except if I misunderstand what you mean by this). DES-MAC is defined as the last block (or bits) of the encryption under CBC. Therefore, by using the same key, your authentication results in repeating the last block of the ciphertext, but then changing the ciphertext to *anything* and then appending the last (possibly modified) block as checsum will be undetected. Notice that appending the MAC to the message and encrypting this MAC together with the rest will not help: you'll be always appending a fixed value: DES(0)! Hugo From ipsec-request@ans.net Wed Jan 18 18:28:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17024 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 15:57:24 -0500 Received: by interlock.ans.net id AA10597 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 15:41:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 15:41:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 15:41:05 -0500 Date: Wed, 18 Jan 95 18:28:18 GMT From: "William Allen Simpson" Message-Id: <1236.bill.simpson@um.cc.umich.edu> To: IPSEC@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: draft-ietf-ipsec-ah-md5-00.txt > From: Theodore Ts'o > I think we should at the very least put a comment into the draft. > > whether or not this is likely), we won't need to rely on someone > remember that we made this assumption, and that we now need to do > something different now that this assumption is gone. > This is a fine idea of text to include, and I will be sure to add it to the security considerations on the next pass. Thank you for your review. Since no other comments have been received on this draft, and new drafts with DES are being proposed, may I assume that we are ready to go forward with it? Is there anyone in the WG who opposes this MD5 transform (as the REQUIRED _BASIC_ one of the many transforms that we will write)? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Jan 18 22:10:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23336 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 17:17:39 -0500 Received: by interlock.ans.net id AA45539 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 17:10:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 17:10:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 17:10:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 17:10:54 -0500 Date: Wed, 18 Jan 1995 15:10:45 -0700 From: Hilarie Orman Message-Id: <199501182210.PAA27224@umbra.CS.Arizona.EDU> To: ipsec@ans.net Subject: triple DES What is the usual method for doing triple DES with CBC? From ipsec-request@ans.net Wed Jan 18 22:49:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21052 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 17:53:43 -0500 Received: by interlock.ans.net id AA52410 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 17:50:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 18 Jan 1995 17:50:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 17:50:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 17:50:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 17:50:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 17:50:02 -0500 From: uri@watson.ibm.com Message-Id: <9501182249.AA19733@buoy.watson.ibm.com> Subject: Re: triple DES To: ho@cs.arizona.edu (Hilarie Orman) Date: Wed, 18 Jan 1995 17:49:57 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199501182210.PAA27224@umbra.CS.Arizona.EDU> from "Hilarie Orman" at Jan 18, 95 03:10:45 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: 221 Hilarie Orman says: > What is the usual method for doing triple DES with CBC? The best way is: P[n] XOR C[n-1] -> Ek1 -> Dk2 -> Ek1 == C[n] -- Regards, Uri uri@watson.ibm.com N2RIU ----------- From ipsec-request@ans.net Wed Jan 18 23:02:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18681 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:14:30 -0500 Received: by interlock.ans.net id AA50314 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:04:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 18:04:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 18:04:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:04:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:04:16 -0500 Date: Wed, 18 Jan 1995 15:02:12 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9501182302.AA19998@miraj.> To: ipsec@ans.net, ho@cs.arizona.edu Subject: Re: triple DES X-Sun-Charset: US-ASCII > From ipsec-request@ans.net Wed Jan 18 14:44 PST 1995 > > What is the usual method for doing triple DES with CBC? > The way we do this is to do Encrypt-Decrypt-Encrypt with three keys in ECB mode, and use the resulting ECB cipher in CBC mode. One can also do 2-key triple DES, where the first and last encryption keys are the same, the decryption key being different. Note that if all three keys are the same, you effectively get single encryption DES (at roughly one-third the speed). Ashar. From ipsec-request@ans.net Wed Jan 18 22:59:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22526 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:14:34 -0500 Received: by interlock.ans.net id AA41061 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:01:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:01:08 -0500 Message-Id: <9501182259.AA02800@snark.imsi.com> To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: triple DES In-Reply-To: Your message of "Wed, 18 Jan 1995 15:10:45 MST." <199501182210.PAA27224@umbra.CS.Arizona.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 18 Jan 1995 17:59:55 -0500 From: "Perry E. Metzger" Hilarie Orman says: > What is the usual method for doing triple DES with CBC? Generally, an encrypt pass is followed by a decrypt pass and followed by another encrypt pass. The three passes are run "independantly", that is, as though a single plaintext was first encrypted in its entirety in the first key, then decrypted with the second key, then encrypted with the third -- phrased another way, the block chaining is within each pass rather than between the passes. If the first and second keys are set to be the same (or second and third), this is equivalent to normal DES with the other key -- which is useful in hardware 3DES implementations that need occassional compatibility with DES. Perry From ipsec-request@ans.net Wed Jan 18 23:13:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22424 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:26:52 -0500 Received: by interlock.ans.net id AA08007 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:13:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:13:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:13:46 -0500 Date: Wed, 18 Jan 1995 18:13:40 -0500 From: John Ioannidis Message-Id: <199501182313.SAA02329@cs.columbia.edu> To: ho@cs.arizona.edu, ipsec@ans.net Subject: Re: triple DES You use 3DES as your basic block cipher, and CBC the results. In other words, C_{i+1} = 3DES(P_{i+1} \xor C_{i}) /ji From ipsec-request@ans.net Wed Jan 18 23:40:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12858 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:44:41 -0500 Received: by interlock.ans.net id AA24520 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:41:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 18:41:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 18:41:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:41:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:41:03 -0500 Message-Id: <9501182340.AA02860@snark.imsi.com> To: uri@watson.ibm.com Cc: ho@cs.arizona.edu (Hilarie Orman), ipsec@ans.net Subject: Re: triple DES In-Reply-To: Your message of "Wed, 18 Jan 1995 17:49:57 EST." <9501182249.AA19733@buoy.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 18 Jan 1995 18:40:02 -0500 From: "Perry E. Metzger" uri@watson.ibm.com says: > Hilarie Orman says: > > What is the usual method for doing triple DES with CBC? > > The best way is: P[n] XOR C[n-1] -> Ek1 -> Dk2 -> Ek1 == C[n] A compact way to express it! I'll be stealing it for the draft! Perry From ipsec-request@ans.net Wed Jan 18 23:49:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13963 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:53:13 -0500 Received: by interlock.ans.net id AA24404 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:50:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 18:50:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 18:50:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:50:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:50:12 -0500 Message-Id: <9501182349.AA02904@snark.imsi.com> To: Hilarie Orman , ipsec@ans.net Subject: Re: triple DES In-Reply-To: Your message of "Wed, 18 Jan 1995 17:59:55 EST." <9501182259.AA02800@snark.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 18 Jan 1995 18:49:41 -0500 From: "Perry E. Metzger" "Perry E. Metzger" says: > The three passes are run "independantly", > that is, as though a single plaintext was first encrypted in its > entirety in the first key, then decrypted with the second key, then > encrypted with the third -- phrased another way, the block chaining is > within each pass rather than between the passes. I realized that I completely botched explaining this. All the mathematical descriptions are far better than my english, which was merely trying to convey that you don't try to CBC between E_k1, E_k2 and E_k3; pay attention to everyone else's one liners, they make it much clearer. Perry From ipsec-request@ans.net Wed Jan 18 23:54:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22712 (5.65c/IDA-1.4.4 for ); Wed, 18 Jan 1995 18:59:08 -0500 Received: by interlock.ans.net id AA38582 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 18 Jan 1995 18:56:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 18 Jan 1995 18:56:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 18 Jan 1995 18:56:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 18 Jan 1995 18:56:13 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 18 Jan 1995 18:56:13 -0500 Message-Id: <9501182354.AA02915@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: triple DES In-Reply-To: Your message of "Wed, 18 Jan 1995 15:02:12 PST." <9501182302.AA19998@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 18 Jan 1995 18:54:36 -0500 From: "Perry E. Metzger" Ashar Aziz says: > The way we do this is to do Encrypt-Decrypt-Encrypt with three > keys in ECB mode, and use the resulting ECB cipher in CBC > mode. One can also do 2-key triple DES, where the first and > last encryption keys are the same, the decryption key being > different. Note that if all three keys are the same, you > effectively get single encryption DES (at roughly one-third > the speed). In general, you want this feature last feature when you are in a hardware implementation emulating ordinary DES with 3DES hardware (and this has in fact been done) so it isn't entirely nonsensical to do it. BTW, all three keys don't have to be the same -- just k1 and k2 or k2 and k3, though in practice there is no reason not to just make them all the same. Perry From ipsec-request@ans.net Tue Jan 24 14:02:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22707 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 09:18:35 -0500 Received: by interlock.ans.net id AA41537 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 09:11:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 09:11:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 09:11:43 -0500 Date: Tue, 24 Jan 95 14:02:41 GMT From: "William Allen Simpson" Message-Id: <3770.bill.simpson@um.cc.umich.edu> To: IPSEC@ans.net Reply-To: bsimpson@morningstar.com Subject: AH-MD5 > Date: Wed, 18 Jan 95 18:28:18 GMT > From: "William Allen Simpson" > Is there anyone in the WG who opposes this MD5 transform (as the > REQUIRED _BASIC_ one of the many transforms that we will write)? > Hearing no objections -- delighted that the WG has come to quiet consensus. I am adding the text requested by Ted and others. New draft in the next few days. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Jan 24 14:06:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22713 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 09:18:57 -0500 Received: by interlock.ans.net id AA07494 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 09:11:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 09:11:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 09:11:45 -0500 Date: Tue, 24 Jan 95 14:06:52 GMT From: "William Allen Simpson" Message-Id: <3771.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: triple DES The only suggestion for our DES draft is to have more implementation notes. We will have them done in a few days. Since there are no other objections to the DES CBC draft, Perry and I will now bring out a second draft for _optional_ triple DES, using the same format. Thank you for your support! Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Jan 24 04:56:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16307 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 10:01:28 -0500 Received: by interlock.ans.net id AA39776 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 09:56:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 24 Jan 1995 09:56:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 24 Jan 1995 09:56:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 09:56:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 09:56:32 -0500 Date: Tue, 24 Jan 95 09:56:21 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9501241456.AA03775@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 09:56:32 -0500 To: ipsec@ans.net Subject: ICMP messages document Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission I'm working on getting out the ICMP messages document for ESP and AH induced error conditions. Its largely straightforward, but I thought I'd solicit community input. If anyone has any prior art that they think I should be examining, or at least referencing in my document, please let me know. Perry From ipsec-request@ans.net Tue Jan 24 13:40:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21183 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 18:49:02 -0500 Received: by interlock.ans.net id AA38670 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 18:45:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 18:45:20 -0500 Message-Id: <199501242345.AA38666@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 18:45:20 -0500 Date: Tue, 24 Jan 95 18:40:52 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com, IPSEC@ans.net Cc: jis@mit.edu Subject: AH-MD5 Ref: Your note of Tue, 24 Jan 95 14:02:41 GMT >> Hearing no objections -- delighted that the WG has come to quiet >> consensus. Just to break the *quiet* consenus: I personally would prefer to see a prepend+append MD5 for IP authentication. The reasons are a more robust security design, less plausible to suffer yet unknown vulnerabilities or implementation errors, at a very low cost compared to prepend only (notice that MD5, by definition, APPends the length of the information and I didn't see any claims that this causes any significant degradation in performance). However, I am not going to "fight" for this if the rest of the group feels comfortable with the prepend solution. Moreover, I do think that this kind of decisions need to involve the security area directorate, especially since the question of which keyed-MD5 mode to use touches almost every security-related WG in IETF, and not just specific to IPSEC. (BTW, In San Jose, in the SAAG meeting (at least in the minutes) it was reported that an rfc on keyed MD5 will be written, and the existence of a "vulnerability" was mentioned. Unfortunately I got no response from the people I asked about the status of this document or the kind of vulnerabilty they referred to.) In my opinion, if the IETF goes for a "standard" prepend-MD5 they should define explicitely that the length parameter is prepended to the computation (say after the key) and not left to the "luck" of having or not the length in a fixed offset in the information (as it "happens" to be in the IP header). Otherwise, we are inviting troubles by misuse of the function (I must say that in some Internet drafts the need of the length is made explicit but NOT the necessity of this length appearing in the beginning - or at a fixed offset from the beginning - of the MD5-ed information). Append only is also an alternative (that does not require the length specification and then more robust for secure implementation) However, it is not necessarily more secure for authentication than the prepend (key+length) option. For example, if collisions are found in MD5 it would immediately break the append mode but not necessarily the prepend. Theoretically, even the prepend+append could be breakable while the prepend-only or append-only not (e.g., an attack on MD5 that works only on information starting and ending with the same string), but this is highly improbable. Hugo From ipsec-request@ans.net Wed Jan 25 00:16:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11557 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 19:19:16 -0500 Received: by interlock.ans.net id AA27115 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 19:16:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 24 Jan 1995 19:16:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 24 Jan 1995 19:16:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 19:16:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 19:16:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 19:16:30 -0500 From: uri@watson.ibm.com Message-Id: <9501250016.AA24628@buoy.watson.ibm.com> Subject: Re: AH-MD5 To: hugo@watson.ibm.com Date: Tue, 24 Jan 1995 19:16:25 -0500 (EST) Cc: bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu In-Reply-To: <199501242345.AA38666@interlock.ans.net> from "hugo@watson.ibm.com" at Jan 24, 95 06:40:52 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: 1723 hugo@watson.ibm.com says: > >> Hearing no objections -- delighted that the WG has come to quiet > >> consensus. > Just to break the *quiet* consenus: I personally would prefer to > see a prepend+append MD5 for IP authentication. > The reasons are a more robust security design, less plausible to > suffer yet unknown vulnerabilities or implementation errors, at > a very low cost compared to prepend only (notice that MD5, by definition, > APPends the length of the information and I didn't see any claims > that this causes any significant degradation in performance). I support this proposal. However I too don't think it's crucial. So - if you'd like to buy some extra security cheap, prepend and append the key. If you don't care - probably you're still OK but... > Moreover, I do think that this kind of decisions need to involve the > security area directorate, especially since the question of which > keyed-MD5 mode to use touches almost every security-related WG in IETF, > and not just specific to IPSEC. Well, in some cases (like SNMP I'm familiar with), the message is encoded in ASN.1 and MD5 runs over the whole thing (with the key somewhere inside the packet), then the key is substituted for the digest obtained and the packet is sent out. Thus no exposure here. Other users may find themselves in less secure position. > Theoretically, even the prepend+append could be breakable > while the prepend-only or append-only not (e.g., an attack on MD5 > that works only on information starting and ending with the same string), > but this is highly improbable. (:-) I'd be afraid rather of Birthday Paradox attack... (2^64) -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Jan 25 01:32:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14967 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 20:33:33 -0500 Received: by interlock.ans.net id AA35489 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 20:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 20:30:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 20:30:22 -0500 Date: Tue, 24 Jan 1995 17:32:22 -0800 From: Phil Karn Message-Id: <199501250132.RAA09873@servo.qualcomm.com> To: hugo@watson.ibm.com Cc: bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu In-Reply-To: <199501242345.AA38666@interlock.ans.net> (hugo@watson.ibm.com) Subject: Re: AH-MD5 Didn't we already agree to MD5(key+data+key)? It's no big deal... Phil From ipsec-request@ans.net Wed Jan 25 01:44:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18894 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 20:46:38 -0500 Received: by interlock.ans.net id AA08997 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 20:42:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 20:42:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 20:42:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 20:42:05 -0500 Message-Id: <9501250147.AA16447@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Jan 1995 20:44:12 -0500 To: hugo@watson.ibm.com, bsimpson@morningstar.com, IPSEC@ans.net From: hughes@hughes.network.com (James P Hughes) Subject: Re: AH-MD5 Cc: jis@mit.edu At 6:40 PM 1/24/95 -0500, hugo@watson.ibm.com wrote: >Ref: Your note of Tue, 24 Jan 95 14:02:41 GMT > >>> Hearing no objections -- delighted that the WG has come to quiet >>> consensus. When the signal to noise ratio gets to low, people stop listening. This is not consensus, it is simply quiet. >Just to break the *quiet* consenus: I personally would prefer to >see a prepend+append MD5 for IP authentication. I agree 100%, I would much rather have a MD5 hash that is irregardless of the content of the packet, header or psudo header or whatever. It is my opinion that prepend and append of the hash with the key is simple, inexpensive, as well as elegant and prone -not- to be weakened by future protocol changes. If the IETF voted, I would vote for prepend and append, but mine is but a single voice...... 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 Wed Jan 25 01:45:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18380 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 20:46:37 -0500 Received: by interlock.ans.net id AA16969 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 20:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 20:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 20:43:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 20:43:50 -0500 Message-Id: <9501250148.AA16586@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Jan 1995 20:45:47 -0500 To: Phil Karn , hugo@watson.ibm.com From: hughes@hughes.network.com (James P Hughes) Subject: Re: AH-MD5 Cc: bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu At 5:32 PM 1/24/95 -0800, Phil Karn wrote: >Didn't we already agree to MD5(key+data+key)? It's no big deal... I thought that we did... No big deal... 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 Wed Jan 25 02:31:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22870 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 21:34:57 -0500 Received: by interlock.ans.net id AA38815 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 21:32:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 21:32:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 21:32:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 21:32:06 -0500 Date: Tue, 24 Jan 1995 19:31:56 -0700 From: Hilarie Orman Message-Id: <199501250231.TAA02316@umbra.CS.Arizona.EDU> To: karn@qualcomm.com Cc: IPSEC@ans.net In-Reply-To: Yourmessage <199501250132.RAA09873@servo.qualcomm.com> Subject: Re: AH-MD5 > Didn't we already agree to MD5(key+data+key)? It's no big deal... It's only a big deal in that the collective we did agree and still agree. I think the document should reflect this decision. From ipsec-request@ans.net Tue Jan 24 16:43:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17340 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 21:46:27 -0500 Received: by interlock.ans.net id AA13620 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 21:44:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 21:44:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 21:44:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 21:44:11 -0500 Date: Tue, 24 Jan 1995 21:43:53 +0500 From: Theodore Ts'o Message-Id: <9501250243.AA08095@dcl.MIT.EDU> To: hughes@hughes.network.com Cc: hugo@watson.ibm.com, bsimpson@morningstar.com, IPSEC@ans.net, jis@MIT.EDU In-Reply-To: James P Hughes's message of Tue, 24 Jan 1995 20:44:12 -0500, <9501250147.AA16447@hughes.network.com> Subject: Re: AH-MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 193 Here's another "me too"; I'd personally feel a lot safer with a prepend and postpend of the MD5 key. Is there some strong objection to this, or should we just go ahead and do it? - Ted From ipsec-request@ans.net Wed Jan 25 04:17:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20061 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 23:23:09 -0500 Received: by interlock.ans.net id AA13814 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 23:18:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 24 Jan 1995 23:18:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 23:18:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 23:18:44 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 23:18:44 -0500 Message-Id: <9501250417.AA14544@snark.imsi.com> To: Phil Karn Cc: hugo@watson.ibm.com, bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu Subject: Re: AH-MD5 In-Reply-To: Your message of "Tue, 24 Jan 1995 17:32:22 PST." <199501250132.RAA09873@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 24 Jan 1995 23:17:54 -0500 From: "Perry E. Metzger" Phil Karn says: > Didn't we already agree to MD5(key+data+key)? It's no big deal... I don't see that its needed (since we are authenticating the whole packet including length) but if people can rationally convince me that the security would be improved by postpending (yuck! thats not a word) I'll go along. Perry From ipsec-request@ans.net Wed Jan 25 04:27:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19326 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 23:30:58 -0500 Received: by interlock.ans.net id AA25949 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 23:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 24 Jan 1995 23:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 23:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 23:28:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 23:28:31 -0500 Message-Id: <9501250427.AA14556@snark.imsi.com> To: "Theodore Ts'o" Cc: hughes@hughes.network.com, hugo@watson.ibm.com, bsimpson@morningstar.com, IPSEC@ans.net, jis@MIT.EDU Subject: Re: AH-MD5 In-Reply-To: Your message of "Tue, 24 Jan 1995 21:43:53 +0500." <9501250243.AA08095@dcl.MIT.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 24 Jan 1995 23:27:58 -0500 From: "Perry E. Metzger" "Theodore Ts'o" says: > Here's another "me too"; I'd personally feel a lot safer with a prepend > and postpend of the MD5 key. > > Is there some strong objection to this, or should we just go ahead and > do it? My only objection is that it feels very much like it just gives people warm fuzzies without any rational need for it -- since we are including the length of the packet in the protected area, we are not susceptible to appending attacks. It also wastes CPU. If people insist, however, I suppose it will go the way the bulk of people want. I'd still like to hear a solidly rational reason for it beyond that it makes people feel better. Remember that this is NOT the same sort of situation as keyed-MD5 without a protected length field. I'm not trying to denegrate anyone here, by the way -- you, Hugo, and others who have asked for this are all high on my list of people I esteem in the working group. In this case, though, I'd feel better if someone gave me a cryptographically based argument for appending the key. Perry From ipsec-request@ans.net Wed Jan 25 04:47:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21008 (5.65c/IDA-1.4.4 for ); Tue, 24 Jan 1995 23:51:23 -0500 Received: by interlock.ans.net id AA25856 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 24 Jan 1995 23:47:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 24 Jan 1995 23:47:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 24 Jan 1995 23:47:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 24 Jan 1995 23:47:38 -0500 Date: Tue, 24 Jan 1995 21:47:32 -0700 From: Hilarie Orman Message-Id: <199501250447.VAA07103@umbra.CS.Arizona.EDU> To: perry@imsi.com Cc: IPSEC@ans.net In-Reply-To: Yourmessage <9501250427.AA14556@snark.imsi.com> Subject: Re: AH-MD5 > ... if someone gave me a cryptographically based argument for > appending the key. It's not cryptography so much as secure software engineering, I think. In practice that's just as important as sound mathematics. From ipsec-request@ans.net Tue Jan 24 17:59:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22301 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 03:06:13 -0500 Received: by interlock.ans.net id AA41879 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 02:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 02:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 02:59:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 02:59:32 -0500 Date: Wed, 25 Jan 95 00:59:23 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501250759.AA16891@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: AH-MD5 In some (purely paper, so far) protocols I've played with, I prepend the key when hashing, but prepend+append seems safe and sounds good. I wouldn't mind, though, if someone could describe the possible hole if you don't do this. Did it assume no length was appended in the last block? -- -Colin From ipsec-request@ans.net Wed Jan 25 14:06:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20192 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 09:23:11 -0500 Received: by interlock.ans.net id AA53024 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 09:13:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 09:13:30 -0500 From: Ran Atkinson Message-Id: <9501250906.ZM1877@bodhi.nrl.navy.mil> Date: Wed, 25 Jan 1995 09:06:40 -0500 In-Reply-To: hugo@watson.ibm.com "AH-MD5" (Jan 24, 18:40) References: <199501242345.AA38666@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Use of Keyed MD5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Folks, It is NOT accurate to state that a "vulnerability" was discussed by the Security Directorate. I mentioned that Russ Housely had sent me an email expressing concern about the use of MD5, nothing more. To my knowledge (and I have mostly been in the loop), there is no known vulnerability. It is true that MD5 was designed as a message digest function and not for cryptographic authentication in the manner becoming commonplace within the IETF. I believe that an Informational RFC on the use of keyed MD5 for authentication is a good idea and I think one is likely to appear. The only statements I've seen have been of the form that (1) if no length field is present at a fixed location, then appending attacks might be possible (Both IPv4 and IPv6 have length fields in fixed locations) (2) use of prepend-only might not be not desirable with IP because, in the words of Eric Rains, "This has the effect that a large block of bits at the beginning of the data fed to the digester [i.e. algorithm] will likely be the same for every packet involved in a communication, with the exception of the payload length." However, this is not a problem as long as we believe that it is not computationally feasible to invert the particular algorithm (in our case MD5) and determine the secret key. I am not aware of any work that would lead us to believe that it is computationally feasible to invert MD5. Further, the work of Joe Touch indicates that MD5 might be hard to parallelise, so the existence of systems such as the Connection Machine are less of a factor wrt computational feasibility. (3) Both prepending and appending the secret key significantly increases the entropy of the result of the hash. It can also be significantly more expensive to compute the hash because one cannot cache the appended computation. Prepended keys can enable a system to precompute (once) the initial part of the computation and thereby possibly speed up the processing of packets. Given the experimental evidence from Hilarie Orman, this is a serious issue to consider. I believe this is the ENTIRE dataset on this matter. If people have specific detailed comments, suggestions, or data that they are willing to backup on this list, then please present it so that the group can consider it. Best Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Jan 25 06:09:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14018 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 11:29:12 -0500 Received: by interlock.ans.net id AA56145 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 11:25:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 11:25:21 -0500 Message-Id: <199501251625.AA19021@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 11:25:21 -0500 Date: Wed, 25 Jan 95 11:09:09 EST From: hugo@watson.ibm.com To: ho@cs.arizona.edu, perry@imsi.com Cc: IPSEC@ans.net Subject: AH-MD5 Ref: Your note of Tue, 24 Jan 1995 21:47:32 -0700 (attached) Perry, this is THE answer! > ... if someone gave me a cryptographically based argument for > appending the key. ************************************************************************* * It's not cryptography so much as secure software engineering, I think.* * In practice that's just as important as sound mathematics. * ************************************************************************* (Thanks, Hillarie, for the perfect phrasing). Also, if you read my original note it says: In my opinion, if the IETF goes for a "standard" prepend-MD5 they should define explicitely that the length parameter is prepended to the computation (say after the key) and not left to the "luck" of having or not the length in a fixed offset in the information (as it "happens" to be in the IP header). If you do that, then my objection is gone. (Still my cryptographic feelings are inclined to prepend+append but then the extra computation -even if quite insignificant- is harder to justify). Hugo From ipsec-request@ans.net Wed Jan 25 06:29:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18457 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 11:36:36 -0500 Received: by interlock.ans.net id AA58836 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 11:34:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 11:34:30 -0500 Message-Id: <199501251634.AA58832@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 11:34:30 -0500 Date: Wed, 25 Jan 95 11:29:20 EST From: hugo@watson.ibm.com To: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Use of Keyed MD5 Ref: Your note of Wed, 25 Jan 1995 09:06:40 -0500 (attached) > Sender: rja@bodhi.itd.nrl.navy.mil > > Folks, > > It is NOT accurate to state that a "vulnerability" was discussed > by the Security Directorate. I mentioned that Russ Housely had sent > me an email expressing concern about the use of MD5, nothing more. > To my knowledge (and I have mostly been in the loop), there is no > known vulnerability. It is true that MD5 was designed as a message > digest function and not for cryptographic authentication in the > manner becoming commonplace within the IETF. I believe that an > Informational RFC on the use of keyed MD5 for authentication is > a good idea and I think one is likely to appear. Ran, I was just citing the published (by Jeff Schiller) minutes of the SAAG meeting (I was not there personally). They read: Ran Atkinson reported on a vulnerability in using keyed MD5 that had been brought to his attention. Since several protocols are considering using keyed MD5 -- SNMPv2 already does -- Jim Galvin volunteered to document the issues in an informational RFC. I thought that we have the right to know the status of that issue. Hugo From ipsec-request@ans.net Wed Jan 25 16:38:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17518 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 11:42:05 -0500 Received: by interlock.ans.net id AA57864 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 11:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 11:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 11:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 11:38:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 11:38:21 -0500 Message-Id: <9501251638.AA15169@snark.imsi.com> To: hugo@watson.ibm.com, bsimpson@morningstar.com, ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Wed, 25 Jan 1995 11:09:09 EST." <199501251625.LAA20495@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 11:38:00 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > Also, if you read my original note it says: > > In my opinion, if the IETF goes for a "standard" prepend-MD5 > they should define explicitely > that the length parameter is prepended to the computation > (say after the key) and not left to the "luck" of having or not > the length in a fixed offset in the information (as it "happens" > to be in the IP header). > > If you do that, then my objection is gone. In fact, because you and Ted Tso asked, we've already inserted that sort of language into the next draft. As I said before, I thought the suggestion was very good. We are being quite explicit in the document that the length is a necessary part of the security. The language will make it very clear that any system which does not have the length at a fixed position in the block isn't secure. I have no objections to the addition of any further explanatory language that might be needed. Given that the language is indeed going to be in the MD5 documents, are there further objections or comments on the documents as written thus far? I was expecting far more commentary, frankly. Surely someone at least objects to some of our grammar or phrasing? (The IETF is not known for its passive acceptance of anything...) Perry From ipsec-request@ans.net Wed Jan 25 14:29:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21016 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 14:29:09 -0500 Received: by interlock.ans.net id AA58638 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 14:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 14:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 14:20:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 14:20:37 -0500 Date: Wed, 25 Jan 95 10:54:37 From: "Housley, Russ" Encoding: 369 Text Message-Id: <9500257910.AA791060077@spysouth.spyrus.com> To: ipsec@ans.net Cc: sils@arc.nasa.gov Subject: Photuris Cookies Phil: The more that I look at cookies, I realize that they are only needed because Phorutis is running over a connectionless service (IP/UDP). If you were to run over a connection-oriented service like TCP, the connection establishment would provice the liveness checking that you need. Why do you think that key management must be run on IP/UDP? Russ From ipsec-request@ans.net Wed Jan 25 09:31:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16652 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 14:59:28 -0500 Received: by interlock.ans.net id AA55665 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 14:50:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 14:50:48 -0500 Message-Id: <199501251950.AA26733@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 14:50:48 -0500 Date: Wed, 25 Jan 95 14:31:32 EST From: hugo@watson.ibm.com To: perry@imsi.com, bsimpson@morningstar.com, ipsec@ans.net Subject: AH-MD5 Ref: Your note of Wed, 25 Jan 1995 11:38:00 -0500 (attached) > From: "Perry E. Metzger" > In fact, because you and Ted Tso asked, we've already inserted that > sort of language into the next draft. As I said before, I thought the > suggestion was very good. We are being quite explicit in the document > that the length is a necessary part of the security. The language > will make it very clear that any system which does not have the length > at a fixed position in the block isn't secure. > I was saying that just a clarification in the draft is NOT enough (it is only the very minimal). What I want is that the function is defined to explicitely prepend the length of the information together with the key. That is, the length is prepended (not physically, but just to the computation) even if the length happens to be part of the information. (This is analogous to MD5 definition which APPends the length to the computation regardless of whether the length parameter happened to be written inside the information or not). Besides, as said before by many, appending is no big deal (in particular, does not require the key prepend) and leaves a better margin for security. Hugo PS: as for cryptographic "evidence" I can show you DES-based constructions of authentication functions that are trivially breakable with append-only and prepend-only but not necessarily easy to break with prepend+append (i.e., I do not see an immediate way to break it). From ipsec-request@ans.net Wed Jan 25 19:53:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14921 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:02:47 -0500 Received: by interlock.ans.net id AA19192 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 14:59:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 14:59:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 14:59:26 -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 Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-metzger-ah-md5-01.txt Date: Wed, 25 Jan 95 14:53:45 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9501251453.aa07415@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Authentication with Keyed MD5 Author(s) : P. Metzger, W. Simpson Filename : draft-metzger-ah-md5-01.txt Pages : 4 Date : 01/24/1995 This document describes the use of MD5 with the IPv4 Authentication Header. 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-metzger-ah-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-ah-md5-01.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-metzger-ah-md5-01.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: <19950124131912.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-ah-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-ah-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950124131912.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Jan 25 19:55:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18766 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:03:23 -0500 Received: by interlock.ans.net id AA31229 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 14:59:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 14:59:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 14:59:31 -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 Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-metzger-esp-des-cbc-01.txt Date: Wed, 25 Jan 95 14:55:03 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9501251455.aa07487@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC Transform Author(s) : P. Metzger, W. Simpson Filename : draft-metzger-esp-des-cbc-01.txt Pages : 7 Date : 01/24/1995 This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). 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-metzger-esp-des-cbc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-esp-des-cbc-01.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-metzger-esp-des-cbc-01.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: <19950124132348.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-des-cbc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-des-cbc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950124132348.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Jan 25 20:06:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21234 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:15:54 -0500 Received: by interlock.ans.net id AA48091 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:07:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 15:07:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 15:07:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:07:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:07:02 -0500 Message-Id: <9501252006.AA15458@snark.imsi.com> To: hugo@watson.ibm.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Wed, 25 Jan 1995 14:31:32 EST." <199501251950.OAA21432@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 15:06:42 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > I was saying that just a clarification in the draft is NOT enough > (it is only the very minimal). What I want is that the function is > defined to explicitely prepend the length of the information together with > the key. That is, the length is prepended (not physically, but just > to the computation) even if the length happens to be part of the information. Just to clarify, the third and fourth octet of an IPv4 datagram always contain the total length of the datagram in octets. If I understand what Hugo is asking for correctly, he would like to prepend for purposes of the MD5 computation two octets of length information to the packet before MD5ing it even though the third and fourth octets already contain this information. I must confess that I don't understand what the point of this would be. Could you or someone else explain how this would increase security, or, if I am wrong about what you are proposing could you clarify? > PS: as for cryptographic "evidence" I can show you DES-based constructions > of authentication functions that are trivially breakable with append-only > and prepend-only but not necessarily easy to break with prepend+append > (i.e., I do not see an immediate way to break it). Well, yes, I could construct such things too -- but what is under consideration is a particular function, and I can't see a way to break the proposed method without breaking MD5. Now, please, understand that I am *not* wedded to particular ways of doing this. I'm happy to see us incorporate any alternative method proposed PROVIDED that there is evidence that it is cryptographically superior to the proposed method and doesn't cost a prohibitive amount to use. However, I must confess that I don't understand the point behind several of the requests that have been made. Perhaps a bit more formalism is needed. Perry From ipsec-request@ans.net Wed Jan 25 20:16:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11088 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:22:57 -0500 Received: by interlock.ans.net id AA22461 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:16:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 15:16:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 15:16:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:16:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:16:59 -0500 Message-Id: <9501252016.AA15488@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net, karn@qualcomm.com Subject: Re: Photuris Cookies In-Reply-To: Your message of "Wed, 25 Jan 1995 10:54:37." <9500257910.AA791060077@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 15:16:45 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > The more that I look at cookies, I realize that they are only needed > because Phorutis is running over a connectionless service (IP/UDP). If you > were to run over a connection-oriented service like TCP, the connection > establishment would provice the liveness checking that you need. Russ; Following yesterdays formal announcement of the open use of Morris style sequence number guess attacks against sites, and the well known fact that spoofed TCP SYN packets are a great denial of service attack, are you sure you timed this posting properly :-) Frankly, I want TCPng if there ever is one to incorporate cookies -- they are the only way I can think of to stop spoof-based denial of service attacks of the second type I mention above, and it is a shame that TCP doesn't have them now. Phil's invention is pretty impressive. Perry From ipsec-request@ans.net Wed Jan 25 19:17:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11022 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:35:17 -0500 Received: by interlock.ans.net id AA26628 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:21:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 25 Jan 1995 15:21:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 15:21:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 15:21:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:21:34 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:21:34 -0500 Date: 25 Jan 95 13:17:00 -0600 To: ipsec@ans.net Subject: Re[2]: AH-MD5 Message-Id: Ignoring the groups consensus is a big deal. >Author: ho@cs.arizona.edu@INTERNET > >> Didn't we already agree to MD5(key+data+key)? It's no big deal... > >It's only a big deal in that the collective we did agree and still agree. >I think the document should reflect this decision. Forward progress can only be made by representing the group consensus. Much progress was made in San Jose that is being ignored in draft-metzger-xxx work. These documents are interesting contributions, but are not being worked in a consensus building manner. BTY, silence on a mailing list should not be misconstrued as agreement. Paul From ipsec-request@ans.net Wed Jan 25 10:24:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14875 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:36:11 -0500 Received: by interlock.ans.net id AA48482 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:28:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:28:37 -0500 Message-Id: <199501252028.AA54366@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:28:37 -0500 Date: Wed, 25 Jan 95 15:24:33 EST From: hugo@watson.ibm.com To: perry@imsi.com Cc: bsimpson@morningstar.com, ipsec@ans.net Subject: AH-MD5 Ref: Your note of Wed, 25 Jan 1995 15:06:42 -0500 Perry, I want an authentication function which is sound independently of the (current) particular IP AH scenario. That's, in my view, the right way to use cryptographic primitives. Hugo From ipsec-request@ans.net Wed Jan 25 20:18:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13916 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:50:53 -0500 Received: by interlock.ans.net id AA27457 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:45:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 15:45:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:45:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:45:08 -0500 Message-Id: <9501252018.AA06325@skidrow.tay.dec.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Photuris Cookies In-Reply-To: Your message of "Wed, 25 Jan 95 10:54:37." <9500257910.AA791060077@spysouth.spyrus.com> Date: Wed, 25 Jan 95 15:18:03 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp ???? The cookies are to avoid a clogging attack. Using TCP make you much more vulnerable to this. You have to use stateless datagrams for the initial set up or the attackes will clog you with state. Donald From: "Housley, Russ" Encoding: 369 Text To: ipsec@ans.net Cc: sils@arc.nasa.gov > >Phil: > >The more that I look at cookies, I realize that they are only needed >because Phorutis is running over a connectionless service (IP/UDP). If you >were to run over a connection-oriented service like TCP, the connection >establishment would provice the liveness checking that you need. > >Why do you think that key management must be run on IP/UDP? > >Russ From ipsec-request@ans.net Wed Jan 25 20:56:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19607 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 15:58:20 -0500 Received: by interlock.ans.net id AA18960 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 15:56:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 15:56:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 15:56:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 15:56:14 -0500 Date: Wed, 25 Jan 1995 13:56:03 -0700 From: Hilarie Orman Message-Id: <199501252056.NAA10917@umbra.CS.Arizona.EDU> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9501252006.AA15458@snark.imsi.com> Subject: Re: AH-MD5 The security provided to IP depends on the MD5 algorithm. The security of the MD5 algorithm depends on the structure of the IP datagram. This is a dependency loop, the sort of thing that one tries to avoid in secure software design. From ipsec-request@ans.net Wed Jan 25 21:33:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18001 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 16:37:10 -0500 Received: by interlock.ans.net id AA23665 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 16:33:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 16:33:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 16:33:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 16:33:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 16:33:32 -0500 Message-Id: <9501252133.AA15608@snark.imsi.com> To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Wed, 25 Jan 1995 13:56:03 MST." <199501252056.NAA10917@umbra.CS.Arizona.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 16:33:09 -0500 From: "Perry E. Metzger" Hilarie Orman says: > The security provided to IP depends on the MD5 algorithm. The security > of the MD5 algorithm depends on the structure of the IP datagram. This > is a dependency loop, the sort of thing that one tries to avoid in > secure software design. If MD5 is a strong hash algorithm, then it should be impossible for an attacker to produce another text that has the same hash. That means that it should be impossible for an attacker to replace contents of the packet -- including the length -- without it being noticed. The attacker could replace the hash, but without knowing the key that should not be possible. The attacker could steal the packet and replace it with one with an extension of the plaintext and a hash derived from the original hash by extension, but then they would have to hack the length. If anyone can concretely think of something we haven't thought of here, please mention it. .pm From ipsec-request@ans.net Wed Jan 25 21:58:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15087 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 17:10:55 -0500 Received: by interlock.ans.net id AA26705 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 17:00:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 17:00:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 17:00:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 17:00:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 17:00:59 -0500 Message-Id: <9501252158.AA15629@snark.imsi.com> To: Paul_Lambert-P15452@email.mot.com Cc: ipsec@ans.net Subject: Re: Re[2]: AH-MD5 In-Reply-To: Your message of "25 Jan 1995 13:17:00 CST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 16:58:21 -0500 From: "Perry E. Metzger" Paul_Lambert-P15452@email.mot.com says: > > Ignoring the groups consensus is a big deal. Thats why we are discussing this, Paul, rather than fiating. I don't recall either Bill or myself indicating that we would refuse to alter the document. However, I was unaware that it was forbidden to discuss the issue. Thats what we are doing. > Forward progress can only be made by representing the group > consensus. No. Forward progress is made by producing good, functioning implementations of good standards. If you just want to represent the collective wisdom, we could go to voting, you know -- and perhaps even adopt the Confucionist ethic of the ISO rather than following the Tao of the IETF. I'll stick to IETF Taoism myself. > Much progress was made in San Jose that is being ignored in > draft-metzger-xxx work. > These documents are interesting contributions, but are not being > worked in a consensus building manner. Lets be very clear here. The documents submitted are based on the IPv6 work, which was essentially what the group adopted in Toronto as our consensus. They almost fully follow the Toronto decisions concerning packet types and formats, and the San Jose decisions concerning security transforms. (The 3DES and DES/3DES/MD5 documents will be showing up in the next day or two). Thus far, Bill and I (mostly Bill as editor -- he's holding the master copies) have incorporated every suggestion that has been made but one -- and that is because that one is being actively discussed. I realize that our (one) decision concerning prepending vs. prepending and appending did not follow wide discussion, but it was well thought out based on the IPv6 consensus, and as I've said, it is hardly fixed in stone. No one has said "we will not change the document", only "please explain your reasoning". If you think that asking questions is inappropriate, then I do not think you are following the Tao of the IETF. As for, "interesting contributions", they aren't "interesting contributions". They are, so far as I can tell, the current working documents. I have seen no other working documents in the internet-drafts directory. I'm implementing as we speak based on these documents. My implementation, which is being written for 4.4BSD Unix, will be given away for free. Now you've said... > Forward progress can only be made by representing the group > consensus. I think that for forward progress to occur, someone has to actually have a document in place. We've produced it. If you have suggestions, please make them so that we can move forward. Perry From ipsec-request@ans.net Wed Jan 25 22:00:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16690 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 17:15:27 -0500 Received: by interlock.ans.net id AA60162 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 17:05:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 25 Jan 1995 17:05:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 17:05:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 17:05:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 17:05:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 17:05:39 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9501252200.AA38973@hawpub1.watson.ibm.com> To: ipsec@ans.net Subject: Re: AH-MD5 Date: Wed, 25 Jan 95 17:00:29 -0500 Perry Metzger: > >Hilarie Orman: >> The security provided to IP depends on the MD5 algorithm. The security >> of the MD5 algorithm depends on the structure of the IP datagram. This >> is a dependency loop, the sort of thing that one tries to avoid in >> secure software design. > > If MD5 is a strong hash algorithm, then it should be impossible for an > attacker to produce another text that has the same hash. That means > that it should be impossible for an attacker to replace contents of > the packet -- including the length -- without it being noticed. The > attacker could replace the hash, but without knowing the key that > should not be possible. The attacker could steal the packet and > replace it with one with an extension of the plaintext and a hash > derived from the original hash by extension, but then they would have > to hack the length. If anyone can concretely think of something we > haven't thought of here, please mention it. I'm usually just a lurker, but how about the following scenario. Say we have two protocols -- IP, and XXP. XXP was invented in 1999. Just by coincidence that nobody thought of, it is possible with protocol XXP to cause a packet to emerge that looks like a valid IP packet (but isn't) and seems to have a long IP length field. Then the resulting XXP packet, authenticated with an MD5 checksum, may be vulnerable to a variety of append attack to "fill out" the rest of the "pretend-IP" packet to be something dangerous. Charlie P. From ipsec-request@ans.net Wed Jan 25 14:18:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19601 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 19:22:36 -0500 Received: by interlock.ans.net id AA21142 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 19:19:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 25 Jan 1995 19:19:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 19:19:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 19:19:14 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 19:19:14 -0500 Date: Wed, 25 Jan 95 19:18:56 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9501260018.AA04504@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 19:19:14 -0500 To: ipsec@ans.net Subject: on a more serious note... do we want MD5? Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission On a more serious note, as I stated in the security issues section of the MD5 draft, there has been some progress of late on the cracking of MD5. Its still rudimentary, but it has been made. Given that there are legitimate cryptographic concerns about MD5 itself, should we be looking at SHA (mark 2 :-) as the mandatory base transform rather than MD5? .pm From ipsec-request@ans.net Thu Jan 26 00:27:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19492 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 19:34:04 -0500 Received: by interlock.ans.net id AA08226 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 19:29:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 19:29:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 19:29:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 19:29:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 19:29:16 -0500 Message-Id: <9501260027.AA15806@snark.imsi.com> To: perk@watson.ibm.com (Charlie Perkins) Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Wed, 25 Jan 1995 17:00:29 EST." <9501252200.AA38973@hawpub1.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 19:27:42 -0500 From: "Perry E. Metzger" Charlie Perkins says: > Say we have two protocols -- IP, and XXP. XXP was invented in 1999. > Just by coincidence that nobody thought of, it is possible with > protocol XXP to cause a packet to emerge that looks like a valid > IP packet (but isn't) and seems to have a long IP length field. > Then the resulting XXP packet, authenticated with an MD5 checksum, > may be vulnerable to a variety of append attack to "fill out" the > rest of the "pretend-IP" packet to be something dangerous. I don't understand how this exploit works. Could you explain it in more detail? Wouldn't exploiting this require that the attacker steal the MD5 key somehow? After all, you wouldn't normally be authenticating an XXP packet with the same key that you'd be using for some arbitrary IP connection (or at least, you'd have only a tiny chance of doing so -- no greater a chance than of using the same MD5 key for two arbitrary IP SAIDs). Perry From ipsec-request@ans.net Thu Jan 26 00:25:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17673 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 19:51:26 -0500 Received: by interlock.ans.net id AA26344 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 19:48:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 19:48:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 19:48:32 -0500 Date: Thu, 26 Jan 95 00:25:57 GMT From: "William Allen Simpson" Message-Id: <3789.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: keyed-MD5 placement of secret I asked the Security Area this many months ago. We discussed it on the M-Bone wrt IPv6, and I believe it was discussed in other fora. Here is the decision: > Date: Sun, 11 Sep 94 11:34:19 -0400 > From: Jeffrey I. Schiller > .... I would recommend the front of > the data. in that fashion you can precompute the internal MD5 state (i.e., > initialize MD5, feed it the key and then snapshot its internal state) > in order to get better performance. > Now, unless the Security Area reverses itself, and changes the standard in SNMP also, that is what we will use in the AH implementations going forward as we speak. There is absolutely no reason to do it differently for each MD5 usage. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Jan 26 00:30:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20235 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 19:51:27 -0500 Received: by interlock.ans.net id AA20721 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 19:48:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 19:48:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 19:48:35 -0500 Date: Thu, 26 Jan 95 00:30:59 GMT From: "William Allen Simpson" Message-Id: <3790.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re[2]: AH-MD5 > From: Paul_Lambert-P15452@email.mot.com > Ignoring the groups consensus is a big deal. > This group arrived at a consensus long ago (Toronto). It was to use the same mechanisms as IPv6, as much as is practical. Moreover, there are times when groups have arrived at "consensus" simply because the people getting the real work done simply up and left. For example, a group that I gave up on reached the "consensus" that T1/T3 constituted the most widespread of serial link applications. That this is completely contrary to observable reality didn't phase them in the least. Our credo is _ROUGH_ consensus, and _running_ code. We have that. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Jan 26 01:36:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19985 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 20:40:19 -0500 Received: by interlock.ans.net id AA27326 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 20:33:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 20:33:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 20:33:59 -0500 Date: Wed, 25 Jan 1995 17:36:05 -0800 From: Phil Karn Message-Id: <199501260136.RAA20524@servo.qualcomm.com> To: ipsec@ans.net, rhousley@spyrus.com Subject: Re: Photuris Cookies Cc: sils@arc.nasa.gov Russ, Your timing is beautiful. :-) See the current discussion on comp.security.* of the TCP sequence-number attack that occurred recently at SDSC. There's a CERT advisory out on it now that references some papers by Bellovin and Morris that go into the gory details. They should explain why you need cookies and a non-TCP protocol. Phil From ipsec-request@ans.net Thu Jan 26 02:07:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20295 (5.65c/IDA-1.4.4 for ); Wed, 25 Jan 1995 21:11:09 -0500 Received: by interlock.ans.net id AA07936 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 Jan 1995 21:08:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 25 Jan 1995 21:08:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 Jan 1995 21:08:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 Jan 1995 21:08:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 Jan 1995 21:08:27 -0500 Message-Id: <9501260207.AA15914@snark.imsi.com> To: bsimpson@morningstar.com Cc: ipsec@ans.net Subject: Re: keyed-MD5 placement of secret In-Reply-To: Your message of "Thu, 26 Jan 1995 00:25:57 GMT." <3789.bill.simpson@um.cc.umich.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Jan 1995 21:07:26 -0500 From: "Perry E. Metzger" "William Allen Simpson" says: > Now, unless the Security Area reverses itself, and changes the standard > in SNMP also, that is what we will use in the AH implementations going > forward as we speak. I wouldn't go that far. The security area directorate isn't infallible. If someone presented with reasonable evidence that we were making a mistake I'd say that we should change. However, thus far I haven't seen evidence that we shouldn't follow the SNMP/IPv6 precedent. Myself, I'm pretty flexible. I have no religious convictions here -- this ends up being a change of a couple of lines of code in my implementation. Making that sort of change wouldn't break me. There was a time where I would have said "to hell with it" and changed my position just to reach consensus faster. However, Ran Atkinson beat it into my head not that long ago that here in the IETF we make our decisions for good technical reasons and not for political reasons, and I've stuck by his advice on this sort of thing since then. As I've yet to hear a good technical argument, I'm sticking with my personal position -- no offense intended to Hugo or any of the other partisans of appending or other mechanisms. Perry From ipsec-request@ans.net Thu Jan 26 00:16:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13307 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 09:33:39 -0500 Received: by interlock.ans.net id AA41530 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 09:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 09:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 09:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 09:17:06 -0500 Date: Thu, 26 Jan 95 07:16:47 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501261416.AA12671@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: AH-MD5 I just figured out the attack on prepend-only MD5. Thanks to Perry Metzger for indirectly pointing it out to me. If I hash "abcd", MD5Transform is invoked once, on the 16 words: 'abcd' 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 The trailing "20" is the message length in bits (32 bits). If I have the hash of this, I can compose a message which begins with this information, then adds another block with additional data, and compute the hash on the larger message by adding the appropriate padding and (revised) bit count, and call MD5Transform to convert the original hash to the hash of the revised message. I can do this even if I don't know the "ab" authenticator part of the message, but the recipient who's going to "verify" theh hash does. In light of this, appending seems safer. However, it's easier to discover collisions in MD5 if you have the inputs to the MD5Transform function, which a secret key deprives you of. One possibility is to place the secret key into its own MD5Transform block, enabling the output hash from the first block to be precomputed and used directly. Or change the input "magic constants" directly. This avoids the extra time overhead. -- -Colin From ipsec-request@ans.net Thu Jan 26 15:28:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14858 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 10:30:21 -0500 Received: by interlock.ans.net id AA09651 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 10:27:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 10:27:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 10:27:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 10:27:03 -0500 Message-Id: <9501261528.AA01039@skidrow.tay.dec.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: on a more serious note... do we want MD5? In-Reply-To: Your message of "Wed, 25 Jan 95 19:18:56 EST." <9501260018.AA04504@webster.imsi.com> Date: Thu, 26 Jan 95 10:28:58 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I initially proposed SHA for DNS security but gotten beaten back on the grouds that MD5 with the Internet way of doing it. I still think that SHA is better and believe that, sooner or later, there will be a transition to it. Donald From: perry@imsi.com (Perry E. Metzger) To: ipsec@ans.net Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission >On a more serious note, as I stated in the security issues section of >the MD5 draft, there has been some progress of late on the cracking of >MD5. Its still rudimentary, but it has been made. Given that there are >legitimate cryptographic concerns about MD5 itself, should we be >looking at SHA (mark 2 :-) as the mandatory base transform rather than >MD5? > >.pm From ipsec-request@ans.net Thu Jan 26 15:57:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13170 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 11:00:52 -0500 Received: by interlock.ans.net id AA48679 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 10:58:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 26 Jan 1995 10:58:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 10:58:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 10:58:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 10:58:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 10:58:16 -0500 From: uri@watson.ibm.com Message-Id: <9501261557.AA15676@buoy.watson.ibm.com> Subject: Re: on a more serious note... do we want MD5? To: perry@imsi.com Date: Thu, 26 Jan 1995 10:57:49 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9501260018.AA04504@webster.imsi.com> from "Perry E. Metzger" at Jan 25, 95 07:18:56 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: 1116 Perry E. Metzger says: > On a more serious note, as I stated in the security issues section of > the MD5 draft, there has been some progress of late on the cracking of > MD5. Its still rudimentary, but it has been made. I'd say - the reason is similar to why DES-based MAC functions aren't all that great. Birthday Paradox attacks are very much feasible, when you have 64 bits (need 2^32), and on the margin today for 128 bits,as you need 2^64... SHA with it's 160 bits would require 2^80, still not practical... Besides, what a coincidence - where have I seen that number 80? (:-) > Given that there are legitimate cryptographic concerns about MD5 itself, > should we be looking at SHA (mark 2 :-) as the mandatory base transform > rather than MD5? I would vote yes for this. Probably nobody today knows exactly how strong authentication based on hash-functions is... Probably 2^64 is good enough... But obviously if attacker needs 2^80 messages, it's much safer. I'd go with SHA [besides, it's designers will be pleased :-]. -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Thu Jan 26 09:17:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16763 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 11:01:41 -0500 Received: by interlock.ans.net id AA57153 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 10:59:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 10:59:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 10:59:22 -0500 Date: Thu, 26 Jan 95 09:17:13 GMT From: "William Allen Simpson" Message-Id: <3799.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: keyed-MD5 placement of secret > From: "Perry E. Metzger" > "William Allen Simpson" says: > > Now, unless the Security Area reverses itself, and changes the standard > > in SNMP also, that is what we will use in the AH implementations going > > forward as we speak. > > I wouldn't go that far. The security area directorate isn't > infallible. If someone presented with reasonable evidence that we were > making a mistake I'd say that we should change. However, thus far I > haven't seen evidence that we shouldn't follow the SNMP/IPv6 > precedent. > Nobody said they were. But, they are the final deciders, not us. This WG might think there is reasonable evidence, but that simply doesn't matter. This is not tyranny of the majority. This is about interoperability and technical direction. > As I've yet to hear a good technical argument, I'm sticking with my > personal position > I agree. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Jan 26 16:02:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13803 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 11:07:07 -0500 Received: by interlock.ans.net id AA48822 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 11:03:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 26 Jan 1995 11:03:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 11:03:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 11:03:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 11:03:15 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 11:03:15 -0500 From: uri@watson.ibm.com Message-Id: <9501261602.AA22622@buoy.watson.ibm.com> Subject: Re: keyed-MD5 placement of secret To: bsimpson@morningstar.com Date: Thu, 26 Jan 1995 11:02:43 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <3789.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jan 26, 95 00:25:57 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1159 William Allen Simpson says: > I asked the Security Area this many months ago. We discussed it on the > M-Bone wrt IPv6, and I believe it was discussed in other fora. Here is > the decision: > > Date: Sun, 11 Sep 94 11:34:19 -0400 > > From: Jeffrey I. Schiller > > .... I would recommend the front of > > the data. in that fashion you can precompute the internal MD5 state (i.e., > > initialize MD5, feed it the key and then snapshot its internal state) > > in order to get better performance. > > > Now, unless the Security Area reverses itself, and changes the standard > in SNMP also, that is what we will use in the AH implementations going > forward as we speak. There is absolutely no reason to do it differently > for each MD5 usage. This is faster but less secure. It isn't possible to tel exactly how much less [to the best of my knowledge]. Some attacks are possible, unless length is in certain place and such... I'd ask - what's the rush? I personally won't care about speed advantage of precomputed MD5 (unless I'm cracking MD5 key, of course :-)... -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Thu Jan 26 16:23:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17211 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 11:37:55 -0500 Received: by interlock.ans.net id AA32500 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 11:30:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 11:30:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 11:30:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 11:30:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 11:30:16 -0500 From: Charlie Watt Sender: Charlie Watt Message-Id: <9501261623.AA01696@mordred.sware.com> Subject: Re: AH-MD5 To: colin@nyx10.cs.du.edu (Colin Plumb) Date: Thu, 26 Jan 1995 11:23:44 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9501261416.AA12671@nyx10.cs.du.edu> from "Colin Plumb" at Jan 26, 95 07:16:47 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2487 X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, C6DHhVltQjFW7sG1nvHjifiXpZcSTB9vKtxUtYOhhNvffZ+YII7PpV2HKqEBUZxE ZH7duzPNfYcHVrg9BVtGNXE= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED Colin Plumb writes: > > I just figured out the attack on prepend-only MD5. > Thanks to Perry Metzger for indirectly pointing it out to me. > > If I hash "abcd", MD5Transform is invoked once, on the 16 words: > > 'abcd' 80000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 > > The trailing "20" is the message length in bits (32 bits). > If I have the hash of this, I can compose a message which begins > with this information, then adds another block with additional data, > and compute the hash on the larger message by adding the appropriate > padding and (revised) bit count, and call MD5Transform to convert the > original hash to the hash of the revised message. I can do this even > if I don't know the "ab" authenticator part of the message, but the > recipient who's going to "verify" theh hash does. > > In light of this, appending seems safer. > I must admit that I do not understand this debate and side with Perry. What is this purpose of this group? I understood it to be the design of a layer 3 security protocol for IP v4. Well, 1) The purpose of any layer 3 security protocol is to protect layer 3 PDUs including the security critical header information such as addresses. Well, the PDU length is security critical information. 2) For all layer 3 protocols that I have seen: - the header includes the PDU length, - the header comes before the payload so that the PDU can be parsed. - the length field is contained within a known fixed length initial portion of the header. This meets all of the requirements for authentication using a hashing function and a prepended key. There is no need for an appended length, for as Colin points out it is worthless. There is no need for an appended key, it only adds an extra MD5 cycle per packet. True, if this approach is later used for some other layer 3 protocol and the length is not included within a initial known length segment, it is open for append attacks. But what is a layer 3 protocol without the PDU length? Talk about poor software engineering practices. What is a layer 3 security protocol that does not include the PDU header (or selected components of it)? Insecure. The only comment that I have heard that is really relevent to the security of this approach are the rumors of some progress towards breaking MD5. Does anyone have real information on this? Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Thu Jan 26 16:30:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15195 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 11:42:33 -0500 Received: by interlock.ans.net id AA41089 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 11:38:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 11:38:11 -0500 From: Ran Atkinson Message-Id: <9501261130.ZM3681@bodhi.nrl.navy.mil> Date: Thu, 26 Jan 1995 11:30:07 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: MD5 vs. SHA Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil All, It is important to keep in mind that whatever algorithm is chosen needs to be fast enough in real commercial systems with standard commercial processors that it is actually practical to use with many packets over fairly fast networks (e.g. FDDI, FastEthernet, and ATM are all order(100Mbps)). Software implementations are what most systems will have, so we need to avoid solutions that effectively require hardware implementations of the security- related algorithms. Now I'm not arguing for or against any particular algorithm, but if we pick an algorithm that is impractical to deploy widely we will (IMHO) have failed to do our jobs properly. This is fundamentally an engineering exercise in risk reduction NOT a theoretical/research exercise in designing flawless security. There is already concern that MD5 only performs at order(70Mbps) on an Alpha when everything is neatly aligned (and so forth). Should we not do the same kind of experimentation/testing on SHA and whatever other algorithms the group is seriously discussing ? In any event, algorithm-independence is IMHO a design requirement because the world will probably migrate to different or additional algorithms with time. I can live with imperfect security in IPvN as long as it is widely deployed, practical to use, and significantly reduces risk. Mind you, this is all just my opinion... Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Jan 26 16:20:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17622 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 12:09:54 -0500 Received: by interlock.ans.net id AA47544 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 12:02:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 12:02:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 12:02:24 -0500 Date: Thu, 26 Jan 95 16:20:35 GMT From: "William Allen Simpson" Message-Id: <3802.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: AH-MD5 > From: colin@nyx10.cs.du.edu (Colin Plumb) > I just figured out the attack on prepend-only MD5. > If I hash "abcd", MD5Transform is invoked once, on the 16 words: > > 'abcd' 80000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 > Sigh. Whatever does this have to do with the current AH draft, or the AH-MD5 draft? Have you read them? Both drafts explicitly state that the IP Total Length is included in the hash. That would, in your example for secret 'ab' and data 'cd', yield: 'ab'0002 'cd'8000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 An appending attack would add 'ef' after 'cd'. Exactly how is the hash recomputed, when the 0002 is changed to something larger? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Thu Jan 26 03:30:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14855 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 12:49:11 -0500 Received: by interlock.ans.net id AA37385 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 12:31:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 12:31:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 12:31:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 12:31:05 -0500 Date: Thu, 26 Jan 95 10:30:21 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501261730.AA08356@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: bsimpson@morningstar.com Subject: Re: AH-MD5 Cc: ipsec@ans.net > Sigh. Whatever does this have to do with the current AH draft, or the > AH-MD5 draft? Have you read them? Nothing really, since the inclusion of the length at the beginning (as many people have pointed out) renders it irrelevant. It's just that I didn't know the original attack, and it appeared that some others didn't, so I thought to describe it. > Both drafts explicitly state that the IP Total Length is included in the > hash. As you point out, that does change things. But there had been some discussion of the disadvantages of introducing that format dependency. (Probably my discussion of countermeasures was out of place since it wasn't well thought out.) -- -Colin From ipsec-request@ans.net Thu Jan 26 17:39:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19264 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 12:53:42 -0500 Received: by interlock.ans.net id AA54281 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 12:42:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 12:42:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 12:42:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 12:42:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 12:42:41 -0500 Message-Id: <9501261739.AA16696@snark.imsi.com> To: colin@nyx10.cs.du.edu (Colin Plumb) Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Thu, 26 Jan 1995 07:16:47 MST." <9501261416.AA12671@nyx10.cs.du.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 26 Jan 1995 12:39:51 -0500 From: "Perry E. Metzger" Colin Plumb says: > I just figured out the attack on prepend-only MD5. > Thanks to Perry Metzger for indirectly pointing it out to me. > > If I hash "abcd", MD5Transform is invoked once, on the 16 words: > > 'abcd' 80000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 > > The trailing "20" is the message length in bits (32 bits). > If I have the hash of this, I can compose a message which begins > with this information, then adds another block with additional data, > and compute the hash on the larger message by adding the appropriate > padding and (revised) bit count, and call MD5Transform to convert the > original hash to the hash of the revised message. I can do this even > if I don't know the "ab" authenticator part of the message, but the > recipient who's going to "verify" theh hash does. > > In light of this, appending seems safer. Colin; This is the famous "appending attack". Its fairly well known. We defend against it because we include the length of the message in the authenticated message at a fixed location, which means that we could detect received messages that had been tampered with. Perry From ipsec-request@ans.net Thu Jan 26 09:40:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13604 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 14:53:12 -0500 Received: by interlock.ans.net id AA28228 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 14:45:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 14:45:41 -0500 Message-Id: <199501261945.AA34880@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 14:45:41 -0500 Date: Thu, 26 Jan 95 14:40:40 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com Cc: IPSEC@ans.net, jis@mit.edu Subject: keyed-MD5 placement of secret Ref: Your note of Thu, 26 Jan 95 00:25:57 GMT (attached) Bill (and Jeff) > I asked the Security Area this many months ago. We discussed it on the > M-Bone wrt IPv6, and I believe it was discussed in other fora. Here is > the decision: > > > Date: Sun, 11 Sep 94 11:34:19 -0400 > > From: Jeffrey I. Schiller > > .... I would recommend the front of > > the data. in that fashion you can precompute the internal MD5 state (i.e., > > initialize MD5, feed it the key and then snapshot its internal state) > > in order to get better performance. > > > Now, unless the Security Area reverses itself, and changes the standard > in SNMP also, that is what we will use in the AH implementations going > forward as we speak. > > There is absolutely no reason to do it differently for each MD5 usage. Exactly! This is why you want an authentication function whose security is independent of the particular usage/scenario/assumptions. And yes, I hope the Security Area changes its decision as for what is the standard keyed-MD5 mode for authentication. Hugo From ipsec-request@ans.net Thu Jan 26 20:16:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15283 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 15:20:40 -0500 Received: by interlock.ans.net id AA11367 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 15:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 26 Jan 1995 15:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 15:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 15:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 15:17:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 15:17:06 -0500 From: uri@watson.ibm.com Message-Id: <9501262016.AA20910@buoy.watson.ibm.com> Subject: Re: keyed-MD5 placement of secret To: ipsec@ans.net Date: Thu, 26 Jan 1995 15:16:58 -0500 (EST) Cc: bsimpson@morningstar.com In-Reply-To: <199501261945.AA34880@interlock.ans.net> from "hugo@watson.ibm.com" at Jan 26, 95 02:40:40 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: 730 > > Now, unless the Security Area reverses itself, and changes the standard > > in SNMP also, that is what we will use in the AH implementations going > > forward as we speak. I suggest SNMP in this rutn of discussion if left alone, as it's specifically refuses to use other services, especially regarding security. The assumption there is - you can't know in advance what will be operational at the time of network fire, which you'll need to fight - so all your eggs must be in your basket. (:-) Thus, it's certain that SNMP will *not* make use of any "standard" network-wide security services and such, so SNMP won't care/need AH/whatever... -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Fri Jan 27 00:02:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13394 (5.65c/IDA-1.4.4 for ); Thu, 26 Jan 1995 19:11:27 -0500 Received: by interlock.ans.net id AA13805 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 Jan 1995 19:04:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 Jan 1995 19:04:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 Jan 1995 19:04:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 Jan 1995 19:04:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 Jan 1995 19:04:18 -0500 Message-Id: <9501270002.AA17819@snark.imsi.com> To: hugo@watson.ibm.com Cc: bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu Subject: Re: keyed-MD5 placement of secret In-Reply-To: Your message of "Thu, 26 Jan 1995 14:40:40 EST." <199501261945.AA34880@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 26 Jan 1995 19:02:28 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > Exactly! This is why you want an authentication function whose security > is independent of the particular usage/scenario/assumptions. You are asking that we prepend the length to packets that already specify their length at a fixed location. I don't understand why we need that. The specification is "keyed MD5 with length at a fixed point in the packet to prevent appending attacks". We've got that. I see no cryptographic reason to include the length twice -- the two are identical. From a software engineering standpoint there is no reason that I can see, either -- there is no code sharing between the kernel and your SNMP implementation, for instance. Remember that no security function can operate for all possible scenarios. Our security function works fine for our scenario. Perry From ipsec-request@ans.net Fri Jan 27 02:48:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22671 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 05:02:20 -0500 Received: by interlock.ans.net id AA24292 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 04:51:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 04:51:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 04:51:53 -0500 Date: Fri, 27 Jan 95 02:48:38 GMT From: "William Allen Simpson" Message-Id: <3806.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: pointless semantic dithering Thanks to Charlie Watt for the intelligent message: > From: Charlie Watt > I must admit that I do not understand this debate and side with Perry. > What is this purpose of this group? I understood it to be the design of > a layer 3 security protocol for IP v4. ... > No thanks to Hugo and Uri for the pointless dithering: > From: hugo@watson.ibm.com > Exactly! This is why you want an authentication function whose security > is independent of the particular usage/scenario/assumptions. > > From: uri@watson.ibm.com > Some attacks are possible, unless > length is in certain place and such... I'd ask - what's the rush? > I personally won't care about speed advantage of precomputed > MD5 (unless I'm cracking MD5 key, of course :-)... What universe are you two from? This is the IP Security WG. We are talking about Internet protocols (which include SNMP and DNS). We have Internet usage/scenario/assumptions. IP always has a Length which is always in the same place. We have lots of messages about speed concerns. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Jan 27 06:58:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22435 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 12:21:20 -0500 Received: by interlock.ans.net id AA45755 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 12:00:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 12:00:19 -0500 Message-Id: <199501271700.AA47536@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 12:00:19 -0500 Date: Fri, 27 Jan 95 11:58:40 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com, ipsec@ans.net Subject: pointless semantic dithering Ref: Your note of Fri, 27 Jan 95 02:48:38 GMT Bill, no-thanks for being so Bill Simpson! Hugo From ipsec-request@ans.net Fri Jan 27 07:00:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13564 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 12:26:38 -0500 Received: by interlock.ans.net id AA30522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 12:17:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 12:17:33 -0500 Message-Id: <199501271717.AA54581@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 12:17:33 -0500 Date: Fri, 27 Jan 95 12:00:59 EST From: hugo@watson.ibm.com To: perry@imsi.com Cc: bsimpson@morningstar.com, IPSEC@ans.net, jis@mit.edu Subject: keyed-MD5 placement of secret Ref: Your note of Thu, 26 Jan 1995 19:02:28 -0500 (attached) > From: "Perry E. Metzger" > > hugo@watson.ibm.com says: > > Exactly! This is why you want an authentication function whose security > > is independent of the particular usage/scenario/assumptions. > > You are asking that we prepend the length to packets that already > specify their length at a fixed location. I don't understand why we Indeed, when you apply MD5 to information that happens to have the length as its last field you still append the length again during the hash computation. This is because the standard, unique definition of MD5 (Rivest's function, not the derivated keyed functions), asks for automatic addition of the length parameter (not to the physical information but to the computation). Do you know of any application that modifies the definition of MD5 because it happens to have the length as a field in the information? Using well defined, standard cryptographic functions is good practice. This is also why I wanted to involve the security directorate since this is (in my view) a global issue for the IETF. Now, let's stop this loop of messages. The last thing I intended was to clog this list (and myself!) Go ahead with whatever you feel is rough consensus in the group. Hugo From ipsec-request@ans.net Fri Jan 27 16:24:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23444 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 16:24:52 -0500 Received: by interlock.ans.net id AA21507 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 16:15:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 27 Jan 1995 16:15:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 16:15:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 16:15:46 -0500 Date: Fri, 27 Jan 95 13:00:28 From: "Housley, Russ" Encoding: 1606 Text Message-Id: <9500277912.AA791240428@spysouth.spyrus.com> To: atkinson@itd.nrl.navy.mil, ipsec@ans.net, hugo@watson.ibm.com Subject: Re: Use of Keyed MD5 Hugo: Jim Galvin has not written the RFC yet, but Burt Kaliski from RSA Data Security has volunteered to help Jim with the document. That is the only new news that I am aware of.... Russ ______________________________ Reply Separator _________________________________ Subject: Use of Keyed MD5 Author: hugo@watson.ibm.com at internet Date: 01/25/95 11:29 Ref: Your note of Wed, 25 Jan 1995 09:06:40 -0500 (attached) > Sender: rja@bodhi.itd.nrl.navy.mil > > Folks, > > It is NOT accurate to state that a "vulnerability" was discussed > by the Security Directorate. I mentioned that Russ Housely had sent > me an email expressing concern about the use of MD5, nothing more. > To my knowledge (and I have mostly been in the loop), there is no > known vulnerability. It is true that MD5 was designed as a message > digest function and not for cryptographic authentication in the > manner becoming commonplace within the IETF. I believe that an > Informational RFC on the use of keyed MD5 for authentication is > a good idea and I think one is likely to appear. Ran, I was just citing the published (by Jeff Schiller) minutes of the SAAG meeting (I was not there personally). They read: Ran Atkinson reported on a vulnerability in using keyed MD5 that had been brought to his attention. Since several protocols are considering using keyed MD5 -- SNMPv2 already does -- Jim Galvin volunteered to document the issues in an informational RFC. I thought that we have the right to know the status of that issue. Hugo From ipsec-request@ans.net Fri Jan 27 16:24:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22934 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 16:24:53 -0500 Received: by interlock.ans.net id AA56811 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 16:14:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 27 Jan 1995 16:14:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 16:14:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 16:14:59 -0500 Date: Fri, 27 Jan 95 13:00:16 From: "Housley, Russ" Encoding: 395 Text Message-Id: <9500277912.AA791240416@spysouth.spyrus.com> To: perry@imsi.com, hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: AH-MD5 Hugo said: "Still my cryptographic feelings are inclined to prepend+append but then the extra computation -even if quite insignificant- is harder to justify." Well, I think that it is easy to justify. Given the tiny amount of processing that we are discussing, it is far better to error on the safe side of the decision. Let's just adopt prepend+data+append and move on. Russ From ipsec-request@ans.net Fri Jan 27 23:07:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12939 (5.65c/IDA-1.4.4 for ); Fri, 27 Jan 1995 18:19:09 -0500 Received: by interlock.ans.net id AA46151 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 27 Jan 1995 18:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 27 Jan 1995 18:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 27 Jan 1995 18:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 27 Jan 1995 18:07:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 27 Jan 1995 18:07:40 -0500 Message-Id: <9501272307.AA20117@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Fri, 27 Jan 1995 13:00:16." <9500277912.AA791240416@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 27 Jan 1995 18:07:24 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Hugo said: "Still my cryptographic feelings are inclined to prepend+append > but then the extra computation -even if quite insignificant- is harder to > justify." > > Well, I think that it is easy to justify. Given the tiny amount of > processing that we are discussing, it is far better to error on the safe > side of the decision. Let's just adopt prepend+data+append and move on. Not so fast... I'm not opposed to changing the spec per se, but I am opposed to intuition-based specification writing. If it made someone get warm fuzzies for us to append the word "FOO" in ASCII to the end of every packet, that wouldn't be cause enough to do it -- we would need justification -- a reasonable argument. I still haven't heard any reasonable argument on why a prepend-only keyed MD5 with the data length at a fixed position in the packet wouldn't be secure. Appending the key was purely a mechanism to stop appending attacks and the length being in the packet stops those. Arguments have been made that, given our lack of understanding in depth of the security of MD5, we might be in trouble -- but if MD5 is good, we should be fine, and if MD5 is not good, then we shouldn't be using it at all. We've also heard arguments from Hugo to the effect that he wants a security function that would work for things other than IP packets, but he hasn't presented any arguments that we are insecure -- just unpleasing to his aesthetics unless the function could be used on arbitrary data and not just on IP packets. (This is not to say that aesthetics isn't important but no one else has had this aesthetic problem so I'd say he's in the minority right now.) Does anyone have a concrete argument against the security of MD5 used as we are using it? Not aesthetic concerns, not "well, we don't know if MD5 is secure" (because if it isn't we should just scrap it, period!). I'm looking for an argument of the form... "If we define our function as we have, then an opponent can do X and Y and then spoof packets". Perry From ipsec-request@ans.net Fri Jan 27 13:06:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22729 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 00:12:47 -0500 Received: by interlock.ans.net id AA32467 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 00:08:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 00:08:27 -0500 To: ipsec@ans.net, perry@imsi.com Subject: Minor wording changes to draft-metzger-ah-00.txt X-Signed: PGP-Detached-2-3, iQBXAwUBLynQwdC3U5sdKpFdAQG4vQILBOCQcPPEPBp+AefZnXMCHt+H65SnUnQL 7zrPwABIv/dHT6HFMlmiMaB/fUhrTh9VaB3wdEuuRmg/em9AcfqKjge8 Date: Fri, 27 Jan 95 21:06:15 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501272106.aa22813@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Here are the few changes I would recommend. Most are related to concerns of the english language. j' diff draft-metzger-ah-00.txt draft-metzger-ah-00.txt.ala.jpp 45,47c45,47 < This document describes an authentication mechanism for IPv4, by < inserting an intervening header between the IPv4 Header and any < transport headers. --- > This document describes an authentication mechanism for IPv4 which > inserts an intervening header between the IPv4 Header and the > transport headers of the to be authenticated packet. [english concerns] 277c277 < SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are --- > SAID values in the range 0x00000001 through 0x0000000F are [better to keep special values together in a single block. 0x0 is special also.] 293,294c293,294 < have such special processing instructions included in its < specification. --- > have such [what is refered to?] special processing instructions > included in its specification. [I don't know what "such" refers to here. I may just be slow.] 338a339,340 > [Overly specific, move this (good) discussion to the document describing > the digest algorithm.... 353c355 < --- > ...] [This stuff is specific to the authentication alg. and should be moved there.] 367a370,371 > and the authentication algorith does not specify how to handle non- > integral length messages, [I doubt that there will be any authentication functions which don't specify. In any case, when they do there shouldn't be two specifications ofwhat to do.] From ipsec-request@ans.net Sat Jan 28 01:24:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23147 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 01:24:28 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Sat, 28 Jan 1995 01:22:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 01:22:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 01:22:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 01:22:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Sat, 28 Jan 1995 01:22:28 -0500 Date: Fri, 27 Jan 95 13:00:16 From: "Housley, Russ" Encoding: 395 Text Message-Id: <9500277912.AA791240416@spysouth.spyrus.com> To: perry@imsi.com, hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: AH-MD5 Hugo said: "Still my cryptographic feelings are inclined to prepend+append but then the extra computation -even if quite insignificant- is harder to justify." Well, I think that it is easy to justify. Given the tiny amount of processing that we are discussing, it is far better to error on the safe side of the decision. Let's just adopt prepend+data+append and move on. Russ From ipsec-request@ans.net Sat Jan 28 01:41:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24537 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 01:41:42 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Sat, 28 Jan 1995 01:37:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 01:37:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 01:37:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 01:37:52 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Sat, 28 Jan 1995 01:37:52 -0500 Date: Fri, 27 Jan 95 13:00:28 From: "Housley, Russ" Encoding: 1606 Text Message-Id: <9500277912.AA791240428@spysouth.spyrus.com> To: atkinson@itd.nrl.navy.mil, ipsec@ans.net, hugo@watson.ibm.com Subject: Re: Use of Keyed MD5 Hugo: Jim Galvin has not written the RFC yet, but Burt Kaliski from RSA Data Security has volunteered to help Jim with the document. That is the only new news that I am aware of.... Russ ______________________________ Reply Separator _________________________________ Subject: Use of Keyed MD5 Author: hugo@watson.ibm.com at internet Date: 01/25/95 11:29 Ref: Your note of Wed, 25 Jan 1995 09:06:40 -0500 (attached) > Sender: rja@bodhi.itd.nrl.navy.mil > > Folks, > > It is NOT accurate to state that a "vulnerability" was discussed > by the Security Directorate. I mentioned that Russ Housely had sent > me an email expressing concern about the use of MD5, nothing more. > To my knowledge (and I have mostly been in the loop), there is no > known vulnerability. It is true that MD5 was designed as a message > digest function and not for cryptographic authentication in the > manner becoming commonplace within the IETF. I believe that an > Informational RFC on the use of keyed MD5 for authentication is > a good idea and I think one is likely to appear. Ran, I was just citing the published (by Jeff Schiller) minutes of the SAAG meeting (I was not there personally). They read: Ran Atkinson reported on a vulnerability in using keyed MD5 that had been brought to his attention. Since several protocols are considering using keyed MD5 -- SNMPv2 already does -- Jim Galvin volunteered to document the issues in an informational RFC. I thought that we have the right to know the status of that issue. Hugo From ipsec-request@ans.net Fri Jan 27 23:07:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13192 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 02:11:04 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Sat, 28 Jan 1995 02:06:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 02:06:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 02:06:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 02:06:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 02:06:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Sat, 28 Jan 1995 02:06:36 -0500 Message-Id: <9501272307.AA20117@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Fri, 27 Jan 1995 13:00:16." <9500277912.AA791240416@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 27 Jan 1995 18:07:24 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Hugo said: "Still my cryptographic feelings are inclined to prepend+append > but then the extra computation -even if quite insignificant- is harder to > justify." > > Well, I think that it is easy to justify. Given the tiny amount of > processing that we are discussing, it is far better to error on the safe > side of the decision. Let's just adopt prepend+data+append and move on. Not so fast... I'm not opposed to changing the spec per se, but I am opposed to intuition-based specification writing. If it made someone get warm fuzzies for us to append the word "FOO" in ASCII to the end of every packet, that wouldn't be cause enough to do it -- we would need justification -- a reasonable argument. I still haven't heard any reasonable argument on why a prepend-only keyed MD5 with the data length at a fixed position in the packet wouldn't be secure. Appending the key was purely a mechanism to stop appending attacks and the length being in the packet stops those. Arguments have been made that, given our lack of understanding in depth of the security of MD5, we might be in trouble -- but if MD5 is good, we should be fine, and if MD5 is not good, then we shouldn't be using it at all. We've also heard arguments from Hugo to the effect that he wants a security function that would work for things other than IP packets, but he hasn't presented any arguments that we are insecure -- just unpleasing to his aesthetics unless the function could be used on arbitrary data and not just on IP packets. (This is not to say that aesthetics isn't important but no one else has had this aesthetic problem so I'd say he's in the minority right now.) Does anyone have a concrete argument against the security of MD5 used as we are using it? Not aesthetic concerns, not "well, we don't know if MD5 is secure" (because if it isn't we should just scrap it, period!). I'm looking for an argument of the form... "If we define our function as we have, then an opponent can do X and Y and then spoof packets". Perry From ipsec-request@ans.net Fri Jan 27 15:17:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16841 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 02:26:21 -0500 Received: by interlock.ans.net id AA32235 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 02:21:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 02:21:00 -0500 To: perry@piermont.com, Bill.Simpson@um.cc.umich.edu, ipsec@ans.net Subject: Minor suggestions for draft-metzger-esp-00.txt X-Signed: PGP-Detached-2-3, iQBXAwUBLynvlNC3U5sdKpFdAQGV3AIMCOcuyOS/rqbzOaJ4wpftGDr2iX/m1240 6oL2cartnTGjevKV4VrfHelKibklBW2TH2FWwq+Jm/AvavveXtjHrfSP Date: Fri, 27 Jan 95 23:17:50 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501272318.aa03752@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Here are similar changes to those I proposed for -ah-00. j' diff draft-metzger-esp-00.txt draft-metzger-esp-00.txt.ala.jpp 45,46c45,46 < This document describes a privacy mechanism for IPv4, encapsulating < transport headers within an opaque envelope. --- > This document describes a privacy mechanism for IPv4 analogous to > encapsulating transport headers within an opaque envelope. [english] 267c267 < SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are --- > SAID values in the range 0x00000001 through 0x0000000F are [better to keep special values all together in one block. 0x0 is special too. (It indicates no SAID yet established, right?)] 308c308,309 < If cleartext datagram If a SAID is received which is not valid for a --- > If a cleartext datagram arrives from a Source after a SAID has > been established, or a SAID is received which is not valid for a 310d310 < [typo, i bet] From ipsec-request@ans.net Fri Jan 27 13:06:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14843 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 02:33:09 -0500 Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for archive-ipsec@nis.ans.net); Sat, 28 Jan 1995 02:29:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 02:29:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-0); Sat, 28 Jan 1995 02:29:58 -0500 To: ipsec@ans.net, perry@imsi.com Subject: Minor wording changes to draft-metzger-ah-00.txt X-Signed: PGP-Detached-2-3, iQBXAwUBLynQwdC3U5sdKpFdAQG4vQILBOCQcPPEPBp+AefZnXMCHt+H65SnUnQL 7zrPwABIv/dHT6HFMlmiMaB/fUhrTh9VaB3wdEuuRmg/em9AcfqKjge8 Date: Fri, 27 Jan 95 21:06:15 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501272106.aa22813@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Here are the few changes I would recommend. Most are related to concerns of the english language. j' diff draft-metzger-ah-00.txt draft-metzger-ah-00.txt.ala.jpp 45,47c45,47 < This document describes an authentication mechanism for IPv4, by < inserting an intervening header between the IPv4 Header and any < transport headers. --- > This document describes an authentication mechanism for IPv4 which > inserts an intervening header between the IPv4 Header and the > transport headers of the to be authenticated packet. [english concerns] 277c277 < SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are --- > SAID values in the range 0x00000001 through 0x0000000F are [better to keep special values together in a single block. 0x0 is special also.] 293,294c293,294 < have such special processing instructions included in its < specification. --- > have such [what is refered to?] special processing instructions > included in its specification. [I don't know what "such" refers to here. I may just be slow.] 338a339,340 > [Overly specific, move this (good) discussion to the document describing > the digest algorithm.... 353c355 < --- > ...] [This stuff is specific to the authentication alg. and should be moved there.] 367a370,371 > and the authentication algorith does not specify how to handle non- > integral length messages, [I doubt that there will be any authentication functions which don't specify. In any case, when they do there shouldn't be two specifications ofwhat to do.] From ipsec-request@ans.net Fri Jan 27 16:26:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20862 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 03:39:10 -0500 Received: by interlock.ans.net id AA32430 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 03:30:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 03:30:31 -0500 To: atkinson@itd.nrl.navy.mil, perry@piermont.com, Bill.Simpson@um.cc.umich.edu, ipsec@ans.net Subject: Minor suggestions for draft-metzger-esp-des-cbc-01.txt X-Signed: PGP-Detached-2-3, iQBXAwUBLyn/rNC3U5sdKpFdAQFf+gILBT8C3py5pbqum4j+Ii8h3zmwloxLq9p5 phckMLuym+njQdFzLAHlzGJvqBnC/vB0bm6JPk4M/dsRNImcx44Qfanq Date: Sat, 28 Jan 95 0:26:26 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501280027.aa25688@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Here are some changes I propose for -esp-des-cbc-01. j' diff draft-metzger-esp-des-cbc-01.txt draft-metzger-esp-des-cbc-01.txt.ala.jpp 177,179c177,179 < The field may be longer or shorter than the 64-bits used by DES, < in multiples of 32-bits. This allows alignment of the Encrypted < Data for in-place decryption. --- > Although the field must be a multiple of 32-bits long, it may be > longer or shorter than the 64-bits used by DES. This allows > alignment of the Encrypted Data for in-place decryption. [english] 189,190c189,194 < When the size is negotiated to 32-bits, the inverse of the 32-bits < is appended to form a 64-bit value. --- > When the size is negotiated to 32-bits, the inverse of the 32-bit > field value is folowed by the 32-bit field value to form the > 64-bit IV. A fragment of C code which computes this function is > "iv64= ((~ iv32) << 32) | iv32;" Where iv32, and iv64 are > declared to be 64 (or more) bit integers, and the IV is the least > significant 64 bits of iv64. [Be sure to spell it out clearly enough to be implemented. For convienience in the C code, I (might have (but I am not compleately sure (see the problem?))) re-ordered the halves of the IV.] 191a196,201 > When the size is negotiated to be 64-bits, the 64 bits field > value is used as the 64 bit initialization vector. The vector is > created according to a "big-endian" convention; i.e. the first > octet becomes bits 1-8 of the IV, and the last octet becomes bits > 57-64 of the IV. > [still spelling the obvious out, just to be sure. The big-endian stuff should be stuck on each of the paragraphs, or factored out to a final paragraph somehow.] 193,194c203,204 < of the 64-bit value within this field is negotiated by an | < additional parameter. Unused octets are filled with unspecified | --- > of the 64-bit IV within this field is negotiated by an additional | > parameter. Unused octets are filled with unspecified | [english -- keep the name of the IV consistent] 252,253c262,263 < Append zero or more octets of padding to the plain text, to make | < its length in octets modulo 8 equal to 6. | --- > Append zero or more octets of padding to the plain text, to make its | > length in octets equal to 8i + 6, for some integer i greater than 0. | [I thought mathematicians would say "equal to 6 modulo 8", but computer programmers would say "modulo 8 equal to 6". I hope both can read my version without confusion] 261,262c271 < Encrypt the payload with DES in CBC mode, producing a cipher text of | < the same length. | --- > Compute an initialization vector apropriate to the SAID. | 263a273,275 > Encrypt the payload with DES in CBC mode using the computed | > initialization value, producing a cipher text of the same length. | > [Don't forget to make, and use, the IV] 308a321 > [Are these last two correct for both IP-Mode and Transport-Mode?] [re: changing the value of the IP length, and 'delivering' the result.] 341c354 < a better choice for such purposes. --- > a better choice for such purposes. [reference -esp-3des.txt perhaps?] [Would be nice. Would be nice to have such a doc. :) ] From ipsec-request@ans.net Sat Jan 28 09:43:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14469 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 06:02:26 -0500 Received: by interlock.ans.net id AA22000 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 05:53:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 05:53:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 05:53:22 -0500 Date: Sat, 28 Jan 95 09:43:26 GMT From: "William Allen Simpson" Message-Id: <3827.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Minor wording changes Thanks you for your careful reading. I have made some of the changes, but not all. Your definition of "english" is somewhat different than mine. "of the to be"? > > SAID values in the range 0x00000001 through 0x0000000F are > [better to keep special values together in a single block. 0x0 is > special also.] That is not what was agreed elsewhere. It is quite typical of IETF to reserve values at both the beginning and end of a range. > 338a339,340 > > [Overly specific, move this (good) discussion to the document describing > > the digest algorithm.... Diffs are not helpful. I'm looking at nroff, and have not the slightest idea to what you are referring here. Just quote the section, and put some comments after it. "the" document? Many such documents are expected. These sections apply to all mechanisms, so that the text doesn't need to be repeated in each one. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Jan 28 05:59:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22446 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 11:02:29 -0500 Received: by interlock.ans.net id AA02947 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 10:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 10:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 10:59:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 10:59:19 -0500 Date: Sat, 28 Jan 1995 10:59:10 +0500 From: Theodore Ts'o Message-Id: <9501281559.AA18627@dcl.MIT.EDU> To: perry@imsi.com Cc: "Housley, Russ" , ipsec@ans.net In-Reply-To: Perry E. Metzger's message of Fri, 27 Jan 1995 18:07:24 -0500, <9501272307.AA20117@snark.imsi.com> Subject: Re: AH-MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1288 Date: Fri, 27 Jan 1995 18:07:24 -0500 From: "Perry E. Metzger" Does anyone have a concrete argument against the security of MD5 used as we are using it? Not aesthetic concerns, not "well, we don't know if MD5 is secure" (because if it isn't we should just scrap it, period!). I'm looking for an argument of the form... Perry, perhaps there are people in the NSA with crypto clearances for which the art of designing and using cryptosystems is a science, not an art. Unfortunately, those of us who live in the free world do not have this luxury. You will recall that MD5 was designed and pushed out the door not because the author could prove any weaknesses about MD4 --- as far as he knew there are been no attacks on MD4 --- but because he felt "uncomfortable" with some of the design decisions that had been made, and so he added some complexity to MD5, even though this came at the cost of slowing it down. Those of us who are advocating a similar prepend+data+postpend system are making the same sort of argument which led Ron Rvist to design, and us to use, MD5 instead of the faster MD4. Your same argument could be used to say that we should use MD4 instead of MD5, since no one has come up with an attack against MD4! Yet. - Ted From ipsec-request@ans.net Sat Jan 28 16:38:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17617 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 11:41:25 -0500 Received: by interlock.ans.net id AA17632 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 11:39:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 11:39:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 11:39:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 11:39:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 11:39:10 -0500 Message-Id: <9501281638.AA20754@snark.imsi.com> To: "Theodore Ts'o" Cc: "Housley, Russ" , ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Sat, 28 Jan 1995 10:59:10 +0500." <9501281559.AA18627@dcl.MIT.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sat, 28 Jan 1995 11:38:42 -0500 From: "Perry E. Metzger" "Theodore Ts'o" says: > You will recall that MD5 was designed and pushed out the door not > because the author could prove any weaknesses about MD4 --- as far as > he knew there are been no attacks on MD4 --- Other than the ones by Bert den Boer, Antoon Bosselaers, Ralph Merkle, and Elli Biham, all of whom broke two out of three rounds? I'll point out that they used different techniques, adding insult to injury! If you insist, I'll post references. > but because he felt "uncomfortable" with some of the design > decisions that had been made, and so he added some complexity to > MD5, even though this came at the cost of slowing it down. This is untrue, Ted. There ARE partial attacks against MD4 that cannot be performed against MD5. The decision was not made on a hunch, but because of solid evidence that MD4 was weak. If the decision had been made on a hunch, I would not want to use either MD4 or MD5 because I would have not the slightest trust in the designer's judgement. If we are to make our decisions on "hunches", then why should we assume that appending is more secure than embedding the length? How do we know that appending doesn't somehow reduce our security? > Those of us who are advocating a similar prepend+data+postpend system > are making the same sort of argument which led Ron Rvist to design, and > us to use, MD5 instead of the faster MD4. Nope. You are following hunches -- hunches that don't have any justification. He was following about three refereed math papers. Perry From ipsec-request@ans.net Sat Jan 28 08:58:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17627 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 14:09:04 -0500 Received: by interlock.ans.net id AA44686 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 13:59:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Sat, 28 Jan 1995 13:59:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 13:59:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 13:59:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 13:59:08 -0500 Date: Sat, 28 Jan 95 13:58:54 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9501281858.AA19894@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 13:59:08 -0500 To: ipsec@ans.net Subject: SHA document Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission I am finishing up an SHA-AH document, and I was wondering if anyone out there had the reference for the corrected FIPS for SHA. I'll be needing it. Perry From ipsec-request@ans.net Sat Jan 28 19:42:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14731 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 14:44:24 -0500 Received: by interlock.ans.net id AA32441 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 14:39:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 14:39:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 14:39:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 14:39:42 -0500 Message-Id: <9501281945.AA26048@hughes.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Jan 1995 04:42:14 +0900 To: "Housley, Russ" , perry@imsi.com, hugo@watson.ibm.com From: hughes@hughes.network.com (James P Hughes) Subject: Re: AH-MD5 Cc: IPSEC@ans.net At 1:00 PM 1/27/95 -0600, Housley, Russ wrote: > Let's just adopt prepend+data+append and move on. I agree. 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 Sat Jan 28 10:57:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13246 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 16:02:31 -0500 Received: by interlock.ans.net id AA45070 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 15:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 15:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 15:57:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 15:57:09 -0500 Date: Sat, 28 Jan 1995 15:57:01 +0500 From: Theodore Ts'o Message-Id: <9501282057.AA18665@dcl.MIT.EDU> To: perry@imsi.com Cc: "Theodore Ts'o" , "Housley, Russ" , ipsec@ans.net In-Reply-To: Perry E. Metzger's message of Sat, 28 Jan 1995 11:38:42 -0500, <9501281638.AA20754@snark.imsi.com> Subject: Re: AH-MD5 Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1555 Date: Sat, 28 Jan 1995 11:38:42 -0500 From: "Perry E. Metzger" "Theodore Ts'o" says: > You will recall that MD5 was designed and pushed out the door not > because the author could prove any weaknesses about MD4 --- as far as > he knew there are been no attacks on MD4 --- Other than the ones by Bert den Boer, Antoon Bosselaers, Ralph Merkle, and Elli Biham, all of whom broke two out of three rounds? I'll point out that they used different techniques, adding insult to injury! If you insist, I'll post references. When were those papers published? The MD5 RFC (April 1992) refereneced none of those papers when it discussed why MD5 was released: The MD5 algorithm is an extension of the MD4 message-digest algorithm 1,2]. MD5 is slightly slower than MD4, but is more "conservative" in design. MD5 was designed because it was felt that MD4 was perhaps being adopted for use more quickly than justified by the existing critical review; because MD4 was designed to be exceptionally fast, it is "at the edge" in terms of risking successful cryptanalytic attack. MD5 backs off a bit, giving up a little in speed for a much greater likelihood of ultimate security. It incorporates some suggestions made by various reviewers, and contains additional optimizations. The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard. Notice words such as "felt" and "likelihood"...... those are hunch-like words don't they? - Ted From ipsec-request@ans.net Sat Jan 28 21:44:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14783 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 16:47:54 -0500 Received: by interlock.ans.net id AA55664 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 16:44:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 16:44:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 16:44:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 16:44:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 16:44:35 -0500 Message-Id: <9501282144.AA21162@snark.imsi.com> To: "Theodore Ts'o" Cc: ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Sat, 28 Jan 1995 15:57:01 +0500." <9501282057.AA18665@dcl.MIT.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sat, 28 Jan 1995 16:44:12 -0500 From: "Perry E. Metzger" "Theodore Ts'o" says: > From: "Perry E. Metzger" > > "Theodore Ts'o" says: > > You will recall that MD5 was designed and pushed out the door not > > because the author could prove any weaknesses about MD4 --- as far as > > he knew there are been no attacks on MD4 --- > > Other than the ones by Bert den Boer, Antoon Bosselaers, Ralph Merkle, > and Elli Biham, all of whom broke two out of three rounds? I'll point > out that they used different techniques, adding insult to injury! > If you insist, I'll post references. > > When were those papers published? Don't know when the results were first known on the grapevine, but I know for sure that at least some were presented long (i.e. a year) before the MD5 document. I got these two just doing a cursory scan of Schneier; I'm sure I could dig for more. 1) B. den Boer and A. Bosselaers, "An Attack on the Last Two Rounds of MD4", Advances in Cryptology -- Crypto '91 Proceedings, Berlin, Springer-Verlag, 1992, pp 194-203 [Crypto '91 was substantially before MD5 came out, although the proceedings lagged a bit in publication.] 2) E. Biham, "On the Applicability of Differential Cryptanalysis to Hash Functions," lecture at Workshop on Cryptographic Hash Functions, March 1992 [This was also before MD5 came out; I suspect the work was done earlier and conveyed to Rivest, though I haven't asked -- never came up before now.] > The MD5 RFC (April 1992) refereneced > none of those papers when it discussed why MD5 was released: Its an RFC, not a scholarly document. Also, the MD5 document told the literal truth when it said that MD4 had not been broken -- it hadn't been completely broken, just two out of three rounds. It was enough of a partial break to be of cryptographic significance and to disturb people. I'm trying to make sure that the RFCs coming out of the stuff Bill and I are doing will be a bit better in the scholarship department -- I'm including substantial notes in the security considerations section on the known cryptographic problems in these systems and enough references to let people follow the trail if they like. > Notice words such as "felt" and "likelihood"...... those are hunch-like > words don't they? Maybe, but there was serious scholarship out breaking multiple rounds of MD4 well in advance of MD5 coming out. As I've noted, there are also partial breaks of MD5. There are no known attacks other than brute force against the current SHA. I've just completed an SHA-AH document; Bill is editing it as I write this. Again, can we be serious here? The append vs. including length debate hasn't been conducted with any real scholarship. Anyone care to attempt to prove the security of the system assuming that the underlying hash actually has the claimed properties of a cryptographic hash? (Dunno if I have time, but I suspect it won't be hard.) And on another serious note, I again raise the question: should we adopt MD5, or SHA, or something else? Also, does anyone have benchmarks of SHA? Perry From ipsec-request@ans.net Sat Jan 28 12:51:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13435 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 17:59:34 -0500 Received: by interlock.ans.net id AA31571 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 17:54:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 17:54:30 -0500 Message-Id: <199501282254.AA04430@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 17:54:30 -0500 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: AH-MD5 Date: Sat, 28 Jan 95 17:51:43 EST And on another serious note, I again raise the question: should we adopt MD5, or SHA, or something else? If we're shooting for the long run, we need SHA. SHA (and for that matter Skipjack) were designed to meet a stated a priori requirement of 80 bits of strength. That number seems reasonable to me, given the historic hardware speed-doubling time. There's already been progress at brute-force cracking of MD5; see the paper by Wiener and someone else at the November '94 Fairfax conference. For that matter, we can say that MD5's 64 bits of strength (against a birthday attack) should be vulnerable 12 years after DES is vulnerable, purely based on exhaustive search time considerations. And we know that that's economically feasble now. (On the other hand, one could argue that there's no point in our authentication function being much stronger than our cryptosystem...) --Steve Bellovin From ipsec-request@ans.net Sat Jan 28 08:18:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17431 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 19:23:02 -0500 Received: by interlock.ans.net id AA02971 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 19:19:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 19:19:38 -0500 To: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <3827.bill.simpson@um.cc.umich.edu> Subject: Re: Minor wording changes X-Signed: PGP-Detached-2-3, iQBXAwUBLyrettC3U5sdKpFdAQH+5wIMCLgLxY5bCLi28rMTwxwKI+aqfiyUHgEh xNc1olB7FheGvBM99zV/690FGgq7H2K++iNGJbnQd7eNpGLWNcDfd9zb Date: Sat, 28 Jan 95 16:18:01 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501281618.aa18880@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. > Date: Sat, 28 Jan 95 09:43:26 GMT > From: "William Allen Simpson" > > Thanks you for your careful reading. Thank you authors for creating the document. > I have made some of the changes, but not all. Your definition of > "english" is somewhat different than mine. That is to be expected. And since you are (one of) the authors, your english wins! > That is not what was agreed elsewhere. It is quite typical of IETF to > reserve values at both the beginning and end of a range. Hmm. I don't see any advantage in having two reserved ranges (other than looking like a member of the IETF comunity). But I do see a couple of (minor) costs. (1) code size, speed, or complexity: two if statements (cmp instructions) instead of one. (2) code correctness: two places to get wrong and introduce a potentialy compromising bug. I, unfortuneately, missed the discussions where the two-range decision was made, and so I haven't heard why two-ranges was chosen. If someone wants to volunteer to explain its advantages to me, I would be happy to learn. But, I won't be hurt if no one volunteers. > > 338a339,340 > > > [Overly specific, move this (good) discussion to the document describing > > > the digest algorithm.... > > Diffs are not helpful. I'm looking at nroff, and have not the slightest > idea to what you are referring here. Just quote the section, and put > some comments after it. Sorry about the diff format. I have put my versions of these documents are in ftp://ftp.markv.com/jpp/ipsec/* for the group's reading pleasure. Anyway, here is the section in question: [Overly specific, move this (good) discussion to the document describing the digest algorithm.... When a keyed message digest algorithm is used (such as MD5), the secret key is fed into the algorithm first, followed by the invariant fields of the IP datagram in sequence. The secret key is fed in first, because that increases the work function for someone attempting to cryptanalyse the key from knowledge of the plaintext datagram. Feeding the secret key in first also permits implementations to precompute the start of the hash for a given destination, and possibly improve performance thereby. The key does not need to be fed in at the end. Including the IP Header's invariant Total Length field in the authentication calculation precludes appending attacks. ...] I belive it makes some overly strong assumptions about the nature of keyed digest functions. (It seems to assume that there is an ordering between the key and the message. That may be common, but isn't required. Concider the keyed digest algorithm (I just made up) which does unkeyed MD5 of DES-ECB of the message. The key for this digest algorithm is in the key to the DES-ECB step, and not in any order with the message at all.) It would be better to address this sort of issue in each of the ah-{md5,sha,...} documents, rather than here in the main document. But that's just MHO. j' From ipsec-request@ans.net Sat Jan 28 19:36:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24387 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 19:36:19 -0500 Received: by interlock.ans.net id AA02833 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 19:33:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 19:33:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 19:33:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 19:33:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 19:33:19 -0500 Message-Id: <9501290033.AA21380@snark.imsi.com> To: ipsec@ans.net Cc: bsimpson@morningstar.com, smb@research.att.com Subject: SHA + generic auth specs? (was Re: AH-MD5) In-Reply-To: Your message of "Sat, 28 Jan 1995 17:51:43 EST." <199501282254.AA04430@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sat, 28 Jan 1995 19:33:06 -0500 From: "Perry E. Metzger" ***NOTE***: serious question for thought at the end of this document! If you skip it, don't be suprised if you see something odd in upcoming documents! smb@research.att.com says: > If we're shooting for the long run, we need SHA. > > SHA (and for that matter Skipjack) were designed to meet a stated > a priori requirement of 80 bits of strength. That number seems reasonable > to me, given the historic hardware speed-doubling time. There's already > been progress at brute-force cracking of MD5; see the paper by Wiener > and someone else at the November '94 Fairfax conference. There have also been some partial attacks made against MD5 by Bert den Boer and Antoon Bosselaers -- not really practical attacks, but SHA doesn't suffer from the same problem. > (On the other hand, one could argue that there's no point in our > authentication function being much stronger than our cryptosystem...) The 3DES document is done; 3DES with independent keys is thought to have about 112 bits of strength. (Note that because of clever attacks it doesn't actually have 168 bits of strength, but two independent keys systems have no more than 108 bits of strength so it is probably worth having three keys -- anyone who disagrees should speak up now!) I'll happily cooperate with people in drafting their documents for their favorite systems (IDEA comes to mind). INTERESTING BIT COMES HERE: Now on another serious note, I've discovered an opportunity for a design fix in the way I'm doing combined crypto+auth under the ESP. Mostly, the auth systems are based on hashes and are orthogonal to the cipher systems. However, we don't want to use the AH combined with a cipher-only ESP for combined privacy and auth because it wastes too much space and causes two passes through the section of the kernel dealing with the crypto (which costs!). (We allow people to combine them, but we don't want to force people to do things that way). We (meaning I) were thus going to do combined cipher+hash ESP documents for those wanting both, like DES-CBC+MD5. However, as I sit down to write those documents, it has occured to me that I'm about to write the DES+MD5, 3DES+MD5, IDEA+MD5, DES+SHA, etc, etc, documents, on ad infinitum, with the number of documents approaching #ciphers times #hashes -- not a good thing, especially since the ciphers and hashes don't interact terribly much in these documents. I'd like to know if people think its okay if we specify a generic any cipher+MD5 ESP and a generic any cipher+SHA ESP. Were I to do that, it would reduce to two the number of outstanding transform documents I'd have to write and would mean that any newly defined cipher document would automatically have an authenticated version, and that any new MAC or hash would automatically work across all ciphers. This would, however, complicate key negotiation and the like. Perry From ipsec-request@ans.net Sat Jan 28 15:13:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21369 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 20:16:32 -0500 Received: by interlock.ans.net id AA40830 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 20:13:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Sat, 28 Jan 1995 20:13:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 20:13:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 20:13:18 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 20:13:18 -0500 Date: Sat, 28 Jan 95 20:13:13 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9501290113.AA20720@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 20:13:18 -0500 To: ipsec@ans.net Cc: perry@imsi.com Subject: risks of MACs associated with packets Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission A small serious question about message authenticators in the ESP (not the AH!) environment. Now, we all seem to be pretty happy with keyed hashes as authenticators -- but we are using no initialization vectors on these things. That means that the odds of two identical payload messages having identical authenticators is very high (especially since the only part of the packets likely to vary is the Ident field in the IPv4 packet, which is very short -- in an IPv6 packet no portion would vary at all!) This makes for the following question: should we be 1) adding initialization vectors to our authenticators? (I vote no). 2) placing our authenticators in the ESP under protection of the crypto algorithm? (Might make for extra crypto work.) 3) Authenticating the cyphertext instead of the cleartext? 4) something else? I vote for 2 or 3, with my current leaning to 3 since its somewhat ligher weight. Of course, 2 has the nice property that before they can even start to attack your authenticator they have to break your cipher, but of course in 3 it might be hard for them to fake you out for long even if they do manage to fake authenticators on you. The issues merit discussion. In either case, we have to use different keys for our keyed hashes from the ones our ciphers are using or we make cryptanalysis just a bit too easy for my tastes (any comments on that?)... Perry From ipsec-request@ans.net Sat Jan 28 21:02:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20808 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 21:02:08 -0500 Received: by interlock.ans.net id AA54606 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 20:55:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 20:55:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 20:55:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 20:55:42 -0500 Message-Id: <9501290157.AA20632@skidrow.tay.dec.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: risks of MACs associated with packets In-Reply-To: Your message of "Sat, 28 Jan 95 20:13:13 EST." <9501290113.AA20720@webster.imsi.com> Date: Sat, 28 Jan 95 20:57:09 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I think, as I believe Phil Karn does, that you want authentication to be outside of your encyrption so that it is less work to throw away bogus packets and so that intermediate points can, if properly configured, authenticate the message without reading it. Donald From: perry@imsi.com (Perry E. Metzger) To: ipsec@ans.net Cc: perry@imsi.com Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission >A small serious question about message authenticators in the ESP (not >the AH!) environment. > >Now, we all seem to be pretty happy with keyed hashes as >authenticators -- but we are using no initialization vectors on these >things. That means that the odds of two identical payload messages >having identical authenticators is very high (especially since the >only part of the packets likely to vary is the Ident field in the IPv4 >packet, which is very short -- in an IPv6 packet no portion would vary >at all!) > >This makes for the following question: should we be > >1) adding initialization vectors to our authenticators? (I vote no). >2) placing our authenticators in the ESP under protection of the > crypto algorithm? (Might make for extra crypto work.) >3) Authenticating the cyphertext instead of the cleartext? >4) something else? > >I vote for 2 or 3, with my current leaning to 3 since its somewhat >ligher weight. Of course, 2 has the nice property that before they can >even start to attack your authenticator they have to break your >cipher, but of course in 3 it might be hard for them to fake you out >for long even if they do manage to fake authenticators on you. The >issues merit discussion. > >In either case, we have to use different keys for our keyed hashes >from the ones our ciphers are using or we make cryptanalysis just a >bit too easy for my tastes (any comments on that?)... > >Perry From ipsec-request@ans.net Sat Jan 28 21:49:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20329 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 21:49:52 -0500 Received: by interlock.ans.net id AA37605 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 21:45:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 21:45:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 21:45:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 21:45:59 -0500 Message-Id: <9501290246.AA22076@skidrow.tay.dec.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: SHA + generic auth specs? (was Re: AH-MD5) In-Reply-To: Your message of "Sat, 28 Jan 95 19:33:06 EST." <9501290033.AA21380@snark.imsi.com> Date: Sat, 28 Jan 95 21:46:46 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Yikes! The goal is INTEROPERABILITY. Please don't define a zillion alternatives just out of some desire to document all the suggestions that come along. I don't think it makes that much difference whether we use MD5 or SHA. I personally favor SHA, but MD5 is what has always been "decided" at the WG meetings at the IETF meetings and is the Internet standard. We need documents to progress to a reasonable proposed standard. I'd be happy to do this with documents with either MD5 or SHA. I don't think everyone should have to implement both. Donald From: "Perry E. Metzger" To: ipsec@ans.net Cc: bsimpson@morningstar.com, smb@research.att.com In-Reply-To: Your message of "Sat, 28 Jan 1995 17:51:43 EST." <199501282254.AA04430@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission > >***NOTE***: serious question for thought at the end of this document! >If you skip it, don't be suprised if you see something odd in upcoming >documents! > >smb@research.att.com says: >> If we're shooting for the long run, we need SHA. >> >> SHA (and for that matter Skipjack) were designed to meet a stated >> a priori requirement of 80 bits of strength. That number seems reasonable >> to me, given the historic hardware speed-doubling time. There's already >> been progress at brute-force cracking of MD5; see the paper by Wiener >> and someone else at the November '94 Fairfax conference. > >There have also been some partial attacks made against MD5 by Bert den >Boer and Antoon Bosselaers -- not really practical attacks, but SHA >doesn't suffer from the same problem. > >> (On the other hand, one could argue that there's no point in our >> authentication function being much stronger than our cryptosystem...) > >The 3DES document is done; 3DES with independent keys is thought to >have about 112 bits of strength. (Note that because of clever attacks >it doesn't actually have 168 bits of strength, but two independent >keys systems have no more than 108 bits of strength so it is probably >worth having three keys -- anyone who disagrees should speak up now!) > >I'll happily cooperate with people in drafting their documents for >their favorite systems (IDEA comes to mind). > >INTERESTING BIT COMES HERE: > >Now on another serious note, I've discovered an opportunity for a >design fix in the way I'm doing combined crypto+auth under the >ESP. > >Mostly, the auth systems are based on hashes and are orthogonal to the >cipher systems. However, we don't want to use the AH combined with a >cipher-only ESP for combined privacy and auth because it wastes too >much space and causes two passes through the section of the kernel >dealing with the crypto (which costs!). (We allow people to combine >them, but we don't want to force people to do things that way). > >We (meaning I) were thus going to do combined cipher+hash ESP >documents for those wanting both, like DES-CBC+MD5. However, as I sit >down to write those documents, it has occured to me that I'm about to >write the DES+MD5, 3DES+MD5, IDEA+MD5, DES+SHA, etc, etc, documents, >on ad infinitum, with the number of documents approaching >#ciphers times #hashes -- not a good thing, especially since the >ciphers and hashes don't interact terribly much in these documents. > >I'd like to know if people think its okay if we specify a generic any >cipher+MD5 ESP and a generic any cipher+SHA ESP. Were I to do that, it >would reduce to two the number of outstanding transform documents I'd >have to write and would mean that any newly defined cipher document >would automatically have an authenticated version, and that any new >MAC or hash would automatically work across all ciphers. This would, >however, complicate key negotiation and the like. > >Perry From ipsec-request@ans.net Sat Jan 28 22:12:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20791 (5.65c/IDA-1.4.4 for ); Sat, 28 Jan 1995 22:12:38 -0500 Received: by interlock.ans.net id AA37570 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 28 Jan 1995 22:09:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sat, 28 Jan 1995 22:09:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 28 Jan 1995 22:09:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 28 Jan 1995 22:09:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 28 Jan 1995 22:09:10 -0500 Message-Id: <9501290305.AA21655@snark.imsi.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re: SHA + generic auth specs? (was Re: AH-MD5) In-Reply-To: Your message of "Sat, 28 Jan 1995 21:46:46 EST." <9501290246.AA22076@skidrow.tay.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sat, 28 Jan 1995 22:05:16 -0500 From: "Perry E. Metzger" "Donald E. Eastlake 3rd (Beast)" says: > Yikes! > > The goal is INTEROPERABILITY. Please don't define a zillion > alternatives just out of some desire to document all the suggestions > that come along. I don't intend to -- or at least, only certain base documents will be "MUST" parts of the standard (see below). However, it does prevent the n * m documents problem, and the n * m implementations problem, if new cipher or auth transforms can fit together with old auth and cipher transforms (respectively). There *will* be new transforms with time. > I don't think it makes that much difference whether we use MD5 or SHA. > I personally favor SHA, but MD5 is what has always been "decided" at > the WG meetings at the IETF meetings and is the Internet standard. > > We need documents to progress to a reasonable proposed standard. I'd > be happy to do this with documents with either MD5 or SHA. I don't > think everyone should have to implement both. The intention was to mandate a base standard for interoperability -- originally DES, MD5, and DES+MD5, and permit consenting hosts to use better things as time went on. Thats still the intent. Perry From ipsec-request@ans.net Sun Jan 29 01:33:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14659 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 10:42:45 -0500 Received: by interlock.ans.net id AA06612 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 10:33:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 29 Jan 1995 10:33:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 10:33:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 10:33:31 -0500 Date: Sun, 29 Jan 95 08:33:20 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501291533.AA14527@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 Cc: perry@imsi.com > 1) Use IVs on hashes > 2) Encrypt the authenticators > 3) Authenticate the ciphertext > 4) Other I vote for 2, or maye 3, but strongly feel that the authentication should be either *over* or *under* the encryption - not halfway. If you put the cipher IV into the hash (which you NEED to do if authenticating the ciphertext, anyway - imagine not doing it and having an opponent play with the IV, especially for CBC), it prevents the sort of repeat attack you mentioned. -- -Colin From ipsec-request@ans.net Sun Jan 29 06:28:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24505 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 11:35:08 -0500 Received: by interlock.ans.net id AA32291 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 11:30:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 11:30:07 -0500 Message-Id: <199501291630.AA32287@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 11:30:07 -0500 To: ipsec@ans.net Subject: patent issues on keyed MD5? Cc: gts@ibm.com, schneier@chinet.com, gnu@cygnus.com Date: Sun, 29 Jan 95 11:28:47 EST Folks, we may have a patent issue to contend with. Novell was recently issued U.S. patent number 5,349,642 (my thanks to Tim Farley for posting this information to alt.security and comp.security.misc); it appears to cover the notion of message authentication via a key cryptographic hash function. The patent was filed on 11/03/1992 and issued on 9/20/1994. There may be a question of priority. Tsudik's paper describing keyed hash functions was presented at a conference in May 1992, according to the Postscript copy I have. But I don't know who came up with the idea first, and the U.S. is a first-to-invent country. Nor do I know when the notion was first used for NTP or SNMP authentication. --Steve Bellovin P.S. The patent text is in http://www.town.hall.org/Archives/patent/data2/05349/05349642 From ipsec-request@ans.net Sun Jan 29 16:17:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20453 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 11:44:45 -0500 Received: by interlock.ans.net id AA53576 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 11:40:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 11:40:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 11:40:09 -0500 Date: Sun, 29 Jan 95 16:17:25 GMT From: "William Allen Simpson" Message-Id: <3834.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Reply-To: bsimpson@morningstar.com Subject: Re: Minor wording changes > From: jpp@markv.com > [Overly specific, move this (good) discussion to the document describing > the digest algorithm.... > When a keyed message digest algorithm is used (such as MD5), the > secret key is fed into the algorithm first, followed by the invariant > fields of the IP datagram in sequence. > ... > > I belive it makes some overly strong assumptions about the nature of > keyed digest functions. (It seems to assume that there is an ordering > between the key and the message. That may be common, but isn't > required. First, it is absolutely imperative that the invariant fields of the IP datagram are authenticated. So, that needs to be specified up front! As another message from Eastlake mentions, the goal is interoperability. We need to _eliminate_ many options, rather than try to accomodate unknown possible future schemes. By specifying that the mechanism will always be used in a single standard way, we make it easier to drop another algorithm into the same code. Over generalization would make that hard to do, and confuse implementors. By specifying only 2 algorithms, both freely available, one MUST and the second SHOULD, we hope to provide enough for the forseeable future. Both algorithms use this method. Best to stick with what we know, rather than endlessly hypothesizing future possibilities. That's what this group did for 2 years.... Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sun Jan 29 17:00:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24496 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 12:08:07 -0500 Received: by interlock.ans.net id AA55746 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 12:01:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Sun, 29 Jan 1995 12:01:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 29 Jan 1995 12:01:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 12:01:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 12:01:06 -0500 Message-Id: <9501291700.AA22278@snark.imsi.com> To: smb@research.att.com Cc: ipsec@ans.net, gts@ibm.com, schneier@chinet.com, gnu@cygnus.com Subject: Re: patent issues on keyed MD5? In-Reply-To: Your message of "Sun, 29 Jan 1995 11:28:47 EST." <199501291630.AA32287@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 29 Jan 1995 12:00:33 -0500 From: "Perry E. Metzger" smb@research.att.com says: > Folks, we may have a patent issue to contend with. Novell was recently > issued U.S. patent number 5,349,642 (my thanks to Tim Farley for posting > this information to alt.security and comp.security.misc); it appears to > cover the notion of message authentication via a key cryptographic hash > function. The patent was filed on 11/03/1992 and issued on 9/20/1994. > > There may be a question of priority. Tsudik's paper describing keyed > hash functions was presented at a conference in May 1992, according to > the Postscript copy I have. But I don't know who came up with the idea > first, and the U.S. is a first-to-invent country. Nor do I know when > the notion was first used for NTP or SNMP authentication. My feeling is that this is Yet Another Bad Patent. I heard about the notion well in advance of May 1992 -- I'm almost certain that it was discussed informally in the advanced cryptography seminar I was a part of in 1991, although I have yet to find my notes, and certainly the notion has been floating around as long as the notion of cryptographic hash functions has. If we were to give in on this, we'd also have to give in to that !#@% who claims that he has a patent on networks in general (still being litigated in spite of the obvious prior art) and the !@#$%# who claims he has a patent on client-server computing, and all the others. The X Consortium long ago adopted a policy of ignoring such stuff -- they've never given in on the bogus AT&T backing store patent or the XOR patent -- and I, for one, intend to ignore this patent, too. If Novell bothers me, they can talk to my lawyers. Its one thing if a patent is halfway legitimate, but its another if it was granted on an obvious notion that there was substantial prior art for. Perry From ipsec-request@ans.net Sun Jan 29 17:02:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14423 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 13:09:04 -0500 Received: by interlock.ans.net id AA08935 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 13:03:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 13:03:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 13:03:35 -0500 Date: Sun, 29 Jan 95 17:02:50 GMT From: "William Allen Simpson" Message-Id: <3835.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: gts@ibm.com, schneier@chinet.com, gnu@cygnus.com Reply-To: bsimpson@morningstar.com Subject: Re: patent issues on keyed MD5? > From: smb@research.att.com > Folks, we may have a patent issue to contend with. Novell was recently > issued U.S. patent number 5,349,642 (my thanks to Tim Farley for posting > this information to alt.security and comp.security.misc); it appears to > cover the notion of message authentication via a key cryptographic hash > function. The patent was filed on 11/03/1992 and issued on 9/20/1994. > What?!?!? Well, PPP had "published" draft work (CHAP) using a keyed cryptographic hash function for authentication in 1991. It was in design review for a year, and published as a Proposed Standard in October 1992. And that was based on the Telebit NetBlazer, which was shipping product in 1991. And that was based on work in IBM's SNA and Sytek's Poloneous, and Dave Kaufman's masters thesis work (a form of publication) at UCLA in 1976, and other work by Frank Heinrich and Karl Auerbach at SDC. Time to look at the fraud statutes as applied to bogus patent applications. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sun Jan 29 04:37:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21366 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 15:43:20 -0500 Received: by interlock.ans.net id AA53526 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 15:40:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 15:40:08 -0500 To: perry@imsi.com Cc: ipsec@ans.net, bsimpson@morningstar.com, smb@research.att.com In-Reply-To: <9501290033.AA21380@snark.imsi.com> (perry@imsi.com) Subject: Re: SHA + generic auth specs? (was Re: AH-MD5) Date: Sun, 29 Jan 95 12:37:27 PST From: jpp@markv.com Sender: jpp@markv.com Message-Id: <9501291237.aa28613@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. I think you can solve the problem with only one document. Why not address the crypt+auth by specifying a transformation of the headers that would have been produced had auth(crypt(message)) been done. I.e. specify how to compress AH+ESP headers. Naive implementations can do it in two passes, fast implementations in one. Picky routers can check the cleartext auth. Why would you need to reference the particular auth function in the generic crypt+auth document? j' From ipsec-request@ans.net Sun Jan 29 08:44:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21544 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 17:49:55 -0500 Received: by interlock.ans.net id AA32502 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 17:44:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 29 Jan 1995 17:44:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 17:44:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 17:44:54 -0500 Date: Sun, 29 Jan 95 15:44:27 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501292244.AA07028@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: perry@imsi.com, smb@research.att.com Subject: Re: patent issues on keyed MD5? Cc: gnu@cygnus.com, gts@ibm.com, ipsec@ans.net, schneier@chinet.com A possible easy way around (that is cryptographically equivalent) is to key the initial seed values for MD5 or SHA instead of filling the first block with key data. IF the value you add to the default MD5 initial seed values happens to be the result of Md5Transform on the key data, so what. It's a pseudo-random function. It doesn't matter what you give it as input, as long as it's well distributed. -- -Colin From ipsec-request@ans.net Mon Jan 30 01:49:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17418 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 20:53:26 -0500 Received: by interlock.ans.net id AA32352 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 20:49:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 29 Jan 1995 20:49:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 20:49:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 20:49:30 -0500 Date: Sun, 29 Jan 1995 18:49:19 -0700 From: Hilarie Orman Message-Id: <199501300149.SAA06353@umbra.CS.Arizona.EDU> To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <9501282144.AA21162@snark.imsi.com> Subject: Re: AH-MD5 > Also, does anyone have benchmarks of SHA? Makes DES look zippy. From ipsec-request@ans.net Mon Jan 30 02:24:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22510 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 21:28:23 -0500 Received: by interlock.ans.net id AA30190 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 21:24:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 21:24:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 21:24:07 -0500 Date: Sun, 29 Jan 1995 18:24:02 -0800 From: Syu-Ping Wang Message-Id: <199501300224.SAA18660@pollux.usc.edu> To: ipsec@ans.net Subject: Please remove me from the mailing list, Thank you Sorry for the inconvenience, please delete my email address from the mailing list. From ipsec-request@ans.net Sun Jan 29 14:27:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06941 (5.65c/IDA-1.4.4 for ); Sun, 29 Jan 1995 23:31:29 -0500 Received: by interlock.ans.net id AA27807 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 29 Jan 1995 23:28:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Sun, 29 Jan 1995 23:28:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Jan 1995 23:28:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Jan 1995 23:28:03 -0500 Date: Sun, 29 Jan 95 21:27:48 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9501300427.AA20362@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: Benchmarks of SHA? Perry asked: > Also, does anyone have benchmarks of SHA? to which Hilarie Orman replied: > Makes DES look zippy. Um.. excuse me? It is significantly faster than DES. One round of SHA is comparable in complexity to one round of MD5, but there are 80 as opposed to 64 of them, and the XOR key expansion is used instead of choosing the inputs in odd patterns. On a 32-register machine, it should be possible to perform everything in registers, a significant speedup over DES, which requires large tables for speed. SHA is considerably faster than DES. Even when used as a cipher (a block size of 20 instead of 64), it is much faster than DES. 44 seconds to process 10,000,000 bytes on a 25 MHz 68030. (Or is that 16? I forget.) -- -Colin From ipsec-request@ans.net Mon Jan 30 04:10:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17438 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 04:10:31 -0500 Received: by interlock.ans.net id AA21956 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 04:04:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 04:04:58 -0500 Message-Id: <199501300904.AA21952@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 04:04:58 -0500 Date: Mon, 30 Jan 95 10:04:51 WET From: gts@zurich.ibm.com To: ipsec@ans.net, smb@research.att.com, schneier@chinet.com Subject: Keyed hash functions, Novell's patent Ref: Your note of Sun, 29 Jan 95 11:40:20 EST Folks: I hope that the issue with Novell's patent can be resolved... Indeed, I presented my paper at the 92 Infocom (May) in Florence. Moreover, a rougher version of the very same "paper" is included in the appendix of my PhD thesis which was approved/recorded in April 1991 at the University of Southern California. This is almost a full year earlier than Infocom. (It includes both key-prefix and key-suffix methods.) To the best of my knowledge the idea of using key as a prefix was also (independently) suggested by Steve Kent and Dave Solo who were (back in 90/91) involved with SNMP security features. I recall having an email discussion with them about this subject in the Fall of 90. I also remember seeing a paper by Li Gong where he proposed something quite similar. Cheers, Gene p.s. The Infocom paper can be obtained as: ftp://jerico.usc.edu/gene/www/paps/t92.ps.Z From ipsec-request@ans.net Mon Jan 30 13:02:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16160 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 08:13:23 -0500 Received: by interlock.ans.net id AA45153 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 08:07:29 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 08:07:29 -0500 From: Ran Atkinson Message-Id: <9501300802.ZM7584@bodhi.nrl.navy.mil> Date: Mon, 30 Jan 1995 08:02:03 -0500 In-Reply-To: smb@research.att.com "Re: AH-MD5" (Jan 28, 17:51) References: <199501282254.AA04430@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: AH-MD5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil IMNVHO, The long-run algorithm should NOT be our focus now. Our focus now should be on 1) algorithm-indendent protocol specs and 2) a right-now algorithm that is good enough, but not necessarily perfect, and has tolerable performance. The early performance data I'm hearing about for SHA makes me VERY doubtful that it is practical to deploy SHA universally or to get it used on very many packets. We need an authentication-without- confidentiality mechanism that is practical to use on virtually every packet with acceptable performance. SHA does not appear to be that algorithm at this time with currently available commercial systems (e.g. 90MHz 586s, SPARCs, Alphas, etc). Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Jan 30 18:01:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07019 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 13:14:25 -0500 Received: by interlock.ans.net id AA36600 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 13:01:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 30 Jan 1995 13:01:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 30 Jan 1995 13:01:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 30 Jan 1995 13:01:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 13:01:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 13:01:43 -0500 From: uri@watson.ibm.com Message-Id: <9501301801.AA19748@buoy.watson.ibm.com> Subject: Re: AH-MD5 To: ho@cs.arizona.edu (Hilarie Orman) Date: Mon, 30 Jan 1995 13:01:38 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199501300149.SAA06353@umbra.CS.Arizona.EDU> from "Hilarie Orman" at Jan 29, 95 06:49:19 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: 285 Hilarie Orman says: > > Also, does anyone have benchmarks of SHA? > Makes DES look zippy. Oh, come on... My preliminary and completely unscientific benchmark showed it to be about twice as slow as MD5... -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Mon Jan 30 18:07:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20853 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 13:40:58 -0500 Received: by interlock.ans.net id AA31981 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 13:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 13:29:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 13:29:51 -0500 Date: Mon, 30 Jan 95 18:07:25 GMT From: "William Allen Simpson" Message-Id: <3843.bill.simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: touch@isi.edu Reply-To: bsimpson@morningstar.com Subject: MD5 versus SHA > From: Ran Atkinson > IMNVHO, The long-run algorithm should NOT be our focus now. > Our focus now should be on > 1) algorithm-indendent protocol specs > and 2) a right-now algorithm that is good enough, but not > necessarily perfect, and has tolerable performance. > I somewhat agree, but it _is_ valuable to prepare for the possible next generation, vis a vis 3DES. > The early performance data I'm hearing about for SHA makes me VERY > doubtful that it is practical to deploy SHA universally or to get > it used on very many packets. We need an authentication-without- > confidentiality mechanism that is practical to use on virtually every > packet with acceptable performance. Absolutely! You do remember my comments about slow embedded 186's? > SHA does not appear to be > that algorithm at this time with currently available commercial systems > (e.g. 90MHz 586s, SPARCs, Alphas, etc). > That's disappointing. I had hoped that with the lessons learned, and the fact that it was based on MD4, it could be _FASTER_ than MD5. Unfortunately, the Touch report on MD5 doesn't include 68K machines, so I can't compare MD5 and the report of SHA 4.4 MBps for 68030/25 -- which would be 32+ Mbps, much faster than the MD5 20 Mbps on the 486/33. Anyway, I sent the SHA draft off to CNRI, and we can test MD5 against SHA in the best way possible -- on the same machine with the same data in the same Headers! Could ISI put together a quick test of SHA in one of it's platforms? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Jan 30 18:43:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16464 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 13:59:27 -0500 Received: by interlock.ans.net id AA50937 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 13:48:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 13:48:19 -0500 From: Ran Atkinson Message-Id: <9501301343.ZM8076@bodhi.nrl.navy.mil> Date: Mon, 30 Jan 1995 13:43:23 -0500 In-Reply-To: uri@watson.ibm.com "Re: AH-MD5" (Jan 30, 13:01) References: <9501301801.AA19748@buoy.watson.ibm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: uri@watson.ibm.com, Hilarie Orman Subject: Re: AH-MD5 Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil On Jan 30, 13:01, uri@watson.ibm.com wrote: % Subject: Re: AH-MD5 % % Oh, come on... My preliminary and completely unscientific % benchmark showed it to be about twice as slow as MD5... End of excerpt from uri@watson.ibm.com Uri, Your performance measurements are sufficient to convince me that SHA could not be universally deployed at this time. Major computer vendors are already VERY uncomfortable with the MD5 performance hit and have told me that they simply will not deploy anything worse than MD5. Most vendors are currently fence-sitting about MD5 because its performance impact is very noticable. We need a solution that can and will be deployed today. SHA is not that solution at this time, though it might be in a few years. Hence the need for an algorithm-independent protocol spec. As an aside, I have always found Hilarie's work to be VERY credible and so I believe her assertions apply to her tested platform as stated. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Jan 30 18:18:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13130 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 14:33:24 -0500 Received: by interlock.ans.net id AA29914 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 14:20:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 14:20:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 14:20:58 -0500 Date: Mon, 30 Jan 1995 11:18:52 -0700 (PDT) From: Derrell Piper Subject: Re: risks of MACs associated with packets To: ipsec@ans.net Message-Id: <01HMGEZC9E3E00002M@BILBO.TGV.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT RE: AH I also think the authentication info should be outside of the ESP so that bogus packets can be detected without having to decrypt the whole packet... >I think, as I believe Phil Karn does, that you want authentication >to be outside of your encyrption so that it is less work to throw >away bogus packets and so that intermediate points can, if properly >configured, authenticate the message without reading it. > >Donald 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 Mon Jan 30 04:04:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20336 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 15:17:59 -0500 Received: by interlock.ans.net id AA05392 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 15:07:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 30 Jan 1995 15:07:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 15:07:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 15:07:19 -0500 Date: Mon, 30 Jan 95 12:04:50 PST From: burt@RSA.COM (Burt Kaliski) (burt) Message-Id: <9500307914.AA791496290@snail.rsa.com> To: ipsec@ans.net Cc: Russ" "Housley Subject: Re: Fwd: Use of Keyed MD5 Dear Ran -- Following are some comments on the attached note, per Russ Housley's request. Please copy me on any reply, as I am not on the ipsec list. Folks, It is NOT accurate to state that a "vulnerability" was discussed by the Security Directorate. I mentioned that Russ Housely had sent me an email expressing concern about the use of MD5, nothing more. To my knowledge (and I have mostly been in the loop), there is no known vulnerability. It is true that MD5 was designed as a message digest function and not for cryptographic authentication in the manner becoming commonplace within the IETF. I believe that an Informational RFC on the use of keyed MD5 for authentication is a good idea and I think one is likely to appear. The only statements I've seen have been of the form that (1) if no length field is present at a fixed location, then appending attacks might be possible (Both IPv4 and IPv6 have length fields in fixed locations) Agreed. (2) use of prepend-only might not be not desirable with IP because, in the words of Eric Rains, "This has the effect that a large block of bits at the beginning of the data fed to the digester [i.e. algorithm] will likely be the same for every packet involved in a communication, with the exception of the payload length." Good point, but note that a weakness in MD5 found this way --- say two messages with the same digest, starting with the same bits --- would imply a weakness in MD5 without the special conditions just noted. So, if MD5 is strong, including common bits at the beginning of a message shouldn't affect security. However, this is not a problem as long as we believe that it is not computationally feasible to invert the particular algorithm (in our case MD5) and determine the secret key. I am not aware of any work that would lead us to believe that it is computationally feasible to invert MD5. Further, the work of Joe Touch indicates that MD5 might be hard to parallelise, so the existence of systems such as the Connection Machine are less of a factor wrt computational feasibility. (3) Both prepending and appending the secret key significantly increases the entropy of the result of the hash. It can also be significantly more expensive to compute the hash because one cannot cache the appended computation. Prepended keys can enable a system to precompute (once) the initial part of the computation and thereby possibly speed up the processing of packets. Given the experimental evidence from Hilarie Orman, this is a serious issue to consider. I'm not sure I agree with either part of this point, though I'm open to correction. The entropy (uncertainty) of the hash depends only on the number of secret bits. The number of secret bits is the same whether the key is appended, prepended or both. As far as speed, I would not expect any precomputation to be possible, unless the key is 512 bits or longer, since MD5 processes in 512-bit blocks. Another approach is to hash the message first, and then hash the concatenation of the hash and the key. This avoids the need for any special structure in the message, and is only a little more work than the other proposals. Keep in mind that MD5 wasn't designed with message authentication in mind, so all of these approaches need to be examined very carefully. (As opposed to digital signatures, where one can assume prima facie that MD5 is suitable for hashing a message before a private-key operation is applied.) I believe this is the ENTIRE dataset on this matter. If people have specific detailed comments, suggestions, or data that they are willing to backup on this list, then please present it so that the group can consider it. Best Regards, Ran atkinson@itd.nrl.navy.mil -- Burt Kaliski RSA Laboratories From ipsec-request@ans.net Mon Jan 30 10:41:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20122 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 16:09:36 -0500 Received: by interlock.ans.net id AA07610 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 15:58:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 15:58:46 -0500 Message-Id: <199501302058.AA37302@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 15:58:46 -0500 To: Derrell Piper Cc: ipsec@ans.net Subject: Re: risks of MACs associated with packets Date: Mon, 30 Jan 95 15:41:21 EST I also think the authentication info should be outside of the ESP so that bogus packets can be detected without having to decrypt the whole packet... I don't think this makes much differences. While MD5 and the like are cheaper than DES, they're not that much cheaper. Philosophically, a denial of service attack can occur when it's cheaper for your enemy to send messages than it is for you to process them. But in this case, the enemy's transmission process is very cheap: a random packet generator. That's true whether the verification is done by decryption or by MD5. In either case, your machine will take a tremendous hit. From ipsec-request@ans.net Mon Jan 30 23:09:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21295 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 18:35:45 -0500 Received: by interlock.ans.net id AA03706 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 18:10:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 30 Jan 1995 18:10:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 30 Jan 1995 18:10:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 30 Jan 1995 18:10:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 18:10:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 18:10:16 -0500 From: uri@watson.ibm.com Message-Id: <9501302309.AA18263@buoy.watson.ibm.com> Subject: Re: AH-MD5 To: atkinson@itd.nrl.navy.mil Date: Mon, 30 Jan 1995 18:09:21 -0500 (EST) Cc: ho@cs.arizona.edu, ipsec@ans.net In-Reply-To: <9501301343.ZM8076@bodhi.nrl.navy.mil> from "Ran Atkinson" at Jan 30, 95 01:43:23 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1401 Ran Atkinson says: > Your performance measurements are sufficient to convince me that > SHA could not be universally deployed at this time. Major computer > vendors are already VERY uncomfortable with the MD5 performance > hit and have told me that they simply will not deploy anything > worse than MD5. Most vendors are currently fence-sitting about > MD5 because its performance impact is very noticable. Well, then so be it. My updated results (reference C code for both SHA-1 and MD5) on i486 gave about 1,000,000 bytes/sec for SHA-1 vs. 2,800,000 bytes/sec for MD5. So it's roughly 2.8 times slower. I'm sure hand-crafting the code would speed up both considerably, maybe to the level of acceptability. > We need a solution that can and will be deployed today. SHA > is not that solution at this time, though it might be in a few > years. Hence the need for an algorithm-independent protocol spec. Then why not fast and [marginally] secure MD4 just for now? > As an aside, I have always found Hilarie's work to be VERY > credible and so I believe her assertions apply to her tested > platform as stated. Well, in this case I request an explanation, how software DES was made to run faster than SHA. Plus the numbers, if you'd be so kind. Unless of course Hilarie's remark was sarcastic, in which case -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Tue Jan 31 03:57:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17375 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 23:10:34 -0500 Received: by interlock.ans.net id AA14661 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 22:55:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 22:55:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 22:55:28 -0500 Date: Mon, 30 Jan 1995 19:57:16 -0800 From: Phil Karn Message-Id: <199501310357.TAA09674@servo.qualcomm.com> To: smb@research.att.com Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199501282254.AA04430@interlock.ans.net> (smb@research.att.com) Subject: Re: AH-MD5 >SHA (and for that matter Skipjack) were designed to meet a stated >a priori requirement of 80 bits of strength. That number seems reasonable On the other hand, SHA was designed by NSA. And NSA cannot be unaware of the ease of using crypto hash functions for encryption. This makes me as skeptical of SHA as I am of Skipjack and DSS. I'd stick to MD5 for now, with a door open for other algorithms of course. After SHA has undergone a thorough and open civilian review, we can revisit the issue. Phil From ipsec-request@ans.net Tue Jan 31 04:02:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20972 (5.65c/IDA-1.4.4 for ); Mon, 30 Jan 1995 23:11:39 -0500 Received: by interlock.ans.net id AA47504 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 30 Jan 1995 23:00:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 30 Jan 1995 23:00:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 30 Jan 1995 23:00:57 -0500 Date: Mon, 30 Jan 1995 20:02:30 -0800 From: Phil Karn Message-Id: <199501310402.UAA09678@servo.qualcomm.com> To: perry@imsi.com Cc: ipsec@ans.net, perry@imsi.com In-Reply-To: <9501290113.AA20720@webster.imsi.com> (perry@imsi.com) Subject: Re: risks of MACs associated with packets >authenticators -- but we are using no initialization vectors on these >things. That means that the odds of two identical payload messages >having identical authenticators is very high (especially since the If authentication is done outside encryption, and if the encryption uses an IV, then the data being authenticated will always be different from packet to packet. Phil From ipsec-request@ans.net Tue Jan 31 15:05:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20799 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 10:17:51 -0500 Received: by interlock.ans.net id AA07911 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 10:06:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 31 Jan 1995 10:06:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 31 Jan 1995 10:06:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 10:06:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 10:06:45 -0500 Message-Id: <9501311505.AA24933@snark.imsi.com> To: Phil Karn Cc: smb@research.att.com, ipsec@ans.net Subject: Re: AH-MD5 In-Reply-To: Your message of "Mon, 30 Jan 1995 19:57:16 PST." <199501310357.TAA09674@servo.qualcomm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 31 Jan 1995 10:05:18 -0500 From: "Perry E. Metzger" Phil Karn says: > >SHA (and for that matter Skipjack) were designed to meet a stated > >a priori requirement of 80 bits of strength. That number seems reasonable > > On the other hand, SHA was designed by NSA. And NSA cannot be unaware > of the ease of using crypto hash functions for encryption. This makes > me as skeptical of SHA as I am of Skipjack and DSS. > > I'd stick to MD5 for now, with a door open for other algorithms of > course. After SHA has undergone a thorough and open civilian review, > we can revisit the issue. I'm actually much less suspicious of SHA than I am of MD5; there are already some crude attacks on MD5 but none known against SHA. (There are, for example, ways to induce collisions in the MD5 compression function that don't in practice cause harm but are disturbing. Also, there is the Oorschot and Weiner machine, which isn't yet practical but is still in the realm of possibility but is even less practical an attack on SHA...) The best argument I've seen against SHA is the performance problems it induces. A factor of two is *not* ignorable. Perry From ipsec-request@ans.net Tue Jan 31 19:08:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22764 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 14:32:00 -0500 Received: by interlock.ans.net id AA36460 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 14:09:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 31 Jan 1995 14:09:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 14:09:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 14:09:16 -0500 Message-Id: <9501311908.AA11636@skidrow.tay.dec.com> To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: risks of MACs associated with packets In-Reply-To: Your message of "Mon, 30 Jan 95 15:41:21 EST." <199501302058.AA37302@interlock.ans.net> Date: Tue, 31 Jan 95 14:08:31 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp But even if computation is the same, unencyrpting and then authenticating is at least a factor of two more work. Donald From: smb@research.att.com To: Derrell Piper Cc: ipsec@ans.net > I also think the authentication info should be outside of the ESP > so that bogus packets can be detected without having to decrypt the > whole packet... > >I don't think this makes much differences. While MD5 and the like are >cheaper than DES, they're not that much cheaper. Philosophically, a >denial of service attack can occur when it's cheaper for your enemy >to send messages than it is for you to process them. But in this >case, the enemy's transmission process is very cheap: a random packet >generator. That's true whether the verification is done by decryption >or by MD5. In either case, your machine will take a tremendous hit. From ipsec-request@ans.net Tue Jan 31 19:13:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19999 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 16:00:11 -0500 Received: by interlock.ans.net id AA13690 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 15:49:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 15:49:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 15:49:36 -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-metzger-esp-3des-cbc-00.txt Date: Tue, 31 Jan 95 14:13:51 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9501311413.aa07533@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP Triple DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-metzger-esp-3des-cbc-00.txt Pages : 9 Date : 01/30/1995 This document describes the Triple DES-CBC security transform for the Encapsulating Security Payload (ESP). 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-metzger-esp-3des-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-esp-3des-cbc-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-metzger-esp-3des-cbc-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: <19950130132325.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-3des-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-3des-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130132325.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Jan 31 19:14:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17321 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 16:09:52 -0500 Received: by interlock.ans.net id AA45906 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 15:59:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 15:59:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 15:59:34 -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-metzger-esp-des-cbc-02.txt Date: Tue, 31 Jan 95 14:14:47 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9501311414.aa07578@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-metzger-esp-des-cbc-02.txt Pages : 8 Date : 01/30/1995 This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). 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-metzger-esp-des-cbc-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-esp-des-cbc-02.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-metzger-esp-des-cbc-02.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: <19950130132940.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-des-cbc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-des-cbc-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130132940.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Jan 31 19:15:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16464 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 16:24:44 -0500 Received: by interlock.ans.net id AA50573 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 16:10:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 16:10:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 16:10:22 -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-metzger-ah-sha-00.txt Date: Tue, 31 Jan 95 14:15:12 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9501311415.aa07610@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Authentication with Keyed SHA Author(s) : P. Metzger, W. Simpson Filename : draft-metzger-ah-sha-00.txt Pages : 4 Date : 01/30/1995 This document describes the use of SHA with the IPv4 Authentication Header. 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-metzger-ah-sha-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-ah-sha-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-metzger-ah-sha-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: <19950130133646.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-ah-sha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-ah-sha-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130133646.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Jan 31 15:05:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18904 (5.65c/IDA-1.4.4 for ); Tue, 31 Jan 1995 20:21:16 -0500 Received: by interlock.ans.net id AA07573 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 31 Jan 1995 20:09:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 31 Jan 1995 20:09:33 -0500 Message-Id: <199502010109.AA28305@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 31 Jan 1995 20:09:33 -0500 To: "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re: risks of MACs associated with packets Date: Tue, 31 Jan 95 20:05:32 EST 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?