Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-sec-00.txt 4 November 1994 Expires in six months IPv6 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 IPng working group. It is intended that a future version of this draft be submitted to the IESG for publication as a standards-track RFC. Discussion of this draft normally takes place on the IPng Working Group mailing list: ip-ng@sunroof.eng.sun.com To add/drop from that mailing list, send an email request to: ip-ng-request@sunroof.eng.sun.com 1. INTRODUCTION The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes how security mechanisms outside the scope of the IPng effort (e.g. key management) relate to the IPv6 security mechanisms. 1.1 Definitions SAID Authentication Atkinson [Page 1] Internet Draft 4 November 1994 Integrity Confidentiality Non-repudiation Traffic Analysis 2.0 IPv6 SECURITY MECHANISMS There are two security mechanisms in IPv6. The first is the Authentication Header which provides integrity and authentication without confidentiality. [At94a] The second is the Encapsulating Security Payload which, depending on algorithm and mode, might provide integrity, authentication, and always provides confidentiality. [At94b] The IPv6 mechanisms do not provide security against a number of traffic analysis attacks. However, there are several techniques outside the scope of this specification (e.g. bulk link encryption) that might be used to provide protection against traffic analysis. The two IPv6 security mechanisms may be combined. 2.1 AUTHENTICATION HEADER The IPv6 Authentication Header seeks to provide integrity and authentication for IPv6 datagrams. It does this by computing a cryptographic authentication function over the IPv6 datagram and using a secret authentication key in the computation. [Atk94a] The sender computes the authentication data just prior to sending the authenticated IPv6 packet and the receiver verifies the correctness of the authentication data upon reception. Certain fields which must change in transit, such as the Hop Limit field decremented on each hop, are omitted from the authentication calculation. However the omission of the Hop Limit field does not adversely impact the security provided. Non-repudiation might be provided by some authentication algorithms used with the Authentication Header, but it is not provided by all authentication algorithms that might be used with the Authentication Header. The default authentication algorithm is keyed MD5, which does not provide non-repudiation. Confidentiality and traffic analysis protection are not provided by the Authenticaton Header. The IPv6 Authentication Header holds authentication information for its IPv6 datagram. This authentication information is calculated using all of the fields in the IPv6 datagram which do not change during transit from the originator to the recipient. All IPv6 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. Atkinson [Page 2] Internet Draft 4 November 1994 IPv6 Header's "Hop Count" or the IPv6 Routing Header's "Next Address") are omitted when the authentication data is calculated. Use of the Authentication Header will increase the IPv6 protocol processing costs in participating 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 each receiver for each IPv6 datagram containing an Authentication Header (AH). The Authentication Header provides much stronger security than exists in most of the current Internet and should not affect exportability or significantly increase implementation cost. While the Authentication Header might 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, the Authentication Header should be used from origin to final destination. All IPv6-capable hosts MUST implement the IPv6 Authentication Header with at least the MD5 algorithm using a 128-bit key. Other authentication algorithms may also be implemented in addition to keyed MD5. 2.2 ENCAPSULATING SECURITY PAYLOAD The IPv6 Encapsulating Security Payload (ESP) seeks to provide integrity, authentication, and confidentiality to IPv6 datagrams. It does this by encapsulating either an entire IPv6 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 IPv6 datagram. This cleartext IPv6 datagram carries the protected data through the internetwork. The recipient of the cleartext datagram removes and discards the cleartext IPv6 header and cleartext IPv6 options, decrypts the ESP, processes and then removes the ESP headers, and then processes the (now decrypted) original IPv6 datagram or upper-layer protocol data as per the normal IPv6 protocol specification. 2.2.1 Description of the ESP Modes There are two modes within ESP. The first mode, which is known as IP-mode, encapsulates and entire IP datagram within the ESP header. The second mode, which is known as Transport-mode, encapsulates either a UDP or TCP frame inside IP. 2.2.2 Usage of ESP ESP works between hosts, between a host and a security gateway, or between security gateways. This support for security gateways permits trustworthy networks to exist without the performance and monetary Atkinson [Page 3] Internet Draft 4 November 1994 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 Transport-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 IPv6 datagram confidential. ESP works with both unicast and multicast traffic. 2.2.3 Performance Impacts of ESP The encapsulating security approach used by ESP can noticeably impact network performance in participating systems, but should not adversely impact routers or other intermediate systems that are not participating in the particular ESP association. Protocol processing in participating systems will be more complex when encapsulating security is used, requiring both more time and more processing power. Use of encryption will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IPv6 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. Hardware implementations of the encryption algorithm are recommended when high throughput is desired. Because of the performance impact, users not requiring confidentiality will probably prefer to use the IPv6 Authentication Header instead of ESP. For interoperability throughout the worldwide Internet, all conforming implementations of IPv6 Encapsulting Security Payload MUST support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode. Other confidentiality algorithms and modes may also be implemented in addition to this mandatory algorithm and mode. 2.3 COMBINING SECURITY MECHANISMS In some cases the IPv6 Authentication Header might be combined with the IPv6 Encapsulating Security Protocol to obtain the desired security properties. The Authentication Header always provides integrity and authentication and can provide non-repudiation if used with certain authentication algorithms (e.g. RSA) . The Encapsulating Security Payload always provides integrity and confidentiality and can also provide authentication if used with certain authenticating encryption algorithms. Adding the Authentication Header to a IPv6 datagram prior to encapsulating that datagram using the Encapsulating Security Protocol might be desirable for users wishing to have strong integrity, authentication, confidentiality, and perhaps also non-repudiation. When the two mechanisms are combined, the placement of the IPv6 Authentication Header makes clear which part of the data is being authenticated. Details on combining the two mechanisms are Atkinson [Page 4] Internet Draft 4 November 1994 provided in the IPv6 Encapsulating Security Payload specification. [At94b] 2.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 bulk 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 [VK83] for more information on traffic analysis issues. 3. KEY MANAGEMENT The Key Management protocol that will be used with IPv6 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. 3.1 Manual Key Distribution 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. 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. It also might be appropriate when only selected communications need to be secured. 3.2 Some Existing Key Management Techniques There are a number of key management algorithms that have been described in the public literature. Needham & Schroeder have proposed a key management algorithm which relies on a centralised key distribution system. [NS78, NS81] This algorithm is used in the Kerberos Authentication System developed at MIT under Project Athena. [KB93] More recently, Diffie & Hellman have devised an algorithm which does not require a centralised key distribution system. [DH76] 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. Atkinson [Page 5] Internet Draft 4 November 1994 3.2 Automated Key Distribution Widespread deployment and use of IPv6 security will require an Internet-standard scalable key management protocol. Ideally such a protocol would support a number of protocols in the Internet protocol suite, not just IPv6 security. There is work underway within the IETF to add signed host keys to the Domain Name System [EK94] The DNS keys enable the originating party would to authenticate key management messages with the other key management party using an asymmetric algorithm. The two parties would then have an authenticatible communications channel that could be used to create a shared session key using Diffie-Hellman or other means. [DH76] Further, the security mechanisms can be keyed either on a host-to-host basis, where all users on host 1 share the same key for use on traffic destined for all users on host 2, or on a user-to-user basis, where user A on host 1 has a unique session key with user B on host 2. When host-to-host keying is used and given two users A and B that do not trust each other but do have access to the network connecting their computer with other systems, it is possible for user A to determine the host-to-host key via well known methods and then either read user B's encrypted traffic or forge traffic from user B. When user-to-user keying is used, this particular attack from one user onto another user's traffic is not possible. 3.3 Multicast Key Distribution 3.4 IPv6 Key Management Requirements All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MUST permit the configuration and use of user-to-user keying and MAY additionally permit the configuration of host-to-host keying as an added feature to make manual key distribution easier. The method by which keys are configured on a particular system is implementation-defined. A flat file containing security association identifiers and the security parameters, including the key(s), is an example of one possible method for manual key distribution. 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 IPv6 will have solid security Atkinson [Page 6] Internet Draft 4 November 1994 mechanisms available to users who desire security. These mechanisms are designed such that Internet users who do not employ these mechanisms will not be adversely affected. These mechanisms are intended to be algorithm-independent so that the cryptographic algorithms can be altered without affecting the other parts of the implementation. Standard default algorithms (i.e. keyed MD5, DES CBC) are specified (i.e. keyed MD5, DES CBC) to ensure interoperability in the global Internet. The selected algorithms are the same as the standard default algorithms used in SNMPv2. The IPv6 Security mechanisms should be useful in enforcing a variety of security policies. 5. USAGE This section describes the use of the security mechanisms provided by IPv6 in several different situations. 5.1 USE WITH FIREWALLS Firewalls are not uncommon in the current Internet. While many dislike their presence because they restrict connectivity, they are unlikely to disappear in the near future. Both of the IPv6 mechanisms can be used to increase the security provided by firewalls. Firewalls used with IPv6 will need to be able to parse the header daisy-chain to determine the transport protocol (e.g. UDP or TCP) in use and the port number for that protocol. Firewall performance should not be significantly affected by use of IPv6 because the header format rules in IPv6 make parsing easy and fast. Firewalls can use the Authentication Header to gain assurance that the data (e.g. source, destination, transport protocol, port number) being used for access control decisions is correct and authentic. IPv4 firewalls are unable to authenticate the data being used for access control decisions and necessarily trust data that is not trustworthy. Authentication might be performed not only within an organisation or campus but also end to end with remote systems across the Internet. This use of the Authentication Header with IPv6 provides much more assurance of security than IPv4 provides. Organisations (e.g. the Foo Company) with two or more sites that are interconnected using commercial IP service might wish to use a selectively encrypting firewall. If an encrypting firewall were placed between each site of the Foo Company and the commercial IP service provider, the firewall could provide an encrypted IP tunnel among all of the Foo Company's sites. It could also encrypt traffic between the Foo Company and its suppliers, customers, and other affiliates. Traffic with the NIC, with public Internet archive, or some other organisations might not be encrypted in order to facilitate better communications, improved network performance, and increased Atkinson [Page 7] Internet Draft 4 November 1994 connectivity. Such a practice could easily protect the organisation's sensitive traffic from eavesdropping and modification. Some organisations (e.g. governments) might wish to use a fully encrypting firewall to provide a protected virtual network over commercial IP service. The difference between that and a bulk IPv6 encryption device is that a fully encrypting firewall would provide filtering of the decrypted traffic as well as providing encryption of IP packets. 5.3 USE WITH IPv6 MULTICAST In the past several years, the Multicast Backbone (MBONE) has grown rapidly. IETF meetings and other conferences are now regularly multicast with real-time audio, video, and whiteboards. Many people are now using teleconferencing applications based on IP Multicast in the Internet or in private internal networks. Hence it is important that the security mechanisms in IPv6 be suitable for use in an environment where multicast is the general case. The Security Association Identifiers (SAIDs) used in the IPv6 security mechanisms are receiver-oriented, making them well suited for use in IP multicast. [Atk94a, Atk94b] Unfortunately, most currently published multicast key distribution protocols do not scale well. However, there is active research in this area. As an interim step, a multicast group could repeatedly use a secure unicast key distribution protocol to distribute the key to all members or the group could pre-arrange keys using manual key distribution. 5.4 USE TO PROVIDE QOS PROTECTION The recent IAB Security Workshop identified Quality of Service protection as an area of significant interest. [BCCH] The two IPv6 security mechanisms are intended to provide good support for real-time services as well as multicasting. This section describes one possible approach to providing such protection. The Authentication Header can be used, with appropriate key management, to provide authentication of packets. This authentication is potentially important in packet classification within routers. The IPv6 Flow Identifier can act as a Low-Level Identifier (LLID). Used together, packet classification within routers becomes straightforward if the router is provided with the appropriate key material. For performance reasons the routers might authenticate only every Nth packet rather than every packet, but this is still a significant improvement over capabilities in the current Internet. Quality of service provisioning is likely to also use the Flow ID in conjunction with a resource reservation protocol, such as RSVP. Thus, the authenticated packet classification can be used to help ensure that each packet receives appropriate handling inside routers. Atkinson [Page 8] Internet Draft 4 November 1994 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (e.g. Unclassified and Secret). Many governments have significant interest in MLS networking. The IPv6 security mechanisms have been designed to support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC) which ordinary users are incapable of controlling or violating. Mandatory Access Controls differ from Discretionary Access Controls in this respect. The Authentication Header can be used to provide strong authentication among hosts in a single-level network. This can be used to provide strong assurance for both mandatory access control decisions and discretionary access control decisions. If IP sensitivity labels are used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header is used to provide authentication for the entire packet, including cryptographic binding of the sensitivity level to the IPv6 header and user data. This is a significant improvement over labelled IPv4 networks where the label is trusted even though it is not trustworthy because there is no authentication or cryptographic binding of the label to the IP header and user data. The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each keys must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for Unclassified packets while Key "B" is used only for Secret/No-compartments traffic and Key "C" is used only for Secret/No-Foreign traffic. In sensitive environments, appropriate organisational policies will dictate the actual key management policy and also the set of algorithms that are appropriate for use. In such environments, the ability to communicate between the Internet and the hosts handling sensitive data is probably undesirable. Hence, systems only handling sensitive information might not implement the Internet standard algorithms and instead only have algorithms approved by appropriate policies for such use. Such systems would not be fully conforming to the IPv6 Encapsulating Security Payload specification with regard to implementation of the mandatory Internet algorithm, but those users might not care or might consider that to be desirable. Encryption is very useful and desirable even when all of the hosts are within a protected environment. The Internet-standard encryption algorithm could be used, in conjuction with appropriate key management, to provide strong Discretionary Access Controls (DAC) in conjunction with either implicit or explicit sensitivity labels. Some environments might consider the Internet-standard encryption algorithm Atkinson [Page 9] Internet Draft 4 November 1994 sufficiently strong to provide Mandatory Access Controls (MAC). Full encryption SHOULD be used for all communications between multi-level computers or compartmented mode workstations even when the computing environment is considered to be protected. Atkinson [Page 10] Internet Draft 4 November 1994 6. SECURITY CONSIDERATIONS This entire draft discusses the IPv6 Security Architecture. Users need to understand that the quality of the security provided by the mechanisms provided by IPv6 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 IPv6 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. Because different users on the same system might not trust each other, each user or each session should usually be keyed separately. This will also tend to increase the work required to cryptanalyse the traffic since not all traffic will use the same key. 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. [VK83] 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 IPv6 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. [SDNS, ISO, IBK93a, IBK93b] The work done for SNMP Security and SNMPv2 Security influenced the choice of default cryptological algorithms and modes. [GM93] Steve Bellovin, Steve Deering, Richard Hale, George Kamis, Phil Karn, Frank Kastenholz, and Dave Mihelcic provided critiques of earlier versions of this draft. Atkinson [Page 11] Internet Draft 4 November 1994 REFERENCES [At94a] Randall Atkinson, IPv6 Authentication Header, Internet Draft, draft-atkinson-ipng-auth-00.txt, 4 November 1994. [At94b] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet Draft, draft-atkinson-ipng-esp-00.txt, 4 November 1994. [BCCH] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, June 1994. [SDNS] 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. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IBK93a] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP Security Protocol", USENIX ???, 14 April 1993. [IBK93b] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [Hi94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, draft-hinden-ipv6-spec-00.txt, October 1994. [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, 10 September 1993. [NS78] 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. [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisted", ACM Operating Systems Review, Vol. 21, No. 1., 1981. [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. [Ke93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Atkinson [Page 12] Internet Draft 4 November 1994 Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, 10 February 1993. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [EK94] Donald E. Eastlake III & Charles W. Kaufman, "Domain Name System Protocol Security Extensions", Internet Draft, draft-ietf-dnssec-secext-01.txt, March 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 Voice: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 13]