idnits 2.17.1 draft-ietf-ipsec-ah-md5-03.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-26) 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 14 instances of too long lines in the document, the longest one being 4 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 52: '...er specification MUST implement this M...' RFC 2119 keyword, line 67: '... 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 (April 1995) is 10604 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 168, 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 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1720 (Obsoleted by RFC 1780) -- 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. -------------------------------------------------------------------------------- 2 Network Working Group P Metzger 3 Internet Draft W A Simpson 4 expires in six months April 1995 6 IP Authentication using Keyed MD5 7 draft-ietf-ipsec-ah-md5-03.txt | 9 Status of this Memo 11 This document is a submission to the IP Security Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the ipsec@ans.net mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Abstract 40 This document describes the use of keyed MD5 with the IP 41 Authentication Header. 43 1. Introduction 45 The Authentication Header (AH) [A-AH] provides integrity and 46 authentication for IP datagrams. 48 This specification describes the AH use of Message Digest 5 (MD5) 49 [RFC-1321]. 51 All implementations that claim conformance or compliance with the 52 Authentication Header specification MUST implement this MD5 53 mechanism. 55 Implementors should consult the most recent version of the IAB | 56 Standards [RFC-1720] for further guidance on the status of this 57 document. 59 This document assumes that the reader is familiar with the related 60 document "Security Architecture for the Internet Protocol" [A-SA], 61 which defines the overall security plan for IP, and provides 62 important background for this specification. 64 1.1. Keys 66 The secret authentication key shared between the communicating 67 parties SHOULD be a pseudo-random number, not a guessable string of 68 any sort. 70 1.2. Data Size 72 MD5's 128-bit output is naturally 64-bit aligned. Typically, there 73 is no further padding of the Authentication Data field. 75 1.3. Performance 77 MD5 reportedly has a throughput of about 60 Mbps on a fast 64-bit 78 RISC processor with slightly tuned MD5 code [Touch94]. 80 Nota Bene: This is possibly too slow. Suggestions are sought on 81 alternative authentication algorithms that have significantly 82 faster throughput, are not patent-encumbered, and still retain 83 adequate cryptographic strength. 85 2. Calculation 87 The 128-bit digest is calculated as described in [RFC-1321]. The 88 specification of MD5 includes a portable 'C' programming language 89 description of the MD5 algorithm. 91 The variable length secret authentication key is zero-filled to the | 92 next 128-bit boundary, concatenated with (immediately followed by) | 93 the invariant fields of the entire IP datagram, concatenated with | 94 (immediately followed by) the variable length secret authentication | 95 key again (trailing padding is added by the MD5 algorithm). The | 96 resulting 128-bit digest is inserted into the Authentication Data | 97 field. 99 Care must be taken that the keys and padding are not sent over the | 100 link. 102 Security Considerations 104 Users need to understand that the quality of the security provided by 105 this specification depends completely on the strength of the MD5 hash 106 function, the correctness of that algorithm's implementation, the 107 security of the key management mechanism and its implementation, the 108 strength of the key [CN94], and upon the correctness of the 109 implementations in all of the participating nodes. 111 Among other considerations, applications may wish to take care not to 112 select weak keys, although the odds of picking one at random are low 113 [Schneier94, p 233]. 115 At the time of writing of this document, it is known to be possible 116 to produce collisions in the compression function of MD5 [BB93]. 117 There is not yet a known method to exploit these collisions to attack 118 MD5 in practice, but this fact is disturbing to some authors 119 [Schneier94]. 121 It has also recently been determined [OW94] that it is possible to 122 build a machine for $10 Million that could find messages that hash to 123 an arbitrary given MD5 hash. This attack requires approximately 24 124 days. Although this is not a substantial weakness for most IP 125 security applications, it should be recognized that current 126 technology is catching up to the 128-bit hash length used by MD5. 127 Applications requiring extremely high levels of security may wish to 128 move in the near future to algorithms with longer hash lengths. 130 Acknowledgements 132 Some of the text of this specification was derived from work by 133 Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 135 The basic concept and use of MD5 is derived in large part from the 136 work done for SNMPv2 [RFC-1446]. 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-1700] 169 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 170 1700, USC/Information Sciences Institute, October 1994. | 172 [RFC-1720] | 173 Postel, J., "Internet Official Protocol Standards", STD 1, | 174 RFC 1720, USC/Information Sciences Institute, November 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 ............................................. 3 222 REFERENCES ................................................... 3 224 AUTHOR'S ADDRESS ............................................. 4