idnits 2.17.1 draft-ietf-ipsec-arch-sec-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 376 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 163 instances of too long lines in the document, the longest one being 7 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 115: '... - MUST...' RFC 2119 keyword, line 119: '... - SHOULD...' RFC 2119 keyword, line 125: '... - MAY...' RFC 2119 keyword, line 207: '... implementations MUST support AH and M...' RFC 2119 keyword, line 214: '...gateway implementation MUST be capable...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 335 has weird spacing: '... The way ...' == Line 336 has weird spacing: '...nted in a...' == Line 337 has weird spacing: '... host or a...' == Line 338 has weird spacing: '...ion are the ...' == Line 339 has weird spacing: '... the sender...' == (371 more instances...) -- 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 (10 November 1996) is 10027 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: 'Kent78' is mentioned on line 102, but not defined == Missing Reference: 'Atk95a' is mentioned on line 439, but not defined == Missing Reference: 'Atk95b' is mentioned on line 422, but not defined == Missing Reference: 'Kent91' is mentioned on line 157, but not defined == Missing Reference: 'BCCH' is mentioned on line 846, but not defined == Unused Reference: 'Atk96a' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'BCCH94' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'DH76' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'DH95' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'ISO' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'IB93' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'IBK93' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'Ken78' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'Ken93' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'KB93' is defined on line 1085, but no explicit reference was found in the text == Unused Reference: 'Sch94' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'SDNS' is defined on line 1109, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Atk96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Atk96b' ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. 'BCCH94') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel95' -- Possible downref: Non-RFC (?) normative reference: ref. 'BL73' -- Possible downref: Non-RFC (?) normative reference: ref. 'CERT95' -- Possible downref: Non-RFC (?) normative reference: ref. 'CB94' -- Possible downref: Non-RFC (?) normative reference: ref. 'CG96' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD85' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD87' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' ** Obsolete normative reference: RFC 1883 (ref. 'DH95') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'EK96' ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. 'GM93') ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'HA94') -- Possible downref: Non-RFC (?) normative reference: ref. 'Hugh96' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken78' ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'Ken93') ** Obsolete normative reference: RFC 1510 (ref. 'KB93') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'OG96' -- Possible downref: Non-RFC (?) normative reference: ref. 'OTA94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZDESZ93' Summary: 21 errors (**), 0 flaws (~~), 24 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Randall Atkinson 2 Internet Draft cisco Systems 3 draft-ietf-ipsec-arch-sec-01.txt 10 November 1996 4 Expire in six months 6 Security Architecture for the Internet Protocol 8 STATUS OF THIS MEMO 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of 6 16 months. Internet Drafts may be updated, replaced, or obsoleted by other 17 documents at any time. It is not appropriate to use Internet Drafts as 18 reference material or to cite them other than as "work in progress". 20 This particular Internet Draft is a product of the IETF's IP Security 21 (IPsec) working group. It is intended that a future version of this draft 22 be submitted to the IESG for publication as a Draft Standard RFC. Comments 23 about this draft may be sent to the author or to the IPsec WG mailing list 24 . 26 1. INTRODUCTION 28 This memo describes the security protocols for IP version 4 (IPv4) 29 and IP version 6 (IPv6) and the services that they provide. Each security 30 protocol is specified in a separate document. This document also describes 31 key management requirements for systems implementing these security 32 protocols. This document is not an overall Security Architecture for the 33 Internet; it addresses only IP-layer security. 35 1.1 Technical Definitions 37 This section provides a few basic definitions that are applicable 38 to this document. Other documents provide more definitions and background 39 information. [VK83, HA94] 41 Authentication (of Data Origin) 42 A security property that ensures that the origin of received data 43 is, in fact, the claimed sender. Usually bundled with integrity services, 44 especially connectionless integrity. 46 Integrity (Connectionless) 47 A security property that ensures data is transmitted from source to 48 destination without undetected alteration. If the order of 49 transmitted data also is ensured, the service is termed 50 connection-oriented integrity. The term anti-replay refers to a 51 minimal `qform of connection-oriented integrity designed to detect and 52 reject duplicated or very old data units. 54 Confidentiality 55 A security property that ensures that communicated data is 56 disclosed to intended recipients, but is not disclosed to other, 57 unauthorized parties. Traffic flow confidentiality extends this service to 58 externally visible characteristics of communication, e.g., source and 59 destination identifiers, message length, or frequency of communication. 60 (See also traffic analysis, below.) 62 Encryption 63 A mechanism commonly used to provide confidentiality. 65 Non-repudiation 66 A security property that ensures that a participant in a 67 communication cannot later deny having participated in the communication. 68 This property may apply to either the sender or the recipient of 69 communccated data, or both. 71 SPI 72 Acronym for "Security Parameters Index." The combination of an SPI 73 and a destination address uniquely identifies a simplex security 74 association (SA, see below). The SPI is carried in IPsec protocols to 75 select the set of parameters bound to an SA. An SPI has only local 76 significance, defined by the creator of the SA; thus an SPI is generally 77 viewed as an opaque bit string. However, the creator of an SA may choose 78 to interpret the bits in an SPI to facilitate local processing. 80 Security Association (SA) 81 A simplex (uni-directional) logical connection, created for 82 security purposes. All traffic traversing an SA is subjected to the same 83 security processing at the transmitter and receiver. In IPsec, an SA is a 84 network layer abstraction enforced through the use of AH or ESP. 86 Security Gateway 87 A system that acts as the communications interface between 88 untrusted external, networks and internal (trusted) hosts and subnetworks. 90 The internal subnets and hosts served by a security gateway are presumed to 91 be trusted by virtue of sharing a common, local, security administration. 92 (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway 93 is a point at which AH and/or ESP is implemented in order to serve a set of 94 internal hosts, providing security services for these hosts when they 95 communicate with external hosts also employing IPsec (either directly or 96 via another security gateway). 98 Traffic Analysis 99 The analysis of network traffic flow for the purpose of deducing 100 information that is useful to an adversary. Examples of such information 101 are frequency of transmission, the identities of the conversing parties, 102 sizes of packets, flow Identifiers, etc. [Kent78] 104 Trusted Subnetwork 105 A subnetwork containing hosts and routers that trust each other not 106 to engage in active or passive attacks and trust that the underlying 107 communications channel (e.g., an Ethernet) isn't being attacked. 109 1.2 Requirements Terminology 111 In this document, the words that are used to define the 112 significance of each particular requirement are usually capitalised. These 113 words are: 115 - MUST 116 This word or the adjective "REQUIRED" means that implementation of 117 the item is an absolute requirement of the specification. 119 - SHOULD 120 This word or the adjective "RECOMMENDED" means that there might 121 exist valid reasons in particular circumstances to not implement this item, 122 but the full implications should be understood and the case carefully 123 weighed before taking a different course. 125 - MAY 126 This word or the adjective "OPTIONAL" means that this item is truly 127 optional to implement. One vendor might choose to include the item because 128 a particular marketplace requires it or because it enhances the product, 129 for example; another vendor may omit the same item. 131 1.3 Basic IPsec features 133 Two specific headers used to provide security services in IPv4 and 134 IPv6: the "IP Authentication Header (AH)" [Atk95a] and the "IP 135 Encapsulating Security Payload (ESP)" [Atk95b] header. There are a number 136 of ways in which these IP security mechanisms may be employed, in large 137 part because AH and ESP may be used independently of one another, in 138 combination with one another, or in an interated (nested) fashion. This 139 section describes the basic features of both protocols and typical uses of 140 these protocols. The next section defines the minimum header processing 141 configurations that all compliant IPsec implementations must support. 142 (Additional configurations may be supported at the discretion of the 143 implementor.) Thus the configuration examples in this and the next section 144 are not exhaustive. 146 The IP Authentication Header (AH) can be used to provide 147 connectionless integrity and data origin authentication for IP datagrams, 148 and optionally to provide anti-replay integrity. This last, optional 149 service may be selected when a security association is established. This 150 header protects an entire IP datagram, including all immutable fields in 151 the IP header. AH does not provide confidentiality; thus implementations 152 of AH may be widely deployed, even in countries where controls on 153 encryption would preclude deployment of technology that also offered 154 confidentiality. This header should be used whenever the integrity and 155 authenticity of the IP header, as well as the associted upper layer 156 protocols, must be ensured. For example, AH can be used to bind a 157 sensitivity label (e.g., IPSO [Kent91]) to an IP datagram. 159 The Encapsulating Security Payload (ESP) can be used to provide 160 confidentiality, data origin authentication, connectionless integrity, 161 anti-replay integrity, and limited traffic flow confidentiality. The set 162 of services provided depends on options selected at the time of security 163 association establishment and the implementation placement. 164 Confidentiality may be selected independent of all other services. Data 165 origin authentication and connectionless integrity are joint services, 166 independent of confidentiality. Anti-replay may be selected only if data 167 origin authentication and connectionless integrity are selected, but is 168 independent of confidentiality. Traffic flow confidentiality depends on 169 confidentiality, and requires selection of tunnel mode (see below). 171 Unlike AH, ESP provides security only for the protocols encapsulated by 172 it, not the protocol that carries it. Perhaps the most obvious use of ESP 173 is to provide security services for upper layer protocols such as TCP, 174 without affording protection to the IP header that carries the these 175 protocols. Because ESP is an encapsulation protocol, it may be employed 176 recursively, to create nested security associations. For example, one 177 ESP-protected SA might extend between a host and a security gateway, and a 178 second, nested ESP-protected SA might extend from the same host through the 179 security gateway to a host behind the gateway. 181 Two modes of ESP are defined: transport mode and tunnel mode. In 182 transport mode, ESP encapsulates any transport layer protocol defined for 183 carriage in the TCP/IP suite, e.g., TCP, UDP. This is the simplest mode 184 for use between a pair of hosts implementing ESP. In tunnel model, the 185 protocol encapsulated by ESP is usually IP but could also be another 186 network-layer protocol (e.g. IPX). Tunnel mode is always used by security 187 gateways for all packets not originating on the gateway, to facilitate 188 operation in multi-homed environments, especially in the face of possible 189 fragmentation of ESP-protected packets. Tunnel mode can be used to create 190 virtual private networks between sites protected by security gateways 191 implementing ESP. 193 Both AH and ESP can provide security services between a pair of 194 communicating hosts, or between a pair of communicating security gateways 195 or between a security gateway and a host. Depending on the choice of 196 algorithms, AH and ESP also may support multicast communication, e.g., 197 among a set of hosts or security gateways or combinations thereof. When a 198 security gateway provides services for hosts on a trusted subnet, the 199 security gateway is responsible for establishing and managing security 200 associations on behalf of the trusted hosts it serves. The security 201 gateway also is responsible for providing security services between the 202 gateway itself and correspondant external systems (hosts or security 203 gateways) through the implementation of AH and ESP. 205 1.4 Minimal Essential Support 207 All IPsec-compliant implementations MUST support AH and MUST 208 support ESP in both transport and tunnel modes. The requirement to support 209 tunnel-mode is imposed to ensure interoperability between host and security 210 gateway implementations of ESP. The requirement to support transport-mode 211 ensures interoperability with other hosts using transport-mode and can 212 permit some reduction in security overhead. 214 A compliant host or security gateway implementation MUST be capable 215 of creating and accepting security associations that employ either AH or 216 ESP. A compliant host or security gateway SHOULD also be capable of 217 creating pairs of AH and ESP security associations. A compliant host 218 implementation also MUST also support a second (nested) ESP security 219 association, in transport mode, above a tunnel mode ESP security 220 association. 222 The following sequences of combinations of AH and ESP, each 223 represented by a separate security association, must be supported by an 224 IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport), 225 AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and 226 ESP(tunnel)-ESP(transport). 228 The following sequences of combinations of AH and ESP must be 229 supported by a compliant IPsec security gateway: AH, ESP (tunnel), and 230 AH-ESP(tunnel). Note that transport-mode ESP security associations may be 231 employed across a security gateway, terminating at hosts behind the 232 gateway. The gateway does not process these SAs; they are passed through 233 transparently, and hence there is no required "support" in the gateway for 234 these header combinations. 236 A security gateway which receives a datagram containing a 237 recognised sensitivity label, for example IPSO [Ken91], from a trusted host 238 MUST take that label's value into consideration when creating/selecting an 239 Security Association for use with AH between the gateway and the external 240 destination. In such an environment, a gateway which receives a IP packet 241 containing the IP Encapsulating Security Payload (ESP) should add 242 appropriate authentication, including implicit (i.e. contained in the 243 Security Association used) or explicit label information (e.g. IPSO), for 244 the decrypted packet that it forwards to the trusted host that is the 245 ultimate destination. The IP Authentication Header should always be used 246 on packets containing explicit sensitivity labels to ensure end-to-end 247 label integrity. In environments using security gateways, those gateways 248 MUST perform address-based IP packet filtering on unauthenticated packets 249 purporting to be from a system known to be using IP security. 251 A gateway which receives a datagram containing a recognised sensitivity 252 label from a trusted host should take that label's value into consideration 253 when creating/selecting a Security Association for use with ESP between the 254 gateway and the external destination. In such an environment, a gateway 255 which receives a IP packet containing the ESP should appropriately label 256 the decrypted packet that it forwards to the trusted host that is the 257 ultimate destination. IP security should always be used on packets 258 containing explicit sensitivity labels in a manner to ensure end-to-end 259 label integrity. 261 Routing headers for which integrity has not been cryptographically 262 protected SHOULD be ignored by the receiver. If this rule is not strictly 263 adhered to, then the system will be vulnerable to various kinds of attacks, 264 including source routing attacks. [Bel89][CB94][CERT95] 266 1.5 Security Association Management 268 The concept of a "Security Association" is fundamental to both the 269 IP Encapsulating Security Payload and the IP Authentication Header. The 270 combination of a given Security Parameter Index (SPI) and Destination 271 Address uniquely identifies a particular "Security Association". An 272 implementation of the Authentication Header or the Encapsulating Security 273 Payload MUST support this concept of a Security Association. 275 A single IPsec Security Association is a simplex (unidirectional) 276 connection with which either AH or ESP (but not both) is employed. If both 277 AH and ESP protection is to be applied to a traffic stream, then two (or 278 more) security associations are created to control processing of the 279 traffic stream. 281 A compliant implementation of IPsec Security Association MUST 283 support the following management parameters for each SA; other parameters 284 MAY also be included at the discretion of the implementor: 286 - Authentication algorithm and mode being used for AH or ESP. 287 [REQUIRED for all implementations]. 288 - Key(s) used with the above authentication algorithm 289 [REQUIRED for all implementations]. 290 - Encryption algorithm and mode used with ESP. 291 [REQUIRED for ESP implementations] 292 - Key(s) used with the above encryption algorithm. 293 [REQUIRED for ESP implementations] 294 - Presence/absence and size of a cryptographic synchronisation or 295 initialisation vector field for the encryption algorithm. 296 [REQUIRED for ESP implementations] 297 - Authentication key crypto period (fixed future time or duration). 298 [REQUIRED for all implementations]. 299 - Encryption key crypto period (fixed future tie or duration) 300 [REQUIRED for ESP implementations] 301 - Lifetime of this Security Association 302 [REQUIRED for all implementations] 303 - Destination IP Address of the Security Association; this may be 304 a wildcard address if more than one desitnation system shares the 305 same Security Association (behind a security gateway) 306 [REQUIRED for all implementations] 307 - Source IP Address(es) of the Security Association; this might be 308 a wildcard address if more than one sending system shares the 309 same Security Association with the destination 310 [REQUIRED for all implementations] 311 - Proxy IP Address of the Security Association; this contains 312 the IP address of the security gateway that provides security 313 services on behalf of the source IP address when IPsec is 314 not in use end-to-end from source to destination. 315 [REQUIRED for Security Gateways; 316 RECOMMENDED for all other implementations] 317 - Replay Protection information, including whether it is in use, 318 information on the window size for the sequence numbers, etc. 319 [REQUIRED for all implementations] 320 - Sensitivity level of the protected data (e.g., in IPSO terms) 321 [REQUIRED for all systems claiming to provide multi-level 322 security, RECOMMENDED for all other systems] 323 - Next Protocol (from IP header) as an optional SA selector 324 input for outbound traffic 325 [RECOMMENDED for all implementations] 326 - Source and/or Destination TCP/UDP Ports as an optional SA 327 selector for outbound traffic 328 [RECOMMENDED for all implementations] 329 - Identity of the source of the Security Association 330 [RECOMMENDED for all implementations] 332 - Identity of the destination of the Security Association] 333 [RECOMMENDED for all implementations] 335 The way in which security associations are matched to offered 336 (outbound) traffic varies based on whether IPsec is implemented in a 337 host or a security gateway, and on the granularity of SA management 338 selected. At a host, the inputs to SA selection are the userid of 339 the sender, the Destination Address (perhaps including the next 340 protocol field and source and/or destination port fields and 341 source/destination identities) is used to select the appropriate 342 Security Association for outbound traffic. For a multi-level secure 343 host, the senstivity of the traffic, e.g., as expressed in a security 344 label, also is an input to the SA selection. A security gateway 345 generally does not have access to userid information and thus IPsec 346 implementations in such devices are not required to select SAs for 347 outbound traffic on that basis. Since a security gateway typically 348 serves a number of hosts, the Source Address (perhaps including the 349 next protocol field and source and/or destination port fields) is an 350 input to the SA selection. The Destination Address address also is 351 an input, and when in a multi-level secure network context a traffic 352 sensitivity label is a REQUIRED additional input. 354 Processing for received (inbound) IPsec traffic is much simpler. 355 The receiving host uses the combination of the SPI and the 356 Destination Address to distinguish the correct association. Hence, 357 an IPsec implementation will always be able to use the SPI in 358 combination with the Destination Address to determine the security 359 association with which the traffic is associated. When a formerly 360 valid Security Association is terminated, the destination system(s) 361 SHOULD NOT immediately reuse that SPI and instead SHOULD let that SPI 362 value become stale before reusing it for some other Security 363 Association. 365 As noted above, an IPsec Security Association is unidirectional. 366 Hence, to secure typical, bi-directional communications between two 367 hosts (or security gateways), two Security Associations (one in each 368 direction) will be required. The Destination Address may be a 369 unicast address, an IPv4 broadcast address, or a multicast group 370 address. 372 The receiver-orientation of the Security Association implies 373 that, in the case of unicast traffic, the destination system will 374 normally select the SPI value. By having the destination select the 375 SPI value, there is no potential for manually configured Security 376 Associations that conflict with automatically configured (e.g. via a 377 key management protocol) Security Associations. For multicast 378 traffic, there are multiple destination systems but a single 379 destination multicast group, so some system or person will need to 380 select SPIs on behalf of that multicast group and then communicate 381 the information to all of the legitimate members of that multicast 382 group via mechanisms not defined here. 384 Multiple senders to a multicast group SHOULD use a single 385 Security Association (and hence Security Parameter Index) for all 386 traffic to that group when a symmetric cryptographic algorithm is in 387 use. In that case, the receiver only knows that the message came 388 from a system knowing the security association data for that 389 multicast group. A receiver cannot generally authenticate which 390 system sent the multicast traffic when symmetric algorithms (e.g. 391 DES, IDEA) are in use. Multicast traffic SHOULD use a separate 392 Security Association for each sender to the multicast group when an 393 asymmetric cryptographic algorithm is in use. In this last case, the 394 receiver can know the specific system that originated the message. 396 2. DESIGN OBJECTIVES 398 This section describes some of the design objectives of this 399 security architecture and its component mechanisms. The primary 400 objective of this work is to ensure that IPv4 and IPv6 will have 401 solid cryptographic security mechanisms available to users who desire 402 security. 404 These mechanisms are designed to avoid adverse impacts on 405 Internet users who do not employ these security mechanisms for their 406 traffic. These mechanisms are intended to be algorithm-independent 407 so that the cryptographic algorithms can be altered without affecting 408 the other parts of the implementation. These security mechanisms 409 should be useful in enforcing a variety of security policies. 411 Standard default algorithms (Keyed HMAC MD5, Keyed HMAC SHA, 412 DES- CBC) are specified to ensure interoperability in the global 413 Internet. The selected default algorithms are widely used in other 414 contexts. 416 3. IP-LAYER SECURITY MECHANISMS 418 There are two cryptographic security mechanisms for IP. The 419 first is the Authentication Header which provides integrity and 420 authentication without confidentiality. [Atk95a] The second is the 421 Encapsulating Security Payload which always provides confidentiality, 422 and usually provides integrity and authentication. [Atk95b] The two 423 IP security mechanisms are normally used separately. When both 424 confidentiality and authentication are needed, a combined ESP 425 transform should be used instead of using AH with ESP. 427 These IP-layer mechanisms do not provide complete security 428 against all traffic analysis attacks, though the use of ESP between 429 security gateways can provide partial traffic flow protection. 430 However, there are several techniques outside the scope of this 431 specification (e.g. bulk link encryption) that might be used to 432 provide more comprehensive protection against traffic analysis. 433 [VK83] 435 3.1 AUTHENTICATION HEADER 437 The IP Authentication Header is designed to provide 438 authentication, integrity, and replay protection to IP datagrams. 439 [Atk95a] It does this by computing a cryptographic authentication 440 function over the IP datagram and using one or more authentication 441 keys in the computation. The authentication algorithm may be either 442 symmetric or asymmetric. The sender computes the authentication data 443 prior to sending the authenticated IP packet and places the 444 authentication data inside the Authentication Data. Fragmentation 445 occurs after the Authentication Header processing for outbound 446 packets and reassembly occurs prior to Authentication Header 447 processing for inbound packets. The receiver verifies the 448 correctness of the authentication data upon reception. 450 Certain fields of the outer IP header that may change in transit 451 are zeroed for the authentication calculation. For IPv4, these 452 fields are: 454 Type of Service (TOS) 455 Time To Live (TTL) 456 Checksum 457 Offset 458 Flags 460 Also, IPv4 options are zeroed for the authentication 461 calculation, except for the IP Security Option BSO and ESO (RFC-1038, 462 RFC-1108) and the undocumented non-standard CIPSO (IPv4 Option number 463 134) option, which are included and are not zeroed. 465 For IPv6, the "IP Version", "Type of Service", "Flow Label", and 466 "Hop Limit" fields of the outermost IPv6 header are zeroed for the 467 authentication calculation. IPv6 options contain a bit that 468 indicates whether the option might change during transit. Options 469 that might change during transit are zeroed for the authentication 470 calculation and all others are included in the authentication 471 calculation. See the IPv6 specifications for more information. 473 Non-repudiation is not normally provided with the Authentication 474 Header. Confidentiality and traffic analysis protection are not 475 provided by the Authentication Header. Replay Protection is normally 476 provided by the Authentication Header, though a user might choose not 477 to use it. 479 Use of the Authentication Header will increase the IP protocol 480 processing costs in participating systems and will also increase the 481 communications latency. The increased latency is primarily due to 482 the calculation of the authentication data by the sender and the 483 calculation and comparison of the authentication data by each 484 receiver for each IP datagram containing an Authentication Header 485 (AH). 487 The Authentication Header provides much stronger security than 488 exists in most of the current Internet and should not affect 489 exportability or significantly increase implementation cost. While 490 the Authentication Header might be implemented by a security gateway 491 on behalf of hosts on a trusted network behind that security gateway, 492 this mode of operation is not encouraged. Instead, whenever possible 493 the Authentication Header should be used from origin to final 494 destination so that end-to-end protections are provided. 496 All IPv6-capable nodes and all IPv4 systems claiming to 497 implement the Authentication Header MUST implement the standards- 498 track mandatory-to- implement AH transforms. As of this writing 499 these are HMAC MD5 [OG96] and HMAC SHA [CG96], but implementers 500 should consult the most recent edition of the "Internet Official 501 Protocol Standards" [STD-1] for current guidance. An implementation 502 MAY support other authentication algorithms in addition to the 503 mandatory transforms. 505 3.2 ENCAPSULATING SECURITY PAYLOAD 507 The IP Encapsulating Security Payload (ESP) is designed to 508 provide integrity, authentication, and confidentiality to IP 509 datagrams. [Atk96b] ESP can also provide replay protection when used 510 with certain transforms. ESP encapsulates either an entire IP 511 datagram or only the upper-layer protocol (e.g. TCP, UDP, ICMP) data 512 inside the ESP, applies integrity and authentication protections, and 513 encrypts the data. If tunnel-mode is in use, a new cleartext IP 514 header is prepended to the now encrypted Encapsulating Security 515 Payload. In tunnel-mode, the cleartext IP header is used to carry 516 the protected data through the internetwork. 518 3.2.1 Description of the ESP Modes 520 There are two modes within ESP. The first mode, which is known 521 as Tunnel-mode, encapsulates an entire IP datagram within the 522 ESP header. The second mode, which is known as Transport- 523 mode, encapsulates an upper-layer protocol (for example UDP or TCP) 524 inside ESP and then prepends a cleartext IP header. 526 3.2.2 Usage of ESP 528 ESP works between hosts, between a host and a security gateway, 529 or between security gateways. This support for security gateways 530 permits trustworthy networks behind a security gateway to omit 531 encryption and thereby avoid the performance and monetary costs of 532 encryption, while still providing confidentiality for traffic 533 transiting untrustworthy network segments. When both hosts 534 directly implement ESP and there is no intervening security gateway, 535 then they may use the Transport- mode (where only the upper layer 536 protocol data (e.g. TCP or UDP) is encrypted and there is no 537 encrypted IP header). This mode reduces both the bandwidth 538 consumed and the protocol processing costs for users that don't need 539 to keep the entire IP datagram confidential. ESP works with both 540 unicast and multicast traffic. 542 3.2.3 Performance Impacts of ESP 544 The encapsulating security approach used by ESP can noticeably 545 impact network performance in participating systems, but use of ESP 546 should not adversely impact gateways or other intermediate systems 547 that are not participating in the particular ESP association. 548 Protocol processing in participating systems will be more complex 549 when encapsulating security is used, requiring both more time and 550 more processing power. Use of encryption will also increase the 551 communications latency. The increased latency is primarily due to 552 the encryption and decryption required for each IP datagram 553 containing an Encapsulating Security Payload. The precise cost of 554 ESP will vary with the specifics of the implementation, including the 555 encryption algorithm, key size, and other factors. Hardware 556 implementations of the encryption algorithm are recommended when high 557 throughput is desired. 559 For interoperability throughout the worldwide Internet, all 560 conforming implementations of the IP Encapsulating Security Payload 561 MUST also implement the standard mandatory ESP transform. As of this 562 writing, that is the Combined ESP transform with DES-CBC, HMAC MD5, 563 and Replay Protection. [Hugh96] Implementers should consult the most 564 recent "IAB Official Protocols" RFC for current information on the 565 mandatory to implement ESP transform(s). Other confidentiality 566 algorithms and modes may also be implemented in addition to this 567 mandatory algorithm and mode. Export and use of encryption are 568 regulated in some countries. [OTA94] 570 3.3 COMBINING SECURITY MECHANISMS 572 A node normally does not apply both ESP and AH to the same IP 573 datagram. If confidentiality is not required, then AH should be 574 used. If confidentiality is required, then ESP should be used. In 575 some circumstances a security gateway might apply ESP (or AH) to a 576 packet before forwarding that packet because a secure tunnel has been 577 configured in that security gateway. Hence, IP packets containing 578 both ESP and AH are not strictly prohibited. 580 3.4 OTHER SECURITY MECHANISMS 582 Protection from traffic analysis is not provided by any of the 583 security mechanisms described above. It is unclear whether 584 meaningful protection from traffic analysis can be provided 585 economically at the Internet Layer and it appears that few Internet 586 users are concerned about traffic analysis. One traditional method 587 for protection against traffic analysis is the use of bulk link 588 encryption. Another technique is to send false traffic in order to 589 increase the noise in the data provided by traffic analysis. 590 Reference [VK83] discusses traffic analysis issues in more detail. 592 4. SECURITY ASSOCIATION MANAGEMENT 594 The Security Management protocol that will be used with IP layer 595 security is not specified in this document. However, because the 596 security management protocol is coupled to AH and ESP only via the 597 Security Parameters Index (SPI), we can meaningfully define AH and 598 ESP without having to fully specify how security management is 599 performed. We envision that several security management systems will 600 be usable with these specifications, including manual key 601 configuration. 603 Support for key management methods where the key management data 604 is carried in-line within the IP layer is not a design objective for 605 these IP-layer security mechanisms. Instead these IP-layer security 606 mechanisms will primarily use key management methods where the key 607 management data will be carried by an upper layer protocol, such as 608 UDP or TCP, on some specific port number or where the key management 609 data will be distributed manually. 611 This design permits clear decoupling of the key management 612 mechanism from the other security mechanisms, and thereby permits one 613 to substitute new and improved key management methods without having 614 to modify the implementations of the other security mechanisms. This 615 separation of mechanism is clearly wise given the long history of 616 subtle flaws in published key management protocols. [NS78, NS81] What 617 follows in this section is a brief discussion of a few alternative 618 approaches to key management. Mutually consenting systems may 619 additionally use other key management approaches by private prior 620 agreement. 622 4.1 Manual Key Distribution 624 The simplest form of key management is manual key management, 625 where a person manually configures each system with its own key and 626 also with the keys of other communicating systems. This is quite 627 practical in small, static environments but does not scale. It is 628 not a viable medium-term or long-term approach, but might be 629 appropriate and useful in many environments in the near-term. For 630 example, within a small LAN it is entirely practical to manually 631 configure keys for each system. Within a single administrative 632 domain it is practical to configure keys for each router so that the 633 routing data can be protected and to reduce the risk of an intruder 634 breaking into a router. Another case is where an organisation has an 635 encrypting firewall between the internal network and the Internet at 636 each of its sites and it connects two or more sites via the Internet. 637 In this case, the security gateway might selectively encrypt traffic 638 for other sites within the organisation using a manually configured 639 key, while not encrypting traffic for other destinations. It also 640 might be appropriate when only selected communications need to be 641 secured. 643 4.2 Requirements for Key Management Protocols 645 Widespread deployment and use of IP security requires an 646 Internet-standard scalable key management protocol. This protocol 647 should not be limited to supporting IP security. This protocol 648 should be compatible with the IETF's DNS Security work and should 649 include the ability to obtain bootstrapping information (e.g. keys, 650 addresses) from the Secure DNS as a mandatory-to-implement feature. 651 signed host keys to the Domain Name System [EK96] The DNS keys enable 652 the originating party to authenticate key management messages with 653 the other key management party using an asymmetric algorithm. A 654 standards-track key management protocol for use with IP Security MUST 655 provide the property of "Perfect Forward Secrecy" as a mandatory-to- 656 implement feature. Further, any standards-track key management 657 protocol MUST permit the secure negotiation or secure identification 658 of all of the Security Association attributes [as defined above] to 659 all parties of that Security Association. 661 4.4 Keying Approaches for IP 663 There are several keying approaches for IP. The first approach, 664 called host-oriented keying, has all users on host 1 share the same 665 key for use on traffic destined for all users on host 2. The second 666 approach, called user-oriented keying, lets user A on host 1 have one 667 or more unique session keys for its traffic destined for host 2; such 668 session keys are not shared with other users on host1. For example, 669 user A's ftp session might use a different key than user A's telnet 670 session. In systems claiming to provide multi-level security, user A 671 will typically have at least one key per sensitivity level in use 672 (e.g. one key for UNCLASSIFIED traffic, a second key for SECRET 673 traffic, and a third key for TOP SECRET traffic). Similarly, with 674 user-oriented keying one might use separate keys for information sent 675 to a multicast group and control messages sent to the same multicast 676 group. A third approach, called session-unique keying, has a single 677 key being assigned to a given IP address, upper-layer protocol, and 678 port number triple. 680 In many cases, a single computer system will have at least two 681 mutually suspicious users A and B that do not trust each other. When 682 host-oriented keying is used and mutually suspicious users exist, it 683 is sometimes possible for user A to determine the host-oriented key 684 via well known methods, such as a Chosen Plaintext attack. Once user 685 A has improperly obtained the key in use, user A can then either read 686 user B's encrypted traffic or forge traffic from user B. When user- 687 oriented keying is used, certain kinds of attack from one user onto 688 another user's traffic are not possible. 690 IP Security is intended to be able to provide Authentication, 691 Integrity, and Confidentiality for applications operating on 692 connected end systems when appropriate algorithms are in use. 693 Integrity and Confidentiality can be provided by host-oriented keying 694 when appropriate dynamic key management techniques and appropriate 695 algorithms are in use. However, authentication of principals using 696 applications on end-systems requires that processes running 697 applications be able to request and use their own Security 698 Associations. In this manner, applications can make use of key 699 distribution facilities that provide authentication. 701 Hence, support for session-unique keying MUST be present in all 702 IP Security implementations, as is described in the "IPsec Key 703 Management Requirements" section below. Support for other styles MAY 704 also be implemented. 706 4.5 Multicast Key Distribution 708 Multicast key distribution is an active research area in the 709 published literature as of this writing. For multicast groups having 710 relatively few members, manual key distribution or multiple use of 711 existing unicast key distribution algorithms such as modified Diffie- 712 Hellman appears feasible. For very large groups, new scalable 713 techniques will be needed. In-line key management systems that rely 714 on pre-distributed master keys and then have serious scaling issues 715 that make them questionable for multicast traffic. 717 4.6 IPsec Key Management Requirements 719 This section defines key management requirements for all IPv6 720 implementations and for those IPv4 implementations that implement the 721 IP Authentication Header, the IP Encapsulating Security Payload, or 722 both. It applies equally to the IP Authentication Header and the IP 723 Encapsulating Security Payload. 725 All such implementations MUST support manual configuration of 726 Security Associations, including all of the attributes described in 727 the Security Association definition section of this document, having 728 variable SPI values within the non-reserved range. An implementation 729 that only supports a fixed SPI value is NOT conforming or compliant. 731 All IPv6 IP Security implementations MUST implement 732 ISAKMP/Oakley. All IPv4 IP Security implementations SHOULD implement 733 ISAKMP/Oakley. Other key management protocols MAY also be 734 implemented. [Sch96] 736 Implementations MAY also support other methods of configuring 737 Security Associations. 739 Given two endpoints, it MUST be possible to have more than one 740 concurrent Security Association for communications between them. 741 Implementations on multi-user hosts having at least discretionary 742 access controls MUST support either user granularity (i.e. "user- 743 oriented") Security Associations or session-unique Security 744 Associations. 746 All such implementations MUST permit the configuration of host- 747 oriented keying. 749 A device that encrypts or authenticates IP packets originated by 750 other systems, for example a dedicated IP encryptor or an security 751 gateway, cannot generally provide user-oriented keying for traffic 752 originating on other systems. Such systems MUST support session- 753 unique key selection based on source address, destination address, 754 upper-layer protocol, source port (if any), and destination port (if 755 any). Such systems MAY additionally implement support for user- 756 oriented keying for traffic originating on other systems. 758 The method by which keys are configured on a particular system 759 is implementation-defined. A flat file containing security 760 association identifiers and the security parameters, including the 761 key(s), is an example of one possible method for manual key 762 distribution. An IP Security implementation MUST take reasonable 763 steps to protect the keys and other security association information 764 from unauthorised examination or modification because all of the 765 security lies in the keys. 767 5. USAGE 769 This section describes the possible use of the security 770 mechanisms provided by IP in several different environments and 771 applications in order to give the implementer and user a better idea 772 of how these mechanisms can be used to reduce security risks. 774 5.1 USE WITH FIREWALLS 776 Firewalls are not uncommon in the current Internet. [CB94] 777 While many dislike their presence because they restrict connectivity, 778 they are unlikely to disappear in the near future. Both of these IP 779 mechanisms can be used to increase the security provided by 780 firewalls. 782 Firewalls used with IP often need to be able to parse the 783 headers and options to determine the transport protocol (e.g. UDP or 784 TCP) in use and the port number for that protocol. Firewalls can be 785 used with the Authentication Header regardless of whether that 786 firewall is party to the appropriate Security Assocation. However, a 787 firewall that is not party to the applicable Security Association 788 will not normally be able to decrypt an encrypted upper-layer 789 protocol to view the protocol or port number needed to perform per- 790 packet filtering. 792 Further, firewalls need to verify that the data (e.g. source, 793 destination, transport protocol, port number) being used for access 794 control decisions is correct and authentic. Hence, authentication 795 might be performed not only within an organisation or campus but also 796 end to end with remote systems across the Internet. This use of the 797 Authentication Header with IP provides much more assurance that the 798 data being used for access control decisions is authentic. 800 Organisations with two or more sites that are interconnected 801 using commercial IP service might wish to use a selectively 802 encrypting firewall. If an encrypting firewall were placed between 803 each site of a company and the commercial IP service provider, the 804 firewall could provide an encrypted IP tunnel among all the company's 805 sites. It could also encrypt traffic between the company and its 806 suppliers, customers, and other affiliates. Traffic with the Network 807 Information Center, with public Internet archives, or some other 808 organisations might not be encrypted because of the unavailability of 809 a standard key management protocol or as a deliberate choice to 810 facilitate better communications, improved network performance, and 811 increased connectivity. Such a practice could easily protect the 812 company's sensitive traffic from eavesdropping and modification. 814 Some organisations (e.g. governments) might wish to use a fully 815 encrypting firewall to provide a Virtual Private Network (VPN) over 816 commercial IP service. The difference between that and a bulk IP 817 encryption device is that a fully encrypting firewall would provide 818 filtering of the decrypted traffic as well as providing encryption of 819 IP packets. A related scenario is to use encryption between a mobile 820 computer and the security gateway or encrypting firewall of its home 821 campus. 823 5.2 USE WITH IP MULTICAST 825 In the past several years, the Multicast Backbone (MBONE) has 826 grown rapidly. IETF meetings and other conferences are now regularly 827 multicast with real-time audio, video, and whiteboards. Many people 828 are now using teleconferencing applications based on IP Multicast in 829 the Internet or in private internal networks. Others are using IP 830 multicasting to support distributed simulation or other applications. 831 Hence it is important that the security mechanisms in IP be suitable 832 for use in an environment where multicast is the general case. 834 The Security Parameters Indexes (SPIs) used in the IP security 835 mechanisms are receiver-oriented, making them well suited for use in 836 IP multicast. [Atk95a, Atk95b] Unfortunately, most currently 837 published multicast key distribution protocols do not scale well. 838 However, there is active research in this area. As an interim step, 839 a multicast group could repeatedly use a secure unicast key 840 distribution protocol to distribute the key to all members or the 841 group could pre-arrange keys using manual key distribution. 843 5.3 USE TO PROVIDE QOS PROTECTION 845 The recent IAB Security Workshop identified Quality of Service 846 protection as an area of significant interest. [BCCH] The two IP 847 security mechanisms are intended to provide good support for real- 848 time services as well as multicasting. This section describes one 849 possible approach to providing such protection. 851 The Authentication Header might be used, with appropriate key 852 management, to provide authentication of packets. This 853 authentication is potentially important in packet classification 854 within routers. The IPv6 Flow Identifier might act as a Low-Level 855 Identifier (LLID). Used together, packet classification within 856 routers becomes straightforward if the router is provided with the 857 appropriate keying material. For performance reasons the routers 858 might authenticate only every Nth packet rather than every packet, 859 but this is still a significant improvement over capabilities in the 860 current Internet. Quality of service provisioning is likely to also 861 use the Flow ID in conjunction with a resource reservation protocol, 862 such as RSVP. [ZDESZ93] Thus, the authenticated packet classification 863 can be used to help ensure that each packet receives appropriate 864 handling inside routers. 866 5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS 868 A multi-level secure (MLS) network is one where a single network 869 is used to communicate data at different sensitivity levels (e.g. 870 Unclassified and Secret). [DoD85] [DoD87] Many governments have 871 significant interest in MLS networking. [DIA] The IP security 872 mechanisms have been designed to support MLS networking. MLS 873 networking requires the use of strong Mandatory Access Controls 874 (MAC), which ordinary users are incapable of controlling or 875 violating. [BL73] This section pertains only to the use of these IP 876 security mechanisms in MLS environments. 878 The Authentication Header can be used to provide strong 879 authentication among hosts in a single-level network. The 880 Authentication Header can also be used to provide strong assurance 881 for both mandatory access control decisions in multi-level networks 882 and discretionary access control decisions in all kinds of networks. 883 If explicit IP sensitivity labels (e.g. IPSO) [Ken91] are used and 884 confidentiality is not considered necessary within the particular 885 operational environment, the Authentication Header is used to provide 886 authentication for the entire packet, including cryptographic binding 887 of the sensitivity level to the IP header and user data. This is a 888 significant improvement over labeled IPv4 networks where the label is 889 trusted even though it is not trustworthy because there is no 890 authentication or cryptographic binding of the label to the IP header 891 and user data. IPv6 will normally use implicit sensitivity labels 892 that are part of the Security Association but not transmitted with 893 each packet instead of using explicit sensitivity labels. All 894 explicit IP sensitivity labels MUST be authenticated using either 895 ESP, AH, or both. 897 The Encapsulating Security Payload can be combined with 898 appropriate key policies to provide full multi-level secure 899 networking. In this case each key must be used only at a single 900 sensitivity level and compartment. For example, Key "A" might be 901 used only for sensitive Unclassified packets, while Key "B" is used 902 only for Secret/No-compartments traffic, and Key "C" is used only for 903 Secret/Compartment-X traffic. The sensitivity level of the protected 904 traffic MUST NOT dominate the sensitivity level of the Security 905 Association used with that traffic. The sensitivity level of the 906 Security Association MUST NOT dominate the sensitivity level of the 907 key that belongs to that Security Association. The sensitivity level 908 of the key SHOULD be the same as the sensitivity level of the 909 Security Association. The Authentication Header can also have 910 different keys for the same reasons, with the choice of key depending 911 in part on the sensitivity level of the packet. 913 Encryption is very useful and desirable even when all of the 914 hosts are within a protected environment. The Internet-standard 915 encryption algorithm could be used, in conjunction with appropriate 916 key management, to provide strong Discretionary Access Controls (DAC) 917 in conjunction with either implicit sensitivity labels or explicit 918 sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some 919 environments might consider the Internet-standard encryption 920 algorithm sufficiently strong to provide Mandatory Access Controls 921 (MAC). Full encryption should be used for all communications between 922 multi-level computers or compartmented mode workstations even when 923 the computing environment is considered to be protected. 925 6. SECURITY CONSIDERATIONS 927 This entire draft discusses the Security Architecture for the 928 Internet Protocol. It is not a general security architecture for the 929 Internet, but is instead focused on the IP layer. 931 Cryptographic transforms for ESP which use a block-chaining 932 algorithm and lack a strong integrity mechanism are vulnerable to a 933 cut-and-paste attack described by Bellovin and should not be used 934 unless the Authentication Header is always present with packets using 935 that ESP transform. [Bel95] 937 If more than one sender shares a Security Association with a 938 destination, then the receiving system can only authenticate that the 939 packet was sent from one of those systems and cannot authenticate 940 which of those systems sent it. Similarly, if the receiving system 941 does not check that the Security Association used for a packet is 942 valid for the claimed Source Address of the packet, then the 943 receiving system cannot authenticate whether the packet's claimed 944 Source Address is valid. For example, if senders "A" and "B" each 945 have their own unique Security Association with destination "D" and 946 "B" uses its valid Security Association with D but forges a Source 947 Address of "A", then "D" will be fooled into believing the packet 948 came from "A" unless "D" verifies that the claimed Source Address is 949 party to the Security Association that was used. 951 Users need to understand that the quality of the security 952 provided by the mechanisms provided by these two IP security 953 mechanisms depends completely on the strength of the implemented 954 cryptographic algorithms, the strength of the key being used, the 955 correct implementation of the cryptographic algorithms, the security 956 of the key management protocol, and the correct implementation of IP 957 and the several security mechanisms in all of the participating 958 systems. The security of the implementation is in part related to 959 the security of the operating system which embodies the security 960 implementations. For example, if the operating system does not keep 961 the private cryptologic keys (that is, all symmetric keys and the 962 private asymmetric keys) confidential, then traffic using those keys 963 will not be secure. If any of these is incorrect or insufficiently 964 secure, little or no real security will be provided to the user. 965 Because different users on the same system might not trust each 966 other, each user or each session should usually be keyed separately. 967 This will also tend to increase the work required to cryptanalyse the 968 traffic since not all traffic will use the same key. 970 Certain security properties (e.g. traffic analysis protection) 971 are not provided by any of these mechanisms. One possible approach 972 to traffic analysis protection is appropriate use of link encryption. 973 [VK83] Users must carefully consider which security properties they 974 require and take active steps to ensure that their needs are met by 975 these or other mechanisms. 977 Certain applications (e.g. electronic mail) probably need to 978 have application-specific security mechanisms. Application-specific 979 security mechanisms are out of the scope of this document. Users 980 interested in electronic mail security should consult the RFCs 981 describing the Internet's Privacy-Enhanced Mail system. Users 982 concerned about other application-specific mechanisms should consult 983 the online RFCs to see if suitable Internet Standard mechanisms 984 exist. 986 ACKNOWLEDGEMENTS 988 Steve Kent provided detailed and helpful editorial input into 989 this draft. His contributions improved the draft significantly. 991 Many of the concepts here are derived from or were influenced by 992 the US Government's SDNS security protocol specifications, the 993 ISO/IEC's NLSP specification, or from the proposed swIPe security 994 protocol. [SDNS, ISO, IB93, IBK93] The work done for SNMP Security 995 and SNMPv2 Security influenced the choice of default cryptological 996 algorithms and modes. [GM93] Steve Bellovin, Steve Deering, Phil 997 Karn, Frank Kastenholz, Steve Kent, Perry Metzger, Dave Mihelcic, 998 Hilarie Orman and Bill Simpson provided careful critiques of earlier 999 versions of this draft. 1001 REFERENCES 1003 [Atk96a] Randall Atkinson, IP Authentication Header, RFC-xxxx, 4 June 1996. 1005 [Atk96b] Randall Atkinson, IP Encapsulating Security Payload, RFC-xxxx, 1006 4 June 1996. 1008 [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB 1009 Workshop on Security in the Internet Architecture", RFC-1636, 1010 DDN Network Information Center, June 1994. 1012 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol 1013 Suite", ACM Computer Communications Review, Vol. 19, No. 2, 1014 March 1989. 1016 [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group 1017 Meeting, Proceedings of the 32nd Internet Engineering Task 1018 Force, March 1995, Internet Engineering Task Force, Danvers, MA. 1020 [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical 1021 Foundations and Model", Technical Report M74-244, The MITRE 1022 Corporation, Bedford, MA, May 1973. 1024 [CERT95] CA-95:01 1026 [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet 1027 Security, Addison-Wesley, Reading, MA, 1994. 1029 [CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay 1030 Prevention", Internet Draft, 1 May 1996. 1032 [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation 1033 Specification", Technical Report DDS-2600-6243-87. 1035 [DoD85] US National Computer Security Center, "Department of Defense 1036 Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, 1037 US Department of Defense, Ft. Meade, MD., December 1985. 1039 [DoD87] US National Computer Security Center, "Trusted Network 1040 Interpretation of the Trusted Computer System Evaluation Criteria", 1041 NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 1042 31 July 1987. 1044 [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE 1045 Transactions on Information Theory, Vol. IT-22, No. 6, November 1046 1976, pp. 644-654. 1048 [DH95] Steve Deering & Bob Hinden, Internet Protocol version 6 (IPv6) 1049 Specification, RFC-1883, December 1995. 1051 [EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol 1052 Security Extensions", Internet Draft, 30 January 1996. 1054 [GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2 1055 of the Simple Network Management Protocol (SNMPv2), RFC-1446, 1056 DDN Network Information Center, April 1993. 1058 [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, 1059 DDN Network Information Center, October 1994. 1061 [Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention 1062 Security Transform", Internet Draft, June 1996. 1064 [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 1065 DIS 11577, International Standards Organisation, Geneva, 1066 Switzerland, 29 November 1992. 1068 [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of 1069 Network-layer Security Under Unix", Proceedings of USENIX Security 1070 Symposium, Santa Clara, CA, October 1993. 1072 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer 1073 Security for IP", presentation at the Spring 1993 IETF Meeting, 1074 Columbus, Ohio. 1076 [Ken78] Steve Kent, ..., Proceedings of SIGCOMM '78, ACM SIGCOMM, 1978. 1078 [Ken91] Steve Kent, US DoD Security Options for the Internet Protocol, 1079 RFC-1108, DDN Network Information Center, November 1991. 1081 [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 1082 Part II: Certificate-Based Key Management, RFC-1422, DDN Network 1083 Information Center, 10 February 1993. 1085 [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication 1086 Service (V5), RFC-1510, DDN Network Information Center, 1087 10 September 1993. 1089 [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication 1090 in Large Networks of Computers", Communications of the ACM, 1091 Vol. 21, No. 12, December 1978, pp. 993-999. 1093 [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", 1094 ACM Operating Systems Review, Vol. 21, No. 1., 1981. 1096 [OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay 1097 Prevention", Internet Draft, 1 May 1996. 1099 [OTA94] US Congress, Office of Technology Assessment, "Information 1100 Security & Privacy in Network Environments", OTA-TCT-606, 1101 Government Printing Office, Washington, DC, September 1994. 1103 [Sch96] Jeff Schiller, "Security AD Statement on IPSEC Key Management", 1104 Email to IPsec mailing list, September 19, 1996. 1106 [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, 1107 John Wiley & Sons, New York, NY, 1994. 1109 [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, 1110 Document SDN.301, Revision 1.5, 15 May 1989, published 1111 in NIST Publication NIST-IR-90-4250, February 1990. 1113 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, 1114 March 1996. 1116 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level 1117 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 1119 [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D., 1120 "RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine, 1121 September 1993. 1123 DISCLAIMER 1125 The views expressed in this note are those of the editor and are not 1126 necessarily those of his employer. The editor and his employer 1127 specifically disclaim responsibility for any problems arising from correct 1128 or incorrect implementation or use of this design. 1130 EDITOR INFORMATION: 1132 Randall Atkinson 1133 cisco Systems 1134 170 West Tasman Drive 1135 San Jose, CA, 95134-1706 1136 USA 1138 Telephone: +1 (408) 526-4000