idnits 2.17.1 draft-ietf-msec-ipsec-extensions-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1742. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 6, 2008) is 5803 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) -- Looks like a reference, but probably isn't: '0' on line 1657 -- Looks like a reference, but probably isn't: '1' on line 1636 -- Looks like a reference, but probably isn't: '2' on line 1606 -- Looks like a reference, but probably isn't: '3' on line 1502 -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MSEC Working Group B. Weis 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track G. Gross 4 Expires: December 6, 2008 IdentAware Security 5 D. Ignjatic 6 Polycom 7 June 6, 2008 9 Multicast Extensions to the Security Architecture for the Internet 10 Protocol 11 draft-ietf-msec-ipsec-extensions-09.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The Security Architecture for the Internet Protocol describes 45 security services for traffic at the IP layer. That architecture 46 primarily defines services for Internet Protocol (IP) unicast 47 packets. This document describes how the IPsec security services 48 are applied to IP multicast packets. These extensions are relevant 49 only for an IPsec implementation that supports multicast. 51 Table of Contents 53 1. Introduction.....................................................3 54 1.1 Scope.........................................................3 55 1.2 Terminology...................................................4 56 2. Overview of IP Multicast Operation...............................6 57 3. Security Association Modes.......................................6 58 3.1 Tunnel Mode with Address Preservation.........................7 59 4. Security Association.............................................8 60 4.1 Major IPsec Databases.........................................8 61 4.1.1 Group Security Policy Database (GSPD).....................8 62 4.1.2 Security Association Database (SAD)......................11 63 4.1.3 Group Peer Authorization Database (GPAD).................11 64 4.2 Group Security Association (GSA).............................13 65 4.3 Data Origin Authentication...................................16 66 4.4 Group SA and Key Management..................................17 67 4.4.1 Co-Existence of Multiple Key Management Protocols........17 68 5. IP Traffic Processing...........................................17 69 5.1 Outbound IP Traffic Processing...............................17 70 5.2 Inbound IP Traffic Processing................................18 71 6. Security Considerations.........................................21 72 6.1 Security Issues Solved by IPsec Multicast Extensions.........21 73 6.2 Security Issues Not Solved by IPsec Multicast Extensions.....21 74 6.2.1 Outsider Attacks.........................................22 75 6.2.2 Insider Attacks..........................................22 76 6.3 Implementation or Deployment Issues that Impact Security.....23 77 6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities...23 78 6.3.2 Groups that Span Two or More Security Policy Domains.....23 79 6.3.3 Source-Specific Multicast Group Sender Transient Locators23 80 7. IANA Considerations.............................................24 81 8. Acknowledgements................................................24 82 9. References......................................................24 83 9.1 Normative References.........................................24 84 9.2 Informative References.......................................24 85 Appendix A - Multicast Application Service Models..................27 86 A.1 Unidirectional Multicast Applications........................27 87 A.2 Bi-directional Reliable Multicast Applications...............27 88 A.3 Any-To-Any Multicast Applications............................28 89 Appendix B - ASN.1 for a GSPD Entry................................29 90 B.1 Fields specific to an GSPD Entry.............................29 91 B.2 SPDModule....................................................29 92 Author's Address...................................................35 93 Full Copyright Statement...........................................37 94 Intellectual Property..............................................37 95 1. Introduction 97 The Security Architecture for the Internet Protocol [RFC4301] 98 provides security services for traffic at the IP layer. It 99 describes an architecture for IPsec compliant systems, and a set of 100 security services for the IP layer. These security services 101 primarily describe services and semantics for IPsec Security 102 Associations (SAs) shared between two IPsec devices. Typically, 103 this includes SAs with traffic selectors that include a unicast 104 address in the IP destination field, and results in an IPsec packet 105 with a unicast address in the IP destination field. The security 106 services defined in RFC 4301 can also be used to tunnel IP 107 multicast packets, where the tunnel is a pairwise association 108 between two IPsec devices. RFC4301 defined manually keyed 109 transport mode IPsec SA support for IP packets with a multicast 110 address in the IP destination address field. However, RFC4301 did 111 not define the interaction of an IPsec subsystem with a Group Key 112 Management protocol or the semantics of a tunnel mode IPsec SA with 113 an IP multicast address in the outer IP header. 115 This document describes OPTIONAL extensions to RFC 4301 that 116 further define the IPsec security architecture for groups of IPsec 117 devices to share SAs. In particular, it supports SAs with traffic 118 selectors that include a multicast address in the IP destination 119 field, and that result in an IPsec packet with an IP multicast 120 address in the IP destination field. It also describes additional 121 semantics for IPsec Group Key Management (GKM) subsystems. Note 122 that this document uses the term "GKM protocol" generically and 123 therefore it does not assume a particular GKM protocol. 125 An IPsec implementation that does not support multicast is not 126 required to support these extensions. 128 Throughout this document, RFC 4301 semantics remain unchanged by 129 the presence these multicast extensions unless specifically noted 130 to the contrary. 132 1.1 Scope 134 The IPsec extensions described in this document support IPsec 135 Security Associations that result in IPsec packets with IPv4 or 136 IPv6 multicast group addresses as the destination address. Both 137 Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) 138 [RFC3569] group addresses are supported. These extensions are used 139 when management policy requires IP multicast packets protected by 140 IPsec to remain IP multicast packets. When management policy 141 requires that the IP multicast packets are encapsulated as IP 142 unicast packets (e.g., because the network connected to the 143 unprotected interface does not support IP multicast), the 144 extensions in this document are not used. 146 These extensions also support Security Associations with IPv4 147 Broadcast addresses that result in an IPv4 link-level broadcast 148 packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 149 Anycast packet. These destination address types share many of the 150 same characteristics of multicast addresses because there may be 151 multiple candidate receivers of a packet protected by IPsec. 153 The IPsec architecture does not make requirements upon entities not 154 participating in IPsec (e.g., network devices between IPsec 155 endpoints). As such, these multicast extensions do not require 156 intermediate systems in a multicast enabled network to participate 157 in IPsec. In particular, no requirements are placed on the use of 158 multicast routing protocols (e.g., PIM-SM [RFC4601]) or multicast 159 admission protocols (e.g., IGMP [RFC3376]. 161 All implementation models of IPsec (e.g., "bump-in-the-stack", 162 "bump-in-the-wire") are supported. 164 This version of the multicast IPsec extension specification 165 requires that all IPsec devices participating in a Security 166 Association are homogeneous. They MUST share a common set of 167 cryptographic transform and protocol handling capabilities. The 168 semantics of an "IPsec composite group" [COMPGRP], a heterogeneous 169 IPsec cryptographic group formed from the union of two or more sub- 170 groups, is an area for future standardization. 172 1.2 Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 176 this document are to be interpreted as described in RFC 2119 177 [RFC2119]. 179 The following key terms are used throughout this document. 181 Any-Source Multicast (ASM) 182 The Internet Protocol (IP) multicast service model as defined 183 in RFC 1112 [RFC1112]. In this model one or more senders source 184 packets to a single IP multicast address. When receivers join 185 the group, they receive all packets sent to that IP multicast 186 address. This is known as a (*,G) group. 188 Group 189 A set of devices that work together to protect group 190 communications. 192 Group Controller Key Server (GCKS) 193 A Group Key Management (GKM) protocol server that manages IPsec 194 state for a group. A GCKS authenticates and provides the IPsec 195 SA policy and keying material to GKM group members. 197 Group Key Management (GKM) Protocol 198 A key management protocol used by a GCKS to distribute IPsec 199 Security Association policy and keying material. A GKM protocol 200 is used when a group of IPsec devices require the same SAs. For 201 example, when an IPsec SA describes an IP multicast 202 destination, the sender and all receivers need to have the 203 group SA. 205 Group Key Management Subsystem 206 A subsystem in an IPsec device implementing a Group Key 207 Management protocol. The GKM subsystem provides IPsec SAs to 208 the IPsec subsystem on the IPsec device. Refer to RFC 3547 209 [RFC3547] and RFC 4535 [RFC4535] for additional information. 211 Group Member 212 An IPsec device that belongs to a group. A Group Member is 213 authorized to be a Group Sender and/or a Group Receiver. 215 Group Owner 216 An administrative entity that chooses the policy for a group. 218 Group Security Association (GSA) 219 A collection of IPsec Security Associations (SAs) and GKM 220 Subsystem SAs necessary for a Group Member to receive key 221 updates. A GSA describes the working policy for a group. Refer 222 to RFC 4046 [RFC4046] for additional information. 224 Group Security Policy Database (GSPD) 225 The GSPD is a multicast-capable security policy database, as 226 mentioned in RFC3740 and RFC4301 section 4.4.1.1. Its semantics 227 are a superset of the unicast SPD defined by RFC4301 section 228 4.4.1. Unlike a unicast SPD-S in which point-to-point traffic 229 selectors are inherently bi-directional, multicast security 230 traffic selectors in the GSPD-S introduce a "sender only", 231 "receiver only" or "symmetric" directional attribute. Refer to 232 section 4.1.1 for more details. 234 Group Receiver 235 A Group Member that is authorized to receive packets sent to a 236 group by a Group Sender. 238 Group Sender 239 A Group Member that is authorized to send packets to a group. 241 Source-Specific Multicast (SSM) 242 The Internet Protocol (IP) multicast service model as defined 243 in RFC 3569 [RFC3569]. In this model, each combination of a 244 sender and an IP multicast address is considered a group. This 245 is known as an (S,G) group. 247 Tunnel Mode with Address Preservation 248 A type of IPsec tunnel mode used by security gateway 249 implementations when encapsulating IP multicast packets such 250 that they remain IP multicast packets. This mode is necessary 251 for IP multicast routing to correctly route IP multicast 252 packets protected by IPsec. 254 2. Overview of IP Multicast Operation 256 IP multicasting is a means of sending a single packet to a "host 257 group", a set of zero or more hosts identified by a single IP 258 destination address. IP multicast packets are delivered to all 259 members of the group with either "best-efforts" reliability 260 [RFC1112], or as part of a reliable stream (e.g., NORM) [RFC3940]. 262 A sender to an IP multicast group sets the destination of the 263 packet to an IP address that has been allocated for IP multicast. 264 Allocated IP multicast addresses are defined in RFC 3171, RFC 3306, 265 and RFC 3307 [RFC3171] [RFC3306] [RFC3307]. Potential receivers of 266 the packet "join" the IP multicast group by registering with a 267 network routing device [RFC3376] [RFC3810], signaling its intent to 268 receive packets sent to a particular IP multicast group. 270 Network routing devices configured to pass IP multicast packets 271 participate in multicast routing protocols (e.g., PIM-SM) 272 [RFC4601]. Multicast routing protocols maintain state regarding 273 which devices have registered to receive packets for a particular 274 IP multicast group. When a router receives an IP multicast packet, 275 it forwards a copy of the packet out of each interface for which 276 there are known receivers. 278 3. Security Association Modes 280 IPsec supports two modes of use: transport mode and tunnel mode. 281 In transport mode, IP Authentication Header (AH) [RFC4302] and IP 282 Encapsulating Security Payload (ESP) [RFC4303] provide protection 283 primarily for next layer protocols; in tunnel mode, AH and ESP are 284 applied to tunneled IP packets. 286 A host implementation of IPsec using the multicast extensions MAY 287 use either transport mode or tunnel mode to encapsulate an IP 288 multicast packet. These processing rules are identical to the 289 rules described in Section 4.1 of [RFC4301]. However, the 290 destination address for the IPsec packet is an IP multicast 291 address, rather than a unicast host address. 293 A security gateway implementation of IPsec MUST use a tunnel mode 294 SA, for the reasons described in Section 4.1 of [RFC4301]. In 295 particular, the security gateway needs to use tunnel mode to 296 encapsulate incoming fragments, since IPsec cannot directly 297 operate on fragments. 299 3.1 Tunnel Mode with Address Preservation 301 New (tunnel) header construction semantics are required when 302 tunnel mode is used to encapsulate IP multicast packets that are 303 to remain IP multicast packets. These semantics are due to the 304 following unique requirements of IP multicast routing protocols 305 (e.g., PIM-SM [RFC4601]). This document describes these new header 306 construction semantics as "tunnel mode with address preservation", 307 which are described as follows. 309 - When an IP multicast packet is received by a host or router the 310 destination address of the packet is compared to the local IP 311 multicast state. If the (outer) destination IP address of an IP 312 multicast packet is set to another IP address the host or router 313 receiving the IP multicast packet will not process it properly. 314 Therefore, an IPsec security gateway needs to populate the 315 multicast IP destination address in the outer header using the 316 destination address from the inner header after IPsec tunnel 317 encapsulation. 319 - IP multicast routing protocols typically create multicast 320 distribution trees based on the source address as well as the 321 group address. If an IPsec security gateway populates the 322 (outer) source address of an IP multicast packet (with its own 323 IP address, as called for in RFC 4301), the resulting IPsec 324 protected packet may fail Reverse Path Forwarding (RPF) checks 325 performed by other routers. A failed RPF check may result in the 326 packet being dropped. To accommodate routing protocol RPF 327 checks, the security gateway implementing the IPsec multicast 328 extensions SHOULD populate the outer IP address from the 329 original packet IP source address. However, it should be noted 330 that a security gateway performing source address preservation 331 will not receive ICMP PMTU or other messages intended for the 332 security gateway (triggered by packets that have had the outer 333 IP source address set to that of the inner header). Security 334 gateway applications not requiring source address preservation 335 will be able to receive ICMP PMTU messages and process them as 336 described in section 6.1 of RFC 4301. 338 Because some applications of address preservation may require that 339 only the destination address be preserved, specification of 340 destination address preservation and source address preservation 341 are separated in the above description. Destination address 342 preservation and source address preservation attributes are 343 described in the Group Security Policy Database (GSPD) (defined 344 later in this document), and are copied into corresponding SAD 345 entries. 347 Address preservation is applicable only for tunnel mode IPsec SAs 348 that specify the IP version of the encapsulating header to be the 349 same version as that of the inner header. When the IP versions are 350 different, IP multicast packets can be encapsulated using a tunnel 351 interface, for example as described in [RFC4891], where the tunnel 352 is also treated as an interface by IP multicast routing protocols. 354 In summary, propagating both the IP source and destination 355 addresses of the inner IP header into the outer (tunnel) header 356 allows IP multicast routing protocols to route a packet properly 357 when the packet is protected by IPsec. This result is necessary in 358 order for the multicast extensions to allow a host or security 359 gateway to provide IPsec services for IP multicast packets. This 360 method of RFC 4301 tunnel mode is known as "tunnel mode with 361 address preservation". 363 4. Security Association 365 4.1 Major IPsec Databases 367 The following sections describe the GKM Subsystem and IPsec 368 extension interactions with the IPsec databases. The major IPsec 369 databases need expanded semantics to fully support multicast. 371 4.1.1 Group Security Policy Database (GSPD) 373 The Group Security Policy Database is a security policy database 374 capable of supporting both unicast security associations as 375 defined by RFC 4301 and the multicast extensions defined by this 376 specification. The GSPD is considered to be the SPD, with the 377 addition of the semantics relating to the multicast extensions 378 described in this section. Appendix B provides an example of an 379 ASN.1 definition of a GSPD entry. 381 This document describes a new "Address Preservation" (AP) flag 382 indicating that tunnel mode with address preservation is to be 383 applied to a GSPD entry. The AP flag has two attributes: AP-L used 384 in the processing of the local tunnel address, and AP-R used in the 385 processing of the remote tunnel process. This flag is added to the 386 GSPD "Processing info" field of the GSDP. The following text 387 reproduced from Section 4.4.1.2 of RFC 4301 includes this 388 additional processing. (Note: for brevity, only the Processing info 389 related to tunnel processing has been reproduced.) 391 o Processing info -- which action is required -- PROTECT, 392 BYPASS, or DISCARD. There is just one action that goes 393 with all the selector sets, not a separate action for each 394 set. If the required processing is PROTECT, the entry 395 contains the following information. 396 - IPsec mode -- tunnel or transport 397 - (if tunnel mode) local tunnel address -- For a non 398 mobile host, if there is just one interface, this is 399 straightforward; if there are multiple interfaces, this 400 must be statically configured. For a mobile host, the 401 specification of the local address is handled 402 externally to IPsec. If tunnel mode with address 403 preservation is specified for the local tunnel address, 404 the AP-L attribute is set to TRUE for the local tunnel 405 address and the local tunnel address is unspecified. 406 The presence of the AP-L attribute indicates that the 407 inner IP header source address will be copied to the 408 outer IP header source address during IP header 409 construction for tunnel mode. 410 - (if tunnel mode) remote tunnel address -- There is no 411 standard way to determine this. See 4.5.3, "Locating a 412 Security Gateway". If tunnel mode with address 413 preservation is specified for the remote tunnel 414 address, the AP-R attribute is set to TRUE for the 415 remote tunnel address and the remote tunnel address is 416 unspecified. The presence of the AP-R attribute 417 indicates that the inner IP header destination address 418 will be copied to the outer IP header destination 419 address during IP header construction for tunnel mode. 421 This document describes unique directionality processing for GSPD 422 entries with a remote IP multicast address. Since an IP multicast 423 address must not be sent as the source address of an IP packet 424 [RFC1112], directionality of Local and Remote address and ports is 425 maintained during incoming SPD-S and SPD-I checks rather than 426 being swapped. Section 4.4.1 of RFC 4301 is amended as follows: 428 Representing Directionality in an SPD Entry 430 For traffic protected by IPsec, the Local and Remote 431 address and ports in an SPD entry are swapped to 432 represent directionality, consistent with IKE 433 conventions. In general, the protocols that IPsec 434 deals with have the property of requiring symmetric 435 SAs with flipped Local/Remote IP addresses. However, 436 SPD entries with a remote IP multicast address do not 437 have their Local and Remote address and ports in an 438 SPD entry swapped during incoming SPD-S and SPD-I 439 checks. 441 A new Group Security Policy Database (GSPD) attribute is 442 introduced: GSPD entry directionality. The following text is added 443 to the bullet list of SPD fields described in Section 4.4.1.2 of 444 RFC 4301. 445 o Directionality -- can one of three types: "symmetric", 446 "sender only" or "receiver only". "Symmetric" indicates 447 that a pair of SAs are to be created (one in each 448 direction as specified by RFC 4301). GSPD entries marked 449 as "sender only" indicate that one SA is to be created in 450 the outbound direction. GSPD entries marked as "receiver 451 only" indicate that one SA is to be created in the inbound 452 direction. GSPD entries marked as "sender only" or 453 "receiver only" SHOULD support multicast IP addresses in 454 their destination address selectors. If the processing 455 requested is BYPASS or DISCARD and a "sender only" type is 456 configured the entry MUST be put in GSPD-O only. 457 Reciprocally, if the type is "receiver only", the entry 458 MUST go to GSPD-I only. 460 GSPD entries created by a GCKS may be assigned identical SPIs to 461 SAD entries created by IKEv2 [RFC4306]. This is not a problem for 462 the inbound traffic as the appropriate SAs can be matched using 463 the algorithm described in RFC 4301 section 4.1. However, the 464 outbound traffic needs to be matched against the GSPD selectors so 465 that the appropriate SA can be created. 467 To facilitate dynamic group keying, the outbound GSPD MUST 468 implement a policy action capability that triggers a GKM protocol 469 registration exchange (as per Section 5.1 of [RFC4301]). For 470 example, the Group Sender GSPD policy might trigger on a match 471 with a specified multicast application packet entering the 472 implementation via the protected interface, or emitted by the 473 implementation on the protected side of the boundary and directed 474 toward the unprotected interface. The ensuing Group Sender 475 registration exchange would set up the Group Sender's outbound SAD 476 entry that encrypts the multicast application's data stream. In 477 the inverse direction, group policy may also set up an inbound 478 IPsec SA. 480 At the Group Receiver endpoint(s), the IPsec subsystem MAY use 481 GSPD policy mechanisms that initiate a GKM protocol registration 482 exchange. One such policy mechanism might be on the detection of a 483 device in the protected network joining a multicast group matching 484 GSPD policy (e.g., by receiving a IGMP/MLD join group message on a 485 protected interface). The ensuing Group Receiver registration 486 exchange would set up the Group Receiver's inbound SAD entry that 487 decrypts the multicast application's data stream. In the inverse 488 direction, the group policy may also set up an outbound IPsec SA 489 (e.g., when supporting an ASM service model). 491 Note: A security gateway triggering on the receipt of 492 unauthenticated messages arriving on a protected interface may 493 result in early Group Receiver registration if the message is not 494 the result of a device on the protected network actually wishing 495 to join a multicast group. The unauthenticated messages will only 496 cause the Group Receiver to register once; subsequent messages 497 will have no effect on the Group Receiver. 499 The IPsec subsystem MAY provide GSPD policy mechanisms that 500 automatically initiate a GKM protocol de-registration exchange. 501 De-registration allows a GCKS to minimize exposure of the group's 502 secret key by re-keying a group on a group membership change 503 event. It also minimizes cost on a GCKS for those groups that 504 maintain member state. One such policy mechanism could be the 505 detection of IGMP/MLD leave group exchange. However, a security 506 gateway Group Member would not initiate a GKM protocol de- 507 registration exchange until it detects that there are no more 508 receivers behind a protected interface. 510 Additionally, the GKM subsystem MAY set up the GSPD/SAD state 511 information independent of the multicast application's state. In 512 this scenario, the group's Group Owner issues management 513 directives that tell the GKM subsystem when it should start GKM 514 registration and de-registration protocol exchanges. Typically the 515 registration policy strives to make sure that the group's IPsec 516 subsystem state is "always ready" in anticipation of the multicast 517 application starting its execution. 519 4.1.2 Security Association Database (SAD) 521 The SAD contains an item describing whether tunnel or transport 522 mode is applied to traffic on this SA. The text in RFC 4301 Section 523 4.4.2.1 is amended to describe Address Preservation. 525 o IPsec protocol mode: tunnel or transport. Indicates which 526 mode of AH or ESP is applied to traffic on this SA. When 527 tunnel mode is specified, the data item also indicates 528 whether or not address preservation is applied to the 529 outer IP header. Address preservation MUST NOT be 530 specified when the IP version of the encapsulating header 531 and IP version of the inner header do not match. The local 532 address, remote address, or both addresses MAY be marked 533 as being preserved during tunnel encapsulation. 535 4.1.3 Group Peer Authorization Database (GPAD) 537 The multicast IPsec extensions introduce a new data structure 538 called the Group Peer Authorization Database (GPAD). The GPAD is 539 analogous to the PAD defined in RFC 4301. It provides a link 540 between the GSPD and a Group Key Management (GKM) Subsystem. The 541 GPAD embodies the following critical functions: 543 o identifies a GCKS (or group of GCKS devices) that are 544 authorized to communicate with this IPsec entity 545 o specifies the protocol and method used to authenticate 546 each GCKS 547 o provides the authentication data for each GKCS 548 o constrains the traffic selectors that can be asserted by a 549 GCKS with regard to SA creation 550 o constrains the types and values of Group Identifiers for 551 which an GCKS is authorized to provide group policy 553 The GPAD provides these functions for a Group Key Management 554 Subsystem. The GPAD is not consulted by IKE or other 555 authentication protocols that do not act as a GKM protocol. 557 To provide these functions, the GPAD contains an entry for each 558 GCKS to which the IPsec entity is configured to contact. An entry 559 contains a one or more GCKS Identifiers, the authentication 560 protocol (e.g., GDOI or GSKAMP), authentication method used (e.g., 561 certificates or pre-shared secrets), and the authentication data 562 (e.g., the pre-shared secret or trust anchor relative to which the 563 peer's certificate will be validated). For certificate-based 564 authentication, the entry also may provide information to assist in 565 verifying the revocation status of the peer, e.g., a pointer to a 566 CRL repository or the name of an Online Certificate Status Protocol 567 (OCSP) server associated with the peer or with the trust anchor 568 associated with the peer. The entry also contains constraints a 569 Group Member applies to the policy received from the GKCS. 571 4.1.3.1 GCKS Identifiers 573 GCKS Identifiers are used to identify one or more devices that are 574 authorized to act as a GCKS for this group. GCKS Identifiers are 575 specified as PAD Entry IDs in Section 4.4.3.1 of RFC 4301 and 576 follow the matching rules described therein. 578 4.1.3.2 GCKS Peer Authentication Data 580 Once a GPAD entry is located, it is necessary to verify the 581 asserted identity, i.e., to authenticate the asserted GCKS 582 Identifier. PAD Authentication data types and semantics specified 583 in Section 4.4.3.2 of RFC 4301 are used to authenticate a GCKS. 585 See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM 586 protocol performs peer authentication using certificates and pre- 587 shared secrets. 589 4.1.3.3 Group Identifier Authorization Data 591 A Group Identifier is used by a GCK protocol to identify a 592 particular Group to a GCKS. A GPAD entry includes a Group 593 Identifier to indicate that the GKCS Identifiers in the GPAD entry 594 are authorized to act as a GCKS for the Group. 596 The Group Identifier is an opaque byte string of IKE ID type Key ID 597 that identifies a secure multicast group. The Group Identifier byte 598 string MUST be at least four bytes long and less than 256 bytes 599 long. 601 IKE ID types other than Key ID MAY be supported. 603 4.1.3.4 IPsec SA Traffic Selector Authorization Data 605 Once a GCKS is authenticated, the GCKS delivers IPsec SA policy to 606 the Group Member. Before the Group Member accepts the IPsec SA 607 Policy, the source and destination traffic selectors of the SA are 608 compared to a set of authorized data flows. Each data flow includes 609 a set of authorized source traffic selectors and a set of 610 authorized destination traffic selectors. Traffic selectors are 611 represented as a set of IPv4 and/or IPv6 address ranges. (A peer 612 may be authorized for both address types, so there MUST be 613 provision for both v4 and v6 address ranges.) 615 4.1.3.5 How the GPAD Is Used 617 When a GKM protocol registration exchange is triggered, the Group 618 Member and GCKS each assert their identity as a part of the 619 exchange. Each GKM protocol registration exchange MUST use the 620 asserted ID to locate an identity in the GPAD. The GPAD entry 621 specifies the authentication method to be employed for the 622 identified GCKS. The entry also specifies the authentication data 623 that will be used to verify the asserted identity. This data is 624 employed in conjunction with the specified method to authenticate 625 the GCKS, before accepting any group policy from the GCKS. 627 During the GKM protocol registration, a Group Member includes a 628 Group identifier. Before presenting that Group Identifier to the 629 GCKS, a Group Member verifies that the GPAD entry for 630 authenticated GCKS GPAD entry includes the Group Identifier. This 631 ensures that the GCKS is authorized to provide policy for the 632 Group. 634 When IPsec SA policy is received, each data flow is compared to 635 the data flows in the GPAD entry. The Group Member accepts policy 636 matching a data flow. Policy not matching a data flow is 637 discarded, and the reason SHOULD be recorded in the audit log. 639 A GKM protocol may distribute IPsec SA policy to IPsec devices 640 that have previously registered with it. The method of 641 distribution is part of the GKM protocol, and is outside the scope 642 of this memo. When the IPsec device receives this new policy, it 643 compares the policy to the data flows in the GPAD entry as 644 described above. 646 4.2 Group Security Association (GSA) 648 An IPsec implementation supporting these extensions will support a 649 number of security associations: one or more IPsec SAs, and one or 650 more GKM SAs used to download the parameters used to create IPsec 651 SAs [RFC3740]. These SAs are collectively referred to as a Group 652 Security Association (GSA). 654 4.2.1 Concurrent IPsec SA Life Spans and Re-key Rollover 656 During a secure multicast group's lifetime, multiple IPsec group 657 security associations can exist concurrently. This occurs 658 principally due to two reasons: 660 - There are multiple Group Senders authorized in the group, each 661 with its own IPsec SA which maintains anti-replay state. A group 662 that does not rely on IP Security anti-replay services can share 663 one IPsec SA for all of its Group Senders. 665 - The life spans of a Group Sender's two (or more) IPsec SAs are 666 allowed to overlap in time, so that there is continuity in the 667 multicast data stream across group re-key events. This capability 668 is referred to as "re-key rollover continuity". 670 The rekey continuity rollover algorithm depends on an IPsec SA 671 management interface between the GKM subsystem and the IPsec 672 subsystem. The IPsec subsystem MUST provide management interface 673 mechanisms for the GKM subsystem to add IPsec SAs and to delete 674 IPsec SAs. For illustrative purposes, this text defines the rekey 675 rollover continuity algorithm in terms of two timer parameters 676 that govern IPsec SA lifespans relative to the start of a group 677 rekey event. However, it should be emphasized that the GKM 678 subsystem interprets the group's security policy to direct the 679 correct timing of IPsec SA activation and deactivation. A given 680 group policy may choose timer values that differ from those 681 recommended by this text. The two rekey rollover continuity timer 682 parameters are: 684 1. Activation Time Delay (ATD) - The ATD defines how long after the 685 start of a rekey event to activate new IPsec SAs. The ATD 686 parameter is expressed in units of seconds. Typically, the ATD 687 parameter is set to the maximum time it takes to deliver a 688 multicast message from the GCKS to all of the group's members. 689 For a GCKS that relies on a Reliable Multicast Transport 690 Protocol (RMTP), the ATD parameter could be set equal to the 691 RTMP protocol's maximum error recovery time. When a RMTP is not 692 present, the ATD parameter might be set equal to the network's 693 maximum multicast message delivery latency across all of the 694 group's endpoints. The ATD is a GKM group policy parameter. This 695 value SHOULD be configurable at the Group Owner management 696 interface on a per group basis. 698 2. Deactivation Time Delay (DTD) - The DTD defines how long after 699 the start of a rekey event to deactivate those IPsec SAs that 700 are destroyed by the rekey event. The purpose of the DTD 701 parameter is to minimize the residual exposure of a group's 702 keying material after a rekey event has retired that keying 703 material. The DTD is independent of and should not to be 704 confused with the IPsec SA soft lifetime attribute. The DTD 705 parameter is expressed in units of seconds. Typically, the DTD 706 parameter would be set to the ADT plus the maximum time it takes 707 to deliver a multicast message from the Group Sender to all of 708 the group's members. For a Group Sender that relies on a RMTP, 709 the DTD parameter could be set equal to ADT plus the RTMP 710 protocol's maximum error recovery time. When a RMTP is not 711 present, the DTD parameter might be set equal to ADT plus the 712 network's maximum multicast message delivery latency across all 713 of the group's endpoints. A GKM subsystem MAY implement the DTD 714 as a group security policy parameter. If a GKM subsystem does 715 not implement the DTD parameter then other group security policy 716 mechanisms MUST determine when to deactivate an IPsec SA. 718 Each group re-key multicast message sent by a GCKS signals the 719 start of a new Group Sender IPsec SA time epoch, with each such 720 epoch having an associated set of two IPsec SAs. Note that this 721 document refers to re-key mechanisms as being multicast because of 722 the inherent scalability of IP multicast distribution. However, 723 there is no particular reason that re-keying mechanisms must be 724 multicast. For example, [ZLLY03] describes a method of re-key 725 employing both unicast and multicast messages. 727 The group membership interacts with these IPsec SAs as follows: 729 - As a precursor to the Group Sender beginning its re-key rollover 730 continuity processing, the GCKS periodically multicasts a Re-Key 731 Event (RKE) message to the group. The RKE multicast MAY contain 732 group policy directives, new IPsec SA policy, and group keying 733 material. In the absence of a RMTP, the GCKS may re-transmit the 734 RKE a policy-defined number of times to improve the availability 735 of re-key information. The GKM subsystem starts the ATD and DTD 736 timers after it receives the last RKE retransmission. 738 - The GKM subsystem interprets the RKE multicast to configure the 739 group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that 740 replaces an existing SA is called a "leading edge" IPsec SA. The 741 leading edge IPsec SA has a new Security Parameter Index (SPI) 742 and its associated keying material keys it. For a time period of 743 ATD seconds in duration after the GCKS multicasts the RKE, a 744 Group Sender does not yet transmit data using the leading edge 745 IPsec SA. Meanwhile, other Group Members prepare to use this 746 IPsec SA by installing the new IPsec SAs to their respective 747 GSPD/SAD. 749 - After waiting for the ATD period, such that all of the Group 750 Members have received and processed the RKE message, the GKM 751 subsystem directs the Group Sender to begin to transmit using the 752 leading edge IPsec SA with its data encrypted by the new keying 753 material. Only authorized Group Members can decrypt these IPsec 754 SA multicast transmissions. 756 - The Group Sender's "trailing edge" SA is the oldest security 757 association in use by the group for that sender. All authorized 758 Group Members can receive and decrypt data for this SA, but the 759 Group Sender does not transmit new data using the trailing edge 760 IPsec SA after it has transitioned to the leading edge IPsec SA. 761 The trailing edge IPsec SA is deleted by the group's GKM 762 subsystems after the DTD time period has elapsed since the RKE 763 transmission. 765 This re-key rollover strategy allows the group to drain its in 766 transit datagrams from the network while transitioning to the 767 leading edge IPsec SA. Staggering the roles of each respective 768 IPsec SA as described above improves the group's synchronization 769 even when there are high network propagation delays. Note that due 770 to group membership joins and leaves, each Group Sender IPsec SA 771 time epoch may have a different group membership set. 773 It is a group policy decision whether the re-key event transition 774 between epochs provides forward and backward secrecy. The group's 775 re-key protocol keying material and algorithm (e.g., Logical Key 776 Hierarchy, refer to [RFC2627] and Appendix A of [RFC4535]) enforces 777 this policy. Implementations MAY offer a Group Owner management 778 interface option to enable/disable re-key rollover continuity for a 779 particular group. This specification requires that a GKM/IPsec 780 implementation MUST support at least two concurrent IPsec SA per 781 Group Sender and this re-key rollover continuity algorithm. 783 4.3 Data Origin Authentication 785 As defined in [RFC4301], data origin authentication is a security 786 service that verifies the identity of the claimed source of data. 787 A Message Authentication Code (MAC) is often used to achieve data 788 origin authentication for connections shared between two parties. 789 However, typical MAC authentication methods using a single shared 790 secret are not sufficient to provide data origin authentication 791 for groups with more than two parties. With a MAC algorithm, every 792 group member can use the MAC key to create a valid MAC tag, 793 whether or not they are the authentic originator of the group 794 application's data. 796 When the property of data origin authentication is required for an 797 IPsec SA shared by more than two parties, an authentication 798 transform where receiver is assured that the sender generated that 799 message should be used. Two possible algorithms are TESLA 800 [RFC4082] or RSA digital signature [RFC4359]. 802 In some cases, (e.g., digital signature authentication transforms) 803 the processing cost of the algorithm is significantly greater than 804 an HMAC authentication method. To protect against denial of 805 service attacks from a device that is not authorized to join the 806 group, the IPsec SA using this algorithm may be encapsulated with 807 an IPsec SA using a MAC authentication algorithm. However, doing 808 so requires the packet to be sent across the IPsec boundary a 809 second time for additional outbound processing on the Group Sender 810 (see Section 5.1 of [RFC4301] and a second time for inbound 811 processing on Group Receivers (see Section 5.2 of [RFC4301]). This 812 use of AH or ESP encapsulated within AH or ESP accommodates the 813 constraint that AH and ESP define an Integrity Check Value (ICV) 814 for only a single authenticator transform. 816 4.4 Group SA and Key Management 818 4.4.1 Co-Existence of Multiple Key Management Protocols 820 Often, the GKM subsystem will be introduced to an existent IPsec 821 subsystem as a companion key management protocol to IKEv2 822 [RFC4306]. A fundamental GKM protocol IP Security subsystem 823 requirement is that both the GKM protocol and IKEv2 can 824 simultaneously share access to a common Group Security Policy 825 Database and Security Association Database. The mechanisms that 826 provide mutually exclusive access to the common GSPD/SAD data 827 structures are a local matter. This includes the GSPD-outbound 828 cache and the GSPD-inbound cache. However, implementers should note 829 that IKEv2 SPI allocation is entirely independent from GKM SPI 830 allocation because group security associations are qualified by a 831 destination multicast IP address and may optionally have a source 832 IP address qualifier. See [RFC4303, Section 2.1] for further 833 explanation. 835 The Peer Authorization Database does require explicit coordination 836 between the GKM protocol and IKEv2. Section 4.1.3 describes these 837 interactions. 839 5. IP Traffic Processing 841 Processing of traffic follows Section 5 of [RFC4301], with the 842 additions described below when these IP multicast extensions are 843 supported. 845 5.1 Outbound IP Traffic Processing 847 If an IPsec SA is marked as supporting tunnel mode with address 848 preservation (as described in Section 3.1), either or both of the 849 outer header source or destination addresses are marked as being 850 preserved. 852 Header construction for tunnel mode is described in Section 5.1.2 853 of RFC 4301. The first bullet of that section is amended as 854 follows: 856 o If address preservation is not marked in the SAD entry for 857 either the outer IP header Source Address or Destination 858 Address, the outer IP header Source Address and 859 Destination Address identify the "endpoints" of the tunnel 860 (the encapsulator and decapsulator). If address 861 preservation is marked for the IP header Source Address, 862 it is copied from the inner IP header Source Address. If 863 address preservation is marked for the IP header 864 Destination Address, it is copied from the inner IP header 865 Destination Address. The inner IP header Source Address 866 and Destination Addresses identify the original sender and 867 recipient of the datagram (from the perspective of this 868 tunnel), respectively. Address preservation MUST NOT be 869 marked when the IP version of the encapsulating header and 870 IP version of the inner header do not match. 872 Note (3) regarding construction of tunnel addresses in Section 873 5.1.2.1 of RFC 4301 is amended as follows: 875 (3) Unless marked for address preservation Local and Remote 876 addresses depend on the SA, which is used to determine 877 the Remote address, which in turn determines which Local 878 address (net interface) is used to forward the packet. 879 If address preservation is marked for the Local address, 880 it is copied from the inner IP header. If address 881 preservation is marked for the Remote address, that 882 address is copied from the inner IP header. 884 5.2 Inbound IP Traffic Processing 886 IPsec-protected packets generated by an IPsec device supporting 887 these multicast extensions may (depending on its GSPD policy) 888 populate an outer tunnel header with a destination address such 889 that it is not an IPsec device. This requires an IPsec device 890 supporting these multicast extensions to accept and process IP 891 traffic that is not addressed to the IPsec device itself. The 892 following additions to IPsec inbound IP traffic processing are 893 necessary. 895 For compatibility with RFC 4301, the phrase "addressed to this 896 device" is taken to mean packets with a unicast destination address 897 belonging to the system itself, and multicast packets that are 898 received by the system itself. However, multicast packets not 899 received by the IPsec device are not considered addressed to this 900 device. 902 The discussion of processing Inbound IP Traffic described in 903 Section 5.2 of RFC 4301 is amended as follows. The first dash in 904 item 2 is amended as follows: 906 - If the packet appears to be IPsec protected and it is 907 addressed to this device, or appears to be IPsec protected 908 and is addressed to a multicast group, an attempt is made 909 to map it to an active SA via the SAD. 911 A new item is added to the list between items 3a and 3b to describe 912 processing of IPsec packets with destination address preservation 913 applied: 915 3aa. If the packet is addressed to a multicast group and AH 916 or ESP is specified as the protocol, the packet is looked 917 up in the SAD. Use the SPI plus the destination or SPI 918 plus destination and source addresses, as specified in 919 Section 4.1. If there is no match, the packet is directed 920 to SPD-I lookup. Note that if the IPsec device is a 921 security gateway, and the SPD-I policy is to PYPASS the 922 packet, a subsequent security gateway along the routed 923 path of the multicast packet may decrypt the packet. 925 Figure 3 in RFC 4301 is updated to show the new processing path 926 defined in item 3aa. 928 Unprotected Interface 929 | 930 V 931 +-----+ IPsec protected 932 ------------------->|Demux|-------------------+ 933 | +-----+ | 934 | | | 935 | Not IPsec | | 936 | | IPsec protected not | 937 | V addressed to device | 938 | +-------+ +---------+ and not in SAD | 939 | |DISCARD|<---|SPD-I (*)|<------------+ | 940 | +-------+ +---------+ | | 941 | | | | 942 | |-----+ | | 943 | | | | | 944 | | V | | 945 | | +------+ | | 946 | | | ICMP | | | 947 | | +------+ | | 948 | | | V 949 +---------+ | +-----------+ 950 ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec 951 +---------+ | | (AH/ESP) | Boundary 952 ^ | +-----------+ 953 | | +---+ | 954 | BYPASS | +-->|IKE| | 955 | | | +---+ | 956 | V | V 957 | +----------+ +---------+ +----+ 958 |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| 959 nested SAs +----------+ | (***) | +----+ 960 | +---------+ 961 V 962 Protected Interface 964 Figure 1. Processing Model for Inbound Traffic 965 (amending Figure 3 of RFC 4301) 967 The discussion of processing Inbound IP Traffic described in 968 Section 5.2 of RFC 4301 is amended to insert a new item 6 as 969 follows. 971 6. If an IPsec SA is marked as supporting tunnel mode with 972 address preservation (as described in Section 3.1), the 973 marked address(es) (i.e., source and/or destination 974 address) in the outer IP header MUST be verified to be the 975 same value(s) as in the inner IP header. If the addresses 976 are not consistent, the IPsec system MUST discard the 977 packet, as well as treat the inconsistency as an auditable 978 event. 980 6. Security Considerations 982 The IP security multicast extensions defined by this specification 983 build on the unicast-oriented IP security architecture [RFC4301]. 984 Consequently, this specification inherits many of the RFC4301 985 security considerations and the reader is advised to review it as 986 companion guidance. 988 6.1 Security Issues Solved by IPsec Multicast Extensions 990 The IP security multicast extension service provides the following 991 network layer mechanisms for secure group communications: 993 - Confidentiality using a group shared encryption key. 995 - Group source authentication and integrity protection using a 996 group shared authentication key. 998 - Group Sender data origin authentication using a digital 999 signature, TESLA, or other mechanism. 1001 - Anti-replay protection for a limited number of Group Senders 1002 using the ESP (or AH) sequence number facility. 1004 - Filtering of multicast transmissions identified with a source 1005 address of systems that are not authorized by group policy to be 1006 Group Senders. This feature leverages the IPsec state-less 1007 firewall service (i.e., SPD-I and/or SDP-O entries with a packet 1008 disposition specified as DISCARD). 1010 In support of the above services, this specification enhances the 1011 definition of the SPD, PAD, and SAD databases to facilitate the 1012 automated group key management of large-scale cryptographic groups. 1014 6.2 Security Issues Not Solved by IPsec Multicast Extensions 1016 As noted in RFC4301 section 2.2, it is out of scope of this 1017 architecture to defend the group's keys or its application data 1018 against attacks targeting vulnerabilities of the operating 1019 environment in which the IPsec implementation executes. However, it 1020 should be noted that the risk of attacks originating by an 1021 adversary in the network is magnified to the extent that the group 1022 keys are shared across a large number of systems. 1024 The security issues that are left unsolved by the IPsec multicast 1025 extension service divide into two broad categories: outsider 1026 attacks, and insider attacks. 1028 6.2.1 Outsider Attacks 1030 The IPsec multicast extension service does not defend against an 1031 Adversary outside of the group who has: 1033 - the capability to launch a multicast flooding denial-of-service 1034 attack against the group, originating from a system whose IPsec 1035 subsystem does not filter the unauthorized multicast 1036 transmissions. 1038 - compromised a multicast router, allowing the Adversary to corrupt 1039 or delete all multicast packets destined for the group endpoints 1040 downstream from that router. 1042 - captured a copy of an earlier multicast packet transmission and 1043 then replayed it to a group that does not have the anti-replay 1044 service enabled. Note that for a large-scale any-source multicast 1045 group, it is impractical for the Group Receivers to maintain an 1046 anti-replay state for every potential Group Sender. Group 1047 policies that require anti-replay protection for a large-scale 1048 any-source-multicast group should consider an application layer 1049 multicast protocol that can detect and reject replays. 1051 6.2.2 Insider Attacks 1053 For large-scale groups, the IP security multicast extensions are 1054 dependent on an automated Group Key Management protocol to 1055 correctly authenticate and authorize trustworthy members in 1056 compliance to the group's policies. Inherent in the concept of a 1057 cryptographic group is a set of one or more shared secrets 1058 entrusted to all of the group's members. Consequently, the 1059 service's security guarantees are no stronger than the weakest 1060 member admitted to the group by the GKM system. The GKM system is 1061 responsible for responding to compromised group member detection by 1062 executing a re-key procedure. The GKM re-keying protocol will expel 1063 the compromised group members and distribute new group keying 1064 material to the trusted members. Alternatively, the group policy 1065 may require the GKM system to terminate the group. 1067 In the event that an Adversary has been admitted into the group by 1068 the GKM system, the following attacks are possible and they can not 1069 be solved by the IPsec multicast extension service: 1071 - The Adversary can disclose the secret group key or group data to 1072 an unauthorized party outside of the group. After a group key or 1073 data compromise, cryptographic methods such as traitor tracing or 1074 watermarking can assist in the forensics process. However, these 1075 methods are outside the scope of this specification. 1077 - The insider Adversary can forge packet transmissions that appear 1078 to be from a peer group member. To defend against this attack for 1079 those Group Sender transmissions that merit the overhead, the 1080 group policy can require the Group Sender to multicast packets 1081 using the data origin authentication service. 1083 - If the group's data origin authentication service uses digital 1084 signatures, then the insider Adversary can launch a computational 1085 resource denial of service attack by multicasting bogus signed 1086 packets. 1088 6.3 Implementation or Deployment Issues that Impact Security 1090 6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities 1092 The IP security multicast extensions service can not defend against 1093 a poorly considered group security policy that allows a weaker 1094 cryptographic algorithm simply because all of the group's endpoints 1095 are known to support it. Unfortunately, large-scale groups can be 1096 difficult to upgrade to the current best in class cryptographic 1097 algorithms. One possible approach to solving many of these problems 1098 is the deployment of composite groups that can straddle 1099 heterogeneous groups [COMPGRP]. A standard solution for 1100 heterogeneous groups is an activity for future standardization. In 1101 the interim, synchronization of a group's cryptographic 1102 capabilities could be achieved using a secure and scalable software 1103 distribution management tool. 1105 6.3.2 Groups that Span Two or More Security Policy Domains 1107 Large-scale groups may span multiple legal jurisdictions (e.g 1108 countries) that enforce limits on cryptographic algorithms or key 1109 strengths. As currently defined, the IPsec multicast extension 1110 service requires a single group policy per group. As noted above, 1111 this problem remains an area for future standardization. 1113 6.3.3 Source-Specific Multicast Group Sender Transient Locators 1115 A Source Specific Multicast (SSM) Group Sender's source IP address 1116 can dynamically change during a secure multicast group's lifetime. 1117 Examples of the events that can cause the Group Sender's source 1118 address to change include but are not limited to NAT, a mobility 1119 induced change in the care-of-address, and a multi-homed host 1120 using a new IP interface. The change in the Group Sender's source 1121 IP address will cause those GSPD entries related to that multicast 1122 group to become out of date with respect to the group's multicast 1123 routing state. In the worst case, there is a risk that the Group 1124 Sender's data originating from a new source address will be BYPASS 1125 processed by a security gateway. If this scenario was not 1126 anticipated, then it could leak the group's data. Consequently, it 1127 is recommended that SSM secure multicast groups have a default 1128 DISCARD policy for all unauthorized Group Sender source IP 1129 addresses for the SSM group's destination IP address. 1131 7. IANA Considerations 1133 This document has no actions for IANA. 1135 8. Acknowledgements 1137 The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, 1138 and Tero Kivinen for their helpful comments. 1140 The "Guidelines for Writing RFC Text on Security Considerations" 1141 [RFC3552] was consulted to develop the Security Considerations 1142 section of this memo. 1144 9. References 1146 9.1 Normative References 1148 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1149 1112, August 1989. 1151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1152 Requirement Level", BCP 14, RFC 2119, March 1997. 1154 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1155 Internet Protocol", RFC 4301, December 2005. 1157 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 1158 2005. 1160 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1161 4303, December 2005. 1163 9.2 Informative References 1165 [COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security 1166 Composite Cryptographic Groups", draft-ietf-msec-ipsec- 1167 composite-group-01.txt, work in progress, February 2007. 1169 [RFC2526] Johnson, D., and S. Deering, "Reserved IPv6 Subnet 1170 Anycast Addresses", RFC 2526, March 1999. 1172 [RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for 1173 Multicast: Issues and Architectures", RFC 2627, 1174 September 1998. 1176 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 1177 September 2000. 1179 [RFC3171] Albanni, Z., et al., "IANA Guidelines for IPv4 1180 Multicast Address Assignments", RFC 3171, August 2001. 1182 [RFC3306] Haberman B. and D. Thaler, "Unicast-Prefix-based IPv6 1183 Multicast Addresses", RFC3306, August 2002. 1185 [RFC3307] Haberman B., "Allocation Guidelines for IPv6 Multicast 1186 Addresses", RFC3307, August 2002. 1188 [RFC3376] Cain, B., et al., "Internet Group Management Protocol, 1189 Version 3", RFC 3376, October 2002. 1191 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1192 Group Domain of Interpretation", RFC 3547, December 1193 2002. 1195 [RFC3552] Rescorla, E., et al., "Guidelines for Writing RFC Text on 1196 Security Considerations", RFC 3552, July 2003. 1198 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1199 Multicast (SSM)", RFC 3569, July 2003. 1201 [RFC3740] Hardjono, T., and B. Weis, "The Multicast Group Security 1202 Architecture", RFC 3740, March 2004. 1204 [RFC3810] Vida, R., and L. Costa, "Multicast Listener Discovery 1205 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1207 [RFC3940] Adamson, B., et al., "Negative-acknowledgment (NACK)- 1208 Oriented Reliable Multicast (NORM) Protocol", RFC 3940, 1209 November 2004. 1211 [RFC4046] Baugher, M., Dondeti, L., Canetti, R., and F. Lindholm, 1212 "Multicast Security (MSEC) Group Key Management 1213 Architecture", RFC4046, April 2005. 1215 [RFC4082] Perrig, A., et al., "Timed Efficient Stream Loss- 1216 Tolerant Authentication (TESLA): Multicast Source 1217 Authentication Transform Introduction", RFC 4082, June 1218 2005. 1220 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1221 RFC 4306, December 2005. 1223 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 1224 Encapsulating Security Payload (ESP) and Authentication 1225 Header (AH)", RFC 4359, January 2006. 1227 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1228 "GSAKMP: Group Secure Association Key Management 1229 Protocol", RFC 4535, June 2006. 1231 [RFC4601] Fenner, B., et al., "Protocol Independent Multicast - 1232 Sparse Mode (PIM-SM): Protocol Specification 1233 (Revised)", RFC 4601, August 2006. 1235 [RFC4891] Graveman R., et al., "Using IPsec to Secure IPv6-in-IPv4 1236 Tunnels", RFC 4891, May 2007. 1238 [ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and 1239 Reliable Group Rekeying", IEEE/ACM Transactions on 1240 Networking (TON), Volume 11, Issue 6, December 2003. See 1241 http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.p 1242 df. 1244 Appendix A - Multicast Application Service Models 1246 The vast majority of secure multicast applications can be 1247 catalogued by their service model and accompanying intra-group 1248 communication patterns. Both the Group Key Management (GKM) 1249 Subsystem and the IPsec subsystem MUST be able to configure the 1250 GSPD/SAD security policies to match these dominant usage scenarios. 1251 The GSPD/SAD policies MUST include the ability to configure both 1252 Any-Source-Multicast groups and Source-Specific-Multicast groups 1253 for each of these service models. The GKM Subsystem management 1254 interface MAY include mechanisms to configure the security policies 1255 for service models not identified by this standard. 1257 A.1 Unidirectional Multicast Applications 1259 Multi-media content delivery multicast applications that do not 1260 have congestion notification or retransmission error recovery 1261 mechanisms are inherently unidirectional. RFC 4301 only defines bi- 1262 directional unicast traffic selectors (as per sections 4.4.1 and 1263 5.1 with respect to traffic selector directionality). The GKM 1264 Subsystem requires that the IPsec subsystem MUST support 1265 unidirectional SPD entries, which cause a Group Security 1266 Association (GSA) to be installed in only one direction. Multicast 1267 applications that have only one group member authorized to transmit 1268 can use this type of group security association to enforce that 1269 group policy. In the inverse direction, the GSA does not have a SAD 1270 entry, and the GSPD configuration is optionally set up to discard 1271 unauthorized attempts to transmit unicast or multicast packets to 1272 the group. 1274 The GKM Subsystem's management interface MUST have the ability to 1275 set up a GKM Subsystem group having a unidirectional GSA security 1276 policy. 1278 A.2 Bi-directional Reliable Multicast Applications 1280 Some secure multicast applications are characterized as one Group 1281 Sender to many receivers, but with inverse data flows required by a 1282 reliable multicast transport protocol (e.g., NORM). In such 1283 applications, the data flow from the sender is multicast, and the 1284 inverse flow from the group's receivers is unicast to the sender. 1285 Typically, the inverse data flows carry error repair requests and 1286 congestion control status. 1288 For such applications, it is advantageous to use the same IPsec SA 1289 for protection of both unicast and multicast data flows. This does 1290 introduce one risk: the IKEv2 application may choose the same SPI 1291 for receiving unicast traffic as the GCKS chooses for a group 1292 IPsec SA covering unicast traffic. If both SAs are installed in 1293 the SAD, the SA lookup may return the wrong SPI as the result of 1294 an SA lookup. To avoid this problem, IPsec SAs installed by the 1295 GKM SHOULD use the 2-tuple {destination IP address, SPI} to 1296 identify each IPsec SA. In addition, the GKM SHOULD use a unicast 1297 destination IP address that does not match any destination IP 1298 address in use by an IKE-v2 unicast IPsec SA. For example, suppose 1299 a Group Member is using both IKEv2 and a GKM protocol, and the 1300 group security policy requires protecting the NORM inverse data 1301 flows as described above. In this case, group policy SHOULD 1302 allocate and use a unique unicast destination IP address 1303 representing the NORM Group Sender. This address would be 1304 configured in parallel to the Group Sender's existing IP 1305 addresses. The GKM subsystems at both the NORM Group Sender and 1306 Group Receiver endpoints would install the IPsec SA protecting the 1307 NORM unicast messages such that the SA lookup uses the unicast 1308 destination address as well as the SPI. 1310 The GSA SHOULD use IPsec anti-replay protection service for the 1311 sender's multicast data flow to the group's receivers. Because of 1312 the scalability problem described in the next section, it is not 1313 practical to use the IPsec anti-replay service for the unicast 1314 inverse flows. Consequently, in the inverse direction the IPsec 1315 anti-replay protection MUST be disabled. However, the unicast 1316 inverse flows can use the group's IPsec group authentication 1317 mechanism. The group receiver's GSPD entry for this GSA SHOULD be 1318 configured to only allow a unicast transmission to the sender node 1319 rather than a multicast transmission to the whole group. 1321 If an ESP digital signature authentication is available (e.g., RFC 1322 4359), source authentication MAY be used to authenticate a receiver 1323 node's transmission to the sender. The GKM protocol MUST define a 1324 key management mechanism for the Group Sender to validate the 1325 asserted signature public key of any receiver node without 1326 requiring that the sender maintain state about every group 1327 receiver. 1329 This multicast application service model is RECOMMENDED because it 1330 includes congestion control feedback capabilities. Refer to 1331 [RFC2914] for additional background information. 1333 The GKM Subsystem's Group Owner management interface MUST have the 1334 ability to set up a symmetric GSPD entry and one Group Sender. The 1335 management interface SHOULD be able to configure a group to have at 1336 least 16 concurrent authorized senders, each with their own GSA 1337 anti-replay state. 1339 A.3 Any-To-Any Multicast Applications 1341 Another family of secure multicast applications exhibits an "any to 1342 many" communications pattern. A representative example of such an 1343 application is a videoconference combined with an electronic 1344 whiteboard. 1346 For such applications, all (or a large subset) of the Group Members 1347 are authorized multicast senders. In such service models, creating 1348 a distinct IPsec SA with anti-replay state for every potential 1349 sender does not scale to large groups. The group SHOULD share one 1350 IPsec SA for all of its senders. The IPsec SA SHOULD NOT use the 1351 IPsec anti-replay protection service for the sender's multicast 1352 data flow to the Group Receivers. 1354 The GKM Subsystem's management interface MUST have the ability to 1355 set up a group having an Any-To-Many Multicast GSA security policy. 1357 Appendix B - ASN.1 for a GSPD Entry 1359 This appendix describes an additional way to describe GSPD entries, 1360 as defined in Section 4.1.1. It uses ASN.1 syntax that has been 1361 successfully compiled. This syntax is merely illustrative and need 1362 not be employed in an implementation to achieve compliance. The 1363 GSPD description in Section 4.1.1 is normative. As shown in Section 1364 4.1.1, the GSPD updates the SPD and thus this appendix updates the 1365 SPD object identifier. 1367 B.1 Fields specific to an GSPD Entry 1369 The following fields summarize the fields of the GSPD that are not 1370 present in the SPD. 1372 - direction (in IPsecEntry) 1373 - DirectionFlags 1374 - noswap (in SelectorList) 1375 - ap-l, ap-r (in TunnelOptions) 1377 B.2 SPDModule 1379 SPDModule 1381 {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) 1382 ipsec (8) asn1-modules (3) spd-module (1) } 1384 DEFINITIONS IMPLICIT TAGS ::= 1386 BEGIN 1388 IMPORTS 1389 RDNSequence FROM PKIX1Explicit88 1390 { iso(1) identified-organization(3) 1391 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1392 id-mod(0) id-pkix1-explicit(18) } ; 1394 -- An SPD is a list of policies in decreasing order of 1395 preference 1396 SPD ::= SEQUENCE OF SPDEntry 1397 SPDEntry ::= CHOICE { 1398 iPsecEntry IPsecEntry, -- PROTECT 1399 traffic 1400 bypassOrDiscard [0] BypassOrDiscardEntry } -- 1401 DISCARD/BYPASS 1403 IPsecEntry ::= SEQUENCE { -- Each entry consists of 1404 name NameSets OPTIONAL, 1405 pFPs PacketFlags, -- Populate from packet flags 1406 -- Applies to ALL of the corresponding 1407 -- traffic selectors in the SelectorLists 1408 direction DirectionFlags, -- SA directionality 1409 condition SelectorLists, -- Policy "condition" 1410 processing Processing -- Policy "action" 1411 } 1413 BypassOrDiscardEntry ::= SEQUENCE { 1414 bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD 1415 condition InOutBound } 1417 InOutBound ::= CHOICE { 1418 outbound [0] SelectorLists, 1419 inbound [1] SelectorLists, 1420 bothways [2] BothWays } 1422 BothWays ::= SEQUENCE { 1423 inbound SelectorLists, 1424 outbound SelectorLists } 1426 NameSets ::= SEQUENCE { 1427 passed SET OF Names-R, -- Matched to IKE ID by 1428 -- responder 1429 local SET OF Names-I } -- Used internally by IKE 1430 -- initiator 1432 Names-R ::= CHOICE { -- IKEv2 IDs 1433 dName RDNSequence, -- ID_DER_ASN1_DN 1434 fqdn FQDN, -- ID_FQDN 1435 rfc822 [0] RFC822Name, -- ID_RFC822_ADDR 1436 keyID OCTET STRING } -- KEY_ID 1438 Names-I ::= OCTET STRING -- Used internally by IKE 1439 -- initiator 1441 FQDN ::= IA5String 1443 RFC822Name ::= IA5String 1445 PacketFlags ::= BIT STRING { 1446 -- if set, take selector value from packet 1447 -- establishing SA 1448 -- else use value in SPD entry 1449 localAddr (0), 1450 remoteAddr (1), 1451 protocol (2), 1452 localPort (3), 1453 remotePort (4) } 1455 DirectionFlags ::= BIT STRING { 1456 -- if set, install SA in the specified 1457 -- direction. symmetric policy is 1458 -- represented by setting both bits 1459 inbound (0), 1460 outbound (1) } 1462 SelectorLists ::= SET OF SelectorList 1464 SelectorList ::= SEQUENCE { 1465 localAddr AddrList, 1466 remoteAddr AddrList, 1467 protocol ProtocolChoice, 1468 noswap BOOLEAN } -- Do not swap local and remote 1469 -- addresses and ports on incoming 1470 -- SPD-S and SPD-I checks 1472 Processing ::= SEQUENCE { 1473 extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit 1474 seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit 1475 fragCheck BOOLEAN, -- TRUE stateful fragment checking, 1476 -- FALSE no stateful fragment checking 1477 lifetime SALifetime, 1478 spi ManualSPI, 1479 algorithms ProcessingAlgs, 1480 tunnel TunnelOptions OPTIONAL } -- if absent, use 1481 -- transport mode 1483 SALifetime ::= SEQUENCE { 1484 seconds [0] INTEGER OPTIONAL, 1485 bytes [1] INTEGER OPTIONAL } 1487 ManualSPI ::= SEQUENCE { 1488 spi INTEGER, 1489 keys KeyIDs } 1491 KeyIDs ::= SEQUENCE OF OCTET STRING 1493 ProcessingAlgs ::= CHOICE { 1494 ah [0] IntegrityAlgs, -- AH 1495 esp [1] ESPAlgs} -- ESP 1497 ESPAlgs ::= CHOICE { 1498 integrity [0] IntegrityAlgs, -- integrity only 1499 confidentiality [1] ConfidentialityAlgs, -- confidentiality 1500 -- only 1501 both [2] IntegrityConfidentialityAlgs, 1502 combined [3] CombinedModeAlgs } 1504 IntegrityConfidentialityAlgs ::= SEQUENCE { 1505 integrity IntegrityAlgs, 1506 confidentiality ConfidentialityAlgs } 1508 -- Integrity Algorithms, ordered by decreasing preference 1509 IntegrityAlgs ::= SEQUENCE OF IntegrityAlg 1511 -- Confidentiality Algorithms, ordered by decreasing preference 1512 ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg 1514 -- Integrity Algorithms 1515 IntegrityAlg ::= SEQUENCE { 1516 algorithm IntegrityAlgType, 1517 parameters ANY -- DEFINED BY algorithm -- OPTIONAL } 1519 IntegrityAlgType ::= INTEGER { 1520 none (0), 1521 auth-HMAC-MD5-96 (1), 1522 auth-HMAC-SHA1-96 (2), 1523 auth-DES-MAC (3), 1524 auth-KPDK-MD5 (4), 1525 auth-AES-XCBC-96 (5) 1526 -- tbd (6..65535) 1527 } 1529 -- Confidentiality Algorithms 1530 ConfidentialityAlg ::= SEQUENCE { 1531 algorithm ConfidentialityAlgType, 1532 parameters ANY -- DEFINED BY algorithm -- OPTIONAL } 1534 ConfidentialityAlgType ::= INTEGER { 1535 encr-DES-IV64 (1), 1536 encr-DES (2), 1537 encr-3DES (3), 1538 encr-RC5 (4), 1539 encr-IDEA (5), 1540 encr-CAST (6), 1541 encr-BLOWFISH (7), 1542 encr-3IDEA (8), 1543 encr-DES-IV32 (9), 1544 encr-RC4 (10), 1545 encr-NULL (11), 1546 encr-AES-CBC (12), 1547 encr-AES-CTR (13) 1548 -- tbd (14..65535) 1549 } 1551 CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg 1553 CombinedModeAlg ::= SEQUENCE { 1554 algorithm CombinedModeType, 1555 parameters ANY -- DEFINED BY algorithm -- } 1556 -- defined outside 1557 -- of this document for AES modes. 1559 CombinedModeType ::= INTEGER { 1560 comb-AES-CCM (1), 1561 comb-AES-GCM (2) 1562 -- tbd (3..65535) 1563 } 1565 TunnelOptions ::= SEQUENCE { 1566 dscp DSCP, 1567 ecn BOOLEAN, -- TRUE Copy CE to inner header 1568 ap-l BOOLEAN, -- TRUE Copy inner IP header 1569 -- source address to outer 1570 -- IP header source address 1571 ap-r BOOLEAN, -- TRUE Copy inner IP header 1572 -- destination address to outer 1573 -- IP header destination address 1574 df DF, 1575 addresses TunnelAddresses } 1577 TunnelAddresses ::= CHOICE { 1578 ipv4 IPv4Pair, 1579 ipv6 [0] IPv6Pair } 1581 IPv4Pair ::= SEQUENCE { 1582 local OCTET STRING (SIZE(4)), 1583 remote OCTET STRING (SIZE(4)) } 1585 IPv6Pair ::= SEQUENCE { 1586 local OCTET STRING (SIZE(16)), 1587 remote OCTET STRING (SIZE(16)) } 1589 DSCP ::= SEQUENCE { 1590 copy BOOLEAN, -- TRUE copy from inner header 1591 -- FALSE do not copy 1592 mapping OCTET STRING OPTIONAL} -- points to table 1593 -- if no copy 1595 DF ::= INTEGER { 1596 clear (0), 1597 set (1), 1598 copy (2) } 1600 ProtocolChoice::= CHOICE { 1601 anyProt AnyProtocol, -- for ANY protocol 1602 noNext [0] NoNextLayerProtocol, -- has no next layer 1603 -- items 1604 oneNext [1] OneNextLayerProtocol, -- has one next layer 1605 -- item 1606 twoNext [2] TwoNextLayerProtocol, -- has two next layer 1607 -- items 1608 fragment FragmentNoNext } -- has no next layer 1609 -- info 1611 AnyProtocol ::= SEQUENCE { 1612 id INTEGER (0), -- ANY protocol 1613 nextLayer AnyNextLayers } 1615 AnyNextLayers ::= SEQUENCE { -- with either 1616 first AnyNextLayer, -- ANY next layer selector 1617 second AnyNextLayer } -- ANY next layer selector 1619 NoNextLayerProtocol ::= INTEGER (2..254) 1621 FragmentNoNext ::= INTEGER (44) -- Fragment identifier 1623 OneNextLayerProtocol ::= SEQUENCE { 1624 id INTEGER (1..254), -- ICMP, MH, ICMPv6 1625 nextLayer NextLayerChoice } -- ICMP Type*256+Code 1626 -- MH Type*256 1628 TwoNextLayerProtocol ::= SEQUENCE { 1629 id INTEGER (2..254), -- Protocol 1630 local NextLayerChoice, -- Local and 1631 remote NextLayerChoice } -- Remote ports 1633 NextLayerChoice ::= CHOICE { 1634 any AnyNextLayer, 1635 opaque [0] OpaqueNextLayer, 1636 range [1] NextLayerRange } 1638 -- Representation of ANY in next layer field 1639 AnyNextLayer ::= SEQUENCE { 1640 start INTEGER (0), 1641 end INTEGER (65535) } 1643 -- Representation of OPAQUE in next layer field. 1644 -- Matches IKE convention 1645 OpaqueNextLayer ::= SEQUENCE { 1646 start INTEGER (65535), 1647 end INTEGER (0) } 1649 -- Range for a next layer field 1650 NextLayerRange ::= SEQUENCE { 1651 start INTEGER (0..65535), 1652 end INTEGER (0..65535) } 1654 -- List of IP addresses 1655 AddrList ::= SEQUENCE { 1656 v4List IPv4List OPTIONAL, 1657 v6List [0] IPv6List OPTIONAL } 1659 -- IPv4 address representations 1660 IPv4List ::= SEQUENCE OF IPv4Range 1662 IPv4Range ::= SEQUENCE { -- close, but not quite right ... 1663 ipv4Start OCTET STRING (SIZE (4)), 1664 ipv4End OCTET STRING (SIZE (4)) } 1666 -- IPv6 address representations 1667 IPv6List ::= SEQUENCE OF IPv6Range 1669 IPv6Range ::= SEQUENCE { -- close, but not quite right ... 1670 ipv6Start OCTET STRING (SIZE (16)), 1671 ipv6End OCTET STRING (SIZE (16)) } 1673 END 1675 Author's Address 1677 Brian Weis 1678 Cisco Systems 1679 170 W. Tasman Drive, 1680 San Jose, CA 95134-1706 1681 USA 1683 Phone: +1-408-526-4796 1684 Email: bew@cisco.com 1686 George Gross 1687 IdentAware Security 1688 977 Bates Road 1689 Shoreham, VT 05770 1690 USA 1692 Phone: +1-908-268-1629 1693 Email: gmgross@identaware.com 1694 Dragan Ignjatic 1695 Polycom 1696 1000 W. 14th Street 1697 North Vancouver, BC V7P 3P3 1698 Canada 1700 Phone: +1-604-982-3424 1701 Email: dignjatic@polycom.com 1703 Full Copyright Statement 1705 Copyright (C) The IETF Trust (2008). 1707 This document is subject to the rights, licenses and restrictions 1708 contained in BCP 78, and except as set forth therein, the authors 1709 retain all their rights. 1711 This document and the information contained herein are provided on 1712 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1713 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1714 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1715 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1716 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1717 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1718 FOR A PARTICULAR PURPOSE. 1720 Intellectual Property 1722 The IETF takes no position regarding the validity or scope of any 1723 Intellectual Property Rights or other rights that might be claimed 1724 to pertain to the implementation or use of the technology 1725 described in this document or the extent to which any license 1726 under such rights might or might not be available; nor does it 1727 represent that it has made any independent effort to identify any 1728 such rights. Information on the procedures with respect to rights 1729 in RFC documents can be found in BCP 78 and BCP 79. 1731 Copies of IPR disclosures made to the IETF Secretariat and any 1732 assurances of licenses to be made available, or the result of an 1733 attempt made to obtain a general license or permission for the use 1734 of such proprietary rights by implementers or users of this 1735 specification can be obtained from the IETF on-line IPR repository 1736 at http://www.ietf.org/ipr. 1738 The IETF invites any interested party to bring to its attention 1739 any copyrights, patents or patent applications, or other 1740 proprietary rights that may cover technology that may be required 1741 to implement this standard. Please address the information to the 1742 IETF at ietf-ipr@ietf.org. 1744 Acknowledgement 1746 Funding for the RFC Editor function is provided by the IETF 1747 Administrative Support Activity (IASA).