Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-sipp-ap-01.txt 9 March 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 - 9 March 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, payloads, 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 payload (i.e. just before the TCP or UDP data). 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 may authenticate the traffic being handled. 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 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 Atkinson [Page 2] Internet Draft - 3 - 9 March 1994 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 considered to contain all zeros for the sole purpose of 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 payloads | Authentication Header | User Data | +-------------+---------------------+------------------------+------------+ Atkinson [Page 3] Internet Draft - 4 - 9 March 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 (8 bits) | Sequence Number (16 bits) | +--------------+-----------------+----------------+------------+ | Security Association Identifier (32 bits) | +--------------+---------------+----------------+--------------+ | 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 SIPP). 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. SEQUENCE NUMBER An unsigned 16 bit integer. This is the sequence number of the SIPP datagram and is monotonically increasing during the lifetime of the security association. The initial packet will have a sequence number of zero. The value of this field will automatically roll over to zero once the field reaches its maximum value. This field is fully authenticated and so provides some protection against replay attacks. SECURITY ASSOCIATION IDENTIFIER (SAID) A 32-bit value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x0000. 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, the receiver only knows that the message came from a member of the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each originating system in the multicast group. In this case, Atkinson [Page 4] Internet Draft - 5 - 9 March 1994 the originating system is fully authenticatable because each originating system is using a different security configuration. Each SAID value implies the key(s) used with the authentication algorithm, the authentication algorithm and its mode, and the block size (if any) of the authentication algorithm. AUTHENTICATION DATA This data carried in this field is variable length, but the field size 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 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 audit the occurence. 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 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 receiving system(s) should keep a small sliding window of allowable packet sequence numbers from the Authentication Header. This will permit some slight reordering of SIPP datagrams in transit Atkinson [Page 5] Internet Draft - 6 - 9 March 1994 while not significantly reducing security. If a packet is received that has an invalid sequence number in the Authentication Header, then that packet should be discarded as invalid and the event should be audited because it might represent an attempted attack on the network. 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, while still permitting SIPP to take full advantage of these advanced routing capabilities. (More here TBD) 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 - 9 March 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. 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 - 9 March 1994 AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Atkinson [Page 8] Internet Draft - 9 - 9 March 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, 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]