idnits 2.17.1 draft-simpson-ah-sha-kdp-00.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-25) 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 62: '... ties SHOULD be a cryptographically ...' RFC 2119 keyword, line 66: '...bits (20 octets) MUST be supported by ...' 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 1996) is 10237 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 255, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'KR95' -- Possible downref: Non-RFC (?) normative reference: ref. 'PO95a' -- Possible downref: Non-RFC (?) normative reference: ref. 'PO95b' ** Obsolete normative reference: RFC 1320 (Obsoleted by RFC 6150) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P Metzger 3 Internet Draft Piermont 4 W A Simpson 5 DayDreamer 6 expires in six months April 1996 8 IP Authentication using Keyed SHA1 with Data Padding 9 draft-simpson-ah-sha-kdp-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet Drafts are working doc- 14 uments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute work- 16 ing documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as refer- 21 ence material, or to cite them other than as a ``working draft'' or 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 26 Directories on: 28 ftp.is.co.za (Africa) 29 nic.nordu.net (Europe) 30 ds.internic.net (US East Coast) 31 ftp.isi.edu (US West Coast) 32 munnari.oz.au (Pacific Rim) 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes the use of keyed SHA1 with the IP Authentica- 39 tion Header. 41 1. Introduction 43 The Authentication Header (AH) [RFC-1826] provides integrity and 44 authentication for IP datagrams. This specification describes the AH 45 use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1]. This 46 SHA1-KDP algorithm uses a leading and trailing key (a variant of the 47 "envelope method"), with alignment padding between both keys and 48 data. 50 It should be noted that this document specifies a newer version of 51 the SHA than that described in [FIPS-180], which was flawed. The 52 older version is not interoperable with the newer version. 54 This document assumes that the reader is familiar with the related 55 document "Security Architecture for the Internet Protocol" 56 [RFC-1825], that defines the overall security plan for IP, and pro- 57 vides important background for this specification. 59 1.1. Keys 61 The secret authentication key shared between the communicating par- 62 ties SHOULD be a cryptographically strong random number, not a guess- 63 able string of any sort. 65 The shared key is not constrained by this transform to any particular 66 size. Lengths of 160-bits (20 octets) MUST be supported by the 67 implementation, although any particular key may be shorter. Longer 68 keys are encouraged. 70 1.2. Data Size 72 SHA1's 160-bit output is naturally 32-bit aligned. However, many 73 implementations require 64-bit alignment of the following headers. 75 Therefore, several options are available for data alignment (most 76 preferred to least preferred): 78 1) only the most significant 128-bits (16 octets) of output are used. 80 2) an additional 32-bits (4 octets) of padding is added before the 81 SHA1 output. 83 3) an additional 32-bits (4 octets) of padding is added after the 84 SHA1 output. 86 4) the SHA1 output is variably bit-positioned within 192-bits (24 87 octets). 89 The size and position of the output are negotiated as part of the key 90 management. Padding bits are filled with unspecified implementation 91 dependent (random) values, which are ignored on receipt. 93 Discussion: 95 Although truncation of the output for alignment purposes may 96 appear to reduce the effectiveness of the algorithm, some analysts 97 of attack verification suggest that this may instead improve the 98 overall robustness [PO95a]. 100 1.3. Performance 102 Preliminary results indicate that SHA1 is 62% as fast as MD5, and 80% 103 as fast as DES hashing. That is: 105 SHA1 < DES < MD5 107 This appears to be a reasonable performance tradeoff, as SHA1 inter- 108 nal chaining is significantly longer than either DES or MD5: 110 DES < MD5 < SHA1 112 Nota Bene: 113 Suggestions are sought on alternative authentication algorithms 114 that have significantly faster throughput, are not patent- 115 encumbered, and still retain adequate cryptographic strength. 117 2. Calculation 119 The 160-bit digest is calculated as described in [FIPS-180-1]. A 120 portable C language implementation of SHA1 is available via FTP from 121 ftp://rand.org/pub/jim/sha.tar.gz. 123 The form of the authenticated message is: 125 SHA1( key, keyfill, datagram, datafill, key, sha1fill ) 127 First, the variable length secret authentication key is filled to the 128 next 512-bit boundary, using the same pad-with-length technique 129 defined for SHA1. The padding technique includes a length that pro- 130 tects arbitrary length keys. 132 Next, the filled key is concatenated with (immediately followed by) 133 the invariant fields of the entire IP datagram (variant fields are 134 zeroed). This is also filled to the next 512-bit boundary, using the 135 same pad-with-length technique defined for SHA1. The length includes 136 the leading key and data. 138 Then, the filled data is concatenated with (immediately followed by) 139 the original variable length key again. A trailing pad-with-length 140 to the next 512-bit boundary for the entire message is added by SHA1 141 itself. 143 Finally, the 160-bit SHA1 digest is calculated, and the result is 144 inserted into the Authentication Data field. 146 Discussion: 148 The leading copy of the key is padded in order to facilitate copy- 149 ing of the key at machine boundaries without requiring re- 150 alignment of the following datagram. Filling to the SHA1 block 151 size also allows the key to be prehashed to avoid the physical 152 copy in some implementations. 154 The trailing copy of the key is not necessary to protect against 155 appending attacks, as the IP datagram already includes a total 156 length field. It reintroduces mixing of the entire key, providing 157 protection for very long and very short datagrams, and robustness 158 against possible attacks on the IP length field itself. 160 When the implementation adds the keys and padding in place before 161 and after the IP datagram, care must be taken that the keys and/or 162 padding are not sent over the link by the link driver. 164 A. Changes 166 Changes from RFC-1852: 168 Use of SHA1 term (as always intended). 170 Added shortened 128-bit output, and clarify output text. 172 Added tradeoff text. 174 Changed padding technique to comply with Crypto '95 recommendations. 176 Updated references. 178 Updated contacts. 180 Minor editorial changes. 182 Security Considerations 184 Users need to understand that the quality of the security provided by 185 this specification depends completely on the strength of the SHA1 186 hash function, the correctness of that algorithm's implementation, 187 the security of the key management mechanism and its implementation, 188 the strength of the key, and upon the correctness of the implementa- 189 tions in all of the participating nodes. 191 The SHA algorithm was originally derived from the MD4 algorithm 192 [RFC-1320]. A flaw was apparently found in the original specifica- 193 tion of SHA [FIPS-180], and this document specifies the use of a cor- 194 rected version [FIPS-180-1]. 196 At the time of writing of this document, there are no known flaws in 197 the SHA1 algorithm. That is, there are no known attacks on SHA1 or 198 any of its components that are better than brute force, and the 199 160-bit hash size of SHA1 is substantially more resistant to brute 200 force attacks than the 128-bit hash size of MD4 and MD5. 202 However, as the flaw in the original SHA1 algorithm shows, cryptogra- 203 phers are fallible, and there may be substantial deficiencies yet to 204 be discovered in the algorithm. 206 Acknowledgements 208 Some of the text of this specification was derived from work by Ran- 209 dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 211 Preliminary performance analysis was provided by Joe Touch. 213 Padding the leading copy of the key to a hash block boundary for 214 increased performance was originally suggested by William Allen Simp- 215 son. 217 Padding the leading copy of the key to a hash block boundary for 218 increased security was suggested by [KR95]. Including the key length 219 for increased security was suggested by David Wagner. 221 Padding the datagram to a hash block boundary to avoid (an impracti- 222 cal) key recovery attack was suggested by [PO95b]. 224 References 226 [FIPS-180] 227 "Secure Hash Standard", Computer Systems Laboratory, 228 National Institute of Standards and Technology, U.S. Depart- 229 ment Of Commerce, May 1993. 231 Also known as: 58 Fed Reg 27712 (1993). 233 [FIPS-180-1] 234 "Secure Hash Standard", National Institute of Standards and 235 Technology, U.S. Department Of Commerce, April 1995. 237 Also known as: 59 Fed Reg 35317 (1994). 239 [KR95] Kaliski, B., and Robshaw, M., "Message authentication with 240 MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1 241 no.1, Spring 1995. 243 [PO95a] Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast 244 MACs from Hash Functions", Advances in Cryptology -- Crypto 245 '95 Proceedings, Santa Barbara, California, August 1995. 247 [PO95b] Preneel, B., and van Oorshot, P., "On the Security of Two 248 MAC Algorithms", Presented at the Rump Session of Crypto 249 '95, Santa Barbara, California, August 1995. 251 [RFC-1320] 252 Ronald Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, 253 April 1992. 255 [RFC-1700] 256 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 257 1700, USC/Information Sciences Institute, October 1994. 259 [RFC-1825] 260 Atkinson, R., "Security Architecture for the Internet Proto- 261 col", RFC-1825, Naval Research Laboratory, July 1995. 263 [RFC-1826] 264 Atkinson, R., "IP Authentication Header", RFC-1826, Naval 265 Research Laboratory, July 1995. 267 Contacts 268 Comments about this document should be discussed on the ipsec- 269 dev@terisa.com mailing list. 271 Questions about this document can also be directed to: 273 Perry Metzger 274 Piermont Information Systems Inc. 275 160 Cabrini Blvd., Suite #2 276 New York, NY 10033 278 perry@piermont.com 280 William Allen Simpson 281 Daydreamer 282 Computer Systems Consulting Services 283 1384 Fontaine 284 Madison Heights, Michigan 48071 286 wsimpson@UMich.edu 287 wsimpson@GreenDragon.com (preferred) 288 bsimpson@MorningStar.com