idnits 2.17.1 draft-metzger-esp-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-24) 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. ** 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 232: '...ed. The failure SHOULD be recorded in...' RFC 2119 keyword, line 330: '...receiving system MUST ignore all routi...' 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 (January 1995) is 10692 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: 'TBD' is mentioned on line 95, but not defined == Unused Reference: '14' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 416, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93a' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11577' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAsa' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAah' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Metzger 2 Internet Draft W A Simpson 3 expires in six months January 1995 5 IPv4 Encapsulating Security Payload (4ESP) 6 draft-metzger-esp-00.txt 8 Status of this Memo 10 This document is a submission to the IP Security Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the ipsec@ans.net mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 29 Directories on: 31 ftp.is.co.za (Africa) 32 nic.nordu.net (Europe) 33 ds.internic.net (US East Coast) 34 ftp.isi.edu (US West Coast) 35 munnari.oz.au (Pacific Rim) 37 Abstract 39 This document describes a privacy mechanism for IPv4, encapsulating 40 transport headers within an opaque envelope. 42 1. Introduction 44 The Encapsulating Security Payload (ESP) seeks to provide integrity 45 and confidentiality to IP datagrams. It may also provide 46 authentication, depending on which algorithm and algorithm mode are 47 used. 49 Users desiring integrity and authentication without confidentiality 50 should use the Authentication Header (AH) instead of ESP. 52 This document assumes that the reader is familiar with the related 53 document "IPv4 Security Overview" [RAsa], which defines the overall 54 security plan for IPv4, and provides important background for this 55 specification. 57 1.1. Overview 59 The Encapsulating Security Payload (ESP) provides confidentiality and 60 integrity by encrypting the data to be protected. Depending on the 61 user's security requirements, only a transport-layer segment (such as 62 UDP or TCP) is encrypted, or the entire IP datagram may be encrypted 63 and tunneled to the destination. 65 In order for ESP to work properly without changing the entire 66 Internet infrastructure (particularly non-participating routers), the 67 payload is placed within a datagram having unencrypted IP headers. 68 The information in the unencrypted IP headers is used to route the 69 secure datagram. 71 Use of this specification will increase the protocol processing costs 72 in participating systems, and will also increase the communications 73 latency. The increased latency is primarily due to time required for 74 encryption and decryption of each datagram containing an 75 Encapsulating Security Payload. Encapsulating the protected data can 76 be very expensive to implement. 78 1.2. Key Management 80 Key management is an important part of the IP security architecture. 81 A scalable standard Internet key management protocol is needed to 82 make widespread use of ESP practical. 84 However, in order to facilitate early adoption, manual key management 85 is the only key management technique required by this specification. 87 The only coupling between key management and ESP is the Security 88 Association Identifier (SAID), which is described in more detail 89 later. This permits several different key management mechanisms to 90 be used. 92 More importantly, it permits the key management protocol to be 93 changed or corrected without unduly impacting the security protocol 94 implementations. Thus, key management is specified in a separate 95 specification [TBD]. 97 Nota Bene: It is intended that the key management mechanisms being 98 developed in other IETF Working Groups will be useful for both 99 IPv4 and IPv6. 101 1.3. Security Associations 103 The key management mechanism is used to negotiate a number of 104 parameters for each Security Association between the communicating 105 parties. This includes the key(s) used to encrypt and decrypt the 106 opaque portion of the ESP payload, the sensitivity level (such as 107 Secret or Unclassified) of the user data in the ESP payload, and the 108 particular transform to be used. 110 The key management implementation usually maintains a table 111 containing the several parameters for each current Security 112 Association. The ESP implementation needs to access that security 113 parameter table to determine how to process each datagram. 115 The Security Association Identifier (SAID) is assigned by the entity 116 controlling the Destination IP address of the Security Association. 117 The selection mechanism used for the SAID is implementation 118 dependent. 120 A given Destination is not necessarily in control of the 121 negotiation process. In the case of multicast groups, a single 122 node or cooperating subset of the multicast group may work on 123 behalf of the entire group to set up a Security Association. 125 A session between two nodes will normally have two SAID values (one 126 in each direction). The nodes use the combination of SAID and IP 127 Destination to distinguish the correct association. 129 Senders to a multicast group may share a common Security Association, 130 if all communications are authenticated using the same security 131 configuration parameters. In this case, the receiver only knows that 132 the message came from a node knowing the Security Association for the 133 group, and cannot authenticate which member of the group sent the 134 datagram when symmetric algorithms are in use. 136 Multicast groups may also use a separate Security Association value 137 for each Source. If each sender is keyed separately and asymmetric 138 algorithms are used, data origin authentication is also provided. 140 1.4. Transforms 142 Encryption and authentication algorithms, and the precise format of 143 opaque ESP data associated with them, are known as "transforms". It 144 is intended that ESP should be sufficiently general to permit the 145 specification of new transforms as new cryptographic algorithms are 146 developed. 148 Each SAID value indicates the encryption algorithm and mode used, the 149 block size (if any) of the encryption algorithm, the authentication 150 algorithm being used (if separate from the encryption algorithm), the 151 block size (if any) of the authentication algorithm, and the 152 presence/absence and size of a cryptographic synchronization or 153 initialization vector field. These transforms are described in 154 companion documents. 156 2. Payload Format 158 The Encapsulating Security Payload (ESP) may appear anywhere after 159 the IP header. The header immediately preceding the ESP header will 160 always contain the value in its Next Header (Protocol) field. 162 <-- Transparent (not encrypted) --> <-- Opaque --> 163 +-----------+-----------------+--------------+------------------+ 164 | IP Header | Other Headers | ESP Header | encrypted data | 165 +-----------+-----------------+--------------+------------------+ 167 The Encapsulating Security Payload has two components. 169 The transparent ESP header consists of the unencrypted field(s) of 170 the payload. The transparent field(s) of the unencrypted ESP header 171 inform the intended receiver how to properly decrypt and process the 172 encrypted data. 174 The opaque ESP component consists of encrypted data. The encrypted 175 data includes protected fields for the ESP transform, and also the 176 encapsulated IP datagram. 178 2.1. Header Fields 180 A more detailed diagram of the ESP Header follows: 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Security Association Identifier (SAID) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 ~ Transform Data ~ 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Security Association Identifier (SAID) 192 A value identifying the Security Association for this datagram. 193 If no Security Association has been established, the value of this 194 field is zero. 196 SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are 197 reserved for future use. 199 Transform Data 201 The length of this field is variable, but is always at least 32- 202 bits. 204 An implementation will normally use the SAID to determine the 205 field's size and use. It retains the same format for all 206 datagrams of any given SAID and IP Destination. 208 Refer to each Security Transform specification for more 209 information regarding the contents of this field. 211 3. Payload Processing 213 This chapter describes the steps taken when ESP is in use between two 214 communicating parties. There are two modes of use for ESP. 216 The first mode, which is herein called "IP-mode", encapsulates an 217 entire IP datagram inside ESP. 219 The second mode, which is herein called "Transport-Mode", 220 encapsulates a transport-layer segment (such as UDP or TCP) inside 221 ESP. 223 In either case, the sender first determines if a Security Association 224 has been established with the target receiver. If not, then the key 225 management mechanism is used to establish the SAID for this 226 communications session prior to the encryption. 228 If cleartext datagram If a SAID is received which is not valid for a 229 particular Destination, 231 then the datagram is discarded, and an appropriate ICMP message is 232 returned. The failure SHOULD be recorded in the system or audit log, 233 including the cleartext values for the SAID, date/time, Source, 234 Destination, and other identifying information. 236 Multicast is different from unicast only in the area of key 237 management. 239 3.1. IP-mode 241 The sender takes the entire original IP datagram, applies the 242 encryption algorithm using the appropriate key for the receiving 243 party, and encapsulates the result within an ESP header. Next, ESP 244 is sent as the final payload of a cleartext IP datagram. 246 This mode is used to send encrypted ICMP or IGMP messages. Such 247 messages are often specific to the IP addressing and routing 248 information. 250 If strict red/black separation is being enforced, then the 251 addressing and other information in the cleartext IP headers and 252 payloads might be different from the values contained in the (now 253 encrypted and encapsulated) original datagram. 255 The receiver processes the cleartext IP header and other intervening 256 headers (if any). It then decrypts the ESP using the session key 257 that has been established for this SAID. 259 The original datagram is extracted from the (now decrypted) ESP. 260 This datagram is then processed as if received normally. In the case 261 of a B1 or Compartmented Mode Workstation, additional mandatory 262 access controls are applied, as appropriate. 264 3.2. Transport-mode 266 The sender takes the original transport segment, applies the 267 encryption algorithm using the appropriate key for the receiving 268 party, and encapsulates the result within an ESP header. Next, ESP 269 is sent as the final payload of a cleartext IP datagram. 271 The receiver processes the cleartext IP header and other invervening 272 IP headers (if any), and temporarily stores pertinent information 273 (such as Source and Destination). It then decrypts the ESP using the 274 session key that has been established for this SAID. 276 The original transport header is extracted from the (now decrypted) 277 ESP. The information from the cleartext IP header and the extracted 278 transport header is jointly used to determine to which application 279 the data belongs. In the case of a B1 or Compartmented Mode 280 Workstation, additional mandatory access controls are applied, as 281 appropriate. 283 3.3. Authentication 285 Some Transforms provide authentication as well as encryption. When 286 such a mechanism is not in use, the Authentication Header [RAah] 287 might be used. 289 There are several different approaches, depending on which part of 290 the data is to be authenticated. The location of the Authentication 291 Header makes it clear which set of data is being authenticated. 293 In the first usage, the entire received datagram is authenticated, 294 including both the encrypted and unencrypted portions, while only the 295 data sent after the ESP Header is confidential. In this usage, the 296 sender first applies ESP to the data being protected. Next, any 297 intervening IP headers are added before the ESP header. Finally, the 298 Authentication Header is calculated over the resulting datagram 299 according to the normal method. 301 Upon receipt, the receiver first verifies the authenticity of the 302 entire datagram, using the normal Authentication Header process. If 303 authentication succeeds, decryption using the normal ESP process 304 occurs. If decryption is successful, the resulting data is passed to 305 the higher protocol layers. 307 If the authentication is to be applied only to the data protected by 308 ESP, and the protected data is an entire IP datagram, then the 309 Authentication Header is placed normally within that protected IP 310 datagram. 312 If the authentication is to be applied to less than an entire IP 313 datagram, then the Authentication Header is placed within the 314 encrypted payload, immediately after the ESP protected header, and 315 before any other header. 317 An Authentication Header may be present both preceding the ESP 318 header, and also as a header within the encrypted ESP envelope. In 319 such a case, the unencrypted Authentication Header is primarily used 320 to provide protection for the contents of the unencrypted IP headers, 321 and the encrypted Authentication Header is used to provide 322 authentication for the encapsulated datagram. 324 3.4. Other Headers 326 It is important that all routing information and other such internal 327 headers be included within the encrypted datagram, even if the same 328 information is in the unencrypted part of the datagram. 330 The receiving system MUST ignore all routing information in the 331 unencrypted portion of the received datagram, and strictly rely on 332 the routing information from the protected payload instead. If this 333 rule is not strictly adhered to, then the system will be vulnerable 334 to various kinds of attacks, including source routing attacks. 336 The original datagram may contain an explicit Sensitivity Label, but 337 the encrypted datagram need not include any Sensitivity Label. The 338 SAID indicates the Sensitivity Label for the encrypted datagram. 340 Security Considerations 342 This specification is principly concerned with a security mechanism 343 for use with IP. This mechanism is not a panacea, but it does 344 provide an important component useful in creating a secure 345 internetwork. 347 Users need to understand that the quality of the security provided by 348 this specification depends completely on the strength of whichever 349 encryption algorithm that has been implemented, the correctness of 350 that algorithm's implementation, the security of the key management 351 mechanism and its implementation, the strength of the key [CN94], and 352 upon the correctness of the ESP and IP implementations in all of the 353 participating systems. 355 If any of these assumptions do not hold, then little or no real 356 security will be provided to the user. Use of high assurance 357 development techniques is recommended for the Encapsulating Security 358 Payload. 360 Note that it is possible, when some cryptographic algorithms are 361 employed without an authentication mechanism, for a third party to 362 alter the cleartext of a message, even though that party does not 363 possess the key. It is important that applications requiring both 364 confidentiality and authentication select a transform that prevents 365 this. 367 This mechanism alone does not provide complete immunity from traffic 368 analysis. Users seeking further protection from traffic analysis 369 might consider the use of appropriate link encryption. These details 370 are outside the scope of this specification. 372 Acknowledgements 374 The original text of this specification was derived from work by Ran 375 Atkinson for the SIP, SIPP, and IPv6 Working Groups. 377 Many of the concepts here are derived from or were influenced by the 378 US Government's SP3 security protocol specification [SDN.301], the 379 ISO/IEC's NLSP specification [ISO-11577], and the proposed swIPe 380 security protocol [IBK93a, IBK93b]. 382 Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful 383 critiques of earlier versions of this draft. 385 References 387 [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: 388 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 389 253-280, July 1994. 391 [IBK93a] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP 392 Security Protocol", unpublished draft, 14 April 1993. 394 [IBK93b] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- 395 Layer Security for IP", Presentation at the Spring 1993 IETF 396 Meeting, Columbus, Ohio. 398 [ISO-11577] 399 ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 400 DIS 11577, International Standards Organisation, Geneva, 401 Switzerland, 29 November 1992. 403 [RAsa] Randall Atkinson, et alia, IPv6 Security Architecture, work 404 in progress. 406 [RAah] Randall Atkinson, IPv6 Authentication Header, work in 407 progress. 409 [SDN.301]SDNS Secure Data Network System, Security Protocol 3 (SP3), 410 Document SDN.301, Revision 1.5, 15 May 1989, as published in 411 NIST Publication NIST-IR-90-4250, February 1990. 413 [14] Bruce Schneier, "Applied Cryptography", John Wiley & Sons, 414 New York, NY, 1994. ISBN 0-471-59756-2 416 [15] Dan McDonald, "Security Extensions to the IPv6 Sockets API", 417 work in progress. 419 Author's Address 421 Questions about this memo can also be directed to: 423 Randall Atkinson 424 Information Technology Division 425 Naval Research Laboratory 426 Washington, 427 DC 20375-5320 428 USA 430 Telephone: (DSN) 354-8590 431 Fax: (DSN) 354-7942 432 434 Perry Metzger 435 Piermont Information Systems Inc. 436 160 Cabrini Blvd., Suite #2 437 New York, NY 10033 439 perry@piermont.com 441 William Allen Simpson 442 Daydreamer 443 Computer Systems Consulting Services 444 1384 Fontaine 445 Madison Heights, Michigan 48071 447 Bill.Simpson@um.cc.umich.edu 448 bsimpson@MorningStar.com 449 Table of Contents 451 1. Introduction .......................................... 1 452 1.1 Overview ........................................ 1 453 1.2 Key Management .................................. 1 454 1.3 Security Associations ........................... 2 455 1.4 Transforms ...................................... 3 457 2. Payload Format ........................................ 4 458 2.1 Header Fields ................................... 4 460 3. Payload Processing .................................... 5 461 3.1 IP-mode ......................................... 5 462 3.2 Transport-mode .................................. 6 463 3.3 Authentication .................................. 6 464 3.4 Other Headers ................................... 7 466 SECURITY CONSIDERATIONS ...................................... 8 468 ACKNOWLEDGEMENTS ............................................. 8 470 REFERENCES ................................................... 9 472 AUTHOR'S ADDRESS ............................................. 9