idnits 2.17.1 draft-metzger-ah-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 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 171: '... and can be easily reversed, they MUST...' RFC 2119 keyword, line 234: '... positions MUST be ignored by the...' RFC 2119 keyword, line 254: '...ed. The failure SHOULD be recorded in...' RFC 2119 keyword, line 306: '... The sender MUST compute the calcula...' RFC 2119 keyword, line 318: '...hen the receiver SHOULD discard the re...' (1 more instance...) 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 (January 1995) is 10693 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) == Missing Reference: 'TBD' is mentioned on line 113, but not defined == Unused Reference: 'Bell89' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'VK83' is defined on line 385, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAsa' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAesp' ** Downref: Normative reference to an Historic RFC: RFC 1446 ** Downref: Normative reference to an Informational RFC: RFC 1636 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell89' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 January 1995 5 IPv4 Authentication Header (4AH) 6 draft-metzger-ah-00.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 an authentication mechanism for IPv4, by 40 inserting an intervening header between the IPv4 Header and any 41 transport headers. 43 1. Introduction 45 The Authentication Header (AH) seeks to provide integrity and 46 authentication for IP datagrams. It may also provide non- 47 repudiation, depending on which algorithm is used. 49 Users desiring confidentiality should consider using the 50 Encapsulating Security Protocol (ESP) [RAesp], either in lieu of or 51 in conjunction with the Authentication Header. 53 This document assumes that the reader is familiar with the related 54 document "IPv4 Security Overview" [RAsa], which defines the overall 55 security plan for IPv4, and provides important background for this 56 specification. 58 1.1. Overview 60 The Authentication Header (AH) seeks to provide security by adding 61 authentication information to an IP datagram. The authentication 62 information is calculated using all of the fields in the IP datagram 63 which do not change in transit. This includes portions of the IP 64 Header, transport headers, and the user data. 66 In order for the Authentication Header to work properly without 67 changing the entire Internet infrastructure (particularly non- 68 participating routers), the authentication data is carried in its own 69 IP protocol payload. Nodes that aren't participating in the 70 authentication ignore the Authentication Header. 72 In some environments, intermediate routing authentication might be 73 desirable [RFC-1636]. If an asymmetric authentication algorithm is 74 used, then the routers performing such intermediate authentication 75 would need to be aware of the appropriate public keys and 76 authentication algorithm. The routers could authenticate the traffic 77 being handled, without being able to forge or modify otherwise 78 legitimate traffic. 80 If a symmetric authentication algorithm is used, then the routers 81 performing such intermediate authentication would need to be provided 82 with the appropriate keys. Possession of those keys would permit any 83 one of those systems to forge traffic claiming to be from the 84 legitimate sender to the legitimate receiver, or to modify the 85 contents of otherwise legitimate traffic. 87 Use of this specification will increase the protocol processing costs 88 in participating systems, and will also increase the communications 89 latency. The increased latency is primarily due to time required for 90 calculation of the authentication data by the sender, and the 91 calculation and comparison of the authentication data by the 92 receiver, over each datagram containing an Authentication Header. 93 The impact will vary with authentication algorithm used and other 94 factors, but is expected to be relatively inexpensive to implement. 96 1.2. Key Management 98 Key management is an important part of the IP security architecture. 99 A scalable standard Internet key management protocol is needed to 100 make widespread use of authentication practical. 102 However, in order to facilitate early adoption, manual key management 103 is the only key management technique required by this specification. 105 The only coupling between key management and the AH is the Security 106 Association Identifier (SAID), which is described in more detail 107 later. This permits several different key management mechanisms to 108 be used. 110 More importantly, it permits the key management protocol to be 111 changed or corrected without unduly impacting the security protocol 112 implementations. Thus, key management is specified in a separate 113 specification [TBD]. 115 Nota Bene: It is intended that the key management mechanisms being 116 developed in other IETF Working Groups will be useful for both 117 IPv4 and IPv6. 119 1.3. Security Associations 121 The key management mechanism is used to negotiate a number of 122 parameters for each Security Association between the communicating 123 parties. This includes the key(s) used to generate the 124 authentication data, and also other parameters (such as the 125 authentication algorithm and mode). 127 The key management protocol implementation usually maintains a table 128 containing the several parameters for each current Security 129 Association. The AH implementation needs to access that security 130 parameter table to determine how to process each datagram. 132 The Security Association Identifier (SAID) is assigned by the entity 133 controlling the Destination IP address of the Security Association. 134 The selection mechanism used for the SAID is implementation 135 dependent. 137 A given Destination is not necessarily in control of the 138 negotiation process. In the case of multicast groups, a single 139 node or cooperating subset of the multicast group may work on 140 behalf of the entire group to set up a Security Association. 142 A session between two nodes will normally have two SAID values (one 143 in each direction). The nodes use the combination of SAID and IP 144 Destination to distinguish the correct association. 146 Senders to a multicast group may share a common Security Association, 147 if all communications are authenticated using the same security 148 configuration parameters. In this case, the receiver only knows that 149 the message came from a node knowing the Security Association for the 150 group, and cannot authenticate which member of the group sent the 151 datagram when symmetric algorithms are in use. 153 Multicast groups may also use a separate Security Association value 154 for each Source. If each sender is keyed separately and asymmetric 155 algorithms are used, data origin authentication is also provided. 157 1.4. Mechanisms 159 It is intended that the AH format should be sufficiently general to 160 permit the specification of new mechanisms as new cryptographic 161 algorithms are developed. 163 Each SAID value indicates the algorithm and mode used, the block size 164 (if any) of the algorithm, and the presence/absence and size of a 165 cryptographic synchronization or initialization vector field. These 166 parameters are described in companion mechanism documents. 168 The authentication mechanism uses a message digest algorithm (such as 169 MD5), either encrypting that message digest or keying the message 170 digest directly. Because conventional checksums (such as CRC-16) are 171 not cryptographically strong and can be easily reversed, they MUST 172 NOT be used with the Authentication Header. 174 2. Payload Format 176 The Authentication Header (AH) may appear after any other headers 177 which are examined at each hop, and before any other headers which 178 are not examined at an intermediate hop. The header immediately 179 preceding the Authentication Header will always contain the value 180 in its Next Header (Protocol) field. 182 +-----------+-----------------+-----------+---------+-----------+ 183 | IP Header | Routing/Hop-Hop | Auth Head | End-End | Transport | 184 +-----------+-----------------+-----------+---------+-----------+ 186 2.1. Header Fields 188 A more detailed diagram of the Authentication Header follows: 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Next Header | Length | 0 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Security Association Identifier (SAID) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 ~ Authentication Data ~ 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Next Header 202 Identifies the next header after the Authentication Header, using 203 the IP Protocol/Payload value. Up-to-date values of the IP 204 Protocol/Payload are specified in the most recent "Assigned 205 Numbers" [RFC-1700]. 207 Length 209 The length of the Authentication Data field in 64-bit increments. 210 Minimum value is 0, which is only used in the degenerate case of a 211 "null" authentication algorithm. 213 Security Association Identifier (SAID) 215 A value identifying the Security Association for this datagram. 216 If no Security Association has been established, the value of this 217 field is zero. 219 SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are 220 reserved for future use. 222 Authentication Data 224 The length of this field is variable, but is always an integral 225 number of 64-bits. 227 An implementation will normally use the SAID to determine the 228 field's size and use. It retains the same format for all 229 datagrams of any given SAID and IP Destination. 231 The Authentication Data fills the field beginning immediately 232 after the SAID field. If the field is longer than necessary to 233 store the actual authentication data, then the unused bit 234 positions MUST be ignored by the receiver. Each mechanism will 235 have such special processing instructions included in its 236 specification. 238 Refer to each Authentication Mechanism specification for more 239 information regarding the contents of this field. 241 3. Processing 243 This chapter describes the steps taken when the AH is in use between 244 two communicating parties. 246 The sender first determines if a Security Association has been 247 established with the target Destination. If not, then the key 248 management mechanism is used to establish the SAID for this 249 communications session prior to the use of the AH. 251 If an unauthenticated datagram arrives from a Source after a SAID has 252 been established, or a SAID is received which is not valid, then an 253 error is indicated. The datagram is discarded, and an appropriate 254 ICMP message is returned. The failure SHOULD be recorded in the 255 system or audit log, including the cleartext values for the SAID, 256 date/time, Source, Destination, and other identifying information. 258 Multicast is different from unicast only in the area of key 259 management. 261 3.1. Calculation 263 The Authentication Data is the output of the authentication algorithm 264 calculated over the invariant portions of the entire IPv4 datagram. 265 The sender places this algorithm output into the Authentication Data 266 field within the Authentication Header. 268 When a keyed message digest algorithm is used (such as MD5), the 269 secret key is fed into the algorithm first, followed by the invariant 270 fields of the IP datagram in sequence. 272 The secret key is fed in first, because that increases the work 273 function for someone attempting to cryptanalyse the key from 274 knowledge of the plaintext datagram. Feeding the secret key in 275 first also permits implementations to precompute the start of the 276 hash for a given destination, and possibly improve performance 277 thereby. 279 The key does not need to be fed in at the end. Including the IP 280 Header's invariant Total Length field in the authentication 281 calculation precludes appending attacks. 283 Fields which will necessarily vary in transit from the sender to the 284 receiver (such as the Hop Count), are included in the calculation, 285 but the value zero is substituted for the actual value of such 286 fields. 288 The Authentication Data field itself is also zeroed during the 289 calculation. All other Authentication Header fields are included. 291 This substitution of zero is used instead of omitting those 292 fields, because it preserves alignment of the data during 293 calculation, which can significantly improve performance. 295 If a block-oriented authentication algorithm is in use (such as MD2, 296 MD4, MD5), and the IP datagram is not an integral number of blocks, 297 the authentication data calculation is performed using zero bytes at 298 the end of the datagram to pad the length out to an integral number 299 of blocks. 301 These block padding bytes are not included in the actual IP 302 datagram, and are not sent over the link. Adding padding at that 303 point in protocol processing could make implementation of MTU 304 related calculations very difficult. 306 The sender MUST compute the calculation over the datagram as it will 307 appear at the receiver. This requirement allows for future 308 intervening headers which are removed or altered during transit. The 309 sender needs to know the final values when including such headers in 310 the datagram. Each such header will have special processing 311 instructions included in its specification. 313 Upon receipt of a datagram containing an Authentication Header, the 314 receiver independently calculates the authentication data. It 315 compares the received Authentication Data field contents with the 316 calculated authentication value. 318 If they differ, then the receiver SHOULD discard the received IP 319 datagram, and return an appropriate ICMP message. The failure MUST 320 be recorded in the system or audit log, as described earlier. 322 Security Considerations 324 This specification is principly concerned with a security mechanism 325 for use with IP. This mechanism is not a panacea, but it does 326 provide an important component useful in creating a secure 327 internetwork. 329 Users need to understand that the quality of the security provided by 330 this specification depends completely on the strength of whichever 331 cryptographic algorithm that has been implemented, the correctness of 332 that algorithm's implementation, the security of the key management 333 mechanism and its implementation, the strength of the key [CN94], and 334 upon the correctness of the implementations in all of the 335 participating systems. 337 If any of these assumptions do not hold, then little or no real 338 security will be provided to the user. Implementers are encouraged 339 to use high assurance development techniques to develop all of the 340 security relevant parts of their products. 342 Acknowledgements 344 The original text of this specification was derived from work by Ran 345 Atkinson for the SIP, SIPP, and IPv6 Working Groups. 347 The basic concept is derived in large part from the work done for 348 SNMPv2 [RFC-1446]. 350 Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic 351 provided useful critiques of earlier versions of this draft. 353 References 355 [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: 356 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 357 253-280, July 1994. 359 [RAsa] Randall Atkinson, IPv6 Security Architecture, work in 360 progress, 4 November 1994. 362 [RAesp] Randall Atkinson, IPv6 Encapsulating Security Payload, work 363 in progress, 4 November 1994. 365 [RFC-1446] 366 James Galvin & Keith McCloghrie, Security Protocols for 367 version 2 of the Simple Network Management Protocol 368 (SNMPv2), RFC-1446, DDN Network Information Center, April 369 1993. 371 [RFC-1636] 372 R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of 373 IAB Workshop on Security in the Internet Architecture", 374 RFC-1636, DDN Network Information Center, 9 June 1994, pp. 375 21-34. 377 [RFC-1700] 378 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 379 1700, USC/Information Sciences Institute, October 1994. 381 [Bell89] Steven M. Bellovin, "Security Problems in the TCP/IP 382 Protocol Suite", ACM Computer Communications Review, Vol. 383 19, No. 2, March 1989. 385 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level 386 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 388 Author's Address 390 Questions about this memo can also be directed to: 392 Randall Atkinson 393 Information Technology Division 394 Naval Research Laboratory 395 Washington, 396 DC 20375-5320 397 USA 398 Telephone: (DSN) 354-8590 399 Fax: (DSN) 354-7942 400 402 Perry Metzger 403 Piermont Information Systems Inc. 404 160 Cabrini Blvd., Suite #2 405 New York, NY 10033 407 perry@piermont.com 409 William Allen Simpson 410 Daydreamer 411 Computer Systems Consulting Services 412 1384 Fontaine 413 Madison Heights, Michigan 48071 415 Bill.Simpson@um.cc.umich.edu 416 bsimpson@MorningStar.com 417 Table of Contents 419 1. Introduction .......................................... 1 420 1.1 Overview ........................................ 1 421 1.2 Key Management .................................. 2 422 1.3 Security Associations ........................... 2 423 1.4 Mechanisms ...................................... 3 425 2. Payload Format ........................................ 4 426 2.1 Header Fields ................................... 4 428 3. Processing ............................................ 5 429 3.1 Calculation ..................................... 6 431 SECURITY CONSIDERATIONS ...................................... 7 433 ACKNOWLEDGEMENTS ............................................. 7 435 REFERENCES ................................................... 8 437 AUTHOR'S ADDRESS ............................................. 8