idnits 2.17.1 draft-ietf-ipsec-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-23) 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 77 instances of too long lines in the document, the longest one being 5 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 105: '... - MUST...' RFC 2119 keyword, line 110: '... - SHOULD...' RFC 2119 keyword, line 117: '... - MAY...' RFC 2119 keyword, line 215: '... [DIA] In some situations, users MAY choose to carry explicit labels...' RFC 2119 keyword, line 220: '... Implementations MAY support explicit ...' (19 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 (23 March 1995) is 10624 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) == Unused Reference: 'Bel89' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'CERT95' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'Hin94' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'NIST77' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'NIST80' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'NIST81' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'NIST88' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'Sch94' is defined on line 498, but no explicit reference was found in the text -- No information found for draft-ietf-ipng-sec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Atk95a' -- No information found for draft-ietf-ipng-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Atk95b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- 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. 'Mit94' -- 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 (~~), 9 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Randall Atkinson 3 Internet Draft Naval Research Laboratory 4 draft-ietf-ipsec-esp-00.txt 23 March 1995 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. This 30 document also describes the mandatory DES CBC encryption transform for 31 use with ESP. 33 1. INTRODUCTION 35 ESP is a mechanism for providing integrity and confidentiality to IP 36 datagrams. It may also provide authentication, depending on which 37 algorithm and algorithm mode are used. Non-repudiation and protection 38 from traffic analysis are not provided by ESP. The IP Authentication 39 Header (AH) might provide non-repudiation if used with certain 40 authentication algorithms. [Atk95b] The IP Authentication Header may 41 be used in conjunction with ESP to provide authentication. Users 42 desiring integrity and authentication without confidentiality should 43 use the IP Authentication Header (AH) instead of ESP. This document 44 assumes that the reader is familiar with the related document "IP 45 Security Architecture", which defines the overall Internet-layer 46 security architecture for IPv4 and IPv6 and provides important 47 background for this specification. [Atk95a] 49 1.1 Overview 51 The IP Encapsulating Security Payload (ESP) seeks to provide 52 confidentiality and integrity by encrypting data to be protected and 53 placing the encrypted data in the data portion of the IP Encapsulating 54 Security Payload. Depending on the user's security requirements, this 55 mechanism may be used to encrypt either a transport-layer segment 56 (e.g. TCP, UDP, ICMP, IGMP) or an entire IP datagram. Encapsulating 57 the protected data is necessary to provide confidentiality for the 58 entire original datagram. 60 Use of this specification will increase the IP protocol processing 61 costs in participating systems and will also increase the 62 communications latency. The increased latency is primarily due to the 63 encryption and decryption required for each IP datagram containing an 64 Encapsulating Security Payload. 66 In order for ESP to work properly without changing the entire 67 Internet infrastructure (e.g. non-participating systems), the original 68 IP datagram is placed in the encrypted portion of the Encapsulating 69 Security Payload and that entire ESP frame is placed within an 70 datagram having unencrypted IP headers. The information in the 71 unencrypted IP headers is used to route the secure datagram from 72 origin to destination. An unencrypted IP Routing Header might be 73 included between the IP Header and the Encapsulating Security Payload. 75 In the case of IP, an IP Authentication Header may be present both 76 as an header of the unencrypted IP packet and also as a header within 77 the encrypted IP packet. In such a case, the unencrypted IPv6 78 Authentication Header is primarily used to provide protection for the 79 contents of the unencrypted IP headers and the encrypted 80 Authentication Header is used to provide authentication for the 81 encrypted IP packet. This is discussed in more detail later in this 82 document. 84 The encapsulating security payload is structured a bit differently 85 than other IP payloads. The first component of the ESP payload 86 consist of the unencrypted field(s) of the payload. The second 87 component consists of encrypted data. The field(s) of the unencrypted 88 ESP header inform the intended receiver how to properly decrypt and 89 process the encrypted data. The encrypted data component includes 90 protected fields for the security protocol and also the encrypted 91 encapsulated IP datagram. 93 The concept of a "Security Association" is fundamental to ESP. It 94 is described in detail in the compaion document "Security Architecture 95 for the Internet Protocol" which is incorporated here by 96 reference. [Atk95a] Implementers should read that document before 97 reading this one. 99 1.2 Requirements Terminology 101 In this document, the words that are used to define the significance 102 of each particular requirement are usually capitalised. These words 103 are: 105 - MUST 107 This word or the adjective "REQUIRED" means that the item is an 108 absolute requirement of the specification. 110 - SHOULD 112 This word or the adjective "RECOMMENDED" means that there might 113 exist valid reasons in particular circumstances to ignore this item, 114 but the full implications should be understood and the case carefully 115 weighed before taking a different course. 117 - MAY 119 This word or the adjective "OPTIONAL" means that this item is truly 120 optional. One vendor might choose to include the item because a 121 particular marketplace requires it or because it enhances the product, 122 for example; another vendor may omit the same item. 124 2. KEY MANAGEMENT 126 Key management is an important part of the IP security 127 architecture. However, a specific key management protocol is not 128 included in this specification because of a long history in the public 129 literature of subtle flaws in key management algorithms and protocols. 130 IP tries to decouple the key management mechanisms from the security 131 protocol mechanisms. The only coupling between the key management 132 protocol and the security protocol is with the Security Association 133 Identifier (SPI), which is described in more detail below. This 134 decoupling permits several different key management mechanisms to be 135 used. More importantly, it permits the key management protocol to be 136 changed or corrected without unduly impacting the security protocol 137 implementations. Thus, a key management protocol for IP is not 138 specifed within this draft. The IP Security Architecture describes 139 key management in more detail and specifies the key management 140 requirements for IP. Those key management requirements are 141 incorporated here by reference. [Atk95a] 143 The key management mechanism is used to negotiate a number of 144 parameters for each security association, including not only the keys 145 but other information (e.g. the cryptographic algorithms and modes, 146 security classification level if any) used by the communicating 147 parties. The key management protocol implementation usually creates 148 and maintains a logical table containing the several parameters for 149 each current security association. An ESP implementation normally 150 needs to read that security parameter table to determine how to 151 process each datagram containing an ESP (e.g. which algorithm/mode and 152 key to use). 154 3. ENCAPSULATING SECURITY PAYLOAD SYNTAX 156 The Encapsulating Security Payload (ESP) may appear anywhere after 157 the IP header. The Internet Assigned Numbers Authority has assigned 158 Protocol Number 50 to IP ESP. [STD-2] The header immediately 159 preceding an ESP header will always contain the value 50 in its Next 160 Header field. ESP consists of an unencrypted header followed by 161 encrypted data. The encrypted data includes both the protected ESP 162 header fields and the protected user data, which is either an entire 163 IP datagram or an upper-layer protocol frame (e.g. TCP or UDP). A 164 high-level diagram of a secure IP datagram follows. 166 |<-- Unencrypted -->|<---- Encrypted ------>| 167 +-------------+--------------------+------------+---------------------+ 168 | IP Header | Other IP Headers | ESP Header | encrypted data | 169 +-------------+--------------------+------------+---------------------+ 171 A more detailed diagram of the ESP Header follows below. 173 +-------------+--------------------+------------+---------------------+ 174 | Security Association Identifier (SPI), 32 bits | 175 +=============+====================+============+=====================+ 176 | Opaque Transform Data, variable length | 177 +-------------+--------------------+------------+---------------------+ 179 Encryption and authentication algorithms, and the precise format of 180 the Opaque Transform Data associated with them are known as 181 "transforms". The ESP format is designed to support new transforms in 182 the future to support new or additional cryptographic algorithms. The 183 transforms are specified by themselves rather than in the main body of 184 this specification. The mandatory transform for use with IP is 185 defined in Appendix A of this specification. Other optional 186 transforms exist in separate specifications and additional transforms 187 might be defined in the future. 189 3.1 Fields of the Encapsulating Security Payload 191 This is a 32-bit pseudo-random value identifying the security 192 association for this datagram. If no security association has been 193 established, the value of this field shall be 0x00000000. An 194 SPI is similar to the SAID used in other security protocols. The 195 name has been changed because the semantics used here are not 196 exactly the same as those used in other security protocols. 198 The set of SPI values in the range 0x00000001 though 0x000000FF 199 are reserved to the Internet Assigned Numbers Authority (IANA) for 200 future use. A reserved SPI value will not normally be assigned by 201 IANA unless the use of that particular assigned SPI value is openly 202 specified in an RFC. 204 The SPI is the only mandatory transform-independent field. 205 Particular transforms may have other fields unique to the transform. 206 Transforms are not specified in this document. 208 3.2 Security Labeling with ESP 210 The encrypted IP datagram need not and does not normally contain any 211 explicit Security Label because the SPI indicates the sensitivity 212 label. This is an improvement over the current practices with IPv4 213 where an explicit Security Label is normally used with Compartmented 214 Mode Workstations and other systems requiring Security Labels. [Ken91] 215 [DIA] In some situations, users MAY choose to carry explicit labels 216 (for example, IPSO labels as defined by RFC-1108 might be used with 217 IPv4) in addition to using the implicit labels provided by ESP. 218 Explicit label options could be defined for use with IPv6 (e.g. using 219 the IPv6 End-to-End Options Header or the IPv6 Hop-by-Hop Options 220 Header). Implementations MAY support explicit labels in addition to 221 implicit labels, but implementations are not required to support 222 explicit labels. Implementations of ESP in systems claiming to 223 provide multi-level security MUST support implicit labels. 225 4. ENCAPSULATING SECURITY PROTOCOL PROCESSING 226 This section describes the steps taken when ESP is in use between 227 two communicating parties. Multicast is different from unicast only 228 in the area of key management (See the definition of the SPI, above, 229 for more detail on this). There are two modes of use for ESP. The 230 first mode, which is called "Tunnel-mode", encapsulates an entire IP 231 datagram inside ESP. The second mode, which is called 232 "Transport-Mode", encapsulates a transport-layer (e.g. UDP or TCP) 233 frame inside ESP. The term "Transport-mode" must not be misconstrued 234 as restricting its use to TCP and UDP. For example, an ICMP 235 message MAY be sent either using the "Transport-mode" or the 236 "IP-mode" depending upon circumstance. This section describes 237 protocol processing for each of these two modes. 239 4.1 ESP in Tunnel-mode 241 The sender takes the original IP datagram, encapsulates it into the 242 ESP, locates the correct Security Association using the sending userid 243 and the Destination Address, and then applies the appropriate 244 encryption transform. If host-oriented keying is in use, then all 245 sending userids on a given system will have the same Security 246 Association for a given Destination Address. If no key has been 247 established, then the key management mechanism is used to establish a 248 encryption key for this communications session prior to the use of 249 ESP. The (now encrypted) ESP is then encapsulated in a cleartext IP 250 datagram as the last payload. If strict red/black separation is being 251 enforced, then the addressing and other information in the cleartext 252 IP headers and optional payloads MAY be different from the values 253 contained in the (now encrypted and encapsulated) original datagram. 255 The receiver strips off the cleartext IP header and cleartext 256 optional IP payloads (if any) and discards them. It then uses the 257 combination of Destination Address and SPI value to locate the 258 correct decryption key to use for this packet. Then, it decrypts 259 the ESP using the session key that has been established for this 260 traffic. 262 If no valid Security Association exists for this session (for 263 example, the receiver has no key), the receiver MUST discard the 264 encrypted ESP and the failure MUST be recorded in the system log or 265 audit log. This system log or audit log entry SHOULD include the SPI 266 value, date/time, clear-text Sending Address, clear-text Destination 267 Address, and the clear-text Flow ID. The log entry MAY also include 268 other identifying data. The receiver might not wish to react by 269 immediately informing the sender of this failure because of the strong 270 potential for easy-to-exploit denial of service attacks. 272 If decryption succeeds, the original IP datagram is then removed 273 from the (now decrypted) ESP. This original IP datagram is then 274 processed as per the normal IP protocol specification. In the case of 275 system claiming to provide multilevel security (for example, a B1 or 276 Compartmented Mode Workstation) additional appropriate mandatory 277 access controls MUST be applied based on the security level of the 278 receiving process and the security level associated with this Security 279 Association. If those mandatory access controls fail, then the packet 280 SHOULD be discarded and the failure SHOULD be logged using 281 implementation-specific procedures. 283 4.2 ESP in Transport-mode 285 The sender takes the original UDP or TCP or ICMP frame, encapsulates 286 it into the ESP, locates the correct Security Association using the 287 sending userid and Destination Address, and then applies the 288 appropriate encryption transform. If host-oriented keying is in use, 289 then all sending userids on a given system will have the same Security 290 Association for a given Destination Address. If no key has been 291 established, then the key management mechanism is used to establish a 292 encryption key for this communications session prior to the 293 encryption. The (now encrypted) ESP is then encapsulated as the last 294 payload of a cleartext IP datagram. 296 The receiver processes the cleartext IP header and cleartext 297 optional IP headers (if any) and temporarily stores pertinent 298 information (e.g. source and destination addresses, Flow ID, Routing 299 Header). It then decrypts the ESP using the session key that has been 300 established for this traffic, using the combination of the destination 301 address and the packet's Security Association Identifier (SPI) to 302 locate the correct key. 304 If no key exists for this session or the attempt to decrypt fails, 305 the encrypted ESP MUST be discarded and the failure MUST be recorded 306 in the system log or audit log. If such a failure occurs, the 307 recorded log data SHOULD include the SPI value, date/time received, 308 clear-text Sending Address, clear-text Destination Address, and the 309 Flow ID. The log data MAY also include other information about the 310 failed packet. 312 If decryption succeeds, the original UDP or TCP frame is removed 313 from the (now decrypted) ESP. The information from the cleartext IP 314 header and the now decrypted UDP or TCP header is jointly used to 315 determine which application the data should be sent to. The data is 316 then sent along to the appropriate application as normally per IP 317 protocol specification. In the case of a system claiming to provide 318 multilevel security (for example, a B1 or Compartmented Mode 319 Workstation), additional Mandatory Access Controls MUST be applied 320 based on the security level of the receiving process and the security 321 level of the received packet's Security Association. 323 4.3. Authentication 325 Some transforms provide authentication as well as confidentiality 326 and integrity. When such a transform is not used, then the 327 Authentication Header might be used in conjunction with the 328 Encapsulating Security Payload. There are two different approaches to 329 using the Authentication Header with ESP, depending on which data is 330 to be authenticated. The location of the Authentication Header makes 331 it clear which set of data is being authenticated. 333 In the first usage, the entire received datagram is authenticated, 334 including both the encrypted and unencrypted portions, while only the 335 data sent after the ESP Header is confidential. In this usage, the 336 sender first applies ESP to the data being protected. Then the other 337 plaintext IP headers are prepended to the ESP header and its now 338 encrypted data. Finally, the IP Authentication Header is calculated 339 over the resulting datagram according to the normal method. Upon 340 receipt, the receiver first verifies the authenticity of the entire 341 datagram using the normal IP Authentication Header process. Then if 342 authentication succeeds, decryption using the normal IP ESP process 343 occurs. If decryption is successful, then the resulting data is 344 passed up to the upper layer. 346 If the authentication process were to be applied only to the data 347 protected by IP ESP and the protected data were an entire IP 348 datagram, then the IP Authentication Header would be placed normally 349 within that protected datagram. However, if the protected data were 350 less than an entire IP datagram, then the IP Authentication Header 351 would be placed within the encrypted payload immediately after the ESP 352 protected header and before any other header. 354 If the Authentication Header is encapsulated within the ESP header, 355 and both headers have specific security classification levels 356 associated with them, and the two security classification levels are 357 not identical, then an error has occurred. That error SHOULD be 358 recorded in the system log or audit log using the procedures described 359 previously. It is not necessarily an error for an Authentication 360 Header located outside of the ESP header to have a different security 361 classification level than the ESP header's classification level. This 362 might be valid because the cleartext IP headers might have a different 363 classification level when the data has been encrypted using ESP. 365 5. CONFORMANCE REQUIREMENTS 366 Implementations that claim conformance or compliance with this 367 specification MUST fully implement the header described here, MUST 368 support manual key distribution with this header, MUST comply with all 369 requirements of the "Security Architecture for the Internet Protocol" 370 [Atk95a], and MUST support the use of DES CBC as specified in the 371 companion document entitled "The ESP DES-CBC Transform" [MS95]. 372 Implementers MAY also implement other ESP transforms. Implementers 373 should consult the most recent version of the "IAB Official Standards" 374 RFC for further guidance on the status of this document. 376 6. SECURITY CONSIDERATIONS 378 This entire draft discusses a security mechanism for use with IP. 379 This mechanism is not a panacea, but it does provide an important 380 component useful in creating a secure internetwork. 382 Users need to understand that the quality of the security provided 383 by this specification depends completely on the strength of whichever 384 encryption algorithm that has been implemented, the correctness of 385 that algorithm's implementation, upon the security of the key 386 management mechanism and its implementation, the strength of the key 387 [CN94][Sch94, p233] and upon the correctness of the ESP and IP 388 implementations in all of the participating systems. 390 If any of these assumptions do not hold, then little or no real 391 security will be provided to the user. Use of high assurance 392 development techniques is recommended for the IP Encapsulating 393 Security Payload. 395 Users seeking protection from traffic analysis might consider the 396 use of appropriate link encryption. Description and specification of 397 link encryption is outside the scope of this note. 399 If user-oriented keying is not in use, then the algorithm in use 400 should not be an algorithm vulnerable to any kind of Chosen Plaintext 401 attack. Chosen Plaintext attacks on DES are described in [BS93] and 402 [Mit94]. Use of user-oriented keying is recommended in order to 403 preclude any sort of Chosen Plaintext attack and to generally make 404 cryptanalysis more difficult. Implementations MUST support 405 user-oriented keying as is described in the IP Security 406 Architecture. [Atk95a] 408 ACKNOWLEDGEMENTS 409 This document benefited greatly from work done by Bill Simpson, Perry 410 Metzger, and Phil Karn to make general the approach originally defined 411 by the author for SIP, SIPP, and finally IPv6. 413 Many of the concepts here are derived from or were influenced by the 414 US Government's SP3 security protocol specification, the ISO/IEC's 415 NLSP specification, or from the proposed swIPe security 416 protocol. [SDNS89, ISO92a, IB93, IBK93, ISO92b] The use of DES for 417 confidentiality is closely modeled on the work done for the 418 SNMPv2. [GM93] Steve Bellovin, Steve Deering, Dave Mihelcic, and 419 Hilarie Orman provided solid critiques of early versions of this 420 draft. 422 REFERENCES 423 [Atk95a] Randall J. Atkinson, IP Security Architecture, Internet Draft, 424 draft-ietf-ipng-sec-01.txt, 16 March 1995. 426 [Atk95b] Randall J. Atkinson, IP Authentication Header, Internet Draft, 427 draft-ietf-ipng-auth-01.txt, 16 March 1995. 429 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol 430 Suite", ACM Computer Communications Review, Vol. 19, No. 2, 431 March 1989. 433 [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the 434 Data Encryption Standard", Springer-Verlag, New York, NY, 1993. 436 [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: 437 Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, 438 July 1994. pp. 253-280 440 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 441 and Hijacked Terminal Connections", CA-95:01, January 1995. 442 Available via anonymous ftp from info.cert.org. 444 [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode 445 Workstation Specification", Technical Report DDS-2600-6243-87. 447 [GM93] James Galvin & Keith McCloghrie, Security Protocols for Version 2 448 of the Simple Network Management Protocol (SNMPv2), RFC-1446, 449 DDN Network Information Center, April 1993. 451 [Hin94] Robert Hinden (Editor), IP Specification, Internet Draft, 452 draft-hinden-ipng-IP-spec-00.txt, October 1994. 454 [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation 455 of Network-layer Security Under Unix", Proceedings of the USENIX 456 Security Symposium, Santa Clara, CA, October 1993. 458 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer 459 Security for IP", presentation at the Spring 1993 IETF Meeting, 460 Columbus, Ohio. 462 [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 463 DIS 11577, International Standards Organisation, Geneva, 464 Switzerland, 29 November 1992. 466 [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 467 DIS 11577, Section 13.4.1, page 33, International Standards 468 Organisation, Geneva, Switzerland, 29 November 1992. 470 [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol 471 (IPSO)", RFC-1108, DDN Network Information Center, November 1991. 473 [Mit94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", 474 Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994. 476 [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", 477 Work in Progress, March 1995. 479 [NIST77] US National Bureau of Standards, "Data Encryption Standard", 480 Federal Information Processing Standard (FIPS) Publication 46, 481 January 1977. 483 [NIST80] US National Bureau of Standards, "DES Modes of Operation" 484 Federal Information Processing Standard (FIPS) Publication 81, 485 December 1980. 487 [NIST81] US National Bureau of Standards, "Guidelines for Implementing and 488 Using the Data Encryption Standard", Federal Information 489 Processing Standard (FIPS) Publication 74, April 1981. 491 [NIST88] US National Bureau of Standards, "Data Encryption Standard", 492 Federal Information Processing Standard (FIPS) Publication 46-1, 493 January 1988. 495 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 496 DDN Network Information Center, 20 October 1994. 498 [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, 499 New York, NY, 1994. ISBN 0-471-59756-2 501 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, 502 Document SDN.301, Revision 1.5, 15 May 1989, as published 503 in NIST Publication NIST-IR-90-4250, February 1990. 505 DISCLAIMER 507 The views and specification here are those of the author and are not 508 necessarily those of his employer. The Naval Research Laboratory has 509 not passed judgement on the merits, if any, of this work. The author 510 and his employer specifically disclaim responsibility for any problems 511 arising from correct or incorrect implementation or use of this 512 specification. 514 AUTHOR INFORMATION 516 Randall Atkinson 517 Information Technology Division 518 Naval Research Laboratory 519 Washington, DC 20375-5320 520 USA 522 Telephone: (DSN) 354-8590 523 Fax: (DSN) 354-7942