From ipsec-request@ans.net Mon Jul 3 12:28:45 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04991 (5.65c/IDA-1.4.4 for ); Mon, 3 Jul 1995 12:28:45 -0400 Received: by interlock.ans.net id AA25537 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Jul 1995 12:11:57 -0400 Message-Id: <199507031611.AA25537@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Jul 1995 12:11:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Jul 1995 12:11:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Jul 1995 12:11:57 -0400 Date: Mon, 03 Jul 95 08:58:44 From: "Housley, Russ" Encoding: 807 Text Cc: ipsec@ans.net Subject: Re: response to Last Call on: IP Authentication using Key >> Now that it may finally be on the table to do something about >> draft-ietf-ipsec-ah-md5-03.txt >> I would like to remind this community that not only >> should the MAC be defined independent of >> its intended use, so too should the encryption transform. > > More properly, you should state that it is your opinion that the > transforms should be independant of use. There are many advantages to a protocol specifiation that is independent of mechanism and a separate mechanism description. One iportnat benefit is that other IETF groups can use the same mechanism description in the same way that Hugo's I-D references the MD5 RFC. Good modularity in the specifications saves alot of time and effort down the road. And, it makes specification maintenence easier too. Russ From ipsec-request@ans.net Mon Jul 3 16:53:13 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13279 (5.65c/IDA-1.4.4 for ); Mon, 3 Jul 1995 13:05:51 -0400 Received: by interlock.ans.net id AA59177 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Jul 1995 12:53:44 -0400 Message-Id: <199507031653.AA59177@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Jul 1995 12:53:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Jul 1995 12:53:44 -0400 Organization: ESAT, K.U.Leuven, Belgium Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Jul 1995 12:53:44 -0400 Date: Mon, 3 Jul 1995 18:53:13 +0200 From: Bart.Preneel@esat.kuleuven.ac.be To: ipsec@ans.net Subject: IP Authentication using Keyed MD5 / The ESP DES-CBC Transform Cc: preneel@esat.kuleuven.ac.be X-Charset: LATIN1 X-Char-Esc: 29 ====================================================================== Some comments on Keyed-MD5 for Message Authentication and on the ESP DES-CBC Transform Bart Preneel Katholieke Universiteit Leuven, Belgium Summary In this document we comment on the security of keyed-MD5 for message authentication and on some alternatives which have been put forward. We also make a note on the ESP DES-CBC transform. 1. Keyed-MD5 for Message Authentication --------------------------------------- In [Krawczyk] H. Krawczyk proposes a modification to the keyed MD5 method proposed in [Metzger-Simpson]. The new method has a security proof based on the pseudo-randomness of the function MD5#, which is the MD5 compression function keyed with the IV [Krawczyk2]. THE PSEUDO-RANDOMNESS ASSUMPTION A first remark is that while the collision resistance of MD4 and MD5 has been analyzed, no one has ever published any results regarding an evaluation to verify whether MD5# is actually a pseudo-random function. Both properties (collision resistance of MD5 and pseudo-randomness of MD5#) are independent, i.e., either of them can be present without the other one. A related observation has been made in [Roe et al.]. Second, weaknesses have been found in the compression function of MD5, and recent work on MD4 [Vaudenay] and RIPEMD [Dobbertin] suggests that the internal structure of these hash functions could be used to find collisions faster than by a brute force birthday attack (2^{64} operations). It is not clear what the implications of this are on the pseudo-randomness of MD5#, but it seems quite plausible that the internal structure of these functions can be exploited in an attack as well. Note that in [Krawczyk2] it is stated that "everybody uses these functions [MD5, SHA] to generate (pseudo) random keys": while it is true that this is based on the pseudo-randomness of MD5#, it should be noted that when MD5 is used for key derivation, an attacker has much less input-output pairs available, which makes statistical attacks infeasible. In view of the above it would appear more secure (or at least prudent) to key not only the beginning and the end of the hashing process, but also the compression function as done in MD5-MAC. In this way, the MAC is more robust against weaknesses of the underlying hash function. By keeping the modification as simple as possible, it is highly unlikely that new vulnerabilities are introduced. While both the scheme proposed by Krawczyk and MD5-MAC use a key as IV, the introduction of a secret key in the compression function is a major difference between both schemes. Note that this does not preclude a security proof based on the pseudo-randomness of the compression function MD5-MAC#. The following quote of [Krawczyk] seems to support this statement: % However, the proposed scheme does not suffer of any practical weakness % known today. On the other hand, if the above properties are to be relaxed % then other designs which may prove more robust to future attacks are % possible. % % A separate note by Paul Van Oorschot to these lists proposes going in this % direction. I support his position if the above conditions (no modification % of MD5, speed, etc) are relaxed. Otherwise, I propose the adoption of % keyed-MD5 as described in the above draft (draft-krawczyk-keyed-md5-00.txt). % In [Krawczyk2], it is also remarked that "functions completely unrelated to MD5 or similar hash functions could be used". However, no concrete proposal along these lines has been made yet. SIZE OF THE MAC: 64 vs. 128 BITS The reference [crypto'95] explains why keeping 64 bits of the MAC rather than 128 can increase the security. Indeed, a birthday attack on the 64-bit MAC requires 2^{64} chosen and 2^{64} known texts, while the same attack on the 128-bit MAC requires 2^{64} known texts and only a single chosen text (under the assumption that the appended key is padded to a complete block). A point to drive this home: this *known* attack demonstrates that one method is better than the other, vs. this attack. While both may be unrealistic, it is reasonable to argue that this may well indicate that the same scheme is more secure than the other against yet-unknown attacks, which may be feasible in the one case and not in the other. In [Krawczyk2], it is stated that the birthday attack requires strictly speaking 2^{64} chosen messages for his proposal [Krawczyk], even with a 128-bit result: indeed, the attack requires that the last block is constant, which need not be true for all texts. This is the motivation to omit the padding of the appended key. However, it is likely that mixing in a single block the secret key and data under complete control of an attacker makes it easier to obtain information on that secret key. Note that the model in [Bellare94] does not make a distinction between chosen and known text attacks, while in practice there is a major difference between both types of attacks. CBC-MAC In [Roe et al.], it is proposed to make DES based CBC-MAC the default algorithm. We do not support this proposal for the following reasons: 1. While it is shown in [Bellare94] that certain variants of the CBC-MAC are secure, provided the underlying encryption algorithm is pseudo-random, it should also be noted that in [crypto95] a practical attack is described on DES CBC-MAC, which requires 2^{32} known text-MAC pairs and a single chosen text. One can argue that the key should be changed more frequently, but if the CBC-MAC key is changed after 2^{25} messages, the success probability equals 1/30,000, which is still non-negligible. 2. It is suggested in [Roe et al.] to use simple CBC mode as defined in [Fips81]; however, if no additional measures are taken (such as a special processing of the last block), simple CBC-MAC is vulnerable to an attack requiring 2 known and 1 chosen texts. 3. Because of the short key size, single DES does not offer a sufficient security level, as noted in [Metzger-Karn-Simpson]. 4. The fastest DES implementations in software are about 5 times slower than a fast MD5 implementation on the same machine. Current DES hardware solutions are in general not much faster due to communication overhead and loss of pipelining in CBC/CFB mode. Note that the 1 Gbit implementation referenced in [Metzger-Karn-Simpson] is a very expensive GA-As chip, which was an academic design exercise; it is far from a commercial product (the fastest chips available are about 4 times slower). This problem will become more important if one moves to triple-DES, which is about 2.5 times slower in software. 2. The ESP DES-CBC Transform ---------------------------- THE INITIALIZATION VALUE (IV) The IV in CBC-mode should be unpredictable and should be kept secret; it must be impossible to correlate subsequent IV's (see also [Roe et al.]). Therefore the solution proposed in [Metzger-Karn-Simpson] is not acceptable. If one wants to use a counter, one could encrypt it with the session key (or with a key derived from the session key) to obtain the IV. A second alternative is to use a pseudo-random generator based on the OFB mode of DES. Both solutions require only a negligible amount of computation compared to the encryption of a complete message. The problem of the IV could be eliminated by using 64-bit CFB mode, which has the same performance as the CBC-mode, but allows to send the IV in clear (since it is encrypted before it is used). Also, the IV need not be a pseudo-random value (it can be a counter). The integrity protection of the last 64 bits of a message is weaker than that of the CBC mode (with a secret IV), but encryption should not be used to provide integrity anyway. REFERENCES [Bellare94] M. Bellare, J. Kilian, P. Rogaway, "The Security of Cipher Block Chaining," Proc. Crypto'94, Springer-Verlag LNCS 839, 1994, pp. 341-358 [crypto95] B. Preneel, P.C. van Oorschot, "MDx-MAC and Building Fast MACs from Hash Functions," Proc. Crypto'95, Springer-Verlag LNCS (to appear, Aug. 1995). {ftp: ftp.esat.kuleuven.ac.be, directory pub/COSIC/preneel} [Dobbertin] H. Dobbertin, "Collisions for the Last Two Rounds of the RIPEMD Compress Function," presented at rump session of Eurocrypt'95, St. Malo, France, May 1995. {email: dobbertin@skom.rhein.de} [FIPS180-1] Secure Hash Standard, NIST, US Department of Commerce, Washington D.C., April 1995. {http://csrc.ncsl.nist.gov/fips/fip180-1.txt} [Krawczyk] H.~Krawczyk, "Keyed MD5 for Message Authentication", draft-krawczyk-keyed-md5-00.txt. [Krawczyk2] H.~Krawczyk, "Analysis of Keyed MD5 (sketch)", June 30, 1995. [Metzger-Karn-Simpson] P. Metzger, P, Karn, W.A. Simpson, "The ESP DES-CBC transform", draft-ietf-ipsec-esp-des-cbc-04.txt. [Metzger-Simpson] P. Metzger, W.A. Simpson, "IP Authentication Using Keyed MD5", draft-ietf-ipsec-ah-md5-03.txt. [Roe et al.] M Roe, R. Needham, M. Lomas, R. Anderson, I. Jackson, "Comments on the IP Security Internet Drafts," June 30, 1995. [Vaudenay] S. Vaudenay, "On the Need for Multipermutations: Cryptanalysis of MD4 and SAFER," Fast Software Encryption, Springer-Verlag LNCS, 1995 (to appear). (Proc. of Algorithms Workshop, Leuven, Belgium, Dec. 1994). {email: Serge.Vaudenay@ens.fr} ============================================================================== From ipsec-request@ans.net Mon Jul 3 12:42:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11448 (5.65c/IDA-1.4.4 for ); Mon, 3 Jul 1995 16:59:50 -0400 Received: by interlock.ans.net id AA31516 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Jul 1995 16:42:42 -0400 Message-Id: <199507032042.AA31516@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Jul 1995 16:42:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Jul 1995 16:42:42 -0400 Date: Mon, 3 Jul 95 16:42:19 EDT From: hugo@watson.ibm.com To: Bart.Preneel@esat.kuleuven.ac.be, ipsec@ans.net Cc: preneel@esat.kuleuven.ac.be Subject: IP Authentication using Keyed MD5 / The ESP DES-CBC Transform Ref: Your note of Mon, 3 Jul 1995 18:53:13 +0200 I agree with most of Bart Preneel's comments (some clarifications are brought below). In particular, I do not see any significant conflict between what Bart says and what I have written in my draft and companion notes. My conclusions are the same as I already presented ("Never underestimate the power of repetition" says an old proverb...), namely: The key-pad-text-key mode of keyed-MD5 in draft-krawczyk-keyed-md5-txt.00 is the result of adapting the analytical work of BCK to the constraints: 1) do not modify MD5 code 2) do not slow down MD5 performance 3) keep simple keying rules The relaxation of any of these constraints can produce a more secure proposal in the sense of better matching the BCK analysis and/or having potentially better heuristic security. It is up to this WG to decide whether this is desirable or not. (Please speak up!). I, as a cryptographer, will always support going to the (plausibly) more secure solutions. However, in this WG the system and performance considerations are of prime importance and trade-offs and compromise are behind any decision made. Again, as said several times, we will eventually need a faster transform, and more secure transforms. The work many of us are carrying in analysis and design of these transforms will hopefully bring a better solution. But, in any case, the choice of an interim default for the authentication transform cannot wait until we have enough confidence in new solutions. I want to make one point that was not mentioned before but is significant If you use an encryption function that is broken 5 years from now, any adversary that recorded today's traffic will be able to read your information then (of course, it depends on the kind of information the attacker gathered and the nature of the encryption breaking). However, an authentication function which is broken in the future has no implication on the security of past traffic. This consideration makes it easier to go towards some system/security trade-offs for the authentication function in spite of potential weaknesses. Of course, one shouldn't gratuitly sacrifice security, and most importantly one has to be ready to replace the authentication function as soon significant evidence against the security of the transform is found. This is why modularity and support (upon negotiation) of alternative functions is of prime importance for the proposed standard. I believe that the keyed-MD5 function specified in the current drafts will be replaced *before* this becomes a final standard. The only reason for my draft is to "optimize" the choice from the security point of view without paying any additional price in performance, complexity, etc. Here is a list of possible improvements depending on how much of the above constraints are relaxed: * With a minimal complexity addition to keying: have "independent" prepended and appended keys (i.e., K1, pad, text, K2, where K1 and K2 may be derived from a common 128-bit key using standard techniques) * A minimal change in MD5 code: do not use prepend and/or append keys to text but rather use the keys to replace the fixed MD5 IV (key-ed IV approach). Define the function to be: MD5_K1(MD5_K2(text)) (which was my original preferred proposal). Note: MD5_K stands for MD5 with IV=K. * If some slow-down of MD5 is accceptable (and somewhat more complex change to MD5 code) then the Preneel-Van Oorschot recommendation of keying the MD5 rounds can be incorporated. And when we'll eventually come with better performance/security transforms we'll replace any of the above. Note: One change that will not pay with any system penalty (actually, has some bandwidth advantage) and applies to any of the avove variants is to reduce the size of the MAC output as Bart proposes. I do not see right now a conflict of that choice with our analysis, however, I have not personally given much thought to this issue. Appended are some direct comments on Bart's note. (In what follows Bart's note is indented and incomplete) > ====================================================================== > Some comments on Keyed-MD5 for Message Authentication > and on the ESP DES-CBC Transform > > Bart Preneel > > THE PSEUDO-RANDOMNESS ASSUMPTION > > A first remark is that while the collision resistance of MD4 and > MD5 has been analyzed, no one has ever published any results regarding > an evaluation to verify whether MD5# is actually a pseudo-random function. > Both properties (collision resistance of MD5 and pseudo-randomness of > MD5#) are independent, i.e., either of them can be present without the > other one. A related observation has been made in [Roe et al.]. Bart is absolutely correct here. Unfortunately, all of the work on iterated one-way hash function from design to further cryptanalytical work concentrated solely in the (known-IV) collision resistance aspect. As I pointed out in my sketch this is an aspect which does not follow from a function being a good MAC neither guarantees the quality of MAC. In order to be able to analyze these functions as a MAC one needs to gain a better understanding of necessary and sufficient conditions of a compression function to produce a good MAC. BCK and PV are a first step in this direction. (And definitely not the final one!) > > Second, weaknesses have been found in the compression function of > MD5, and recent work on MD4 [Vaudenay] and RIPEMD [Dobbertin] suggests > that the internal structure of these hash functions could be used to > find collisions faster than by a brute force birthday attack > (2^{64} operations). It is not clear what the implications of this > are on the pseudo-randomness of MD5#, but it seems quite plausible that > the internal structure of these functions can be exploited in an attack > as well. > > Note that in [Krawczyk2] it is stated that "everybody uses these functions A minor correction: I didn't say that "evrybody uses", though I said it is used "everywhere" (quotes included) to mean that is quite common to find that use of these functions these days. > [MD5, SHA] to generate (pseudo) random keys": while it is true that this > is based on the pseudo-randomness of MD5#, it should be noted that when > MD5 is used for key derivation, an attacker has much less input-output > pairs available, which makes statistical attacks infeasible. In reality, our analysis shows that the significant parameter for the pseudorandomness quality of the compression function depends on information gained by an adversary by quering the function only once (on average). > > In view of the above it would appear more secure (or at least prudent) to > key not only the beginning and the end of the hashing process, but also the > compression function as done in MD5-MAC. In this way, the MAC is more > robust against weaknesses of the underlying hash function. By keeping > the modification as simple as possible, it is highly unlikely that new > vulnerabilities are introduced. While both the scheme proposed by > Krawczyk and MD5-MAC use a key as IV, the introduction of a secret key > in the compression function is a major difference between both schemes. I have no idea how to qualify/quantify this "major difference", but as I said I will support that change, if the slow down it carries is accepted by the WG. > > CBC-MAC > > In [Roe et al.], it is proposed to make DES based CBC-MAC the default algorithm. > We do not support this proposal for the following reasons: I agree with Bart. Attacks in the order of 2^32 messages are not acceptable for a general purpose MAC (which will be used in many differennt scenarios). Moreover, I want to make clear a point which is a fundamental conclusion of the Birthday attacks on MAC: even going to triple-DES will not improve against these attacks as far as the output is (as in CBC-DES) 64 bits!! Hugo From ipsec-request@ans.net Mon Jul 3 14:42:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12708 (5.65c/IDA-1.4.4 for ); Mon, 3 Jul 1995 18:55:15 -0400 Received: by interlock.ans.net id AA21845 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Jul 1995 18:43:19 -0400 Message-Id: <199507032243.AA21845@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Jul 1995 18:43:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Jul 1995 18:43:19 -0400 Date: Mon, 3 Jul 95 18:42:58 EDT From: hugo@watson.ibm.com To: Bart.Preneel@esat.kuleuven.ac.be, ipsec@ans.net Cc: preneel@esat.kuleuven.ac.be Subject: IP Authentication using Keyed MD5 / The ESP DES-CBC Transform Ref: Your note of Mon, 3 Jul 1995 18:53:13 +0200 PS to my response to Preneel's note: I omitted the following comment related to the pseudorandomness condition on the keyed compression function of MD5 and to the construction MD5_K(MD5_K(text)). For the above construction to be a good MAC the requirement of pseudorandomness can be traded for two requirements each of which is weaker than pseudorandomness. The first is the compression function being a MAC. This is significantly weaker condition than being pseudorandom, in particular, statistical weaknesses of the output do not necessarily imply a weakness as MAC. (Let me note that the compression function just being a MAC is no guarantee for the iterative construction to be a MAC. It seems intuitively as a *necessary* requirement, although a proof of that will depend on the particular way the compression function is used in a given construction). The second requirement is that the internal application of MD5_K(text) be collision-resistant against an adversary that does not know K. Notice that this requirement applies to the iterated MD5_K function, not just the compression function. This is weaker than requiring that the compression function is pseudorandom, and weaker also than the traditional requirement of collision resistance with known IVs. The above second requirement is yet to be formalized, and the exact (quantified) security relations between the above assumptions and the quality of the resultant MAC to be derived. However, when purely heuristic arguments are considered (and much of this discussion is carried in pure heuristic terms -- much more than I'd like) the above combination of assumptions must be considered seriously. This is an important consideration behind MD5_K1(MD5_K2(text)). In this case the external MD5_K1 (which involves only one application of the keyed compression function) is assumed to be a MAC function, while the internal application of (iterated) MD5 is assumed to be collision resistant when used with a secret key K2. Intuitively, if one can forge authenticated messages under the composed construction then one can either find collisions in the internal MD5_K2 (with random and secret K2) or break the external MD5_K1 as a MAC. The key-pad-text-key is a "dirty" approximation to this construction. The prepended key acts as the internal K2, and the appended key as the external K1. Hugo From ipsec-request@ans.net Fri Jun 30 21:29:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04869 (5.65c/IDA-1.4.4 for ); Wed, 5 Jul 1995 11:15:22 -0400 Received: by interlock.ans.net id AA06072 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Jul 1995 11:03:02 -0400 Message-Id: <199507051503.AA06072@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 5 Jul 1995 11:03:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 5 Jul 1995 11:03:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Jul 1995 11:03:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Jul 1995 11:03:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Jul 1995 11:03:02 -0400 Date: Fri, 30 Jun 1995 17:29:22 -0400 From: hugo@watson.ibm.com (H.Krawczyk) To: perry@imsi.com Subject: response to Last Call on: IP Authentication using Keyed MD5 Cc: hugo@watson.ibm.com, ipsec@ans.net > > It appears that all that is needed to incorporate Hugo's suggestion is > a change of a line or two of the MD5 AH draft to specify that the > prepended part of the key be padded out with a 1 bit and some number > of 0 bits to 512 bits. Am I correct on this, Hugo? Right, that's the only change to the calculation description. > > Given the simplicity of this change, I'm inclined to see if we can > insert it before RFC publication, in spite of the late timing. Again, > this depends on what my co-authors say and on general consensus. I am not sure if draft draft-ietf-ipsec-ah-md5 is needed anymore. The mandatory function for implementation can be specified in Atkinson's draft-ietf-ipsec-auth by referencing a protocol-independent description of the function as done in draft-krawczyk-keyed-md5 or similar document. > > It would also be nice if Hugo were to post a message explaining the I hope the message I sent an hour ago will help in this regard. > rationale for this in approximate laymans terms. (I'd still like him > to write the language to insert but I don't have much hope that he'll > do it.) I have contributed text by posting draft-krawczyk-keyed-md5. Contributing to draft-ietf-ipsec-ah-md5 would mean for me changing it to the language used in my draft. Hugo > > Perry From ipsec-request@ans.net Wed Jul 5 15:20:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12334 (5.65c/IDA-1.4.4 for ); Wed, 5 Jul 1995 11:31:25 -0400 Received: by interlock.ans.net id AA37439 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Jul 1995 11:20:18 -0400 Message-Id: <199507051520.AA37439@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 5 Jul 1995 11:20:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Jul 1995 11:20:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Jul 1995 11:20:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Jul 1995 11:20:18 -0400 To: hugo@watson.ibm.com (H.Krawczyk) Cc: ipsec@ans.net Subject: Re: response to Last Call on: IP Authentication using Keyed MD5 In-Reply-To: Your message of "Fri, 30 Jun 1995 17:29:22 EDT." <9506302129.AA36669@copacabana.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 05 Jul 1995 11:20:03 -0400 From: "Perry E. Metzger" H.Krawczyk writes: > > It appears that all that is needed to incorporate Hugo's suggestion is > > a change of a line or two of the MD5 AH draft to specify that the > > prepended part of the key be padded out with a 1 bit and some number > > of 0 bits to 512 bits. Am I correct on this, Hugo? > > Right, that's the only change to the calculation description. Bill assures me that it has been inserted in the document, though I have yet to see the language he has used. > > Given the simplicity of this change, I'm inclined to see if we can > > insert it before RFC publication, in spite of the late timing. Again, > > this depends on what my co-authors say and on general consensus. > > I am not sure if draft draft-ietf-ipsec-ah-md5 is needed anymore. The > mandatory function for implementation can be specified in Atkinson's > draft-ietf-ipsec-auth by referencing a protocol-independent description of > the function as done in draft-krawczyk-keyed-md5 or similar document. Hugo, you are a great cryptographer, but I've read your document and I don't think it is suitable for an implementer. Bill has effected the needed change by an alteration of only a sentence or two in the current draft. I will make sure that you are heavily referenced and, although I didn't think to do it, I'll put a large pointer to your work in the security considerations section. I also think that a modified version of your draft should be made into an informational RFC, with much cleaned up language explaining the rationale and the rest -- there is a need for such a document. However, I don't think its suitable as a replacement for the current document. > > It would also be nice if Hugo were to post a message explaining the > > I hope the message I sent an hour ago will help in this regard. It did. Perry From ipsec-request@ans.net Wed Jul 5 08:10:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04792 (5.65c/IDA-1.4.4 for ); Wed, 5 Jul 1995 12:29:46 -0400 Received: by interlock.ans.net id AA59835 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Jul 1995 12:10:13 -0400 Message-Id: <199507051610.AA59835@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 5 Jul 1995 12:10:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 5 Jul 1995 12:10:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Jul 1995 12:10:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Jul 1995 12:10:13 -0400 Date: Wed, 5 Jul 95 12:10:07 EDT From: perry@imsi.com (Perry E. Metzger) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Jul 1995 12:10:13 -0400 To: ipsec@ans.net Subject: MD5 for authentication article in RSA's "CryptoBytes" Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission There is a new RSADSI newsletter called "CryptoBytes". One of their articles in the fist issue is about use of MD5 for authentication. Perry From ipsec-request@ans.net Wed Jul 5 19:05:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11328 (5.65c/IDA-1.4.4 for ); Wed, 5 Jul 1995 15:25:42 -0400 Received: by interlock.ans.net id AA37514 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Jul 1995 15:11:18 -0400 Message-Id: <199507051911.AA37514@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 5 Jul 1995 15:11:18 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Jul 1995 15:11:18 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Jul 1995 15:11:18 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Jul 1995 15:11:18 -0400 Date: Wed, 5 Jul 1995 15:05:00 -0400 X400-Originator: "/dd.id=1631303/g=paul/i=pc/s=van oorschot/"@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.909:05.06.95.19.06.04] X400-Content-Type: P2-1984 (2) Content-Identifier: re:MD5 for au... From: "paul (p.c.) van oorschot" Sender: "paul (p.c.) van oorschot" To: ipsec@ans.net Subject: re:MD5 for authentication article in RSA's "CryptoBytes" In message "MD5 for authentication article in RSA's "CryptoBytes"", 'perry@imsi.com' writes: >There is a new RSADSI newsletter called "CryptoBytes". One of their >articles in the fist issue is about use of MD5 for authentication. > >Perry Note there is a comment related to this in [crypto95], at the end of section 4.3: Three MD5-based MAC proposals for the IPSEC working group are made in [kaliski95]: one is the envelope method with $K_1=K_2$ and $k_1=128$ ($K_1$ is padded to a complete block), the other two are $MAC(x) = h( K_1 || h( K_2 || x))$ and $MAC(x) = h( K_1 || h( K_1 || x))$. It is suggested that the best known attack on these schemes requires $2^{64}$ chosen messages; however, Proposition 4 shows that $2^{56.5}$ known text-MAC pairs are sufficient (if $s=2^{16}$). Also, the second scheme is vulnerable to the divide and conquer attack described above. [crypto95] Bart Preneel, Paul C. van Oorschot, ``MDx-MAC and Building Fast MACs from Hash Functions,'' Proc. Crypto'95, Springer-Verlag LNCS (to appear, Aug. 1995). {ftp: ftp.esat.kuleuven.ac.be, directory pub/COSIC/preneel} [kaliski95] B. Kaliski, M. Robshaw, ``Message authentication with MD5,'' CryptoBytes (RSA Laboratories Technical Newsletter), Vol.1, No.1, Spring 1995, pp.5--8. Paul Van Oorschot. From ipsec-request@ans.net Wed Jul 5 18:35:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12537 (5.65c/IDA-1.4.4 for ); Wed, 5 Jul 1995 22:44:44 -0400 Received: by interlock.ans.net id AA44360 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Jul 1995 22:35:54 -0400 Message-Id: <199507060235.AA44360@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Jul 1995 22:35:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Jul 1995 22:35:54 -0400 Date: Wed, 5 Jul 95 22:35:07 EDT From: hugo@watson.ibm.com To: paulv@bnr.ca, ipsec@ans.net Subject: re:MD5 for authentication article in RSA's "CryptoBytes" Ref: Your note of Wed, 5 Jul 1995 15:05:00 -0400 (attached) Paul, What are you concluding from your remarks below? If you see that as an indication that the functions proposed in [kaliski95] are weak I disagree. (Not that I am claiming that these functions must be good, but, in my opinion, your arguments below show no real weaknesses of these schemes). More details below: > > In message "MD5 for authentication article in RSA's "CryptoBytes"", > 'perry@imsi.com' writes: > > >There is a new RSADSI newsletter called "CryptoBytes". One of their > >articles in the fist issue is about use of MD5 for authentication. > > > >Perry > > Note there is a comment related to this in [crypto95], > at the end of section 4.3: > > Three MD5-based MAC proposals for the IPSEC > working group are made in [kaliski95]: > one is the envelope method with > $K_1=K_2$ and $k_1=128$ ($K_1$ is padded to a complete block), > the other two are > $MAC(x) = h( K_1 || h( K_2 || x))$ and > $MAC(x) = h( K_1 || h( K_1 || x))$. > It is suggested that the best known attack on > these schemes requires $2^{64}$ chosen messages; > however, Proposition 4 shows that $2^{56.5}$ known text-MAC > pairs are sufficient (if $s=2^{16}$). As I already explained in past notes when the appended key in the envelope method is not padded but mixed with data, the attack is *strictly speaking* a *chosen* message attack. Moreover, I would not call an attack assuming common trailing blocks in the queried messages a *known* message attack. This is mainly a semantical issue with not much contents in the case of 128-bit output functions as MD5. Indeed, when I communicated this attack to Kaliski and Robshaw (the authors in [kaliski95]), I saw little value in making the precise distinction in the chosen vs semi-chosen vs known-message attacks (there is even place for a "semi-known" category here) when in any case: * all of these attacks *require* to be applicable to maintain * * the *same* key for MAC-ing 2^73 bits of information !!! * This is true also in the $2^{56.5}$ attack (that in addition requires 4Mb of common trailing information in all queried messages). The attacks are unrealistic anyway. Moreover, they do not imply by themselves any further weaknesses of these constructions. These attacks are applicable to any of the proposed constructions even if you use a perfectly random compression function! (Things are *very* different when you move from 2^64 to 2^32 as is the case of DES-MAC-CBC) > Also, the second scheme is vulnerable to the > divide and conquer attack described above. That is true. But what is the conclusion?. In any case no one is claiming an effective key length of more than 128 bits. Notice that [kaliski95] explicitly says that these two keys could be derived from a single 128-bit key. Hugo > > [crypto95] Bart Preneel, Paul C. van Oorschot, > ``MDx-MAC and Building Fast MACs from Hash Functions,'' > Proc. Crypto'95, Springer-Verlag LNCS (to appear, Aug. 1995). > {ftp: ftp.esat.kuleuven.ac.be, directory pub/COSIC/preneel} > > [kaliski95] B. Kaliski, M. Robshaw, ``Message authentication with MD5,'' > CryptoBytes (RSA Laboratories Technical Newsletter), > Vol.1, No.1, Spring 1995, pp.5--8. > > > Paul Van Oorschot. > > From ipsec-request@ans.net Thu Jul 6 09:51:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13231 (5.65c/IDA-1.4.4 for ); Thu, 6 Jul 1995 06:01:29 -0400 Received: by interlock.ans.net id AA06899 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Jul 1995 05:52:06 -0400 Message-Id: <199507060952.AA06899@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Jul 1995 05:52:06 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Jul 1995 05:52:06 -0400 Organization: ESAT, K.U.Leuven, Belgium Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Jul 1995 05:52:06 -0400 Date: Thu, 6 Jul 1995 11:51:43 +0200 From: Bart.Preneel@esat.kuleuven.ac.be To: ipsec@ans.net Subject: IP Authentication using Keyed MD5 Cc: preneel@esat.kuleuven.ac.be X-Charset: LATIN1 X-Char-Esc: 29 The following note contains a short description of MD5-MAC, which is a simple and efficient way to derive a Message Authentication Code from MD5. We believe that the Internet Draft on IP Authentication should contain the most robust algorithm currently available, which meets the performance constraints, and which requires only a very small implementation effort. We thus propose that MD5-MAC be included in the Internet Draft on Authentication Using Keyed MD5. The rationale behind this scheme can be found in the reference [crypto95]. A short description of MD5-MAC ------------------------------ MD5-MAC is a conservative construction for a MAC based on MD5. MD5 itself is specified in [RFC-1321]. The key size is 128 bits, (provision can be made to extend a key less than 128 bits up to 128 bits) and the MAC size is 64 bits. For an extensive motivation of the design (including the weaknesses observed in other constructions), the reader is referred to [crypto95]. The 16-byte key K is used to derive three 16-byte keys K0, K1, and K2. K1 is split into four 32-bit substrings K1[0], K1[1], K1[2], and K1[3]. MD5-MAC(x) is computed in a similar way as MD5(x), with the following modifications: 1 the initial value IV of MD5 is replaced by K0; 2 the value K1[i] is added modulo 2**32 to the all the constants in round i (the rounds are numbered 0,1,2,3), i.e. effectively to the result of each of the 64 steps, immediately prior to the circular shift; 3 after the last block (which contains the padding and the appended length), the following 64-byte block is inserted: K2 ; K2 + T0 ; K2 + T1 ; K2 + T2 (here T0, T1, and T2 are 16-byte constant strings defined below, ; denotes concatenation, and + denotes XOR, i.e. bitwise addition modulo 2); 4 the MD5-MAC value consists of the leftmost 64 bits of the hash value. The computational overhead of MD5-MAC is a single MD5 block operation for each message (step 3); the basic operation can become slightly slower, since the constants are replaced by variables. MD5-MAC is only 5% to 20% slower than MD5 (depending on the processor and the implementation). Code for MD5-MAC can be obtained by some small and easy modifications to existing code for MD5. When the 16-byte key K is installed, K0, K1, and K2 are computed as follows: K0 := MD5*( K ; U0 ; K) K1 := MD5*( K ; U1 ; K) K2 := MD5*( K ; U2 ; K) Here - U0, U1, and U2 are 96-byte constant strings defined below; - MD5* is the MD5 hash function without postprocessing (.e. omitting padding and appended length). This computation has to be done only once and requires in total 6 MD5 block operations. The 16-byte `magic' strings T0, T1, and T2 (given in hexadecimal): T0 = 97 ef 45 ac 29 0f 43 cd 45 7e 1b 55 1c 80 11 34 T1 = b1 77 ce 96 2e 72 8e 7c 5f 5a ab 0a 36 43 be 18 T2 = 9d 21 b4 21 bc 87 b9 4d a2 9d 27 bd c7 5b d7 c3 The 96-byte strings U0, U1, and U2: U0 = T0 ; T1 ; T2 ; T0 ; T1 ; T2 U1 = T1 ; T2 ; T0 ; T1 ; T2 ; T0 U2 = T2 ; T0 ; T1 ; T2 ; T0 ; T1 [crypto95] Bart Preneel, Paul C. van Oorschot, ``MDx-MAC and Building Fast MACs from Hash Functions,'' Proc. Crypto'95, Springer-Verlag LNCS (to appear, Aug. 1995). {ftp: ftp.esat.kuleuven.ac.be, directory pub/COSIC/preneel} From ipsec-request@ans.net Thu Jul 6 12:49:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13433 (5.65c/IDA-1.4.4 for ); Thu, 6 Jul 1995 09:35:13 -0400 Received: by interlock.ans.net id AA47500 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Jul 1995 09:22:57 -0400 Message-Id: <199507061322.AA47500@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Jul 1995 09:22:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Jul 1995 09:22:57 -0400 Date: Thu, 6 Jul 95 12:49:00 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: MDng > From: Bart.Preneel@esat.kuleuven.ac.be > The following note contains a short description of MD5-MAC, which is > a simple and efficient way to derive a Message Authentication Code > from MD5. This is not, strictly speaking, MD5. If you wish to propose a new MD, with different parameters and internal modifications, please indicate with a new name. And demonstrate how it is _faster_ than MD5, since a few others are indicating that MD5 is unacceptably slow in their environments. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Jul 6 15:51:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04969 (5.65c/IDA-1.4.4 for ); Thu, 6 Jul 1995 13:52:28 -0400 Received: by interlock.ans.net id AA12123 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Jul 1995 13:31:34 -0400 Message-Id: <199507061731.AA12123@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Jul 1995 13:31:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Jul 1995 13:31:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Jul 1995 13:31:34 -0400 Date: Thu, 06 Jul 1995 11:51:49 -0400 From: Donald Sharp#Other Subject: subscription request To: ipsec@ans.net Content-Transfer-Encoding: 7BIT subscribe I don't know if this is an automated listserver, but if a human reads this please add me to the list -------- Don Sharp cc32859@vantage.fmrco.com Fidelity Investments (617) 570-3905 82 Devonshire St. A2A Boston, MA 02109 From ipsec-request@ans.net Sat Jul 8 18:51:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA07656 (5.65c/IDA-1.4.4 for ); Sat, 8 Jul 1995 16:46:58 -0400 Received: by interlock.ans.net id AA15279 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 8 Jul 1995 16:43:05 -0400 Message-Id: <199507082043.AA15279@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 8 Jul 1995 16:43:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 8 Jul 1995 16:43:05 -0400 To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@ans.net From: The IESG Subject: Protocol Action: Security Architecture for the Internet Protocol to Proposed Standard Date: Sat, 08 Jul 95 14:51:38 -0400 Sender: scoya@CNRI.Reston.VA.US The IESG has approved the Internet-Drafts as a Proposed Standards: 1. Security Architecture for the Internet Protocol 2. IP Authentication Header 3. IP Encapsulating Security Payload (ESP) 4. IP Authentication using Keyed MD5 5. The ESP DES-CBC Transform These documents are the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller. Technical Summary These documents specify mechanisms for providing Authentication, Integrity, and Confidentiality of data traveling at the IP (both IPv4 and IPv6) layer. Although not intended as a replacement for security services at other layers of the protocol stack, this technology provides significant benefit to the many applications that today use the network with little or no security protection. Working Group Summary After an extended period of discussion and debate, the Working Group has come to consensus around these five documents. More work remains to be done, including the development of an Internet key management protocol, which the working group is currently addressing. Although an automated key management protocol is not yet specified, the above documents do not require a specific mechanism, by design. As such they are implementable as they stand. Protocol Quality Jeff Schiller reviewed these protocols for the IESG. The need for security services on the Internet is now well known and these protocols provide an effective and in many cases transparent solution for many of the Internet Security problems we are experiencing today. Several implementations are currently underway and there is high confidence that these protocols will operate properly. Note: A formal response to the comments raised during the Last Call period will be forthcoming. From ipsec-request@ans.net Mon Jul 10 14:09:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13049 (5.65c/IDA-1.4.4 for ); Mon, 10 Jul 1995 11:06:10 -0400 Received: by interlock.ans.net id AA22458 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Jul 1995 10:58:32 -0400 Message-Id: <199507101458.AA22458@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Jul 1995 10:58:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Jul 1995 10:58:32 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-02.txt Date: Mon, 10 Jul 95 10:09:00 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-02.txt Pages : 35 Date : 07/07/1995 Photuris [1] is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP) in a point-to-point mode. Photuris is still in the early design stages and has not yet been completely specified. It is hoped that this draft will stimulate discussion about the merits of the design philosophy. 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-ietf-ipsec-photuris-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-ietf-ipsec-photuris-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: <19950707150009.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950707150009.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Jul 10 14:03:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA07513 (5.65c/IDA-1.4.4 for ); Mon, 10 Jul 1995 17:16:58 -0400 Received: by interlock.ans.net id AA08218 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Jul 1995 17:13:05 -0400 Message-Id: <199507102113.AA08218@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Jul 1995 17:13:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Jul 1995 17:13:05 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-nsa-isakmp-01.txt, .ps Date: Mon, 10 Jul 95 10:03:49 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, B. Patrick, M. Schertler Filename : draft-nsa-isakmp-01.txt, .ps Pages : 38 Date : 07/07/1995 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those enclaves with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat (e.g. denial of service and replay attacks) mitigation. All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-nsa-isakmp-01.txt". Or "get draft-nsa-isakmp-01.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-nsa-isakmp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-nsa-isakmp-01.txt". Or "FILE /internet-drafts/draft-nsa-isakmp-01.ps". 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: <19950707190040.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-nsa-isakmp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-nsa-isakmp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950707190040.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Sat Jul 15 15:26:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11429 (5.65c/IDA-1.4.4 for ); Sat, 15 Jul 1995 11:34:21 -0400 Received: by interlock.ans.net id AA03862 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 15 Jul 1995 11:26:52 -0400 Message-Id: <199507151526.AA03862@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 15 Jul 1995 11:26:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 15 Jul 1995 11:26:52 -0400 From: Darren Reed Subject: More restrictive controls on cryptography proposed in US Senate (fwd) To: ipsec@ans.net Date: Sun, 16 Jul 1995 01:26:41 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1740 I just picked this up from www-security: > Message-Id: > Date: Sat, 15 Jul 1995 06:54:27 -0500 > From: Albert-Lunde@nwu.edu (Albert Lunde) > Subject: More restrictive controls on cryptography proposed in US Senate > > Senator Grassley has proposed a bill S974 "The Anti-Electronic Racketeering > Act": > > >S974 prohibits the distribution of "computer software that encodes or > >encrypts electronic or digital communications to computer networks that > >the person distributing the software knows or reasonably should know, > >is accessible to foreign nationals and foreign governments, > >regardless of whether such software has been designated as > >nonexportable". > [...] > >There is an important exception though. S974 allows distribution if > >the software contains a "universal decoding device". It is assumed that > >key escrow schemes such the now-infamous "Clipper Chip" are the target of > >this statement. > > The material above is taken from the "Voters Telecommunication Watch" > analysis. (I got the first announcement in VTW BillWatch Issue #9, Date: > Sat Jul 15) For the full text of the bill e-mail: vtw@vtw.org with "send > s974" in the subject line. (For general VTW info see: > http://www.panix.com/vtw/) > > It appears that the bill was referred to the Judiciary Committee and action > is not imminent, but it seems this bears watching as it could have an > extremely adverse effect on electronic commerce and network security. One > might read it to outlaw international use of any kind of cryptography > without Clipper-like holes: i.e. the encryption functions of PGP, SSL, > SHTTP, etc. > > --- > Albert Lunde Albert-Lunde@nwu.edu From ipsec-request@ans.net Sat Jul 15 17:29:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13469 (5.65c/IDA-1.4.4 for ); Sat, 15 Jul 1995 13:37:04 -0400 Received: by interlock.ans.net id AA25346 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 15 Jul 1995 13:29:38 -0400 Message-Id: <199507151729.AA25346@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Sat, 15 Jul 1995 13:29:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sat, 15 Jul 1995 13:29:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 15 Jul 1995 13:29:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 15 Jul 1995 13:29:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 15 Jul 1995 13:29:38 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: Albert-Lunde@nwu.edu (Albert Lunde), jis@mit.edu, linehan@watson.ibm.com, epalmer@watson.ibm.com Cc: e-payment@cc.bellcore.com, ipsec@ans.net Subject: Re: More restrictive controls on cryptography proposed in US Senate In-Reply-To: Your message of "Sat, 15 Jul 1995 06:43:50 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Jul 1995 13:29:01 -0400 From: Amir Herzberg Albert, you are right, this is a big danger. Jeff, Mark, read this!!! > Senator Grassley has proposed a bill S974 "The Anti-Electronic Racketeering > Act": We should suggest it renamed "The Racketeering Anti-Electronic Act"!! > > >S974 prohibits the distribution of "computer software that encodes or > >encrypts electronic or digital communications to computer networks that > >the person distributing the software knows or reasonably should know, > >is accessible to foreign nationals and foreign governments, > >regardless of whether such software has been designated as > >nonexportable". > [...] This should be prevented. Mark, I trust you to get this message in IBM and CSPP. Jeff, I suggest we discuss this in the SAAG and make IETF position known to all relevant bodies including the press (whatever that position would be :-) (I admit; this is so crazy that probably it wouldn't pass anyway, I mean, these people do _think_ about the bills, right? Umm... I guess maybe we should still do something...) > >There is an important exception though. S974 allows distribution if > >the software contains a "universal decoding device". It is assumed that > >key escrow schemes such the now-infamous "Clipper Chip" are the target of > >this statement. Oh, wonderful, such a surprise exception!! > > The material above is taken from the "Voters Telecommunication Watch" > analysis. (I got the first announcement in VTW BillWatch Issue #9, Date: > Sat Jul 15) For the full text of the bill Email: vtw@vtw.org with "send > s974" in the subject line. (For general VTW info see: > http://www.panix.com/vtw/exon) > > It appears that the bill was referred to the Judiciary Committee and action > is not imminent, but it seems this bears watching as it could have an > extremely adverse effect on electronic commerce and network security. One You bet! > might read it to outlaw international use of any kind of cryptography > without Clipper-like holes: i.e. the encryption functions of PGP, SSL, > SHTTP, etc. > best, Amir From ipsec-request@ans.net Wed Jul 19 14:06:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10983 (5.65c/IDA-1.4.4 for ); Wed, 19 Jul 1995 10:17:00 -0400 Received: by interlock.ans.net id AA04034 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Jul 1995 10:04:52 -0400 Message-Id: <199507191404.AA04034@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Jul 1995 10:04:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Jul 1995 10:04:52 -0400 Date: Wed, 19 Jul 1995 07:06:33 -0700 Posted-Date: Wed, 19 Jul 1995 07:06:33 -0700 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Jul 1995 10:04:52 -0400 From: Clifford Neuman To: ipsec@ans.net Subject: Second CFP - ISOC Symposium on Network and Distributed System SecurityBCC: bcn SECOND CALL FOR PAPERS Submission deadline is 14 August LESS THAN ONE MONTH AWAY The Internet Society Symposium on Network and Distributed System Security February 22-23, 1996 San Diego Princess Resort, San Diego, California GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following: * Design and implementation of communication security services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Design and implementation of security mechanisms, services, and APIs to support communication security services, key management and certification infrastructures, audit, and intrusion detection. * Requirements and designs for securing network information resources and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS. * Requirements and designs for systems supporting electronic commerce -- payment services, fee-for-access, EDI, notary -- endorsement, licensing, bonding, and other forms of assurance. * Design and implementation of measures for controlling network communication -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integration of security services with system and application security facilities, and application protocols -- including but not limited to message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems Clifford Neuman, USC Information Sciences Institute LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Doug Engert, Argonne National Laboratory Warwick Ford, Bell Northern Research (Canada) Burt Kaliski, RSA Laboratories Steve Kent, Bolt Beranek and Newman Paul Lambert, Motorola John Linn, OpenVision Technologies Teresa Lunt, Advanced Research Projects Agency Dan Nessett, Sun Microsystems Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Avi Rubin, Bellcore Jeff Schiller, Massachusetts Institute of Technology Rob Shirey, Bolt Beranek and Newman Doug Tygar, Carnegie Mellon University Roberto Zamparo, Telia Research (Sweden) SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Deadline for paper submission: August 14, 1995 Notification sent to authors by: October 16, 1995 Deadline for camera-ready copy: November 13, 1995 Submissions must be received by 14 August 1995. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 14 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Clifford Neuman University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695 Phone: +1 (310) 822-1511 FAX: +1 (310) 823-6714 Email: sndss96-submissions@isi.edu Dates, final call for papers, advance program, and registration information will be made available at the URL: http://nii.isi.edu/info/sndss Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 16 October 1995. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 13 November 1995. From ipsec-request@ans.net Mon Jul 24 17:38:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12188 (5.65c/IDA-1.4.4 for ); Mon, 24 Jul 1995 13:55:23 -0400 Received: by interlock.ans.net id AA46311 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 24 Jul 1995 13:43:02 -0400 Message-Id: <199507241743.AA46311@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 24 Jul 1995 13:43:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 24 Jul 1995 13:43:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 24 Jul 1995 13:43:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 24 Jul 1995 13:43:02 -0400 Date: Mon, 24 Jul 1995 13:38:17 -0400 From: Mary Ellen Corbett Subject: Subscription List To: ipsec@ans.net Mime-Version: 1.0 X-Mailer: InterCon TCP/Connect II 2.1 Content-Type: Text/Plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: Inline Subscribe ipsec From ipsec-request@ans.net Mon Jul 24 13:08:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13037 (5.65c/IDA-1.4.4 for ); Mon, 24 Jul 1995 17:21:05 -0400 Received: by interlock.ans.net id AA09910 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 24 Jul 1995 17:09:06 -0400 Message-Id: <199507242109.AA09910@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 24 Jul 1995 17:09:06 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 24 Jul 1995 17:09:06 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 24 Jul 1995 17:09:06 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 24 Jul 1995 17:09:06 -0400 Date: Mon, 24 Jul 95 17:08:40 EDT From: perry@imsi.com (Perry E. Metzger) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 24 Jul 1995 17:09:06 -0400 To: ipsec@ans.net, ietf@cnri.reston.va.us Subject: IPSEC implementors list Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission An IPSEC implementors list has been created to work towards Steve Crocker's "manual keyed IPSEC by Dallas" challenge. If I haven't already sent you mail informing you of how to subscribe (which I did for most of the implementors I know of -- no slight intended if I forgot about you), please get in touch. Note that this mailing list is for implementors and testers ONLY. Please don't subscribe just to monitor progress -- we will be making periodic announcements. Perry From ipsec-request@ans.net Fri Jul 28 18:23:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14084 (5.65c/IDA-1.4.4 for ); Fri, 28 Jul 1995 14:35:00 -0400 Received: by interlock.ans.net id AA06230 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 28 Jul 1995 14:24:33 -0400 Message-Id: <199507281824.AA06230@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 28 Jul 1995 14:24:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 28 Jul 1995 14:24:33 -0400 Date: Fri, 28 Jul 1995 11:23:48 -0700 From: touch@ISI.EDU Posted-Date: Fri, 28 Jul 1995 11:23:48 -0700 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 28 Jul 1995 14:24:33 -0400 To: ipsec@ans.net Subject: location of the AH in IPv4 Hi, I'm a little confused about the location of the AH in IPv4. The AH spec (draft-ietf-ipsec-auth-02.txt, 25 May '95), says that: 0. Abstract (p 1) AH is normally inserted after the main IP header 3. Authentication Header (p 4-5) When used with IPv4, the AH normally follows the main IPv4 header. but later says: 4. Calculation... (p 8) The IPv4 TTL and HDR-CHKSM fields are then only fields in the IPv4 base header that... This confuses base and main header. What is the main header? I'm presuming the following: A. AH comes after IPv4 base and after IPv4 options (if any) B. IPv4 base length includes base and options only i.e., IPv4 length points to the AH start Is there any verification of this in the specs? Joe ---------------------------------------------------------------------- Joe Touch touch@isi.edu ISI / Project Leader, ATOMIC-2 http://www.isi.edu/~touch USC / Research Assistant Prof. http://www.isi.edu/atomic2 From ipsec-request@ans.net Fri Jul 28 19:16:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13940 (5.65c/IDA-1.4.4 for ); Fri, 28 Jul 1995 15:24:02 -0400 Received: by interlock.ans.net id AA44351 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 28 Jul 1995 15:16:27 -0400 Message-Id: <199507281916.AA44351@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 28 Jul 1995 15:16:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 28 Jul 1995 15:16:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 28 Jul 1995 15:16:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 28 Jul 1995 15:16:27 -0400 To: touch@ISI.EDU Cc: ipsec@ans.net Subject: Re: location of the AH in IPv4 In-Reply-To: Your message of "Fri, 28 Jul 1995 11:23:48 PDT." <199507281824.AA06230@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 28 Jul 1995 15:16:18 -0400 From: "Perry E. Metzger" touch@ISI.EDU writes: > The IPv4 TTL and HDR-CHKSM fields are then only fields > in the IPv4 base header that... > > This confuses base and main header. What is the main header? IPv6isms creeping back to v4. Think of base header as "IPv4 header" > I'm presuming the following: > > A. AH comes after IPv4 base and after IPv4 options (if any) In IPv4, AH comes in the payload. [IPv4 Header][AH [Original payload]] ^payload boundary. Just think of it that way and you are far safer. Perry