idnits 2.17.1 draft-ietf-ipsec-ah-md5-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 51: '...er specification MUST implement this M...' RFC 2119 keyword, line 66: '... parties SHOULD be a pseudo-random n...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1995) is 10628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-1700' is defined on line 172, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'A-SA' -- Possible downref: Non-RFC (?) normative reference: ref. 'A-AH' -- Possible downref: Non-RFC (?) normative reference: ref. 'BB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1446 ** Obsolete normative reference: RFC 1610 (Obsoleted by RFC 1720) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'OW94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Touch94' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Metzger 2 Internet Draft W A Simpson 3 expires in six months March 1995 5 IP Authentication using Keyed MD5 6 draft-ietf-ipsec-ah-md5-02.txt | 8 Status of this Memo 10 This document is a submission to the IP Security Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the ipsec@ans.net mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 29 Directories on: 31 ftp.is.co.za (Africa) 32 nic.nordu.net (Europe) 33 ds.internic.net (US East Coast) 34 ftp.isi.edu (US West Coast) 35 munnari.oz.au (Pacific Rim) 37 Abstract 39 This document describes the use of keyed MD5 with the IP 40 Authentication Header. 42 1. Introduction 44 The Authentication Header (AH) [A-AH] provides integrity and 45 authentication for IP datagrams. 47 This specification describes the AH use of Message Digest 5 (MD5) 48 [RFC-1321]. 50 All implementations that claim conformance or compliance with the 51 Authentication Header specification MUST implement this MD5 52 mechanism. 54 Implementors should consult the most recent version of the IAB 55 Standards [RFC-1610] for further guidance on the status of this 56 document. 58 This document assumes that the reader is familiar with the related 59 document "Security Architecture for the Internet Protocol" [A-SA], 60 which defines the overall security plan for IP, and provides 61 important background for this specification. 63 1.1. Keys 65 The secret authentication key shared between the communicating 66 parties SHOULD be a pseudo-random number, not a guessable string of 67 any sort. 69 1.2. Data Size 71 MD5's 128-bit output is naturally 64-bit aligned. Typically, there 72 is no further padding of the Authentication Data field. 74 1.3. Performance 76 MD5 reportedly has a throughput of about 60 Mbps on a fast 64-bit 77 RISC processor with slightly tuned MD5 code [Touch94]. 79 Nota Bene: This is possibly too slow. Suggestions are sought on 80 alternative authentication algorithms that have significantly 81 faster throughput, are not patent-encumbered, and still retain 82 adequate cryptographic strength. 84 2. Calculation 86 The 128-bit digest is calculated as described in [RFC-1321]. The 87 specification of MD5 includes a portable 'C' programming language 88 description of the MD5 algorithm. 90 The invariant fields of the entire IP datagram are hashed first. The 91 variable length secret authentication key is concatenated with 92 (immediately followed by) this initial 128-bit digest, and the 93 combination is hashed again. This final 128-bit digest is inserted 94 into the Authentication Data field. 96 The MD5 algorithm requires a particular format of padding after the * 97 end of the authenticated data. This padding is not sent over the 98 link. * 100 Security Considerations 102 Users need to understand that the quality of the security provided by 103 this specification depends completely on the strength of the MD5 hash 104 function, the correctness of that algorithm's implementation, the 105 security of the key management mechanism and its implementation, the 106 strength of the key [CN94], and upon the correctness of the 107 implementations in all of the participating nodes. 109 Among other considerations, applications may wish to take care not to 110 select weak keys, although the odds of picking one at random are low 111 [Schneier94, p 233]. 113 At the time of writing of this document, it is known to be possible 114 to produce collisions in the compression function of MD5 [BB93]. 115 There is not yet a known method to exploit these collisions to attack 116 MD5 in practice, but this fact is disturbing to some authors 117 [Schneier94]. 119 It has also recently been determined [OW94] that it is possible to 120 build a machine for $10 Million that could find messages that hash to 121 an arbitrary given MD5 hash. This attack requires approximately 24 122 days. Although this is not a substantial weakness for most IP 123 security applications, it should be recognized that current 124 technology is catching up to the 128-bit hash length used by MD5. 125 Applications requiring extremely high levels of security may wish to 126 move in the near future to algorithms with longer hash lengths. 128 Acknowledgements 130 Some of the text of this specification was derived from work by 131 Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 133 The basic concept and use of MD5 is derived in large part from the 134 work done for SNMPv2 [RFC-1446]. 136 Burt Kaliski suggested the two step keyed-MD5 technique. 138 Steve Bellovin, Steve Deering, Frank Kastenholz, Charles Lynn, and 139 Dave Mihelcic provided useful critiques of earlier versions of this 140 draft. 142 References 144 [A-SA] Randall Atkinson, "Security Architecture for the Internet 145 Protocol", work in progress. 147 [A-AH] Randall Atkinson, "IP Authentication Header", work in 148 progress. 150 [BB93] B. den Boer and A. Bosselaers, "Collisions for the 151 Compression function of MD5", Advances in Cryptology -- 152 Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994 154 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 155 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 156 253-280, July 1994. 158 [RFC-1321] 159 Ronald Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, 160 DDN Network Information Center, April 1992. 162 [RFC-1446] 163 Galvin, J., and McCloghrie, K., "Security Protocols for 164 Version 2 of the Simple Network Management Protocol 165 (SNMPv2)", RFC-1446, DDN Network Information Center, April 166 1993. 168 [RFC-1610] 169 Postel, J., "Internet Official Protocol Standards", STD 1, 170 RFC 1610, USC/Information Sciences Institute, July 1994. 172 [RFC-1700] 173 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 174 1700, USC/Information Sciences Institute, October 1994. 176 [OW94] Paul C. van Oorschot & Michael J. Wiener, "Parallel 177 Collision Search with Application to Hash Functions and 178 Discrete Logarithms", Proceedings of the 2nd ACM Conf. 179 Computer and Communications Security, Fairfax, VA, Nov 3-5 180 1994. 182 [Schneier94] 183 Schneier, B., "Applied Cryptography", John Wiley & Sons, New 184 York, NY, 1994. ISBN 0-471-59756-2 186 [Touch94] 187 Touch, J., "Report on MD5 Performance", work in progress, 188 December 1994. 190 Author's Address 192 Questions about this memo can also be directed to: 194 Perry Metzger 195 Piermont Information Systems Inc. 196 160 Cabrini Blvd., Suite #2 197 New York, NY 10033 199 perry@piermont.com 201 William Allen Simpson 202 Daydreamer 203 Computer Systems Consulting Services 204 1384 Fontaine 205 Madison Heights, Michigan 48071 207 Bill.Simpson@um.cc.umich.edu 208 bsimpson@MorningStar.com 209 Table of Contents 211 1. Introduction .......................................... 1 212 1.1 Keys ............................................ 1 213 1.2 Data Size ....................................... 1 214 1.3 Performance ..................................... 1 216 2. Calculation ........................................... 2 218 SECURITY CONSIDERATIONS ...................................... 2 220 ACKNOWLEDGEMENTS ............................................. 2 222 REFERENCES ................................................... 3 224 AUTHOR'S ADDRESS ............................................. 4