Network Working Group Randall Atkinson INTERNET DRAFT Naval Research Laboratory draft-ietf-sipp-sa-02.txt 19 April 1994 SIPP Security Architecture 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 "work in progress". This particular Internet Draft is a product of the IETF's SIPP working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol (as a part of the SIPP proposal for IPng). Discussion of this draft normally takes place on the SIPP Working Group mailing list: sipp@sunroof.eng.sun.com 1. INTRODUCTION This memo describes the overall SIPP Security Architecture. The security architecture is a high-level description of the several security mechanisms for the SIPP protocol and their relationship. Each security mechanism is specified separately. 2. KEY MANAGEMENT The Key Management protocol that will be used with SIPP has not been specified yet. However, because the key management protocol is coupled to the other security mechanisms only via the Security Association Identifier (SAID), those other security mechanisms have already been defined. What follows in this section is a brief discussion of a few alternative approaches to key management. Atkinson [Page 1] Internet Draft 19 April 1994 The simplest form of key management is manual key management, where a person manually configures each system with its own key and also with the keys of other communicating systems. This is quite practical in small, static environments but does not scale at all. It is not a viable medium-term or long-term approach, but might be appropriate in a small LAN environment or with routers that only need to authenticate routing updates with adjacent routers. All implementations of the SIPP Security Mechanisms must support manual key management. In order for SIPP security to become obiquitous, an Internet- standard scalable key management protocol will be required. Ideally such a protocol would support a number of protocols in the Internet protocol suite, not just SIPP security. There are a number of key management algorithms that have been proposed in the public literature. Needham & Schroeder have proposed a key management algorithm which relies on a centralised key distribution system. [11, 12] This algorithm is used in the Kerberos Authentication System developed at MIT under Project Athena. [10] More recently, Diffie & Hellman have devised an algorithm which does not require a centralised key distribution system. [13] Unfortunately, the original Diffie-Hellman technique is vulnerable to an active attack. However, this vulnerability can be mitigated by using signed keys to bootstrap into the Diffie-Hellman exchange. The Internet's Privacy Enhanced Mail (PEM) uses a kind of key certificate that appears suitable for use with the Diffie-Hellman key management algorithm. [14] However, such a hybrid key management protocol requires several exchanges to setup a session key between the two parties. It is desirable to minimise the number of exchanges required to setup a session key. There are several means by which a key certificate might be distributed. One obvious choice would be to add some kind of host key certificate into the Domain Name System as a new resource record type. Another approach would be for each party to have a host key certificate available via a UDP service. Then the originating party would authenticate key management traffic to the other key management party using an asymmetric algorithm. The two parties would then have a secure communications channel that could be used to create a shared session key. SIPP implementations must support manual key configuration. SIPP implementations should support a standard key management protocol once the latter is defined. Widespread use of the SIPP security mechanisms described below relies on adequate key management mechanisms being widely deployed. Atkinson [Page 2] Internet Draft 19 April 1994 3.0 SIPP SECURITY MECHANISMS There are two security mechanisms in SIPP. The first is the Authentication Payload which provides integrity and authentication without confidentiality. The second is the Encapsulating Security Payload which provides integrity, authentication, and confidentiality. These may be combined if appropriate. 3.1 AUTHENTICATION HEADER The SIPP Authentication Header (AH) 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 by all authentication algorithms that might be used with AH. Confidentiality, and protection from traffic analysis are not provided by AH. Users desiring confidentiality should use the SIPP Encapsulating Security Protocol (ESP). The SIPP Authentication Header (AH) holds authentication information for its SIPP datagram. This authentication information is calculated using all of the fields in the SIPP datagram which do not change during transit from the originator to the recipient. All SIPP headers, payloads, and the user data are included in this calculation. The only exception is that fields which need to change in transit (e.g. SIPP Header's "Hop Count" or the SIPP Routing Header's "Next Address") are omitted when the authentication data is calculated. Use of AH 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 (AH). All SIPP implementations should implement the Authentication Header. Implementation of AH provides much stronger security than exists in most of the current Internet and should not affect exportability or significantly increase implementation cost. While AH could be implemented by a security gateway on behalf of hosts on a trusted network behind that security gateway, this mode of operation is not encouraged. Instead, all SIPP-capable hosts must implement the SIPP Authentication Header with at least the MD5 algorithm using a 128-bit key. Other authentication algorithms may also be implemented. Atkinson [Page 3] Internet Draft 19 April 1994 3.2 ENCAPSULATING SECURITY PAYLOAD The SIPP Encapsulating Security Payload (ESP) seeks to provide integrity, authentication, and confidentiality to SIPP datagrams. It does this by encapsulating either an entire SIPP datagram or only the upper-layer protocol data inside the ESP, encrypting most of the ESP contents, and then using the ESP as the user data for a cleartext SIPP datagram. This cleartext SIPP datagram carries the protected data through the internetwork. The recipient of the cleartext datagram removes and discards the cleartext SIPP header and cleartext SIPP options, decrypts the ESP, removes the ESP headers, and then processes the (now decrypted) original SIPP datagram or upper-layer protocol data as per the normal SIPP protocol specification. ESP works between hosts, between a host and a security gateway, or between security gateways. This support for security gateways permits trusted networks to exist without the performance and monetary costs of security, while providing security for traffic transiting untrustworthy network segments. When both hosts directly implement ESP and there is no intervening security gateway, then they may use the mode where only the upper layer protocol data (e.g. TCP or UDP) is encrypted. This mode reduces both the bandwidth consumed and the protocol processing costs for users that don't need to keep the entire SIPP datagram confidential. ESP works with both unicast and multicast traffic, though published key management mechanisms do not scale well to large or highly dynamic multicast groups. It is important to understand that the security properties that ESP provides come from the encryption mechanisms used with ESP rather than from the ESP itself. Consequently the implementer's choice of encryption algorithms, modes, key management schemes, and keys will strongly influence the quality of the security provided. The encapsulating security approach used by ESP can noticeably impact network performance. SIPP protocol processing will be more complex, requiring both more time and more processing power. Using ESP will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each SIPP datagram containing an Encapsulating Security Payload. The precise cost of ESP will vary with the specifics of the implementation, including the encryption algorithm, key size, and other factors. Because of the performance impact, users not requiring confidentiality will probably prefer to use the SIPP Authentication Header instead of ESP. For interoperability throughout the worldwide Internet, the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode is required of all systems which implement SIPP ESP. Other confidentiality algorithms and modes may also be implemented. Atkinson [Page 4] Internet Draft 19 April 1994 3.3 COMBINING SECURITY MECHANISMS In some cases it might be desirable to combine the SIPP Authentication Header (AH) with the SIPP Encapsulating Security Protocol (ESP) to obtain higher quality security. AH always provides integrity and authentication and can provide non-repudiation if used with certain authentication algorithms. ESP always provides integrity and confidentiality and can provide authentication if used with certain authenticating encryption algorithms and schemes. Adding the Authentication Header to a SIPP datagram prior to encapsulating that datagram using ESP might be desirable for users wishing to have strong integrity, authentication, confidentiality, and perhaps non-repudiation. When the two mechanisms are combined, the placement of the SIPP Authentication Header makes clear which part of the data is being authenticated. Details on combining the two mechanisms are provided in the SIPP Encapsulating Security Payload specification. [2] 3.4 OTHER SECURITY MECHANISMS Protection from traffic analysis is not provided by any of the security mechanisms described above. It is unclear whether meaningful protection from traffic analysis can be provided economically at the Internet Layer and it appears that few Internet users are concerned about traffic analysis. One traditional method for protection against traffic analysis is the use of suitable link encryption. Another technique is to send false traffic in order to increase the noise in the data provided by traffic analysis. The reader is referred to [15] for more information on traffic analysis issues. 4. DESIGN OBJECTIVES This section describes some of the design objectives of this security architecture and its component mechanisms. The primary objective of this work is to ensure that SIPP will have solid security mechanisms available to users who desire security. These mechanisms are designed such that Internet users who do not employ these mechanisms will not be negatively impacted in their use of SIPP. These mechanisms seek to be algorithm-independent so that the cryptography might be changed in the future without affecting the other parts of the implementation. SIPP Security requires that all conforming implementations support at least the default standard algorithm. This helps to ensure interoperability in the global Internet. The algorithms used in SNMPv2 are used as the default standard algorithms for SIPP Security (i.e. MD5 for authentication and DES CBC for confidentiality). The SIPP Security mechanisms seek to be general-purpose and to avoid restricting the security policies Atkinson [Page 5] Internet Draft 19 April 1994 that might be enforced. 5. SECURITY CONSIDERATIONS This entire draft discusses the SIPP Security Architecture. Users need to understand that the quality of the security provided by the mechanisms provided by SIPP depends completely on the strength of the implemented cryptographic algorithms, the strength of the key being used, the correct implementation of the cryptographic algorithms, the security of the key management protocol, and the correct implementation of SIPP and the several security mechanisms in all of the participating systems. The security of the implementation is in part related to the security of the operating system which embodies the security implementations. For example, if the operating system does not keep the private cryptologic keys confidential, then traffic using those keys will not be secure. If any of these is incorrect or insufficiently secure, little or no real security will be provided to the user. Certain security properties (e.g. traffic analysis protection) are not provided by any of these mechanisms. One possible approach to traffic analysis protection is appropriate use of link encryption. [15] Users must carefully consider which security properties they require and take active steps to ensure that their needs are met by these or other mechanisms. Certain applications (e.g. electronic mail) probably need to have application-specific security mechanisms. Application-specific security mechanisms are out of the scope of the SIPP Security Architecture. Users interested in electronic mail security should consult the RFCs describing the Internet's Privacy-Enhanced Mail system. Users concerned about other application-specific mechanisms should consult the online RFCs to see if suitable Internet Standard mechanisms exist. ACKNOWLEDGEMENTS Many of the concepts here are derived from or were influenced by the US Government's SDNS security protocol specifications, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [3, 4, 5, 6, 7] The work done for SNMP and SNMPv2 Security influenced the choice of default cryptological algorithms and modes. [8] Steve Bellovin, Steve Deering, George Kamis, Phil Karn, and Dave Mihelcic provided critiques of earlier versions of this draft. Atkinson [Page 6] Internet Draft 19 April 1994 REFERENCES [1] Randall Atkinson, SIPP Authentication Header, Internet Draft, draft-ietf-sip-ap-03.txt, 19 April 1994. [2] Randall Atkinson, SIPP Encapsulating Security Payload, Internet Draft, draft-ietf-sip-esp-02.txt, 19 April 1994. [3] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [4] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [5] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP Security Protocol", unpublished draft, 14 April 1993. [6] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [7] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [8] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [9] Steve Deering, Simple Internet Protocol Plus (SIPP) Specification, draft-ietf-sipp-spec-00.txt, 21 February 1994 [10] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, 10 September 1993. [11] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. [12] R.M. Needham & M.D. Schroeder, "Authentication Revisted", ACM Operating Systems Review, Vol. 21, No. 1. [13] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. [14] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Atkinson [Page 7] Internet Draft 19 April 1994 Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, 10 February 1993. [15] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. DISCLAIMER The views expressed in this note 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 design. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Atkinson [Page 8]