Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-esp-00.txt 4 November 1994 Expires in six months IPv6 Encapsulating Security Payload (ESP) 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 IPng Area Directors and the IESG for possible publication as a standards-track protocol. Discussion of this draft takes place on the IPng Working Group mailing list: ipng@sunroof.eng.sun.com 1. INTRODUCTION This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. Atkinson [Page 1] Internet Draft 4 November 1994 1.1 OVERVIEW The IPv6 Encapsulating Security Payload (ESP) seeks to provide confidentiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IPv6 Encapsulating Security Payload. Either a transport-layer (e.g. UDP or TCP) frame may be encrypted or an entire IPv6 datagram may be encrypted, depending on the user's security requirements. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram, but can be very expensive to implement. Use of this specification 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 encryption and decryption required for each IPv6 datagram containing an Encapsulating Security Payload. In order for ESP to work properly without changing the entire Internet infrastructure (e.g. non-participating systems), the original IPv6 datagram is placed in the encrypted portion of the Encapsulating Security Payload and that entire ESP frame is placed within an datagram having unencrypted IPv6 headers. The information in the unencrypted IPv6 headers is used to route the secure datagram from origin to destination. An unencrypted IPv6 Routing Header might be included between the IPv6 Header and the Encapsulating Security Payload. An IPv6 Authentication Header may be present both as an header of the unencrypted IPv6 packet and also as a header within the encrypted IPv6 packet. In such a case, the unencrypted Authentication Header is primarily used to provide protection for the contents of the unencrypted IPv6 headers and the encrypted Authentication Header is used to provide authentication for the encrypted IPv6 packet. The encapsulating security payload is structured a bit differently than other IPv6 payloads. The first component of the ESP payload consist of the unencrypted field(s) of the payload. The second component consists of encrypted data. The field(s) of the unencrypted ESP header inform the intended receiver how to properly decrypt and process the encrypted data. The encrypted data component includes protected fields for the security protocol and also the encrypted encapsulated IPv6 datagram. 2. KEY MANAGEMENT Key management is an important part of the IPv6 security architecture. However, it is not included in this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security Atkinson [Page 2] Internet Draft 4 November 1994 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, IPv6 key management is specified in a separate (TBD) draft. [NB: It is intended that the key management mechanisms being developed in the IETF's Key Management Working Group and DNS Security Working Group will be reused for IPv6. ] The key management mechanism is used to negotiate a number of parameters for each security association, including not only the keys but other information (e.g. the cryptographic algorithms and modes) 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. An ESP implementation normally needs to read that security parameter table to determine how to process each datagram containing an ESP (e.g. which algorithm/mode and key to use). 3. ENCAPSULATING SECURITY PAYLOAD SYNTAX The Encapsulating Security Payload (ESP) may appear anywhere after the IPv6 header. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to IPv6 ESP. Thus the header immediately preceding the ESP header will always contain the value 50 in its Next Header field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IPv6 datagram or an upper-layer protocol frame (e.g. TCP or UDP). A high-level diagram of a secure IPv6 datagram follows. |<-- Unencrypted -->|<---- Encrypted ------>| +-------------+--------------------+------------+---------------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+---------------------+ A more detailed diagram of the ESP Header follows. In this diagram, the cleartext fields are detailed. +-------------+--------------------+------------+---------------------+ | Security Association Identifier (SAID), 32 bits | +-------------+--------------------+------------+---------------------+ | Syncronisation Data, variable length | +=============+====================+============+=====================+ | Encrypted Data, variable length | +-------------+--------------------+------------+---------------------+ Atkinson [Page 3] Internet Draft 4 November 1994 After decryption, the data transmitted in the above "Encrypted Data" field is formatted as follows: +-------------+--------------------+-----------------+----------------+ | Next Header | Header Length | Reserved | +-------------+--------------------+-----------------+----------------+ | Protected data (either an entire IPv6 datagram | | or a UDP frame or a TCP frame), variable length | +-------------+--------------------+-----------------+----------------+ 3.1 CLEARTEXT FIELDS The IPv6 Header is the conventional IPv6 Header defined by others in a separate Internet Draft. The ESP unencrypted field(s) are as follows: _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 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. An ESP implementation will always be able to use the SAID in combination with the 128-bit Destination Address to determine the security association and related security configuration data for all valid incoming packets. Senders to a multicast group 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 host knowing the security association data for the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each sender. In any event, the combination of Destination Address and SAID is used to determine the correct security association data. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also a provided service. Each SAID value implies the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation or initialisation vector field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). Atkinson [Page 4] Internet Draft 4 November 1994 _S_Y_N_C_H_R_O_N_I_S_A_T_I_O_N _D_A_T_A This field is present only for algorithms which require a cryptographic synchronisation field for each packet. The value of this field is arbitrary. The length of this field is variable, though for any given algorithm it has a particular known length. It is considered to be plaintext in this document, though most users will not be able to make sense of its contents. Its presence or absence and its size are constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. If present, the field contains cryptographic synchronisation data, such as a DES Initialisation Vector, for whichever algorithm is in use. [2] An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and to determine the field's size and use if present. 3.2 ENCRYPTED FIELDS The ESP encrypted fields are as follows: _N_E_X_T _H_E_A_D_E_R This field contains the value indicating which header follows the ESP Encrypted Fields. For example, if an entire IP datagram follows, the field will contain the number 94, which has been allocated by IANA to indicate IP-in-IP encapsulation. [cite Assigned Numbers RFC] _H_E_A_D_E_R _L_E_N_G_T_H This field is contains the length of the set of encrypted ESP fields (i.e. Next Header, Header Length, Reserved) minus the 8 byte minimum length. The minimum length is 64-bit aligned to comply with normal IPv6 alignment rules. _R_E_S_E_R_V_E_D This field is currently used primarily for padding out to 64-bit alignment but might be used for other purposes in the future. It MUST be set to zero on transmission and MUST be ignored upon receipt. It is 16 bits long. It is important that all routing headers and other data be included within the encrypted IPv6 datagram, even if the same data is in the unencrypted part of the IPv6 datagram. The receiving system shall ignore all routing information in the unencrypted portion of the received datagram and shall strictly rely on the routing information from the protected payload instead. If this rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks. The encrypted IPv6 datagram may contain an explicit IPv6 Sensitivity Label (which is not yet defined) but the encrypted IPv6 datagram need not include the IPv6 Atkinson [Page 5] Internet Draft 4 November 1994 Sensitivity Label because the SAID indicates the sensitivity label for the encrypted IPv6 datagram. If it is necessary to pad the protected data (e.g. to an integral block-size of the cryptographic algorithm in use), then the normal IPv6 Pad header is used to provide that padding. This means that ESP will not work with block oriented algorithms whose block size is not an integral number of 8-bit bytes. 4. ENCAPSULATING SECURITY PROTOCOL PROCESSING This section describes the steps taken when ESP is in use between two communicating parties. Multicast is different from unicast only in the area of key management (See the definition of the SAID, above, for more detail on this). There are two modes of use for ESP. The first mode, which is called "IP-mode", encapsulates an entire IP datagram inside ESP. This mode also works well for the case where one wants to send an encrypted ICMP or IGMP message. The second mode, which is called "Transport-Mode", encapsulates a transport-layer (i.e. UDP or TCP) frame inside ESP. This section describes protocol processing for each of these modes. 4.1 ESP in IP-mode The sender takes the original IPv6 datagram, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for the receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated in a cleartext IPv6 datagram as the last payload. If strict red/black separation is being enforced, then the addressing and other information in the cleartext IPv6 headers and optional payloads might be different from the values contained in the (now encrypted and encapsulated) original datagram. The receiver strips off the cleartext IPv6 header and cleartext optional IPv6 payloads (if any) and discards them. It then decrypts the ESP using the session key that has been established for this traffic. If no encryption key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log, including the cleartext values for the SAID, date/time, Sending Address, Destination Address, and the Flow ID. The original IPv6 datagram is then removed from the (now decrypted) ESP. This original IPv6 datagram is then processed as per the normal IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional appropriate mandatory access controls should be applied. Atkinson [Page 6] Internet Draft 4 November 1994 4.2 ESP in Transport-mode The sender takes the original UDP or TCP frame, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for the receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated as the last payload of a cleartext IPv6 datagram. The receiver processes the cleartext IPv6 header and cleartext optional IPv6 headers (if any) and temporarily stores pertinent information (e.g. source and destination addresses, Flow ID, Routing Header). It then decrypts the ESP using the session key that has been established for this traffic. If no encryption key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log, including the cleartext values for the SAID, date/time received, Sending Address, Destination Address, and the Flow ID. The original UDP or TCP frame is then removed from the (now decrypted) ESP. The information from the cleartext IPv6 header and the now decrypted UDP or TCP header is jointly used to determine which application the data should be sent to. The data is then sent along to the appropriate application as normally per IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional Mandatory Access Controls should be appropriately applied. Atkinson [Page 7] Internet Draft 4 November 1994 4.3. Combining ESP and the Authentication Header This section describes how to combine the Encapsulating Security Protocol with Authentication Header. There are two different approaches, depending on which part of the data is to be authenticated. The location of the IPv6 Authentication Header makes it clear which set of data is being authenticated. In the first usage, the entire received datagram is authenticated, including both the encrypted and unencrypted portions, while only the data sent after the ESP Header is confidential. In this usage, the sender first applies ESP to the data being protected. Then the other plaintext IPv6 headers are prepended to the ESP header and its now encrypted data. Finally, the IPv6 Authentication Header is calculated over the resulting datagram according to the normal method. Upon receipt, the receiver first verifies the authenticity of the entire datagram using the normal IPv6 Authentication Header process. Then if authentication succeeds, decryption using the normal IPv6 ESP process occurs. If decryption is successful, then the resulting data is passed up to the upper layer. If the authentication process were to be applied only to the data protected by IPv6 ESP and the protected data were an entire IPv6 datagram, then the IPv6 Authentication Header would be placed normally within that protected datagram. However, if the protected data were less than an entire IPv6 datagram, then the IPv6 Authentication Header would be placed within the encrypted payload immediately after the ESP protected header and before any other header or the UDP or TCP frame. 6. TYPICAL USE The ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork and provides security services for the trusted hosts when they communicate with external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g. an Ethernet) isn't being attacked. Trusted systems always should be trustworthy, but in practice they often are not trustworthy. In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security Atkinson [Page 8] Internet Draft 4 November 1994 gateway and the external system(s). In this case, only the gateway need implement ESP, while all of the systems behind the gateway on the trusted subnet may take advantage of ESP services between the gateway and external systems. A gateway which receives a datagram containing a recognised sensitivity label from a trusted host should take that label's value into account when creating/selecting an SAID for use with ESP between the gateway and the external destination. A gateway which receives a IPv6 packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IPv6 Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity. If there are no security gateways present in the connection, then two end systems that implement ESP can use it to encrypt only the user data (e.g. TCP or UDP) being carried between the two systems. ESP is designed to provide all this flexibility so that users may select and use only the security that they desire and need. Others have developed an Informational document describing how IPv6 security may be supported as part of a Sockets API. [15] 7. SECURITY CONSIDERATIONS This entire draft discusses a security mechanism for use with IPv6. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, the strength of the key [16] and upon the correctness of the ESP and IPv6 implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Use of high assurance development techniques is recommended for the IPv6 Encapsulating Security Payload. 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 Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [1, Atkinson [Page 9] Internet Draft 4 November 1994 2, 3, 4, 5] The use of DES for confidentiality is closely modeled on the work done for the SNMPv2. [7] Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful critiques of earlier versions of this draft. REFERENCES [1] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. [2] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [3] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP Security Protocol", unpublished draft, 14 April 1993. [4] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [5] 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. [7] James Galvin & Keith McCloghrie, Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [7] Randall Atkinson, IPv6 Security Architecture, Internet Draft, draft-atkinson-ipng-sec-00.txt, 4 November 1994. [8] Randall Atkinson, IPv6 Authentication Header, Internet Draft, draft-atkinson-ipng-auth-00.txt, 4 November 1994. [9] Robert Hinden (Editor), IPv6 Specification, Internet Draft, draft-hinden-ipng-ipv6-spec-00.txt, October 1994. [10] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [11] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [12] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Atkinson [Page 10] Internet Draft 4 November 1994 Processing Standard (FIPS) Publication 74, April 1981. [13] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [14] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [15] Dan McDonald, Security Extensions to the IPv6 Sockets API, Internet Draft, November 1994. [16] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, July 1994. pp. 253-280 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. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 11] Internet Draft 4 November 1994 APPENDIX A: Use of CBC-Mode DES with IPv6 ESP This appendix describes the application of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm to the IPv6 Encapsulating Security Payload. This mode of DES requires an Initialisation Vector that is 8 bytes long and requires that the encrypted data be a multiple of 8 bytes long. DES is described is several US Government publications. [10, 11, 12, 13] A recent book also provides information on DES. [14] That same reference indicates on page 231 that at least one hardware implementation of DES CBC can encrypt or decrypt at about 1 Gbps. Each ESP header shall contain a 64-bit DES Initialisation Vector in the Cryptographic Synchronisation field when DES-CBC is in use. Each packet needs to contain its own different DES Initialisation Vector. Including the Initialisation Vector in each packet also ensures decryption of each received packet can be performed even though other packets might have been dropped or packets might have been misordered in transit. The method for selection of the Initialisation Vector value is implementation-defined. The secret DES key shared between the communicating parties is 64 bits long, as per the DES specifications [10, 11, 12, 13]. The 64-bit DES key consists of a 56-bit quantity used by the DES algorithm and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. The length of the octet sequence to be encrypted by the DES algorithm must be an integral multiple of 8. When encrypting, any needed padding shall be included by using a IPv6 hop-by-hop padding option. When the Transport-mode of ESP is used, such padding must appear between the encrypted ESP header fields and the start of the UDP or TCP data. If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, then processing shall be halted, the packet shall be discarded, and the event shall be audited using implementation-specific methods. Atkinson [Page 12]