Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-simpson-esp-v2-00.txt < prev next >

Wrap

Text File | 1997-08-02 | 31KB | 881 lines

Network Working Group W A Simpson, Editor Internet Draft [DayDreamer] expires in six months July 1997 IP Encapsulating Security Payload (ESP) for Implementors draft-simpson-esp-v2-00.txt Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Abstract This document describes a confidentiality mechanism for IP datagrams. Payload headers are encapsulated within an opaque envelope. Under some circumstances, authentication and integrity are optionally pro- vided for IP datagrams. Simpson expires in six months [Page i] DRAFT ESP2 July 1997 1. Introduction The Encapsulating Security Payload (ESP) provides confidentiality for IP datagrams by encrypting the payload data to be protected. Depend- ing on the user's security requirements, either an upper protocol- layer segment (such as TCP or UDP) is encrypted (transport-mode), or an entire IP datagram is encrypted and tunneled to the destination within another IP datagram (tunnel-mode). To work properly without changing the entire Internet infrastructure (particularly non-participating routers), ESP is carried in a data- gram with transparent IP headers. The information in these outer IP headers is used to route the protected datagram. For more details about ESP in various network environments, see "Security Architecture for the Internet Protocol" [RFC-1825x]. That document provides important background for this specification, such as an explanation of Security Associations, forms of Security Associ- ation management, guidelines on transport and tunnel modes of opera- tion, and interaction between ESP and the Authentication Header (AH) [RFC-1826x]. ESP may optionally provide authentication and integrity. Users desiring authentication and/or integrity without confidentiality should use AH instead of ESP. ESP may also provide a form of anti-replay service, depending upon the selection of integrity. The enforcement of replay protection is solely at the discretion of the receiver. Security services can be provided between: - a pair of single user hosts, - a single user host and a security firewall router, or - a pair of firewall routers. In the latter case, together with the tunnel mode of encapsulation, ESP may provide traffic flow confidentiality. Traffic aggregation at the firewalls may be able to mask source to destination patterns of the protected internal users. In this document, the key words "MAY", "MUST", "optional", "recom- mended", "required", "SHOULD", and "SHOULD NOT", are to be inter- preted as described in [RFC-2119]. Simpson expires in six months [Page 1] DRAFT ESP2 July 1997 1.1. Performance Use of this specification will increase the protocol processing costs in participating systems, and will also increase the communications latency. The increased latency is primarily due to time required for encryption and decryption of each datagram. This can be very time intensive to implement. 1.2. Construction ESP will always appear as the final payload header. The header imme- diately preceding the ESP Header will contain the value 50 (0x32) in its Next Header (Protocol) field. <-- Transparent --> <-- Opaque --> +-----------+-----------------+--------------+--------------+ | IP Header | other headers | ESP Header | ESP Data | +-----------+-----------------+--------------+--------------+ The Encapsulating Security Payload has two components. The transparent ESP Header consists of the unencrypted field(s) of the payload. The transparent field(s) of the unencrypted ESP Header inform the intended recipient how to properly process the opaque data. The opaque ESP Data consists of protected fields for the ESP trans- form(s). 1.3. Transforms Cipher and authenticator algorithms, and the precise format of opaque ESP data associated with them, are known as "ESP transforms". It is intended that the ESP format should be sufficiently general to permit the specification of new transforms as new cryptographic algorithms are developed. The parameter description requirements for companion transform docu- ments are described in [RFC-ffff]. When the authenticator transform requires a separate key, that key is generated after any cipher keys. Simpson expires in six months [Page 2] DRAFT ESP2 July 1997 2. Field Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | A E ~ Transform Data ~ A E | | A E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | Pad Length | Payload Type | A E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authenticator (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are transmitted in network order (most significant byte first). Fields that may be authenticated are designated by a trailing A. Fields that may be encrypted are designated by a trailing E. 2.1. Security Parameters Index (SPI) The SPI is a 32-bit (4 byte) unsigned value identifying the Security Association parameters for the ESP transform. The value is relative to the IP Destination in the preceding IP Header of the datagram. The use of this value is orthogonal to usage of similar values by other related security protocols, such as the Authentication Header (AH). That is, the same value MAY be used by multiple protocols to concurrently indicate different Security Association parameters. The value zero (0) indicates that no Security Association has been established, and is primarily used for testing. Values in the range 1 through 255 are reserved to the Internet Assigned Numbers Authority (IANA) for future use. A reserved SPI value will not normally be assigned by IANA unless the specification is openly available and documented in the RFC publication series. Values in the range 256 through 65535 are recommended for manual con- figuration. Simpson expires in six months [Page 3] DRAFT ESP2 July 1997 Remaining values are utilized by automated Security Association man- agement. These values are recommended to be generated by a crypto- graphically random method, to protect against replay attacks and traffic analysis. This field is mandatory and transparent. That is, the field is always present, and the value is not concealed by encryption. Rationale: Even when many SPIs are part of the same Security Association, there is no numerical relation between SPIs in different direc- tions, and no requirement that SPIs be defined in pairs or other multiples. It should be understood that the same SPI value for different pro- tocols will indicate different parameters. For example, one might indicate a cipher algorithm, and another an authenticator algo- rithm. The requirement for SPI orthogonality between protocols arises whenever the values are assigned for multiple protocols in the same transaction by automated or manual configuration using a sin- gle common value, or the values are assigned independently by an outside agent (such as a Key Distribution Center). Orthogonality may also be desirable in future multicast implementations. A small range of values for manual configuration is utilized to promote ease of configuration and interoperability. Experience has shown that large random numbers are not easily remembered and checked by human operators. This does not preclude automated configuration from utilizing unused values in the reserved and/or recommended manual configura- tion ranges during operation. 2.2. Sequence Number The Sequence Number is a 32-bit (4 byte) unsigned counter. This field protects against replay attacks, and may also be used for syn- chronization by stream or block-chaining ciphers. Manual configuration can only detect replay of consecutive duplicate Seqeunce Numbers, and during short runs of Sequence Numbers within the round trip time for the parties. The limited anti-replay secu- rity of the sequence of datagrams depends upon the unpredictability of the values. When configured manually, the first value sent SHOULD Simpson expires in six months [Page 4] DRAFT ESP2 July 1997 be a random number. Long term replay prevention requires automated configuration. When configured via an automated Security Association management protocol, the first value sent is 1, unless otherwise negotiated. Thereafter, the value is monotonically increased for each datagram sent. A replacement SPI SHOULD be established before the value rolls over and repeats. This field is mandatory and transparent. That is, the field is always present, and the value is not concealed by encryption. Although sending this field is mandatory, verification of the sequence of values is at the discretion of the receiver. When integrity checking is available, either through the optional Authen- ticator field or an external Authentication Header (AH), the imple- mentation SHOULD NOT accept duplicate values. This may be achieved by accepting only those datagrams that contain a different value than previously received, or by maintaining a small window of acceptable values. See Operational Considerations. Rationale: To prevent replay of payloads by substitution of a fresh Sequence Number, anti-replay must be coupled with authentication and/or integrity. Less than 2**32 datagrams are sent under any single key when anti- replay protection is enforced. 2.3. Transform Data An implementation will use the SPI to determine the Transform Data contents and use. It retains the same general format for all data- grams of any given IP Destination and SPI. The length of this field is variable, but is always an integral number of bytes. If the transform requires a separate synchronization field, then such data SHOULD be carried at the beginning of this field. This field is optional and opaque. That is, the field is not inter- pretable without knowledge of the Security Association parameters. Refer to each Security Transform specification for more information regarding the contents of this field. Simpson expires in six months [Page 5] DRAFT ESP2 July 1997 2.4. Padding If a cipher algorithm requires the plaintext to be a multiple of some number of bytes (such as the block size of a block cipher), the Padding field is used to fill the plaintext to the size required by the algorithm. All implementations MUST support generation and con- sumption of such padding. In addition, padding may be used to conceal the actual length of the plaintext. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. Finally, when the Authenticator field is present, padding also may be required to ensure that the resulting ciphertext terminates on a 32-bit (4 byte) boundary. Prior to encryption, this field is filled with a series of integer values, to align the Pad Length and Payload Type fields at the end of the required boundary (measured from the beginning of the Transform Data). By default, Self-Describing-Padding is used [RFC-1790]. Each byte of padding contains the index of that byte. The first pad byte contains the value one (1). The final pad byte indicates the number of pad bytes to remove. For example, three pad bytes would contain the values 1, 2, and 3. After decryption, this field MAY be examined for a valid series of integer values. Verification of the sequence of values is at the discretion of the receiver. This field is optional and opaque. That is, the value (when present) is set prior to encryption, and is examined only after decryption. Rationale: The default padding values were selected for simplicity, ease of implementation in hardware, and compatibility with other internet security efforts. 2.5. Pad Length The Pad Length (1 byte) indicates the amount of Padding immediately preceding it. The value does not include the Pad Length and Payload Type fields. The range of valid values is 0 through 255. A value of zero indi- cates that no Padding is present. Simpson expires in six months [Page 6] DRAFT ESP2 July 1997 This field is mandatory and opaque. That is, the value is set prior to encryption, and is examined only after decryption. Rationale: This extra field is appended to Self-Describing-Padding for com- patibility with earlier implementations that used random padding values. 2.6. Payload Type The Payload Type (1 byte) indicates the contents of the Transform Data field, using the IP Next Header (Protocol) value. Up-to-date values of the IP Next Header (Protocol) are specified in the most recent "Assigned Numbers" [RFC-1700]. For example, when encrypting an entire IP datagram (Tunnel-Mode), this field will contain the value 4, indicating IP-in-IP encapsula- tion. This field is mandatory and opaque. That is, the value is set prior to encryption, and is examined only after decryption. 2.7. Authenticator When the ESP data is not otherwise validated (externally using AH or internally by the transform algorithm itself), it is recommended (but not required) that an Integrity Check Value (ICV) be provided here. The ICV is computed over the ESP data after encryption, beginning with the SPI and ending with the Payload Type. A keyed algorithm must be employed to compute the ICV. The length of the field depends upon the authenticator transform selected. For some authenticator transforms, the bytes over which the computa- tion is performed must be a multiple of a block size specified by the algorithm, or the block must be "strengthed" by appending a length. Implicit padding is appended to the end of the ESP packet, prior to Authenticator computation. The size and form of the padding is spec- ified by the transform specification. This implicit padding is not transmitted with the datagram. This field is optional and opaque. That is, the field (when present) is not concealed by encryption, but is not interpretable without knowledge of the Security Association parameters. Simpson expires in six months [Page 7] DRAFT ESP2 July 1997 Rationale: The order of processing (authentication "outside" encryption) facilitates rapid detection of bogus datagrams by the receiver prior to decrypting, potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing at the receiver; decryption can take place in parallel with authentication, but care must be taken to avoid race condi- tions for packet access and reconstruction of the decrypted packet. 3. Processing The Security Parameters Index (SPI) is the only coupling between ESP and Security Association management mechanisms. This permits differ- ent management mechanisms to be used concurrently. More importantly, it permits any automated management protocol to be changed or cor- rected without unduly impacting the security protocol implementa- tions. In order to facilitate early adoption, manual configuration is the only mechanism required by this specification. The Security Association management mechanism specifies a number of parameters for each Security Association between the communicating parties. Manually configurable parameters are summarized in "Opera- tional Considerations". These Security Association determinations are described in more detail in the Security Architecture document [RFC-1825]. 3.1. Outgoing ESP is applied to an outgoing datagram only after an implementation determines that an existing Security Association calls for ESP pro- cessing, based on the IP Destination. If not, then the Security Association management mechanism is used to establish the SPI for this communication session prior to the use of ESP. The indicated SPI begins the ESP Header. 3.1.1. Compression When configured, perform data compression of the payload. If expan- sion occurs, the outgoing SPI may be changed to a value that indi- cates unexpanded data. Simpson expires in six months [Page 8] DRAFT ESP2 July 1997 3.1.2. Sequence Number Check to ensure that the Sequence Number for this SPI has not over- flowed. If the implementation detects that 2**32 datagrams have already been sent, the datagram is discarded, and an auditable event is indicated. Otherwise, insert the next value into the Sequence Number field. 3.1.3. Padding Append zero or more bytes of padding to the plaintext, as required by the transform. Append a Pad Length byte containing the number of padding bytes just added. For example, if the plaintext length is 41, and the block size is 64-bits (8 bytes), padding is needed to make its modulo 8 length equal to 6, leaving 2 bytes for the Pad Length and Payload Type. The padding values are 1, 2, 3, 4, 5, and the following Pad Length is 5. 3.1.4. Payload Type Append a Payload Type byte containing the IP Next Header (Protocol) value which identifies the protocol header that begins the payload. 3.1.5. Encryption Provide an Initialization Variable (IV) of the form indicated by the cipher transform specification. Encrypt the plaintext, Padding, Pad Length and Payload Type, produc- ing a ciphertext in the form indicated by the cipher transform speci- fication. 3.1.6. Authentication When configured, calculate and append the optional Authenticator in the form indicated by the authenticator transform specification. Simpson expires in six months [Page 9] DRAFT ESP2 July 1997 3.1.7. Completion Construct an appropriate IP datagram for the target Destination. The IP Total/Payload Length is adjusted to reflect the length of the encrypted payload, with the SPI, Sequence Number, and optional Authenticator. 3.2. Incoming Upon receipt of a (reassembled) incoming datagram containing an ESP Header, the implementation determines the appropriate Security Asso- ciation, based on the IP Destination and the SPI. If the SPI is invalid, then the datagram is discarded, and the "Bad SPI" error is indicated. The SPI field is used as an index into the local Security Association table to find the negotiated parameters and key(s). 3.2.1. Sequence Number When replay checking is enabled, ensure that the Sequence Number is in the appropriate window for this SPI, and that it has not been pre- viously received. If the Sequence Number appears to be valid, then the implementation proceeds to authentication. The receive window is updated only when authentication, decryption and decompression succeed. If the Sequence Number is invalid, then the datagram is discarded, and the "Authentication Failed" error is indicated. 3.2.2. Authentication When present, remove and verify the optional Authenticator. If the Authenticator is invalid, then the datagram is discarded, and the "Authentication Failed" error is indicated. 3.2.3. Decryption If the length of the data to be decrypted is not an integral multiple of the transform block size, then the datagram is discarded, and the "Decryption Failed" error is indicated. Simpson expires in six months [Page 10] DRAFT ESP2 July 1997 Provide an Initialization Variable (IV) of the form indicated by the cipher transform specification. Decrypt the ciphertext, producing a plaintext, Padding, Pad Length and Payload Type, in the form indicated by the cipher transform spec- ification. 3.2.4. Payload Type The Payload Type is removed and examined. If it is unrecognized, then the datagram is discarded, and the "Decryption Failed" error is indicated. 3.2.5. Padding The Pad Length is removed and examined. If pad checking is config- ured, and the padding bytes are not the correct values for the Pad Length, then the datagram is discarded, and the "Decryption Failed" error is indicated. The specified number of padding bytes are removed from the end of the decrypted payload. 3.2.6. Decompression As indicated by the configured SPI, perform decompression of the plaintext. If it is invalid, then the datagram is discarded, and the "Decompression Failed" error is indicated. 3.2.7. Completion The IP Total/Payload Length is adjusted to reflect the length of the resulting payload, without the SPI, Sequence Number, Padding, Pad Length, Payload Type, and optional Authenticator. The IP Header(s) and the remaining portion of the payload are passed to the protocol processing routine specified by the Payload Type field. Simpson expires in six months [Page 11] DRAFT ESP2 July 1997 3.3. Error Procedures When an error is indicated by this specification, an ICMP error mes- sage of that type is transmitted [RFC-xxxx]. In addition, the implementation SHOULD record the event in a statis- tics counter, and SHOULD generate an audit log containing date and time, IP Source, IP Destination, IP Flow Label (when present), SPI, Sequence Number, and/or the entire contents of the discarded data- gram. Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing, and MUST allow a sys- tem administrator to enable or disable auditing for ESP. Additional events not explicitly called out in this specification MAY result in audit log entries. Operational Considerations This specification provides only a few manually configurable parame- ters: SPI Manually configured SPIs are limited in range to aid operations. Automated SPIs are pseudo-randomly distributed throughout the remaining 2**32 values. Default: 0 (none). Range: 256 to 65,535. SPI LifeTime (SPILT) Manually configured LifeTimes are generally measured in days. Automated LifeTimes are specified in seconds. Default: 32 days (2,764,800 seconds). Maximum: 182 days (15,724,800 seconds). Replay Window Some earlier implementations use pseudo-random values in the pre- sent Sequence Number field. This check must only be used with those peers that are known to have implemented this feature. Default: 0 (checking off). Range: 32 to 256. Pad Values New implementations use verifiable values. Some earlier Simpson expires in six months [Page 12] DRAFT ESP2 July 1997 implementations used random values. This check must only be used with those peers that are known to have implemented this feature. Also, some operations desire additional padding to inhibit traffic analysis. This feature can be combined with verifiable values to provide limited integrity checking. The value zero (0) indicates that no checking is done, and the range of padding values is defined by the default required for the cipher algorithm. Default: 0 (checking off). Range: 3 to 255, defined per cipher. Encryption Each cipher document will describe the keying material needed. Default: DES-CBC with derived IV. Compression Default: none. Authentication Each authenticator document will describe the keying material needed. Default: none. Each party configures a list of known SPIs and symmetric secret-keys. In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular SPI. For example, a party might allow FTP, but prohibit Telnet. Such consid- erations are outside the scope of this document. Simpson expires in six months [Page 13] DRAFT ESP2 July 1997 Security Considerations This specification is principly concerned with a security mechanism for use with IP. This mechanism is not a panacea, but it does pro- vide an important component useful in creating a secure internetwork environment. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever cryptographic algorithm that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implementations in all of the participat- ing systems. If any of these assumptions do not hold, then little or no real secu- rity will be provided to the user. Implementers are encouraged to use high assurance development techniques to develop all of the secu- rity relevant parts of their products. Note that it is possible, when some cryptographic algorithms are employed without an authentication mechanism, for a third party to alter the cleartext of a message, even though that party does not possess the key. It is important that applications requiring both confidentiality and authentication select transforms that prevents this. The padding bytes have a predictable value. They provide a small measure of tamper detection on their own block and the previous block in CBC mode. This makes it somewhat harder to perform appending attacks in the absence of other integrity protection. Also, this avoids a possible large covert channel (although the amount of padding itself could provide a covert channel), and aids in mechani- cal certification of the implementation. This small amount of poten- tial known plaintext does not create any problems for modern ciphers. This mechanism alone does not provide complete immunity from traffic analysis. Users seeking further protection from traffic analysis might consider the use of appropriate link encryption. These details are outside the scope of this specification. Simpson expires in six months [Page 14] DRAFT ESP2 July 1997 Acknowledgements This document benefited greatly from earlier work done by Randall Atkinson, Perry Metzger, William Simpson, and Phil Karn, for the SIP, SIPP, and IPv6 Working Groups. Many of the concepts here are derived from the swIPe security proto- col [IBK93a, IBK93b], or were influenced through community diffusion of knowledge regarding the US Government's SP3 security protocol specification [SDN.301], and the ISO/IEC's NLSP specification [ISO-11577]. Steve Bellovin, Steve Deering, Steve Kent, Dave Mihelcic, and Hilarie Orman provided useful critiques of earlier versions of this document. Contacts Comments about this document should be discussed on the ipsec@tis.com mailing list. Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Simpson expires in six months [Page 15]