Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 IPv4 Authentication Header (4AH) draft-metzger-ah-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. 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 six months, and 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes an authentication mechanism for IPv4, by inserting an intervening header between the IPv4 Header and any transport headers. Troublemakers expires in six months [Page 1] DRAFT 4AH January 1995 1. Introduction The Authentication Header (AH) seeks to provide integrity and authentication for IP datagrams. It may also provide non- repudiation, depending on which algorithm is used. Users desiring confidentiality should consider using the Encapsulating Security Protocol (ESP) [RAesp], either in lieu of or in conjunction with the Authentication Header. This document assumes that the reader is familiar with the related document "IPv4 Security Overview" [RAsa], which defines the overall security plan for IPv4, and provides important background for this specification. 1.1. Overview The Authentication Header (AH) seeks to provide security by adding authentication information to an IP datagram. The authentication information is calculated using all of the fields in the IP datagram which do not change in transit. This includes portions of the IP Header, transport headers, and the user data. In order for the Authentication Header to work properly without changing the entire Internet infrastructure (particularly non- participating routers), the authentication data is carried in its own IP protocol payload. Nodes that aren't participating in the authentication ignore the Authentication Header. In some environments, intermediate routing authentication might be desirable [RFC-1636]. If an asymmetric authentication algorithm is used, then the routers performing such intermediate authentication would need to be aware of the appropriate public keys and authentication algorithm. The routers could authenticate the traffic being handled, without being able to forge or modify otherwise legitimate traffic. If a symmetric authentication algorithm is used, then the routers 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. Use of this specification will increase the protocol processing costs in participating systems, and will also increase the communications Troublemakers expires in six months [Page 1] DRAFT 4AH January 1995 latency. The increased latency is primarily due to time required for calculation of the authentication data by the sender, and the calculation and comparison of the authentication data by the receiver, over each datagram containing an Authentication Header. The impact will vary with authentication algorithm used and other factors, but is expected to be relatively inexpensive to implement. 1.2. Key Management Key management is an important part of the IP security architecture. A scalable standard Internet key management protocol is needed to make widespread use of authentication practical. However, in order to facilitate early adoption, manual key management is the only key management technique required by this specification. The only coupling between key management and the AH is the Security Association Identifier (SAID), which is described in more detail later. This 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. Thus, key management is specified in a separate specification [TBD]. Nota Bene: It is intended that the key management mechanisms being developed in other IETF Working Groups will be useful for both IPv4 and IPv6. 1.3. Security Associations The key management mechanism is used to negotiate a number of parameters for each Security Association between the communicating parties. This includes the key(s) used to generate the authentication data, and also other parameters (such as the authentication algorithm and mode). The key management protocol implementation usually maintains a table containing the several parameters for each current Security Association. The AH implementation needs to access that security parameter table to determine how to process each datagram. The Security Association Identifier (SAID) is assigned by the entity Troublemakers expires in six months [Page 2] DRAFT 4AH January 1995 controlling the Destination IP address of the Security Association. The selection mechanism used for the SAID is implementation dependent. A given Destination is not necessarily in control of the negotiation process. In the case of multicast groups, a single node or cooperating subset of the multicast group may work on behalf of the entire group to set up a Security Association. A session between two nodes will normally have two SAID values (one in each direction). The nodes use the combination of SAID and IP Destination to distinguish the correct association. Senders to a multicast group may share a common Security Association, if all communications are authenticated using the same security configuration parameters. In this case, the receiver only knows that the message came from a node knowing the Security Association for the group, and cannot authenticate which member of the group sent the datagram when symmetric algorithms are in use. Multicast groups may also use a separate Security Association value for each Source. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also provided. 1.4. Mechanisms It is intended that the AH format should be sufficiently general to permit the specification of new mechanisms as new cryptographic algorithms are developed. Each SAID value indicates the algorithm and mode used, the block size (if any) of the algorithm, and the presence/absence and size of a cryptographic synchronization or initialization vector field. These parameters are described in companion mechanism documents. The authentication mechanism uses a message digest algorithm (such as MD5), either encrypting that message digest or keying the message digest directly. Because conventional checksums (such as CRC-16) are not cryptographically strong and can be easily reversed, they MUST NOT be used with the Authentication Header. Troublemakers expires in six months [Page 3] DRAFT 4AH January 1995 2. Payload Format 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 header immediately preceding the Authentication Header will always contain the value in its Next Header (Protocol) field. +-----------+-----------------+-----------+---------+-----------+ | IP Header | Routing/Hop-Hop | Auth Head | End-End | Transport | +-----------+-----------------+-----------+---------+-----------+ 2.1. Header Fields A more detailed diagram of the Authentication Header follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header Identifies the next header after the Authentication Header, using the IP Protocol/Payload value. Up-to-date values of the IP Protocol/Payload are specified in the most recent "Assigned Numbers" [RFC-1700]. Length The length of the Authentication Data field in 64-bit increments. Minimum value is 0, which is only used in the degenerate case of a "null" authentication algorithm. Security Association Identifier (SAID) A value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. Troublemakers expires in six months [Page 4] DRAFT 4AH January 1995 SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are reserved for future use. Authentication Data The length of this field is variable, but is always an integral number of 64-bits. An implementation will normally use the SAID to determine the field's size and use. It retains the same format for all datagrams of any given SAID and IP Destination. The Authentication Data fills the field beginning immediately after the SAID field. If the field is longer than necessary to store the actual authentication data, then the unused bit positions MUST be ignored by the receiver. Each mechanism will have such special processing instructions included in its specification. Refer to each Authentication Mechanism specification for more information regarding the contents of this field. 3. Processing This chapter describes the steps taken when the AH is in use between two communicating parties. The sender first determines if a Security Association has been established with the target Destination. If not, then the key management mechanism is used to establish the SAID for this communications session prior to the use of the AH. If an unauthenticated datagram arrives from a Source after a SAID has been established, or a SAID is received which is not valid, then an error is indicated. The datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. Multicast is different from unicast only in the area of key management. Troublemakers expires in six months [Page 5] DRAFT 4AH January 1995 3.1. Calculation The Authentication Data is the output of the authentication algorithm calculated over the invariant portions of the entire IPv4 datagram. The sender places this algorithm output into the Authentication Data field within the Authentication Header. When a keyed message digest algorithm is used (such as MD5), the secret key is fed into the algorithm first, followed by the invariant fields of the IP datagram in sequence. The secret key is fed in first, because that increases the work function for someone attempting to cryptanalyse the key from knowledge of the plaintext datagram. Feeding the secret key in first also permits implementations to precompute the start of the hash for a given destination, and possibly improve performance thereby. The key does not need to be fed in at the end. Including the IP Header's invariant Total Length field in the authentication calculation precludes appending attacks. Fields which will necessarily vary in transit from the sender to the receiver (such as the Hop Count), are included in the calculation, but the value zero is substituted for the actual value of such fields. The Authentication Data field itself is also zeroed during the calculation. All other Authentication Header fields are included. This substitution of zero is used instead of omitting those fields, because it preserves alignment of the data during calculation, which can significantly improve performance. If a block-oriented authentication algorithm is in use (such as MD2, MD4, MD5), and the IP datagram is not an integral number of blocks, the authentication data calculation is performed using zero bytes at the end of the datagram to pad the length out to an integral number of blocks. These block padding bytes are not included in the actual IP datagram, and are not sent over the link. Adding padding at that point in protocol processing could make implementation of MTU related calculations very difficult. The sender MUST compute the calculation over the datagram as it will appear at the receiver. This requirement allows for future intervening headers which are removed or altered during transit. The Troublemakers expires in six months [Page 6] DRAFT 4AH January 1995 sender needs to know the final values when including such headers in the datagram. Each such header will have special processing instructions included in its specification. Upon receipt of a datagram containing an Authentication Header, the receiver independently calculates the authentication data. It compares the received Authentication Data field contents with the calculated authentication value. If they differ, then the receiver SHOULD discard the received IP datagram, and return an appropriate ICMP message. The failure MUST be recorded in the system or audit log, as described earlier. Security Considerations This specification is principly concerned with a security mechanism for use with IP. This mechanism is not a panacea, but it does provide an important component useful in creating 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 that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the 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 development techniques to develop all of the security relevant parts of their products. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. The basic concept is derived in large part from the work done for SNMPv2 [RFC-1446]. Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques of earlier versions of this draft. Troublemakers expires in six months [Page 7] DRAFT 4AH January 1995 References [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. [RAsa] Randall Atkinson, IPv6 Security Architecture, work in progress, 4 November 1994. [RAesp] Randall Atkinson, IPv6 Encapsulating Security Payload, work in progress, 4 November 1994. [RFC-1446] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [RFC-1636] 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. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [Bell89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Troublemakers expires in six months [Page 8] DRAFT 4AH January 1995 Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 9] DRAFT 4AH January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Overview ........................................ 1 1.2 Key Management .................................. 2 1.3 Security Associations ........................... 2 1.4 Mechanisms ...................................... 3 2. Payload Format ........................................ 4 2.1 Header Fields ................................... 4 3. Processing ............................................ 5 3.1 Calculation ..................................... 6 SECURITY CONSIDERATIONS ...................................... 7 ACKNOWLEDGEMENTS ............................................. 7 REFERENCES ................................................... 8 AUTHOR'S ADDRESS ............................................. 8