Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-sipp-ap-02.txt 14 April 1994 SIPP 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 SIP Plus Working Group. It is intended that a future version of this draft will be submitted to the IPng Area Directors and the IESG as a whole for consideration as a standards-track document (as part of the SIP Plus proposal for IPng). Distribution of this document is unlimited. The author is keen to get early feedback on the clarity and technical correctness of this draft. Discussion of this draft may be posted to the SIP Plus mailing list: sipp@sunroof.eng.sun.com 1. INTRODUCTION & OVERVIEW This memo describes the SIPP Authentication Header (AH). This payload seeks to provide integrity and authentication for SIPP datagrams. Non-repudiation may be provided by an authentication algorithm used with AH, but it is not provided with all authentication algorithms that might be used with AH. Confidentiality, and protection from traffic analysis are not provided by AH. Users desiring confidentiality should consider using the SIPP Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with AH. This document assumes the reader has Atkinson [Page 1] Internet Draft - 2 - 14 April 1994 previously read and understood the related "SIPP Security Architecture" document which defines the overall security architecture for SIP Plus and provides important background information for this specification. The SIPP Authentication Header (AH) seeks to provide security by adding authentication information to a SIPP datagram. This authentication information is calculated using all of the fields in the SIPP datagram (including not only the SIPP 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 SIPP 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 SIPP datagram containing an Authentication Header. The impact will vary with authentication algorithm used and other factors. In order for AH 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. For performance reasons, the AH should normally be the next to the last header (i.e. just before TCP or UDP). The information in the other SIPP headers is used to route the datagram from origin to destination. If a symmetric authentication algorithm will be used, routers will not be able to authenticate traffic because they won't have the needed authentication keys. If an asymmetric authentication algorithm is used and the routers are aware of the appropriate public keys and authentication algorithm, then the routers might be able to authenticate the traffic being handled, subject to the router being able to parse all the headers preceding the Authentication Header, the router having appropriate security association data, and other such factors. 2. KEY MANAGEMENT Key management is an important part of the SIPP 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. SIPP tries to decouple the key management mechanisms from the security protocol mechanisms. The Atkinson [Page 2] Internet Draft - 3 - 14 April 1994 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. Thus, SIPP key management is specified in a separate (TBD) draft. [ NB: It might be possible to reuse the Internet Key Management Protocol (IKMP) being developed in the IETF's IPv4 Security Working Group. However, that group has not been moving very rapidly and time might preclude such reuse. Another candidate key management algorithm is that used in the IEEE 802.10 work. Other possibilities exist. ] 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. A SIPP Authentication Header implementation normally needs to read that security parameter table to determine how to process each datagram containing an AH (e.g. which algorithm/mode and key to use). The SAID value is typically used as the index into that security configuration table. 3. PAYLOAD SYNTAX The Authentication Header (AH) may appear anywhere after the SIP Plus header, but for performance reasons is best placed as the last payload before the transport layer data. The Authentication Header consists of a few clear text AH header fields and then the authentication data. The authentication data is the output of the authentication algorithm calculated over the invariant portions of the entire SIPP 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 a SIPP datagram with the Authentication Header follows. +-------------+---------------------+------------------------+------------+ | SIPP Header | Other SIPP headers | Authentication Header | User Data | +-------------+---------------------+------------------------+------------+ Atkinson [Page 3] Internet Draft - 4 - 14 April 1994 The SIPP Header is the conventional SIPP Header defined by others in a separate Internet Draft. The AH 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 SIPP). _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 0xFF01 through 0xFFFF 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 receiving host uses the combination of SAID value and originating address to distinguish the correct association. 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 because each originating system is using a Atkinson [Page 4] Internet Draft - 5 - 14 April 1994 different security configuration. If asymmetric algorithms are used, then authentication of multicast traffic is much easier. 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 may be filled with arbitrary values by the sender and shall 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) or by encrypting a strong conventional checksum (e.g. standard CRC-32 encrypted in DES). If a block- oriented authentication algorithm is in use and the SIPP packet is not an integral number of blocks, then the SIPP Padding option described in the base SIPP specification should be used. If a message digest algorithm (e.g. MD5) is used, the secret key is fed into the algorithm first, followed by the invariant fields of the SIPP datagram in sequence. The sender places the output from message digest algorithm into the Authentication Data field within the Authentication Payload, while the receiver compares the received contents of the Authentication Data field 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 SIPP datagram as non-authentic and log the occurence to the system log or audit log. The secret key is fed in first because that increases the work function for someone attempting to cryptanalyse the key from knowing the packet data and the Authentication Data of the Authentication Header. The key is not fed in at the end because authentication of the SIPP Header's Payload Length field precludes appending attacks. If the other approach is used, then the conventional checksum (e.g. CRC-32) is calculated across the invariant fields of the SIPP datagram in order. The sender then encrypts that checksum using the agreed upon encryption algorithm, mode, and key, and places the Atkinson [Page 5] Internet Draft - 6 - 14 April 1994 encrypted checksum into the Authentication Data field of the Authentication Header. The receiver decrypts the encrypted checksum and compares the decrypted checksum with the checksum calculated over the received SIPP datagram. If the checksums are identical, then the received SIPP datagram is accepted as authentic. Otherwise the SIPP datagram is discarded as non-authentic and the occurence is audited. The fields in the SIPP Routing Header are normally reordered during transit through the internetwork. Consequently the SIPP Routing Header needs special processing by the receiver when used with the SIPP Authentication Header. If the received SIPP datagram contains a SIPP Routing Header, then the receiver shall reorder the source routing addresses to the original sender's address sequence prior to calculating and comparing the authentication data. The receiver of a SIPP datagram containing a SIPP Source Routing header shall reply using the reverse source route using only the authenticated fields of the SIPP Source Routing header. This practice will eliminate the current (IPv4) security problem of using source routing to engage in a host masquerading attack which is described by Bellovin, while still permitting SIPP to take full advantage of these advanced routing capabilities. [6] 5. CONFORMANCE REQUIREMENTS Implementations that claim conformance or compliance with this specification must fully implement the payload described here, must support manual key distribution, must support the key management specification for SIPP (which is TBD), and must support the use of keyed MD5 as described in Appendix A of this document. Support for other algorithms with this payload is not mandatory for implementations to comply and conform with this specification. Implementors should consult the most recent version of the IAB Official Standards document for further guidance. 6. SECURITY CONSIDERATIONS This entire RFC discusses an authentication mechanism for SIPP. 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 correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, and upon the correctness of the AH and SIPP implementations in all of the participating systems. If any Atkinson [Page 6] Internet Draft - 7 - 14 April 1994 of these assumptions do not hold, then little or no real security will be provided to the user. Users interested in confidentiality should consider using the SIPP Encapsulating Security Protocol (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. ACKNOWLEDGEMENTS The basic concept here is derived in large part from the SNMPv2 Security Protocol work described in [1]. Steve Bellovin, Steve Deering, 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, SIPP Security Architecture, Internet Draft, draft-ietf-sip-sa-00.txt, 9 March 1994. [4] Randall Atkinson, SIPP Encapsulating Security Payload, Internet Draft, draft-ietf-sip-esp-01.txt, 9 March 1994 [5] Steve Deering, Simple Internet Protocol Plus (SIPP) Specification, draft-ietf-sipp-spec-00.txt, 21 February 1994. [6] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. 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. Atkinson [Page 7] Internet Draft - 8 - 14 April 1994 AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Atkinson [Page 8] Internet Draft - 9 - 14 April 1994 APPENDIX A: USE OF KEYED MD5 WITH THE SIPP Authentication Header This section describes the use of the MD5 message digest algorithm with the SIPP Authentication Header to provide integrity and authentication. A 128-bit digest is calculated over the invariant portion of the entire SIPP datagram and the result is included in the Authentication Data field of the SIPP Authentication Header. The specification of MD5 in RFC-1321 includes a 'C' programming language description of the MD5 algorithm. The secret authentication key shall be 128 bits long. 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 SIPP datagram in the order they appear in the SIPP datagram. All SIPP headers and payloads that are present shall be included in the computation, omitting only the specified fields (e.g. ttl) which vary in transit, and including the user data (e.g. TCP or UDP data) being carried in the SIPP datagram. For the purposes of the calculation, the Authentication Data field of the SIPP Authentication Payload shall be considered to contain all zeros. The Sequence Number of the Authentication Header shall be included in the authentication calculation. Because MD5's output is naturally 64-bit aligned, there is no wasted space in the Authentication Data field. Atkinson [Page 9]