Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-ipsec-auth-00.txt 23 March 1995 IP Authentication Header STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng and IPsec Working Groups. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. 0. ABSTRACT This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. An Authentication Header (AH) is normally inserted after the main IP header and before the other information being authenticated. In addition, this document describes the use of keyed MD5 in conjunction with this Authentication Header. 1. INTRODUCTION The Authentication Header is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed. For example, use of an asymmetric digital signature algorithm, for example RSA, could provide non-repudiation. Atkinson [Page 1] Internet Draft IP Authentication Header 23 March 1995 Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IP Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [Atk95b] This document assumes the reader has previously read the related IP Security Architecture document which defines the overall security architecture for IP and provides important background information for this specification. [Atk95a] 1.1 Overview The IP Authentication Header seeks to provide security by adding authentication information to an IP datagram. This authentication information is calculated using all of the fields in the IP datagram (including not only the IP Header but also other headers and the user data) which do not change in transit. Fields which need to change in transit (e.g "hop count" or "routing pointer") are omitted from the calculation of the authentication data. This provides significantly more security than is currently present in IPv4 and might be sufficient for the needs of many users. Use of this specification will increase the IP protocol processing costs in participating end systems and will also increase the communications latency. The increased latency is primarily due to the calculation of the authentication data by the sender and the calculation and comparison of the authentication data by the receiver for each IP datagram containing an Authentication Header. The impact will vary with authentication algorithm used and other factors. In order for the Authentication Header to work properly without changing the entire Internet infrastructure, the authentication data is carried in its own payload. Systems that aren't participating in the authentication MAY ignore the Authentication Data. When used with IPv6, the Authentication Header is normally placed after the Hop-by-Hop header, which is examined at each hop, and before the End-to-End Header, which is never examined at an intermediate hop. The information in the other IP headers is used to route the datagram from origin to destination. When used with IPv4, the Authentication Header immediately follows the main IPv4 header. If a symmetric authentication algorithm is used and intermediate authentication is desired, then the nodes performing such intermediate authentication would need to be provided with the appropriate keys. Possession of those keys would permit any one of those systems to forge traffic claiming to be from the legitimate sender to the legitimate receiver or to modify the contents of otherwise legitimate traffic. In some environments such intermediate authentication might be desirable. [BCCH94] If an asymmetric authentication algorithm is used and the routers are aware of the appropriate public keys and Atkinson [Page 2] Internet Draft IP Authentication Header 23 March 1995 authentication algorithm, then the routers possessing the authentication public key could authenticate the traffic being handled without being able to forge or modify otherwise legitimate traffic. 1.2 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 2. KEY MANAGEMENT Key management is an important part of the IP security architecture. However, it is not integrated with this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. The IP Authentication Header tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security protocol is with the Security Association Identifier (SPI), which is described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. The key management mechanism is used to negotiate a number of parameters for each "Security Association", including not only the keys but also other information (e.g. the authentication algorithm and Atkinson [Page 3] Internet Draft IP Authentication Header 23 March 1995 mode) used by the communicating parties. The key management mechanism creates and maintains a logical table containing the several parameters for each current security association. An implementation of the IP Authentication Header will need to read that logical table of security parameters to determine how to process each datagram containing an Authentication Header (e.g. to determine which algorithm/mode and key to use in authentication). The combination of Destination Address and SPI value is used to identify the appropriate Security Association and hence the security parameters in use. The IP Security Architecture document describes key management in detail. It includes specification of the key management requirements for this protocol, and is incorporated here by reference. [Atk95a] 3. AUTHENTICATION HEADER The Authentication Header (AH) may appear after any other headers which are examined at each hop, and before any other headers which are not examined at an intermediate hop. The IPv4 or IPv6 header immediately preceding the Authentication Header will contain the value 51 in its Next Header (or Protocol) field. [STD-2] Example high-level diagrams of IP datagrams with the Authentication Header follow. +-------------+--------------------+-------------+--------+----------------+ | IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol | +-------------+--------------------+-------------+--------+----------------+ IPv6 Example When used with IPv6, the Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options. +-------------+--------------+-------------------------------+ | IPv4 Header | Auth Header | Upper Protocol (e.g TCP, UDP) | +-------------+--------------+-------------------------------+ IPv4 Example When used with IPv4, the Authentication Header normally follows the main IPv4 header. 3.1 Authentication Header Syntax The authentication data is the output of the authentication algorithm calculated over the invariant portions of the entire IP datagram. The authentication calculation must treat the Authentication Data field itself as if the field contained all zeros. Atkinson [Page 4] Internet Draft IP Authentication Header 23 March 1995 All other Authentication Header fields are included in the authentication calculation normally. The IP Authentication Header has the following syntax: +--------------+---------------+----------------+--------------+ | Next Header | Length | RESERVED | +--------------+---------------+----------------+--------------+ | Security Parameters Index | +--------------+---------------+----------------+--------------+ | Authentication Data (variable number of 32-bit words) | +--------------+---------------+----------------+--------------+ | (more Authentication Data) | +--------------+---------------+----------------+--------------+ 3.2 Fields of the Authentication Header NEXT HEADER 8 bits wide. Identifies the next payload after the Authentication Payload. This values in this field are the set of IP Protocol Numbers as defined in the most recent RFC from the Internet Assigned Numbers Authority (IANA) describing "Assigned Numbers". [STD-2] PAYLOAD LENGTH 8 bits wide. The length of the Authentication Data field in 32-bit words. Minimum value is 0 words, which is only used in the degenerate case of a "null" authentication algorithm. RESERVED Reserved for future use. MUST be set to all zeros when sent and ignored upon receipt. SECURITY PARAMETERS INDEX (SPI) A 32-bit pseudo-random value identifying the security association for this datagram. The Ssecurity Parameters Index value 0 is reserved to indicate that "no security association exists". The set of Security Parameters Index values in the range 1 through 255 are reserved to the Internet Assigned Numbers Authority (IANA) for future use. A reserved SPI value will not normally be assigned by IANA unless the use of that particular assigned SPI value is openly specified in an RFC. _A_U_T_H_E_N_T_I_C_A_T_I_O_N _D_A_T_A This length of this field is variable, but is always an integral Atkinson [Page 5] Internet Draft IP Authentication Header 23 March 1995 number of 32-bit words. Many implementations require padding to other alignments, such as 64-bits, in order to improve performance. All implementations MUST support such padding, which is specified by the Destination on a per SPI basis. An implementation will normally use the combination of Destination Address and SPI to locate the Security Association which specifies the field's size and use. The field retains the same format for all datagrams of any given SPI and Destination Address pair. The Authentication Data fills the field beginning immediately after the SPI field. If the field is longer than necessary to store the actual authentication data, then the unused bit positions are filled with unspecified, implementation-dependent values. Those unused bit positions MUST be ignored upon receipt. Refer to each Authentication Mechanism specification for more information regarding the contents of this field. 3.3 Security Labeling As is discussed in greater detail in the IP Security Architecture document, IPv6 will normally use implicit security classification labels rather than the explicit labels that are currently used with IPv4. [Ken91] [Atk95a] In some situations, users MAY choose to carry explicit labels (for example, IPSO labels as defined by RFC-1108 might be used with IPv4) in addition to using the implicit labels provided by the Authentication Header. Explicit label options could be defined for use with IPv6 (e.g. using the IPv6 end-to-end options header or the IPv6 hop-by-hop options header). Implementations MAY support explicit labels in addition to implicit labels, but implementations are not required to support explicit labels. If explicit labels are in use, then the explicit label MUST be included in the authentication calculation. 4. CALCULATION OF THE AUTHENTICATION DATA The authentication data is usually calculated using a message digest algorithm (for example, MD5) either encrypting that message digest or keying the message digest directly. [Riv92] Only algorithms that are believed to be cryptographically strong one-way functions should be used with this header. Because conventional checksums (e.g. CRC-16) are not cryptographically strong and can be reverse-engineered, they MUST NOT Atkinson [Page 6] Internet Draft IP Authentication Header 23 March 1995 be used with the Authentication Header. If a block-oriented authentication algorithm (e.g. MD5, MD4) is in use and the IP packet is not an integral number of blocks, the authentication data calculation is performed using zero bytes at the end to pad the length out to an integral number of blocks. [Riv92] These block padding bytes are not included in the actual IP datagram and are not sent over the wire because adding padding at that point in IP protocol processing would make implementation of the MTU related calculations very difficult. When a keyed message digest algorithm (e.g. MD5) is used, the secret key is fed into the algorithm first, followed by the invariant fields of the IP datagram in sequence and then concluding by feeding the secret key in a second time. Fields which will necessarily vary in transit from the sender to the receiver (e.g. TTL or Hop Count) are included in the calculation but the value zero is substituted for the actual value of such fields in the IP packet. This substitution of zero is used instead of omitting those fields because it preserves alignment throughout the authentication data calculation and thereby can significantly improve performance. The sender MUST compute the authentication over the packet as it will appear at the receiver. This requirement is placed in order to allow for future IP optional headers which the receiver might not know about but the sender necessarily knows about if it is including such options in the packet. The sender places the calculated message digest algorithm output into the Authentication Data field within the Authentication Header. Upon receipt of a packet containing an IP Authentication Header, the receiver first uses the Destination Address and SPI value to locate the correct Security Association. The receiver then independently calculates the authentication data for the received packet. It then compares the received Authentication Data field contents with the calculated authentication value. If the two match, then the datagram is accepted as authentic. If they differ, then the receiver SHOULD discard the received IP datagram as non-authentic and MUST record the authentication failure in the system log or audit log. If such a failure occurs, the recorded log data SHOULD include the SPI value, date/time received, clear-text Sending Address, clear-text Destination Address, and clear-text Flow ID. The log data MAY also include other information about the failed packet. Not all of the fields of the IPv6 Hop-by-Hop Options header are included in the authentication calculation. The third-highest-order bit of the Option Type field within the IPv6 Hop-by-Hop Options Header indicates whether any particular option is included within the Atkinson [Page 7] Internet Draft IP Authentication Header 23 March 1995 authentication calculation or is omitted from the authentication calculation. If the particular option is to be omitted, that option is skipped over during the authentication calculation as if it were not present. Because of this bit encoding, an implementation can authenticate newly defined IPv6 hop-by-hop options without having to modify the authentication portion of the IP implementation. The IPv6 specification provides additional information on the IPv6 Hop-by-Hop Options Header. [Hin94] 5. CONFORMANCE REQUIREMENTS Implementations that claim conformance or compliance with this specification MUST fully implement the header described here, MUST support manual key distribution for use with this option, MUST comply with all requirements of the "Security Architecuture for the Internet Protocol" [Atk95a], and MUST support the use of keyed MD5 as described in the companion document entitled "IP Authentication using Keyed MD5" [MS95]. Implementations MAY also implement other authentication algorithms. Implementors should consult the most recent version of the "IAB Official Standards" RFC for further guidance on the status of this document. 6. SECURITY CONSIDERATIONS This entire RFC discusses an authentication mechanism for IP. This mechanism is not a panacea to the several security issues in any internetwork, however it does provide a component useful in building a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever cryptographic algorithm has been implemented, the strength of the key being used, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, and upon the correctness of the IP Authentication Header and IP implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Implementers are encouraged to use high assurance methods to develop all of the security relevant parts of their products. Users interested in confidentiality should consider using the IP Encapsulating Security Payload (ESP) instead of or in conjunction with this specification. [Atk95b] Users seeking protection from traffic analysis might consider the use of appropriate link encryption. Description and specification of link encryption is outside the scope of this note. [VK83] Users interested in combining the IP Authentication Header with the IP Encapsulating Security Payload should consult the IP Encapsulating Security Payload specification Atkinson [Page 8] Internet Draft IP Authentication Header 23 March 1995 for details. One particular issue is that in some cases a packet which causes an error to be reported back via ICMP might be so large as not to entirely fit within the ICMP message returned. In such cases, it might not be possible for the receiver of the ICMP message to independently authenticate the portion of the returned message. This could mean that the host receiving such an ICMP message would either trust an unauthenticated ICMP message, which might in turn create some security problem, or not trust and hence not react appropriately to some legitimate ICMP message that should have been reacted to. It is not clear that this issue can be fully resolved in the presence of packets that are the same size as or larger than the minimum IP MTU. Similar complications arise if an encrypted packet causes an ICMP error message to be sent and that packet is truncated. Active attacks are now widely known to exist in the Internet [CER95]. The presence of active attacks means that unauthenticated source routing, either unidirectional (receive-only) or with replies following the original received source route represents a significant security risk unless all received source routed packets are authenticated using the IP Authentication Header or some other cryptologic mechanism. It is noteworthy that the attacks described in [CER95] include a subset of those described in [Bel89]. This documented benefited greatly from work done by Bill Simpson, Perry Metzger, and Phil Karn to make general the approach originally defined by the author for SIP, SIPP, and finally IPv6. The basic concept here is derived in large part from the SNMPv2 Security Protocol work described in [GM93]. Steve Bellovin, Steve Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided thoughtful critiques of early versions of this note. Francis Dupont discovered and pointed out the security issue with ICMP in low IP MTU links that is noted just above. REFERENCES [Atk95a] Randall Atkinson, Security Architecture for the Internet Protocol, Work in Progress, draft-atkinson-ipng-sec-01.txt, 21 March 1995 [Atk95a] Randall Atkinson, IP Encapsulating Security Payload, Work in Progress, draft-atkinson-ipng-esp-01.txt, 21 March 1995 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Atkinson [Page 9] Internet Draft IP Authentication Header 23 March 1995 Information Center, 9 June 1994, pp. 21-34. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, draft-hinden-ipv6-spec-00.txt, October 1994. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, DDN Network Information Center, November 1991. [MS95] Perry Metzger & Bill Simpson, "IP Authentication with Keyed MD5", Work in Progress, 21 March 1995. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, DDN Network Information Center, 20 October 1994. [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information Center, April 1992. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. DISCLAIMER The views and specification here are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. AUTHOR INFORMATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Phone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 10] Internet Draft IP Authentication Header 23 March 1995 Atkinson [Page 11]