Network Working Group Randall Atkinson Internet draft Naval Research Laboratory draft-ietf-sipp-sa-01.txt 9 March 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). The author of this draft is keen on feedback on how to improve this draft, particularly in places where the architecture might be unclear or suboptimal. 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 in its own Internet Draft. 2. KEY MANAGEMENT The Key Management protocol that will be used with SIPP has not yet been specified. Discussion on which approach is best is solicited and should occur on the SIPP mailing list (see above). However, Atkinson [Page 1] Internet Draft 9 March 1994 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. 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. Some kind of key management protocol is necessary for use in the Internet. 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. [N&S 78] This algorithm is used in the Kerberos Authentication System developed at MIT under Project Athena. [KERBEROS RFC] More recently, Diffie & Hellman have devised a key management algorithm which operates on a peer to peer basis and does not require a centralised key distribution system. [D&H 81?] Unfortunately, the original Diffie-Hellman technique is vulnerable to an active attack. [which cite] However, this vulnerability can be mitigated by using key certificates to bootstrap into the Diffie- Hellman exchange. The Internet's Privacy Enhanced Mail (PEM) uses a kind of key certificate that is suitable for use with the Diffie- Hellman key management algorithm. However, this hybrid key management protocol reportedly requires 4-6 exchanges in order to setup a session key for the two parties to the key management transaction. Another approach would be for each party to have a PEM-like key certificate available via a UDP service. Then the originating party would encrypt key management traffic to the other key management party using RSA encryption in a manner which provides origin authentication. The two parties would then have a secure communications channel useable to agree upon a session key. This appears to be a viable approach. It is reported that the IEEE 802.10 work has resulted in another key management protocol that is in some ways similar to the hybrid Diffie-Hellman described two paragraphs above, but only requires 4 exchanges between the parties. This might also be a suitable method. The IETF's IPv4 Security Protocol (IPSP) Working Group is Atkinson [Page 2] Internet Draft 9 March 1994 considering specifying a key management/security association protocol, but they aren't working on this at present and it isn't clear which approach they would adopt. Their key management protocol would probably use UDP because UDP is less susceptible to active attacks than TCP. SIPP implementations should implement both a manual key configuration mechanism and a standard key management protocol (once the latter is defined). Both of the SIPP security mechanisms described below rely on adequate key management mechanisms being widely deployed. 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 "hop count" or "routing pointer") are omitted from the calculation of the authentication data. 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 Atkinson [Page 3] Internet Draft 9 March 1994 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 should implement the SIPP Authentication Header with at least the MD5 algorithm. 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 degrade 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 Atkinson [Page 4] Internet Draft 9 March 1994 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. 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. 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 [Voydock & Kent] 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 Atkinson [Page 5] Internet Draft 9 March 1994 to be general-purpose and to avoid restricting the security policies 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 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. 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. REFERENCES [1] Randall Atkinson, SIPP Authentication Header, Internet Draft, draft-ietf-sip-ap-01.txt, 9 March 1994. Atkinson [Page 6] Internet Draft 9 March 1994 [2] Randall Atkinson, SIPP Encapsulating Security Payload, Internet Draft, draft-ietf-sip-esp-01.txt, 9 March 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 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 7]