idnits 2.17.1 draft-ietf-ipsec-payload-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 105 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '... - MUST...' RFC 2119 keyword, line 118: '... - SHOULD...' RFC 2119 keyword, line 125: '... - MAY...' RFC 2119 keyword, line 194: '... [H96]. Any valid ESP transforms MUST provide confidentiality, integrity,...' RFC 2119 keyword, line 195: '...id ESP transform SHOULD also provide a...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 June 1996) is 10185 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'H96' is mentioned on line 194, but not defined == Unused Reference: 'Bel89' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'CERT95' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'Hin94' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'NIST77' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'NIST80' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'NIST81' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'NIST88' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'Sch94' is defined on line 537, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Atk95a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Atk95b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel95' -- Possible downref: Non-RFC (?) normative reference: ref. 'BS93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'CERT95' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIA' ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. 'GM93') -- No information found for draft-hinden-ipng-IP-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Hin94' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO92a' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO92b' ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') -- Possible downref: Non-RFC (?) normative reference: ref. 'Mat94' -- Possible downref: Non-RFC (?) normative reference: ref. 'MS95' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST77' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST80' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST81' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST88' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS89' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Randall Atkinson 3 Internet Draft cisco Systems 4 draft-ietf-ipsec-payload-00.txt 6 June 1996 6 IP Encapsulating Security Payload (ESP) 8 STATUS OF THIS MEMO 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of 6 months. 15 Internet Drafts may be updated, replaced, or obsoleted by other 16 documents at any time. It is not appropriate to use Internet Drafts as 17 reference material or to cite them other than as "work in progress". 19 This particular Internet Draft is a product of the IETF's IPng and 20 IPsec working groups. It is intended that a future version of this 21 draft be submitted to the IPng Area Directors and the IESG for 22 possible publication as a standards-track protocol. 24 0. ABSTRACT 26 This document describes the IP Encapsulating Security Payload (ESP). 27 ESP is a mechanism for providing integrity and confidentiality to IP 28 datagrams. In some circumstances it can also provide authentication 29 to IP datagrams. The mechanism works with both IPv4 and IPv6. 31 1. INTRODUCTION 33 ESP is designed to provide integrity, authentication, and confidentiality 34 to IP datagrams. ESP can also provide replay protection when used with 35 certain transforms. Non-repudiation and protection from traffic analysis 36 are not provided by ESP. The IP Authentication Header (AH) might provide 37 non-repudiation if used with certain authentication algorithms. [Atk95b] 38 The IP Authentication Header may be used in conjunction with ESP to provide 39 authentication. Users desiring integrity and authentication without 40 confidentiality should use the IP Authentication Header (AH) instead of 41 ESP. This document assumes that the reader is familiar with the related 42 document "IP Security Architecture", which defines the overall 43 Internet-layer security architecture for IPv4 and IPv6 and provides 44 important background for this specification. [Atk95a] 46 1.1 Overview 48 The IP Encapsulating Security Payload (ESP) seeks to provide 49 confidentiality and integrity by encrypting data to be protected and 50 placing the encrypted data in the data portion of the IP Encapsulating 51 Security Payload. Depending on the user's security requirements, this 52 mechanism may be used to encrypt either a transport-layer segment 53 (e.g. TCP, UDP, ICMP, IGMP) or an entire IP datagram. Encapsulating 54 the protected data is necessary to provide confidentiality for the 55 entire original datagram. 57 Use of this specification will increase the IP protocol processing 58 costs in participating systems and will also increase the 59 communications latency. The increased latency is primarily due to the 60 encryption and decryption required for each IP datagram containing an 61 Encapsulating Security Payload. 63 In Tunnel-mode ESP, the original IP datagram is placed in the encrypted 64 portion of the Encapsulating Security Payload and that entire ESP frame is 65 placed within a datagram having unencrypted IP headers. The information in 66 the unencrypted IP headers is used to route the secure datagram from origin 67 to destination. An unencrypted IP Routing Header might be included between 68 the IP Header and the Encapsulating Security Payload. The unencrypted 69 prepended IP header might have different information from that in the 70 encrypted encapsulated IP header, particularly if one or both of the ESP 71 tunnel endpoints is a security gateway that is not coincident with the 72 originator or final recipient of the protected IP datagram. 74 In Transport-mode ESP, the ESP header is inserted into the IP 75 datagram immediately prior to the transport-layer protocol header 76 (e.g. TCP, UDP, or ICMP). In this mode bandwidth is conserved because 77 there are no encrypted IP headers or IP options. 79 In the case of IP, an IP Authentication Header may be present as a 80 header of an unencrypted IP packet, as a header after the IP header 81 and before the ESP header in a Transport-mode ESP packet, and also as 82 a header within the encrypted portion of a Tunnel-mode ESP packet. 83 When AH is present both in the cleartext IP header and also inside a 84 Tunnel-mode ESP header of a single packet, the unencrypted IPv6 85 Authentication Header is primarily used to provide protection for the 86 contents of the unencrypted IP headers and the encrypted 87 Authentication Header is used to provide authentication only for the 88 encrypted IP packet. This is discussed in more detail later in this 89 document. 91 The Encapsulating Security Payload is structured a bit differently 93 than other IP payloads. The first component of the ESP payload 94 consist of the unencrypted field(s) of the payload. The second 95 component consists of encrypted data. The field(s) of the unencrypted 96 ESP header inform the intended receiver how to properly decrypt and 97 process the encrypted data. The encrypted data component includes 98 protected fields for the security protocol and also the encrypted 99 encapsulated IP datagram. 101 The concept of a "Security Association" is fundamental to ESP. It 102 is described in detail in the companion document "Security Architecture 103 for the Internet Protocol" which is incorporated here by 104 reference. [Atk95a] Implementors should read that document before 105 reading this one. 107 1.2 Requirements Terminology 109 In this document, the words that are used to define the significance 110 of each particular requirement are usually capitalised. These words 111 are: 113 - MUST 115 This word or the adjective "REQUIRED" means that the item is an 116 absolute requirement of the specification. 118 - SHOULD 120 This word or the adjective "RECOMMENDED" means that there might 121 exist valid reasons in particular circumstances to ignore this item, 122 but the full implications should be understood and the case carefully 123 weighed before taking a different course. 125 - MAY 127 This word or the adjective "OPTIONAL" means that this item is truly 128 optional. One vendor might choose to include the item because a 129 particular marketplace requires it or because it enhances the product, 130 for example; another vendor may omit the same item. 132 2. KEY MANAGEMENT 134 Key management is an important part of the IP security architecture. 135 However, a specific key management protocol is not included in this 136 specification because of a long history in the public literature of 137 subtle flaws in key management algorithms and protocols. IP tries to 138 decouple the key management mechanisms from the security protocol 139 mechanisms. The only coupling between the key management protocol and 140 the security protocol is with the Security Parameter Index (SPI), 141 which is described in more detail below. This decoupling permits 142 several different key management mechanisms to be used. More 143 importantly, it permits the key management protocol to be changed or 144 corrected without unduly impacting the security protocol 145 implementations. Thus, a key management protocol for IP is not 146 specified within this draft. The IP Security Architecture describes 147 key management in more detail and specifies the key management 148 requirements for IP. Those key management requirements are 149 incorporated here by reference. [Atk95a] 151 The key management mechanism is used to negotiate a number of 152 parameters for each security association, including not only the keys 153 but other information (e.g. the cryptographic algorithms and modes, 154 security classification level, if any) used by the communicating 155 parties. The key management protocol implementation usually creates 156 and maintains a logical table containing the several parameters for 157 each current security association. An ESP implementation normally 158 needs to read that security parameter table to determine how to 159 process each datagram containing an ESP (e.g. which algorithm/mode and 160 key to use). 162 3. ENCAPSULATING SECURITY PAYLOAD SYNTAX 164 The Encapsulating Security Payload (ESP) may appear anywhere after 165 the IP header and before the final transport-layer protocol. The 166 Internet Assigned Numbers Authority has assigned Protocol Number 50 to 167 ESP. [STD-2] The header immediately preceding an ESP header will 168 always contain the value 50 in its Next Header (IPv6) or Protocol 169 (IPv4) field. ESP consists of an unencrypted header followed by 170 encrypted data. The encrypted data includes both the protected ESP 171 header fields and the protected user data, which is either an entire 172 IP datagram or an upper-layer protocol frame (e.g. TCP or UDP). A 173 high-level diagram of a secure IP datagram follows. 175 |<-- Unencrypted -->|<---- Encrypted ------>| 176 +-------------+--------------------+------------+---------------------+ 177 | IP Header | Other IP Headers | ESP Header | encrypted data | 178 +-------------+--------------------+------------+---------------------+ 180 A more detailed diagram of the ESP Header follows below. 182 +-------------+--------------------+------------+---------------------+ 183 | Security Parameters Index (SPI), 32 bits | 184 +=============+====================+============+=====================+ 185 | Opaque Transform Data, variable length | 186 +-------------+--------------------+------------+---------------------+ 188 Encryption and authentication algorithms, and the precise format of the 189 Opaque Transform Data associated with them are known as "transforms". The 190 ESP format is designed to support new transforms in the future to support 191 new or additional cryptographic algorithms. The transforms are specified 192 by themselves rather than in the main body of this specification. The 193 mandatory transform for use with IP is defined in a separate document 194 [H96]. Any valid ESP transforms MUST provide confidentiality, integrity, 195 and authentication. A valid ESP transform SHOULD also provide a method for 196 replay protection. Other optional transforms exist in other separate 197 specifications and additional transforms might be defined in the future. 199 3.1 Fields of the Encapsulating Security Payload 201 The SPI is a 32-bit pseudo-random value identifying the security 202 association for this datagram. If no security association has been 203 established, the value of the SPI field shall be 0x00000000. An 204 SPI is similar to the SAID used in other security protocols. The 205 name has been changed because the semantics used here are not 206 exactly the same as those used in other security protocols. 208 The set of SPI values in the range 0x00000001 though 0x000000FF 209 are reserved to the Internet Assigned Numbers Authority (IANA) for 210 future use. A reserved SPI value will not normally be assigned by 211 IANA unless the use of that particular assigned SPI value is openly 212 specified in an RFC. 214 The SPI is the only mandatory transform-independent field. 215 Particular transforms may have other fields unique to the transform. 216 Transforms are not specified in this document. 218 3.2 Security Labeling with ESP 220 The encrypted IP datagram need not and does not normally contain any 221 explicit Security Label because the SPI indicates the sensitivity 222 level. This is an improvement over the current practices with IPv4 223 where an explicit Sensitivity Label is normally used with 224 Compartmented Mode Workstations and other systems requiring 225 Security Labels. [Ken91] [DIA] In some situations, users MAY choose 226 to carry explicit labels (for example, IPSO labels as defined by 227 RFC-1108 might be used with IPv4) in addition to using the implicit 228 labels provided by ESP. Explicit label options could be defined for 229 use with IPv6 (e.g. using the IPv6 End-to-End Options Header or the 230 IPv6 Hop-by-Hop Options Header). Implementations MAY support explicit 231 labels in addition to implicit labels, but implementations are not 232 required to support explicit labels. Implementations of ESP in 233 systems claiming to provide multi-level security MUST support implicit 234 labels. 236 4. ENCAPSULATING SECURITY PROTOCOL PROCESSING 237 This section describes the steps taken when ESP is in use between 238 two communicating parties. Multicast is different from unicast only 239 in the area of key management (See the definition of the SPI, above, 240 for more detail on this). There are two modes of use for ESP. The 241 first mode, which is called "Tunnel-mode", encapsulates an entire IP 242 datagram inside ESP. The second mode, which is called 243 "Transport-Mode", encapsulates a transport-layer (e.g. UDP, TCP) frame 244 inside ESP. The term "Transport-mode" must not be misconstrued as 245 restricting its use to TCP and UDP. For example, an ICMP message MAY 246 be sent either using the "Transport-mode" or the "Tunnel-mode" 247 depending upon circumstance. ESP processing occurs prior to IP 248 fragmentation on output and after IP reassembly on input. This 249 section describes protocol processing for each of these two modes. 251 4.1 ESP in Tunnel-mode 253 In Tunnel-mode ESP, the ESP header follows all of the end-to-end 254 headers (e.g. Authentication Header, if present in cleartext) and 255 immediately precedes an tunnelled IP datagram. 257 The sender takes the original IP datagram, encapsulates it into the 258 ESP, uses at least the sending userid and Destination Address as data 259 to locate the correct Security Association, and then applies the 260 appropriate encryption transform. If host-oriented keying is in use, 261 then all sending userids on a given system will have the same Security 262 Association for a given Destination Address. If no key has been 263 established, then the key management mechanism is used to establish an 264 encryption key for this communications session prior to the use of 265 ESP. The (now encrypted) ESP is then encapsulated in a cleartext IP 266 datagram as the last payload. If strict red/black separation is being 267 enforced, then the addressing and other information in the cleartext 268 IP headers and optional payloads MAY be different from the values 269 contained in the (now encrypted and encapsulated) original datagram. 271 The receiver strips off the cleartext IP header and cleartext 272 optional IP payloads (if any) and discards them. It then uses the 273 combination of Destination Address and SPI value to locate the 274 correct session key to use for this packet. It then decrypts 275 the ESP using the session key that was just located for this 276 packet. 278 If no valid Security Association exists for this session (for 279 example, the receiver has no key), the receiver MUST discard the 280 encrypted ESP and the failure MUST be recorded in the system log or 281 audit log. This system log or audit log entry SHOULD include the SPI 282 value, date/time, cleartext Sending Address, cleartext Destination 283 Address, and the cleartext Flow ID. The log entry MAY also include 284 other identifying data. The receiver might not wish to react by 285 immediately informing the sender of this failure because of the strong 286 potential for easy-to-exploit denial of service attacks. 288 If decryption succeeds, the original IP datagram is then removed 289 from the (now decrypted) ESP. This original IP datagram is then 290 processed as per the normal IP protocol specification. In the case of 291 a system claiming to provide multilevel security (for example, a B1 or 292 Compartmented Mode Workstation) additional appropriate mandatory 293 access controls MUST be applied based on the security level of the 294 receiving process and the security level associated with this Security 295 Association. If those mandatory access controls fail, then the packet 296 SHOULD be discarded and the failure SHOULD be logged using 297 implementation-specific procedures. 299 4.2 ESP in Transport-mode 301 In Transport-mode ESP, the ESP header follows the end-to-end headers 302 (e.g. Authentication Header) and immediately precedes a 303 transport-layer (e.g. UDP, TCP, ICMP) header. 305 The sender takes the original transport-layer (e.g. UDP, TCP, ICMP) 306 frame, encapsulates it into the ESP, uses at least the sending userid 307 and Destination Address to locate the appropriate Security 308 Association, and then applies the appropriate encryption transform. 309 If host-oriented keying is in use, then all sending userids on a given 310 system will have the same Security Association for a given Destination 311 Address. If no key has been established, then the key management 312 mechanism is used to establish a encryption key for this 313 communications session prior to the encryption. The (now encrypted) 314 ESP is then encapsulated as the last payload of a cleartext IP 315 datagram. 317 The receiver processes the cleartext IP header and cleartext 318 optional IP headers (if any) and temporarily stores pertinent 319 information (e.g. source and destination addresses, Flow ID, Routing 320 Header). It then decrypts the ESP using the session key that has been 321 established for this traffic, using the combination of the destination 322 address and the packet's Security Parameters Index (SPI) to locate 323 the correct key. 325 If no key exists for this session or the attempt to decrypt fails, 326 the encrypted ESP MUST be discarded and the failure MUST be recorded 327 in the system log or audit log. If such a failure occurs, the 328 recorded log data SHOULD include the SPI value, date/time received, 329 clear-text Sending Address, clear-text Destination Address, and the 330 Flow ID. The log data MAY also include other information about the 331 failed packet. If decryption does not work properly for some reason, 332 then the resulting data will not be parsable by the implementation's 333 protocol engine. Hence, failed decryption is generally detectable. 335 If decryption succeeds, the original transport-layer (e.g. UDP, TCP, 336 ICMP) frame is removed from the (now decrypted) ESP. The information 337 from the cleartext IP header and the now decrypted transport-layer 338 header is jointly used to determine which application the data should 339 be sent to. The data is then sent along to the appropriate 340 application as normally per IP protocol specification. In the case of 341 a system claiming to provide multilevel security (for example, a B1 or 342 Compartmented Mode Workstation), additional Mandatory Access Controls 343 MUST be applied based on the security level of the receiving process 344 and the security level of the received packet's Security Association. 346 4.3. Authentication 348 Some transforms provide authentication as well as confidentiality 349 and integrity. When such a transform is not used, then the 350 Authentication Header might be used in conjunction with the 351 Encapsulating Security Payload. There are two different approaches to 352 using the Authentication Header with ESP, depending on which data is 353 to be authenticated. The location of the Authentication Header makes 354 it clear which set of data is being authenticated. 356 In the first usage, the entire received datagram is authenticated, 357 including both the encrypted and unencrypted portions, while only the 358 data sent after the ESP Header is confidential. In this usage, the 359 sender first applies ESP to the data being protected. Then the other 360 plaintext IP headers are prepended to the ESP header and its now 361 encrypted data. Finally, the IP Authentication Header is calculated 362 over the resulting datagram according to the normal method. Upon 363 receipt, the receiver first verifies the authenticity of the entire 364 datagram using the normal IP Authentication Header process. Then if 365 authentication succeeds, decryption using the normal IP ESP process 366 occurs. If decryption is successful, then the resulting data is 367 passed up to the upper layer. 369 If the authentication process were to be applied only to the data 370 protected by Tunnel-mode ESP, then the IP Authentication Header would 371 be placed normally within that protected datagram. However, if one 372 were using Transport-mode ESP, then the IP Authentication Header would 373 be placed before the ESP header and would be calculated across the 374 entire IP datagram. 376 If the Authentication Header is encapsulated within a Tunnel-mode 377 ESP header, and both headers have specific security classification 378 levels associated with them, and the two security classification 379 levels are not identical, then an error has occurred. That error 380 SHOULD be recorded in the system log or audit log using the procedures 381 described previously. It is not necessarily an error for an 382 Authentication Header located outside of the ESP header to have a 383 different security classification level than the ESP header's 384 classification level. This might be valid because the cleartext IP 385 headers might have a different classification level after the data has 386 been encrypted using ESP. 388 5. CONFORMANCE REQUIREMENTS 390 Implementations that claim conformance or compliance with this 391 specification MUST fully implement the header described here, MUST support 392 manual key distribution with this header, MUST comply with all requirements 393 of the "Security Architecture for the Internet Protocol" [Atk95a], and MUST 394 support the use of DES CBC as specified in the companion document entitled 395 "The ESP DES-CBC Transform" [MS95]. An implementation MUST NOT reduce the 396 security provided on a particular session once that session has begun, 397 though it MAY increase the security provided. In particular, this means 398 that if a TCP connection has been established using ESP then an 399 implementation MUST continue to use ESP for the duration of that 400 connection. Implementors MAY also implement other ESP transforms. 401 Implementers should consult the most recent version of the "IAB Official 402 Standards" RFC for further guidance on the status of this document. 404 6. SECURITY CONSIDERATIONS 406 This entire draft discusses a security mechanism for use with IP. 407 This mechanism is not a panacea, but it does provide an important 408 component useful in creating a secure internetwork. 410 Cryptographic transforms for ESP which use a block-chaining 411 algorithm and lack a strong integrity mechanism are vulnerable to a 412 cut-and-paste attack described by Bellovin and should not be used 413 unless the Authentication Header is always present with packets using 414 that ESP transform. [Bel95] 416 Users need to understand that the quality of the security provided 417 by this specification depends completely on the strength of whichever 418 encryption algorithm has been implemented, the correctness of 419 that algorithm's implementation, upon the security of the key 420 management mechanism and its implementation, the strength of the key 421 [CN94][Sch94, p233] and upon the correctness of the ESP and IP 422 implementations in all of the participating systems. 424 If any of these assumptions do not hold, then little or no real 425 security will be provided to the user. Use of high assurance 426 development techniques is recommended for the IP Encapsulating 427 Security Payload. 429 Users seeking protection from traffic analysis might consider the 430 use of appropriate link encryption. Description and specification of 431 link encryption is outside the scope of this note. 433 If user-oriented keying is not in use, then the algorithm in use 434 should not be an algorithm vulnerable to any kind of Chosen Plaintext 435 attack. Chosen Plaintext attacks on DES are described in [BS93] and 436 [Mat94]. Use of user-oriented keying is recommended in order to 437 preclude any sort of Chosen Plaintext attack and to generally make 438 cryptanalysis more difficult. Implementations SHOULD support 439 user-oriented keying as is described in the IP Security 440 Architecture. [Atk95a] 442 ACKNOWLEDGEMENTS 444 This document benefited greatly from work done by Bill Simpson, Perry 445 Metzger, and Phil Karn to make general the approach originally defined 446 by the author for SIP, SIPP, and finally IPv6. 448 Many of the concepts here are derived from or were influenced by the 449 US Government's SP3 security protocol specification, the ISO/IEC's 450 NLSP specification, or from the proposed swIPe security 451 protocol. [SDNS89, ISO92a, IB93, IBK93, ISO92b] The use of DES for 452 confidentiality is closely modeled on the work done for the 453 SNMPv2. [GM93] Steve Bellovin, Steve Deering, Dave Mihelcic, and 454 Hilarie Orman provided solid critiques of early versions of this 455 draft. 457 REFERENCES 458 [Atk95a] Randall J. Atkinson, IP Security Architecture, RFC-xxx, 459 17 July 1995. 461 [Atk95b] Randall J. Atkinson, IP Authentication Header, RFC-xxx, 462 17 July 1995. 464 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol 465 Suite", ACM Computer Communications Review, Vol. 19, No. 2, 466 March 1989. 468 [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group 469 Meeting, Proceedings of the 32nd Internet Engineering Task 470 Force, March 1995, Internet Engineering Task Force, Danvers, MA. 472 [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the 473 Data Encryption Standard", Springer-Verlag, New York, NY, 1993. 475 [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: 476 Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, 477 July 1994. pp. 253-280 479 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 480 and Hijacked Terminal Connections", CA-95:01, January 1995. 481 Available via anonymous ftp from info.cert.org. 483 [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode 484 Workstation Specification", Technical Report DDS-2600-6243-87. 486 [GM93] James Galvin & Keith McCloghrie, Security Protocols for Version 2 487 of the Simple Network Management Protocol (SNMPv2), RFC-1446, 488 DDN Network Information Center, April 1993. 490 [Hin94] Robert Hinden (Editor), IP Specification, Internet Draft, 491 draft-hinden-ipng-IP-spec-00.txt, October 1994. 493 [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation 494 of Network-layer Security Under Unix", Proceedings of the USENIX 495 Security Symposium, Santa Clara, CA, October 1993. 497 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer 498 Security for IP", presentation at the Spring 1993 IETF Meeting, 499 Columbus, Ohio. 501 [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 502 DIS 11577, International Standards Organisation, Geneva, 503 Switzerland, 29 November 1992. 505 [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 506 DIS 11577, Section 13.4.1, page 33, International Standards 507 Organisation, Geneva, Switzerland, 29 November 1992. 509 [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol 510 (IPSO)", RFC-1108, DDN Network Information Center, November 1991. 512 [Mat94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", 513 Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994. 515 [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", 516 RFC-xxx, July 1995. 518 [NIST77] US National Bureau of Standards, "Data Encryption Standard", 519 Federal Information Processing Standard (FIPS) Publication 46, 520 January 1977. 522 [NIST80] US National Bureau of Standards, "DES Modes of Operation" 523 Federal Information Processing Standard (FIPS) Publication 81, 524 December 1980. 526 [NIST81] US National Bureau of Standards, "Guidelines for Implementing and 527 Using the Data Encryption Standard", Federal Information 528 Processing Standard (FIPS) Publication 74, April 1981. 530 [NIST88] US National Bureau of Standards, "Data Encryption Standard", 531 Federal Information Processing Standard (FIPS) Publication 46-1, 532 January 1988. 534 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 535 DDN Network Information Center, 20 October 1994. 537 [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, 538 New York, NY, 1994. ISBN 0-471-59756-2 540 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, 541 Document SDN.301, Revision 1.5, 15 May 1989, as published 542 in NIST Publication NIST-IR-90-4250, February 1990. 544 DISCLAIMER 546 The views and specification here are those of the author and are not 547 necessarily those of his employer. The Naval Research Laboratory has 548 not passed judgement on the merits, if any, of this work. The author 549 and his employer specifically disclaim responsibility for any problems 550 arising from correct or incorrect implementation or use of this 551 specification. 553 AUTHOR INFORMATION 555 Randall Atkinson 556 cisco Systems 557 170 West Tasman Drive 558 San Jose, CA 95134-1706 559 USA 561 Telephone: +1 (408) 526-4000