Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-ipngwg-auth-00.txt 16 February 1995 IPv6 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 Working Group. 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. Discussion of this draft may be posted to the IPng WG mailing list: ipng@sunroof.eng.sun.com Administrative requests regarding that mailing list should always be sent to: ipng-request@sunroof.eng.sun.com 1. INTRODUCTION & OVERVIEW The Internet community is working on a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). This memo describes the IPv6 Authentication Header. This optional header provides strong integrity and authentication for IPv6 datagrams. Non-repudiation might be provided by an authentication algorithm used with the Authentication Header, but it is not provided with all authentication algorithms that might be used. Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IPv6 Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [Atk95b] Atkinson [Page 1]
Internet Draft IPv6 Authentication Header 16 February 1995 This document assumes the reader has previously read and understood the related IPv6 Security Architecture document which defines the overall security architecture for IPv6 and provides important background information for this specification. [Atk95a] The IPv6 Authentication Header seeks to provide security by adding authentication information to an IPv6 datagram. This authentication information is calculated using all of the fields in the IPv6 datagram (including not only the IPv6 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 IPv6 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 IPv6 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 and systems that aren't participating in the authentication MAY ignore the Authentication Data. 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 IPv6 headers is used to route the datagram from origin to destination. 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 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. Atkinson [Page 2]
Internet Draft IPv6 Authentication Header 16 February 1995 2. KEY MANAGEMENT Key management is an important part of the IPv6 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. IPv6 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 (SAID), 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 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 IPv6 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 SAID value is typically used as the index into that logical table of security configuration data. The IPv6 Security Architecture document describes key management in more detail and includes specification of the key management requirements for IPv6. It is incorporated here by reference. [Atk95a] 3. PAYLOAD SYNTAX The Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 End-to-End Header. The Authentication Header consists of a few clear text fields and then the authentication data. The authentication data is the output of the authentication algorithm calculated over the invariant portions of the entire IPv6 datagram. The Authentication Data field itself is ignored only during the authentication calculation. All other Authentication Header fields are included in the authentication calculation normally. A high-level diagram of an IPv6 datagram with the Authentication Header follows. The IPv6 Authentication Header has been assigned the protocol number 51 by the Internet Assigned Numbers Authority (IANA). The IPv6 header immediately prior to the Authentication Header shall use the number 51 to indicate the the following header is the IPv6 Authentication Header. Atkinson [Page 3]
Internet Draft IPv6 Authentication Header 16 February 1995 +-------------+-------------------------+--------------+---------+---------+ | IPv6 Header | Routing/Hop-by-Hop Hdrs | Auth Header | E2E Hdr | TCP/UDP | +-------------+-------------------------+--------------+---------+---------+ The IPv6 Header is the conventional IPv6 Header defined by others in a separate Internet Draft. The IPv6 Authentication Header has the following syntax: +--------------+-----------------+----------------+------------+ | Next Payload | Length | RESERVED | +--------------+-----------------+----------------+------------+ | Security Association Identifier | +--------------+---------------+----------------+--------------+ | Authentication Data (variable number of 64-bit double words) | +--------------+---------------+----------------+--------------+ | (more Authentication Data) | +--------------+---------------+----------------+--------------+ NEXT PAYLOAD 8 bits wide. Identifies the next payload after the Authentication Payload (as is normal for IPv6). PAYLOAD LENGTH 8 bits wide. The length of the Authentication Data field in 64-bit double words. Minimum value is 0 double 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 ASSOCIATION IDENTIFIER (SAID) A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The combination of SAID value and destination address uniquely identifies the security association. The destination address may, of course, be a multicast group address. This receiver-orientation implies that, in the case of unicast traffic, the destination system will usually select the SAID value. By having the destination select the SAID value, there is no potential for manually configured security associations to have SAID values that conflict with automatically configured (e.g. via a key management Atkinson [Page 4]
Internet Draft IPv6 Authentication Header 16 February 1995 protocol) security associations. For multicast traffic, there are multiple destination systems but a single destination multicast group so some system or person will need to select SAIDs for that multicast group and then communicate the information to all of the legitimate members of that multicast group via mechanisms not defined here. Multicast groups MAY share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, etc.). In this case, a receiver only knows that the message came from a system which knew the security association data for that multicast group. A receiver cannot generally authenticate which host sent the multicast traffic when symmetric algorithms are in use. Multicast traffic MAY also use a separate SAID for each sender to the multicast group. In this case, the originating system is fully authenticatable when each sender uses a different SAID and security configuration and asymmetric algorithms are in use. Each SAID value implies the key(s) used with the authentication algorithm, the authentication algorithm and its mode, the block size (if any), initialisation vectors (if any) of the authentication algorithm, and (optionally) the security classification level associated with this key and session. As is discussed in greater detail in the IPv6 Security Architecture document, IPv6 will normally use implicit security classification labels rather than the explicit labels that are used for IPv4. [Ken91] [Atk95a] The sending host uses the sending userid and destination host to select an appropriate Security Association (and hence SAID value). The receiving host uses the combination of SAID value and originating address to distinguish the correct association. Hence, an Authentication Header implementation will always be able to use the SAID in combination with the 128-bit Destination Address to determine the security association and related security configuration data for all valid incoming packets. AUTHENTICATION DATA This data carried in this field is variable length, but the field size is always an integral number of 64-bit double words. The authentication data fills the field beginning immediately after the SAID field and continuing until all the authentication data is in place. If the Authentication Data field is longer than necessary to store the actual authentication data, then the unused trailing bit positions MUST be ignored by the receiver. Atkinson [Page 5]
Internet Draft IPv6 Authentication Header 16 February 1995 4. CALCULATION OF THE AUTHENTICATION DATA The authentication data is usually calculated using a message digest algorithm (e.g. 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 be used with the Authentication Header. If a block-oriented authentication algorithm (e.g. MD5, MD4) is in use and the IPv6 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 IPv6 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 IPv6 datagram in sequence. Fields which will necessarily vary in transit from the sender to the receiver (e.g. Hop Count) are included in the calculation but the value zero is substituted for the actual value of such fields in the IPv6 packet. This substitution of zero is used instead of omitting those fields because it preserves 64-bit alignment throughout the authentication data calculation and thereby can significantly improve performance. At the very end, the secret key is fed in to the keyed message digest algorithm again. The secret key is fed in first because that increases the work function for someone attempting to cryptanalyse the key from knowledge of the packet data and the Authentication Data of the Authentication Header. Feeding the key in first also permits implementations to precompute the start of the hash for a given destination and possibly improve performance thereby. The key is fed in again at the end to provide additional assurance for the authentication mechanism. 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 IPv6 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 IPv6 Authentication Header, the receiver independently calculates the authentication data for the received packet. It then compares the received Authentication Data Atkinson [Page 6]
Internet Draft IPv6 Authentication Header 16 February 1995 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 IPv6 datagram as non-authentic and MUST audit the authentication failure using normal operating system procedures. 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 Hop-by-Hop Options Header indicates whether any particular option is included within the 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 hop-by-hop options without having to modify the authentication portion of the IPv6 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 option described here, MUST support user-to-user manual key distribution for use with this option, and MUST support the use of keyed MD5 as described in Appendix A of this document. Support for host-to-host manual key distribution MAY also be present. Support for other authentication algorithms is not mandatory to comply or conform with this specification. Implementors should consult the most recent version of the IAB Official Standards document for further guidance on the status of this document. 6. SECURITY CONSIDERATIONS This entire RFC discusses an authentication mechanism for IPv6. 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 IPv6 Authentication Header and IPv6 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 Atkinson [Page 7]
Internet Draft IPv6 Authentication Header 16 February 1995 their products. Users interested in confidentiality should consider using the IPv6 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 IPv6 Authentication Header with the IPv6 Encapsulating Security Payload should consult the IPv6 Encapsulating Security Payload specification 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 IPv6 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]. This 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 IPv6 Authentication Header or some other cryptologic mechanism. It is noteworthy that the attacks described in [CER95] include a subset of those described in [Bel89]. The basic concept here is derived in large part from the SNMPv2 Security Protocol work described in [GM93]. Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques of early versions of this draft. Francis Dupont discovered and pointed out the ICMP security issue noted just above. REFERENCES [Atk95a] Randall Atkinson, IPv6 Security Architecture, Internet Draft, draft-atkinson-ipng-sec-01.txt, 15 February 1995. [Atk95a] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet Draft, draft-atkinson-ipng-esp-01.txt, 15 February 1995. Atkinson [Page 8]
Internet Draft IPv6 Authentication Header 16 February 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 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. [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 INFORATION Randall Atkinson <atkinson@itd.nrl.navy.mil> Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Phone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 9]
Internet Draft IPv6 Authentication Header 16 February 1995 APPENDIX A: USE OF KEYED MD5 WITH THE IPv6 Authentication Header This section describes the use of the MD5 message digest algorithm with the IPv6 Authentication Header to provide integrity and authentication. A 128-bit digest is calculated over the invariant portion of the entire IPv6 datagram and the result is included in the Authentication Data field of the IPv6 Authentication Header. The specification of MD5 in RFC-1321 includes a portable 'C' programming language description of the MD5 algorithm. [Riv92] The secret authentication key used with the IPv6 Authentication Header MUST be 128 bits long. The key SHOULD be a pseudo-random number, not a guessable string of any sort. The 128-bit digest shall be calculated as described in Section 3 of RFC-1321. The "b-bit message" referred to in RFC-1321 shall consist of the 128 bit secret authentication key prepended to the invariant fields of the entire IPv6 datagram in the order they appear in the IPv6 datagram. All IPv6 headers and payloads that are present MUST be included in the computation, with header fields whose value varies in transit (e.g. Hop Count) being assumed to contain all zeros for the purpose of the authentication calculation. For the purposes of the calculation, the Authentication Data field of the IPv6 Authentication Payload is considered to contain all zeros. Because MD5's output is naturally 64-bit aligned, there is no wasted space in the Authentication Data field. Atkinson [Page 10]
