idnits 2.17.1 draft-ietf-ipngwg-sec-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-20) 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 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 102 instances of too long lines in the document, the longest one being 10 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 157: '...v6-capable hosts MUST implement the IP...' RFC 2119 keyword, line 159: '...ation algorithms MAY be implemented in...' RFC 2119 keyword, line 217: '...ting Security Payload MUST support the...' RFC 2119 keyword, line 354: '... implementations MUST support manual k...' RFC 2119 keyword, line 355: '... implementations SHOULD support an Int...' (6 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 (16 February 1995) is 10656 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: 'Hi94' is mentioned on line 30, but not defined == Missing Reference: 'At94b' is mentioned on line 241, but not defined == Missing Reference: 'BCCH' is mentioned on line 449, but not defined == Unused Reference: 'BCCH94' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'Hin94' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'Ken93' is defined on line 625, but no explicit reference was found in the text -- No information found for draft-atkinson-ipng-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Atk95a' -- No information found for draft-atkinson-ipng-esp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Atk95b' ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. 'BCCH94') -- Possible downref: Non-RFC (?) normative reference: ref. 'BFC93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CB94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'EK94' ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. 'GM93') ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'HA94') -- No information found for draft-hinden-ipv6-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Hin94' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' ** 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. 'OTA94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Randall Atkinson 2 Internet Draft Naval Research Laboratory 3 draft-ietf-ipngwg-sec-00.txt 16 February 1995 5 IPv6 Security Architecture 7 STATUS OF THIS MEMO 8 This document is an Internet Draft. Internet Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its Areas, and 10 its working groups. Note that other groups may also distribute working 11 documents as Internet Drafts. 13 Internet Drafts are draft documents valid for a maximum of 6 months. 14 Internet Drafts may be updated, replaced, or obsoleted by other 15 documents at any time. It is not appropriate to use Internet Drafts as 16 reference material or to cite them other than as "work in progress". 18 This particular Internet Draft is a product of the IETF's IPng 19 working group. It is intended that a future version of this draft be 20 submitted to the IESG for publication as a standards-track RFC. 21 Discussion of this draft normally takes place on the IPng Working 22 Group mailing list: ipng@sunroof.eng.sun.com 23 To add/drop from that mailing list, send an email request to: 24 ipng-request@sunroof.eng.sun.com 26 1. INTRODUCTION 28 The Internet community is making a transition from version 4 of the 29 Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). 30 [Hi94] This memo describes the security mechanisms integrated into 31 version 6 of the Internet Protocol (IPv6) and the services that they 32 provide. Each security mechanism is specified in a separate document. 33 It also describes key management for the IPv6 security mechanisms. 35 1.1 Definitions 37 This section provides a few basic definitions that are applicable to 38 this document. Other documents provide more definitions and background 39 information. [VK83, HA94] 41 Authentication 42 The property of knowing that the data received is the same as 43 the data that was sent and that the claimed sender is in fact 44 the actual sender. 46 Integrity 47 The property of ensuring that data is transmitted from source 48 to destination without undetected alteration. 50 Confidentiality 51 The property of keeping communications confidential so that 52 intended participants can know what is being sent but 53 unintended parties are unable to determine what is being sent. 55 Encryption 56 A mechanism commonly used to provide confidentiality. 58 Non-repudiation 59 The property of a receiver being able to prove that the sender 60 of some data did in fact send the data even though the sender 61 might later desire to deny ever having sent that data. 63 SAID 64 Acronym for "Security Association IDentifier" 66 Security Association 67 The set of security information relating to a given network 68 connection or set of connections. This usually includes 69 the cryptographic key, key lifetime, algorithm, algorithm mode, 70 sensitivity level (e.g. Unclassified, Secret, Proprietary), 71 what kind of security service is provided (authentication-only, 72 Transport-Mode Encryption, IP-Mode Encryption, or some combination), 73 and possibly other data. 75 Traffic Analysis 76 A kind of network attack where the adversary is able to make 77 deductions about oneself just by analysing the network traffic 78 patterns (such as frequency of transmission, who is talking with 79 whom, size of packets, Flow Identifier used, etc). 81 2. DESIGN OBJECTIVES 83 This section describes some of the design objectives of this 84 security architecture and its component mechanisms. The primary 85 objective of this work is to ensure that IPv6 will have solid security 86 mechanisms available to users who desire security. These mechanisms 87 are designed such that Internet users who do not employ these 88 mechanisms will not be adversely affected. These mechanisms are 89 intended to be algorithm-independent so that the cryptographic 90 algorithms can be altered without affecting the other parts of the 91 implementation. Standard default algorithms (i.e. keyed MD5, DES CBC) 92 are specified to ensure interoperability in the global Internet. The 93 selected algorithms are the same as the standard default algorithms 94 used in SNMPv2. The IPv6 Security mechanisms should be useful in 95 enforcing a variety of security policies. 97 3. IPv6 SECURITY MECHANISMS 99 There are two security mechanisms in IPv6. The first is the 100 Authentication Header which provides integrity and authentication 101 without confidentiality. [Atk95a] The second is the Encapsulating 102 Security Payload which, depending on algorithm and mode, might provide 103 integrity, authentication, and always provides confidentiality. 104 [Atk95b] The IPv6 mechanisms do not provide security against a number 105 of traffic analysis attacks. However, there are several techniques 106 outside the scope of this specification (e.g. bulk link encryption) 107 that might be used to provide protection against traffic analysis. 108 [VK83] The two IPv6 security mechanisms may be combined. 110 3.1 AUTHENTICATION HEADER 112 The IPv6 Authentication Header seeks to provide integrity and 113 authentication for IPv6 datagrams. It does this by computing a 114 cryptographic authentication function over the IPv6 datagram and using 115 a secret authentication key in the computation. [Atk95a] The sender 116 computes the authentication data just prior to sending the 117 authenticated IPv6 packet and the receiver verifies the correctness of 118 the authentication data upon reception. Certain fields which must 119 change in transit, such as the Hop Limit field decremented on each 120 hop, are omitted from the authentication calculation. However the 121 omission of the Hop Limit field does not adversely impact the security 122 provided. Non-repudiation might be provided by some authentication 123 algorithms (e.g. asymmetric algorithms when both sender and receiver 124 keys are used in the authentication calculation) used with the 125 Authentication Header, but it is not necessarily provided by all 126 authentication algorithms that might be used with the Authentication 127 Header. The default authentication algorithm is keyed MD5, which like 128 all symmetric algorithms cannot provide non-repudiation. 129 Confidentiality and traffic analysis protection are not provided by 130 the Authenticaton Header. 132 The IPv6 Authentication Header holds authentication information 133 for its IPv6 datagram. This authentication information is calculated 134 using all of the fields in the IPv6 datagram which do not change 135 during transit from the originator to the recipient. All IPv6 136 headers, payloads, and the user data are included in this calculation. 137 The only exception is that fields which need to change in transit (e.g. 139 IPv6 Header's "Hop Count" or the IPv6 Routing Header's "Next Address") 140 are omitted when the authentication data is calculated. 142 Use of the Authentication Header will increase the IPv6 protocol 143 processing costs in participating systems and will also increase the 144 communications latency. The increased latency is primarily due to the 145 calculation of the authentication data by the sender and the 146 calculation and comparison of the authentication data by each receiver 147 for each IPv6 datagram containing an Authentication Header (AH). 149 The Authentication Header provides much stronger security than 150 exists in most of the current Internet and should not affect 151 exportability or significantly increase implementation cost. While 152 the Authentication Header might be implemented by a security gateway 153 on behalf of hosts on a trusted network behind that security gateway, 154 this mode of operation is not encouraged. Instead, the Authentication 155 Header should be used from origin to final destination. 157 All IPv6-capable hosts MUST implement the IPv6 Authentication Header 158 with at least the MD5 algorithm using a 128-bit key. Other 159 authentication algorithms MAY be implemented in addition to keyed MD5. 161 3.2 ENCAPSULATING SECURITY PAYLOAD 163 The IPv6 Encapsulating Security Payload (ESP) seeks to provide 164 integrity, authentication, and confidentiality to IPv6 165 datagrams. [Atk95b] It does this by encapsulating either an entire 166 IPv6 datagram or only the upper-layer protocol data inside the ESP, 167 encrypting most of the ESP contents, and then appending a new 168 cleartext IPv6 header to the now encrypted Encapsulating Security 169 Payload. This cleartext IPv6 header is used to carry the protected 170 data through the internetwork. The recipient of the cleartext 171 datagram removes and discards the cleartext IPv6 header and cleartext 172 IPv6 options, decrypts the ESP, processes and then removes the ESP 173 headers, and then processes the (now decrypted) original IPv6 datagram 174 or upper-layer protocol data as per the normal IPv6 protocol 175 specification. 177 3.2.1 Description of the ESP Modes 179 There are two modes within ESP. The first mode, which is known as 180 IP-mode, encapsulates and entire IP datagram within the ESP header. 181 The second mode, which is known as Transport-mode, usually encapsulates 182 a UDP or TCP frame inside IP. 184 3.2.2 Usage of ESP 186 ESP works between hosts, between a host and a security gateway, or 187 between security gateways. This support for security gateways permits 188 trustworthy networks behind a security gateway to omit encryption and 189 thereby avoid the performance and monetary costs of encryption, while 190 still providing confidentiality for traffic transiting untrustworthy 191 network segments. When both hosts directly implement ESP and there is 192 no intervening security gateway, then they may use the Transport-mode 193 (where only the upper layer protocol data (e.g. TCP or UDP) is 194 encrypted and there is no encrypted IPv6 header). This mode reduces 195 both the bandwidth consumed and the protocol processing costs for 196 users that don't need to keep the entire IPv6 datagram confidential. 197 ESP works with both unicast and multicast traffic. 199 3.2.3 Performance Impacts of ESP 201 The encapsulating security approach used by ESP can noticeably 202 impact network performance in participating systems, but should not 203 adversely impact routers or other intermediate systems that are not 204 participating in the particular ESP association. Protocol processing 205 in participating systems will be more complex when encapsulating 206 security is used, requiring both more time and more processing power. 207 Use of encryption will also increase the communications latency. The 208 increased latency is primarily due to the encryption and decryption 209 required for each IPv6 datagram containing an Encapsulating Security 210 Payload. The precise cost of ESP will vary with the specifics of the 211 implementation, including the encryption algorithm, key size, and 212 other factors. Hardware implementations of the encryption algorithm 213 are recommended when high throughput is desired. Because of the 214 performance impact, users not requiring confidentiality will probably 215 prefer to use the IPv6 Authentication Header instead of ESP. For 216 interoperability throughout the worldwide Internet, all conforming 217 implementations of IPv6 Encapsulting Security Payload MUST support the 218 use of the Data Encryption Standard (DES) in Cipher-Block Chaining 219 (CBC) Mode. Other confidentiality algorithms and modes may also be 220 implemented in addition to this mandatory algorithm and mode. Export 221 of encryption and use of encryption are regulated in some countries. 222 [OTA94] 224 3.3 COMBINING SECURITY MECHANISMS 226 In some cases the IPv6 Authentication Header might be combined with 227 the IPv6 Encapsulating Security Protocol to obtain the desired 228 security properties. The Authentication Header always provides 229 integrity and authentication and can provide non-repudiation if used 230 with certain authentication algorithms (e.g. RSA) . The Encapsulating 231 Security Payload always provides integrity and confidentiality and can 232 also provide authentication if used with certain authenticating 233 encryption algorithms. Adding the Authentication Header to a IPv6 234 datagram prior to encapsulating that datagram using the Encapsulating 235 Security Protocol might be desirable for users wishing to have strong 236 integrity, authentication, confidentiality, and perhaps also 237 non-repudiation. When the two mechanisms are combined, the placement 238 of the IPv6 Authentication Header makes clear which part of the data 239 is being authenticated. Details on combining the two mechanisms are 240 provided in the IPv6 Encapsulating Security Payload 241 specification. [At94b] 243 3.4 OTHER SECURITY MECHANISMS 244 Protection from traffic analysis is not provided by any of the 245 security mechanisms described above. It is unclear whether meaningful 246 protection from traffic analysis can be provided economically at the 247 Internet Layer and it appears that few Internet users are concerned 248 about traffic analysis. One traditional method for protection against 249 traffic analysis is the use of bulk link encryption. Another 250 technique is to send false traffic in order to increase the noise in 251 the data provided by traffic analysis. Reference [VK83] discusses 252 traffic analysis issues in more detail. 254 4. KEY MANAGEMENT 256 The Key Management protocol that will be used with IPv6 is not 257 specified in this document. However, because the key management 258 protocol is coupled to the other security mechanisms only via the 259 Security Association Identifier (SAID), those other security 260 mechanisms have been defined in two companion documents. IPv6 is not 261 intended to support so-called "in-band" key management, where the key 262 management data is carried in a distinct IPv6 header. Instead it will 263 primarily use so-called "out-of-band" key management, where the key 264 management data will be carried by an upper layer protocol such as UDP 265 or TCP on some specific port number. This permits clear decoupling of 266 the key management mechanism from the other security mechanisms, and 267 thereby permits one to substitute new and improved key management 268 methods without having to modify the implementations of the other 269 security mechanisms. This is clearly wise given the long history of 270 subtle flaws in published key management protocols. [NS78, NS81] What 271 follows in this section is a brief discussion of a few alternative 272 approaches to key management. 274 4.1 Manual Key Distribution 276 The simplest form of key management is manual key management, where 277 a person manually configures each system with its own key and also 278 with the keys of other communicating systems. This is quite practical 279 in small, static environments but does not scale. It is not a viable 280 medium-term or long-term approach, but might be appropriate and useful 281 in many environments in the near-term. For example, within a small 282 LAN it is entirely practical to manually configure keys for each 283 system. Within a single administrative domain it is practical to 284 configure keys for each router so that the routing data can be 285 protected and to reduce the risk of an intruder breaking into a 286 router. Another case is where an organisation has an encrypting 287 firewall between the internal network and the Internet at each of its 288 sites and it connects two or more sites via the Internet. In this 289 case, the encrypting firewall might selectively encrypt traffic for 290 other sites within the organisation using a manually configured key, 291 while not encrypting traffic with other destinations. It also might 292 be appropriate when only selected communications need to be secured. 294 4.2 Some Existing Key Management Techniques 296 There are a number of key management algorithms that have been 297 described in the public literature. Needham & Schroeder have proposed 298 a key management algorithm which relies on a centralised key 299 distribution system. [NS78, NS81] This algorithm is used in the 300 Kerberos Authentication System developed at MIT under Project 301 Athena. [KB93] More recently, Diffie & Hellman have devised an 302 algorithm which does not require a centralised key distribution 303 system. [DH76] Unfortunately, the original Diffie-Hellman technique is 304 vulnerable to an active "man in the middle" attack. However, this 305 vulnerability can be mitigated by using signed keys to authentically 306 bootstrap into the Diffie-Hellman exchange. 308 4.3 Automated Key Distribution 310 Widespread deployment and use of IPv6 security will require an 311 Internet-standard scalable key management protocol. Ideally such a 312 protocol would support a number of protocols in the Internet protocol 313 suite, not just IPv6 security. There is work underway within the IETF 314 to add signed host keys to the Domain Name System [EK94] The DNS keys 315 enable the originating party would to authenticate key management 316 messages with the other key management party using an asymmetric 317 algorithm. The two parties would then have an authenticatible 318 communications channel that could be used to create a shared session 319 key using Diffie-Hellman or other means. [DH76] 321 There are two keying approaches for IPv6. The first approach, 322 called host-to-host keying, has all users on host 1 share the same key 323 for use on traffic destined for all users on host 2. The second 324 approach, called user-to-user keying, lets user A on host 1 have a 325 unique session key with user B on host 2 that is not shared with other 326 users on host1. In many cases, a single computer system will have at 327 least two mutually suspicious users A and B that do not trust each 328 other. When host-to-host keying is used and mutually suspicious users 329 exist, it is possible for user A to determine the host-to-host key via 330 well known methods, such as a Chosen Plaintext attack. Once user A 331 has improperly obtained the key in use, user A can then either read 332 user B's encrypted traffic or forge traffic from user B. When 333 user-to-user keying is used, this kind of attack from one user onto 334 another user's traffic is not possible. Hence, support for 335 user-to-user keying must be present in all IPv6 implementations, as is 336 described in the "IPv6 Key Management Requirements" section below. 338 4.4 Multicast Key Distribution 340 Multicast key distribution is an active research area in the 341 published literature as of this writing. For multicast groups having 342 relatively few members, manual key distribution or multiple use of 343 existing unicast key distribution algorithms such as modified 344 Diffie-Hellman appears feasible. For very large groups, new scalable 345 techniques will be needed. The use of Core-Based Trees (CBT) to 346 provide session key management as well as multicast routing might be 347 an approach used in the future. [BFC93] 349 4.5 IPv6 Key Management Requirements 350 This section defines key management requirements for all IPv6 351 implementations. It applies equally to the IPv6 Authentication Header 352 and the IPv6 Encapsulating Security Payload. 354 All IPv6 implementations MUST support manual key management. All 355 IPv6 implementations SHOULD support an Internet standard key 356 management protocol once the latter is defined. All IPv6 357 implementations MUST permit the configuration and use of user-to-user 358 keying for traffic originating at that system and MAY additionally 359 permit the configuration of host-to-host keying for traffic 360 originating at that system as an added feature to make manual key 361 distribution easier and give the system administrator more 362 flexibility. 364 A device that encrypts or authenticates IPv6 packets originated on 365 other systems, for example a dedicated IP encryptor or an encrypting 366 gateway, cannot generally provide user-to-user keying for traffic 367 originating on other systems. Hence, such systems MUST implement 368 support for host-to-host keying for traffic originating on other 369 systems and MAY implement support for user-to-user keying for traffic 370 originating on other systems. 372 The method by which keys are configured on a particular system is 373 implementation-defined. A flat file containing security association 374 identifiers and the security parameters, including the key(s), is an 375 example of one possible method for manual key distribution. An IPv6 376 system MUST take reasonable steps to protect the keys and other security 377 association information from unauthorised examination or modification 378 because all of the security lies in the keys. 380 5. USAGE 381 This section describes the possible use of the security mechanisms 382 provided by IPv6 in several different environments and applications 383 in order to give the implementer and user a better idea of how these 384 mechanisms can be used to reduce security risks. 386 5.1 USE WITH FIREWALLS 387 Firewalls are not uncommon in the current Internet. [CB94] While 388 many dislike their presence because they restrict connectivity, they 389 are unlikely to disappear in the near future. Both of the IPv6 390 mechanisms can be used to increase the security provided by firewalls. 392 Firewalls used with IPv6 will need to be able to parse the header 393 daisy-chain to determine the transport protocol (e.g. UDP or TCP) in 394 use and the port number for that protocol. Firewall performance 395 should not be significantly affected by use of IPv6 because the header 396 format rules in IPv6 make parsing easy and fast. 398 Firewalls can use the Authentication Header to gain assurance that 399 the data (e.g. source, destination, transport protocol, port number) 400 being used for access control decisions is correct and authentic. 401 IPv4 firewalls are unable to authenticate the data being used for 402 access control decisions and necessarily trust data that is not 403 trustworthy. Authentication might be performed not only within an 404 organisation or campus but also end to end with remote systems across 405 the Internet. This use of the Authentication Header with IPv6 406 provides much more assurance of security than IPv4 provides. 408 Organisations with two or more sites that are interconnected using 409 commercial IP service might wish to use a selectively encrypting 410 firewall. If an encrypting firewall were placed between each site of 411 the Foo Company and the commercial IP service provider, the firewall 412 could provide an encrypted IP tunnel among all of the Foo Company's 413 sites. It could also encrypt traffic between the Foo Company and its 414 suppliers, customers, and other affiliates. Traffic with the NIC, 415 with public Internet archive, or some other organisations might not be 416 encrypted because of the unavailability of a standard key management 417 protocol or as a deliberate choice to facilitate better 418 communications, improved network performance, and increased 419 connectivity. Such a practice could easily protect the organisation's 420 sensitive traffic from eavesdropping and modification. 422 Some organisations (e.g. governments) might wish to use a fully 423 encrypting firewall to provide a protected virtual network over 424 commercial IP service. The difference between that and a bulk IPv6 425 encryption device is that a fully encrypting firewall would provide 426 filtering of the decrypted traffic as well as providing encryption of 427 IP packets. 429 5.3 USE WITH IPv6 MULTICAST 430 In the past several years, the Multicast Backbone (MBONE) has grown 431 rapidly. IETF meetings and other conferences are now regularly 432 multicast with real-time audio, video, and whiteboards. Many people 433 are now using teleconferencing applications based on IP Multicast in 434 the Internet or in private internal networks. Hence it is important 435 that the security mechanisms in IPv6 be suitable for use in an 436 environment where multicast is the general case. 438 The Security Association Identifiers (SAIDs) used in the IPv6 439 security mechanisms are receiver-oriented, making them well suited for 440 use in IP multicast. [Atk95a, Atk95b] Unfortunately, most currently 441 published multicast key distribution protocols do not scale well. 442 However, there is active research in this area. As an interim step, a 443 multicast group could repeatedly use a secure unicast key distribution 444 protocol to distribute the key to all members or the group could 445 pre-arrange keys using manual key distribution. 447 5.4 USE TO PROVIDE QOS PROTECTION 448 The recent IAB Security Workshop identified Quality of Service 449 protection as an area of significant interest. [BCCH] The two IPv6 450 security mechanisms are intended to provide good support for real-time 451 services as well as multicasting. This section describes one possible 452 approach to providing such protection. 454 The Authentication Header can be used, with appropriate key 455 management, to provide authentication of packets. This authentication 456 is potentially important in packet classification within routers. The 457 IPv6 Flow Identifier can act as a Low-Level Identifier (LLID). Used 458 together, packet classification within routers becomes 459 straightforward if the router is provided with the appropriate key 460 material. For performance reasons the routers might authenticate only 461 every Nth packet rather than every packet, but this is still a 462 significant improvement over capabilities in the current Internet. 463 Quality of service provisioning is likely to also use the Flow ID in 464 conjunction with a resource reservation protocol, such as RSVP. Thus, 465 the authenticated packet classification can be used to help ensure 466 that each packet receives appropriate handling inside routers. 468 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS 469 A multi-level secure (MLS) network is one where a single network is 470 used to communicate data at different sensitivity levels (e.g. 471 Unclassified and Secret). Many governments have significant interest 472 in MLS networking. [DIA] The IPv6 security mechanisms have been 473 designed to support MLS networking. MLS networking requires the use 474 of strong Mandatory Access Controls (MAC) which ordinary users are 475 incapable of controlling or violating. Mandatory Access Controls 476 differ from Discretionary Access Controls in this respect. 478 The Authentication Header can be used to provide strong 479 authentication among hosts in a single-level network. The 480 Authentication Header can also be used to provide strong assurance for 481 both mandatory access control decisions in multi-level networks and 482 discretionary access control decisions in all kinds of networks. If 483 IP sensitivity labels are used and confidentiality is not considered 484 necessary within the particular operational environment, the 485 Authentication Header is used to provide authentication for the entire 486 packet, including cryptographic binding of the sensitivity level to 487 the IPv6 header and user data. This is a significant improvement over 488 labelled IPv4 networks where the label is trusted even though it is 489 not trustworthy because there is no authentication or cryptographic 490 binding of the label to the IP header and user data. 492 The Encapsulating Security Payload can be combined with appropriate 493 key policies to provide full multi-level secure networking. In this 494 case each key must be used only at a single sensitivity level and 495 compartment. For example, Key "A" might be used only for sensitive 496 Unclassified packets, while Key "B" is used only for 497 Secret/No-compartments traffic, and Key "C" is used only for 498 Secret/No-Foreign traffic. 500 In sensitive environments, appropriate organisational policies will 501 dictate the actual key management policy and also the set of 502 algorithms that are appropriate for use. In such environments, the 503 ability to communicate between the Internet and the hosts handling 504 sensitive data is probably undesirable. Hence, systems only handling 505 sensitive information might not implement the Internet standard 506 algorithms and instead only have algorithms approved by appropriate 507 policies for such use. Such systems would not be fully conforming to 508 the IPv6 Encapsulating Security Payload specification with regard to 509 implementation of the mandatory Internet algorithm, but those users 510 might not care or might consider that to be desirable. 512 Encryption is very useful and desirable even when all of the hosts 513 are within a protected environment. The Internet-standard encryption 514 algorithm could be used, in conjuction with appropriate key 515 management, to provide strong Discretionary Access Controls (DAC) in 516 conjunction with either implicit or explicit sensitivity 517 labels. [Ken91] Some environments might consider the Internet-standard 518 encryption algorithm sufficiently strong to provide Mandatory Access 519 Controls (MAC). Full encryption SHOULD be used for all communications 520 between multi-level computers or compartmented mode workstations even 521 when the computing environment is considered to be protected. 523 6. SECURITY CONSIDERATIONS 525 This entire draft discusses the IPv6 Security Architecture. 527 Users need to understand that the quality of the security provided 528 by the mechanisms provided by IPv6 depends completely on the strength 529 of the implemented cryptographic algorithms, the strength of the key 530 being used, the correct implementation of the cryptographic 531 algorithms, the security of the key management protocol, and the 532 correct implementation of IPv6 and the several security mechanisms in 533 all of the participating systems. The security of the implementation 534 is in part related to the security of the operating system which 535 embodies the security implementations. For example, if the operating 536 system does not keep the private cryptologic keys confidential, then 537 traffic using those keys will not be secure. If any of these is 538 incorrect or insufficiently secure, little or no real security will be 539 provided to the user. Because different users on the same system might 540 not trust each other, each user or each session should usually be 541 keyed separately. This will also tend to increase the work required 542 to cryptanalyse the traffic since not all traffic will use the same key. 544 Certain security properties (e.g. traffic analysis protection) are 545 not provided by any of these mechanisms. One possible approach to 546 traffic analysis protection is appropriate use of link 547 encryption. [VK83] Users must carefully consider which security 548 properties they require and take active steps to ensure that their 549 needs are met by these or other mechanisms. 551 Certain applications (e.g. electronic mail) probably need to have 552 application-specific security mechanisms. Application-specific 553 security mechanisms are out of the scope of the IPv6 Security 554 Architecture. Users interested in electronic mail security should 555 consult the RFCs describing the Internet's Privacy-Enhanced Mail 556 system. Users concerned about other application-specific mechanisms 557 should consult the online RFCs to see if suitable Internet Standard 558 mechanisms exist. 560 ACKNOWLEDGEMENTS 562 Many of the concepts here are derived from or were influenced by the 563 US Government's SDNS security protocol specifications, the ISO/IEC's 564 NLSP specification, or from the proposed swIPe security 565 protocol. [SDNS, ISO, IB93, IBK93] The work done for SNMP Security 566 and SNMPv2 Security influenced the choice of default cryptological 567 algorithms and modes. [GM93] Steve Bellovin, Steve Deering, Richard 568 Hale, George Kamis, Phil Karn, Frank Kastenholz, and Dave Mihelcic 569 provided critiques of early versions of this draft. 571 REFERENCES 572 [Atk95a] Randall Atkinson, IPv6 Authentication Header, Internet Draft, 573 draft-atkinson-ipng-auth-01.txt, 16 February 1995. 575 [Atk95b] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet 576 Draft, draft-atkinson-ipng-esp-01.txt, 16 February 1995 578 [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB 579 Workshop on Security in the Internet Architecture", RFC-1636, 580 DDN Network Information Center, June 1994. 582 [BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees: 583 An Architecture for Scalable Inter-Domain Multicast Routing", 584 Proceedings of ACM SIGCOMM 93, ACM Computer Communications Review, 585 Volume. 23, Number 4, October 1993, pp. 85-95. 587 [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet 588 Security, Addiwon-Wesley, Reading, MA, 1994. 590 [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation 591 Specification", Technical Report DDS-2600-6243-87. 593 [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE 594 Transactions on Information Theory, Vol. IT-22, No. 6, November 595 1976, pp. 644-654. 597 [EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol 598 Security Extensions", Internet Draft, March 1994. 600 [GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2 601 of the Simple Network Management Protocol (SNMPv2), RFC-1446, 602 DDN Network Information Center, April 1993. 604 [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, 605 DDN Network Information Center, October 1994. 607 [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, 608 draft-hinden-ipv6-spec-00.txt, October 1994. 610 [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 611 DIS 11577, International Standards Organisation, Geneva, 612 Switzerland, 29 November 1992. 614 [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of 615 Network-layer Security Under Unix", Proceedings of USENIX Security 616 Symposium, Santa Clara, CA, October 1993. 618 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer 619 Security for IP", presentation at the Spring 1993 IETF Meeting, 620 Columbus, Ohio. 622 [Ken91] Steve Kent, US DoD Security Options for the Internet Protocol, 623 RFC-1108, DDN Network Information Center, November 1991. 625 [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 626 Part II: Certificate-Based Key Management, RFC-1422, DDN Network 627 Information Center, 10 February 1993. 629 [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), 630 RFC-1510, DDN Network Information Center, 10 September 1993. 632 [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication 633 in Large Networks of Computers", Communications of the ACM, 634 Vol. 21, No. 12, December 1978, pp. 993-999. 636 [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisted", 637 ACM Operating Systems Review, Vol. 21, No. 1., 1981. 639 [OTA94] US Congress, Office of Technology Assessment, "Information Security 640 & Privacy in Network Environments", OTA-TCT-606, Government Printing 641 Office, Washington, DC, September 1994. 643 [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, 644 Document SDN.301, Revision 1.5, 15 May 1989, published 645 in NIST Publication NIST-IR-90-4250, February 1990. 647 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level 648 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 650 DISCLAIMER 652 The views expressed in this note are those of the author and are not 653 necessarily those of his employer. The Naval Research Laboratory has 654 not passed judgement on the merits, if any, of this work. The author 655 and his employer specifically disclaim responsibility for any problems 656 arising from correct or incorrect implementation or use of this 657 design. 659 AUTHOR INFORATION 661 Randall Atkinson 662 Information Technology Division 663 Naval Research Laboratory 664 Washington, DC 20375-5320 665 USA 667 Voice: (DSN) 354-8590 668 Fax: (DSN) 354-7942