Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-sipp-ap-04.txt 15 August 1994 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: ip-ng@sunroof.eng.sun.com Administrative requests regarding that mailing list should always be sent to: ip-ng-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 Atkinson [Page 1] Internet Draft IPv6 Authentication Header 15 August 1994 Authentication Header. [NB: All references to "IPv6 Encapsulating Security Protocol" will be replaced with references to the "IPv6 Security Protocol (IPSP)" if/when such a document appears as an online Internet Draft]. This document assumes the reader has previously read and understood the related "IPv6 Security Overview" document which defines the overall security architecture for IPv6 and provides important background information for this specification. 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. [8] 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 Atkinson [Page 2] Internet Draft IPv6 Authentication Header 15 August 1994 the traffic being handled without being able to forge or modify otherwise legitimate traffic. 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 protocol implementation usually creates and maintains a table containing the several parameters for each current security association. An IPv6 Authentication Header implementation normally needs to read that security parameter table to determine how to process each datagram containing an Authentication Header (e.g. which algorithm/mode and key to use). The SAID value is typically used as the index into that security configuration table. Manual key distribution is the only key management mechanism required by this specification. A scalable standard Internet key management protocol is needed to make widespread use of this mechanism practical. Work on such a key management protocol is underway in the IETF's Key Management Working Group. Other key management mechanisms MAY also be used between cooperating computer systems. 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 Atkinson [Page 3] Internet Draft IPv6 Authentication Header 15 August 1994 Numbers Authority. 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. +-------------+-------------------------+--------------+---------+---------+ | 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) | +--------------+---------------+----------------+--------------+ _N_E_X_T _P_A_Y_L_O_A_D 8 bits wide. Identifies the next payload after the Authentication Payload (as is normal for IPv6). _P_A_Y_L_O_A_D _L_E_N_G_T_H 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. _R_E_S_E_R_V_E_D Reserved for future use. MUST be set to all zeros when sent and ignored upon receipt. _S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D) 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 0x0000. The set of SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF 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. Atkinson [Page 4] Internet Draft IPv6 Authentication Header 15 August 1994 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), and initialisation vectors (if any) of the authentication algorithm. _A_U_T_H_E_N_T_I_C_A_T_I_O_N _D_A_T_A 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. 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. 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. 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 Atkinson [Page 5] Internet Draft IPv6 Authentication Header 15 August 1994 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. 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. The key is not fed in at the end because authentication of the IPv6 Header's Payload Length field precludes appending attacks. 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 this 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 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. [5] [Text is needed on the IPv6 Routing Header and will be provided in a later revision of this draft after that header is specified.] 5. CONFORMANCE REQUIREMENTS Implementations that claim conformance or compliance with this specification MUST fully implement the option described here, MUST Atkinson [Page 6] Internet Draft IPv6 Authentication Header 15 August 1994 support 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 other algorithms with this option 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. [NB: MD5 reportedly has a throughput of about 20 Mbps on a fast 64- bit RISC processor using the code from the RFC defining MD5. This possibly too slow for the Authentication Header to be widely used. Suggestions are sought on alternative authentication algorithms that would be acceptable to the IETF, have significantly faster throughput, are not patent-encumbered, and still retain adequate cryptographic strength for commercial users.] 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 their products. Users interested in confidentiality should consider using the IPv6 Encapsulating Security Payload (ESP) instead of or in conjunction with this specification. 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. [7] Users interested in combining the IPv6 Authentication Header with the IPv6 Encapsulating Security Payload should consult the IPv6 Encapsulating Security Payload specification for details. ACKNOWLEDGEMENTS The basic concept here is derived in large part from the SNMPv2 Security Protocol work described in [1]. Steve Bellovin, Steve Atkinson [Page 7] Internet Draft IPv6 Authentication Header 15 August 1994 Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques of earlier versions of this draft. REFERENCES [1] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [2] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information Center, April 1992. [3] Randall Atkinson, IPv6 Security Overview, Internet Draft, draft-ietf-ipng-security-01.txt, 15 August 1994. [4] Randall Atkinson, SIPP Encapsulating Security Payload, Internet Draft, draft-ietf-sipp-esp-*.txt, April 1993. [5] Steve Deering, Internet Protocol version 6 (IPv6) Specification, July 1994. [6] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [7] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [8] 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. 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 Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Phone: (DSN) 354-8590 Atkinson [Page 8] Internet Draft IPv6 Authentication Header 15 August 1994 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. 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 9]