idnits 2.17.1 draft-ietf-msec-mesp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 145: '...cation transform SHOULD describe any p...' RFC 2119 keyword, line 191: '...recy (GS) transform MUST precede group...' RFC 2119 keyword, line 199: '...ing for SrA: SrA MUST follow GS. Digit...' RFC 2119 keyword, line 221: '...signature, it is REQUIRED that TESLA a...' RFC 2119 keyword, line 223: '...digital signature or TESLA MAC MUST be...' (25 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 (March 2003) is 7713 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: 'RFC2119' is mentioned on line 77, but not defined == Missing Reference: 'RFC2828' is mentioned on line 77, but not defined ** Obsolete undefined reference: RFC 2828 (Obsoleted by RFC 4949) == Missing Reference: 'ESPbis' is mentioned on line 376, but not defined == Missing Reference: 'AHbis' is mentioned on line 240, but not defined == Unused Reference: 'AHBIS' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'GDOI' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'GSAKMP' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'MIKEY' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC2451' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'TESLA' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'Ch' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'PCTS' is defined on line 613, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (ref. 'AHBIS') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'ESPBIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GDOI' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSAKMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIKEY' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'TESLA' -- Unexpected draft version: The latest known version of draft-canetti-secure-multicast-taxonomy is -00, but you're referring to -01. Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Mark Baugher (Cisco Systems) 3 MSEC Working Group Ran Canetti (IBM Watson) 4 INTERNET-DRAFT Pau-Chen Cheng (IBM Watson) 5 Pankaj Rohatgi (IBM Watson) 6 EXPIRES: September 2003 March 2003 8 MESP: A Multicast Framework for the IPsec ESP 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 Multicast ESP (MESP) is a framework for multicast data-origin 35 authentication using the IPsec Encapsulating Security Payload (ESP) 36 protocol. The MESP framework combines group-secrecy, group- 37 authentication, and source-authentication transforms in an ESP 38 packet. MESP uses a message authentication code for group 39 authentication to protect a digital signature, TESLA timed MAC, or 40 other multicast source-authentication transform. 42 TABLE OF CONTENTS 44 1.0 Notational Conventions..........................................2 45 2.0 Introduction....................................................2 46 2.1 Changes from the Previous Version..............................3 47 2.2 Overview.......................................................3 48 3.0 IP Multicast Security Functionalities...........................3 49 3.1 Composition of the Functionalities.............................4 50 3.2 MESP Security Association Database.............................5 51 4.0 MESP Packet Format.............................................5 52 4.1 MESP Transforms................................................7 53 4.1.1 Group Secrecy..............................................7 54 4.1.2 Internal Authentication....................................7 55 4.1.3 External Authentication....................................7 56 4.2 MESP Signaling.................................................7 57 4.2.1 GDOI.......................................................7 58 4.2.2 GSAKMP.....................................................8 59 4.2.3 MIKEY......................................................8 60 5.0 Security Considerations.........................................8 61 5.1 MESP Authentication............................................8 62 5.2 MESP Denial-of-Service Protection..............................9 63 5.3 MESP Encryption................................................9 64 6.0 IANA Considerations............................................10 65 7.0 Acknowledgements...............................................11 66 8.0 Author's Address...............................................11 67 9.0 References.....................................................11 68 9.1 Normative References..........................................11 69 9.2 Informative References........................................12 71 1.0 Notational Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 76 The terminology conforms to [RFC2828]. 78 2.0 Introduction 80 The IPsec Encapsulation Security Payload (ESP) provides a set of 81 security services that include data origin authentication, which 82 enables an IPsec receiver to validate that a received packet 83 originated from a peer-sender in a pairwise security association 84 [Section 3.1, RFC2401]. A Message Authentication Code (MAC), such 85 as the hash-based message authentication code [RFC2104, RFC2404] 86 (HMAC), is the common means to provide data-origin authentication 87 for pairwise IPsec security associations. For secure groups such as 88 IP multicast groups, however, a MAC supports only "group 89 authentication" and not data-origin authentication [CP]. This 90 Internet-Draft document (I-D) defines a framework for ESP data- 91 origin authentication that is suitable for IP multicast groups of 92 ESP receivers. 94 2.1 Changes from the Previous Version 96 This version is not a protocol, unlike the previous version, but is 97 a transform framework for ESP and realizes all of its functions 98 within the ESP protocol. MESP now imposes an additional structure 99 and usage on IPsec ESP Initialization Vector (IV) and Integrity 100 Check Value (ICV) fields [ESPbis]. 102 A smaller change that appears in this version of MESP is the 103 requirement that TESLA authentication be protected by external 104 authentication transform such as a MAC. 106 2.2 Overview 108 This I-D assumes that the reader is familiar with the "Security 109 Architecture for Internet Protocol" [RFC2401] and the "IP 110 Encapsulating Security Payload (ESP)" [ESPBIS] RFCs. Section 3 111 reviews the functionalities of group data-security transforms for 112 applications such as media streaming, process control, and reliable 113 multicast applications. Section 3 describes the problem of 114 authenticating the source when the data-authentication key is shared 115 by more than two IPsec endpoints. Section 4 describes the MESP 116 framework in terms of the extensions and use of the ESP IV and 117 integrity-check-value fields. The three functionalities of the MESP 118 framework are realized in cryptographic transforms that are secure 119 for various uses, and Section 5 recites the security considerations 120 for each MESP transform. Section 5 considers IP multicast risks, 121 the transforms that address a particular risk, and the suitability 122 of a transform for various applications and environments. 124 3.0 IP Multicast Security Functionalities 126 The security requirements for multicast have been discussed in [CP]. 127 In general, group security has different requirements and 128 characteristics than pairwise security. In particular, data-origin 129 authentication using a MAC will not prevent one member from 130 impersonating another when a group of three or more members share 131 the symmetric authentication key. There are three new 132 functionalities needed to add data-origin authentication to ESP. 134 a) Group Secrecy (GS) 136 The GS functionality is ESP confidentiality applied to a group . It 137 ensures that transmitted data are accessible only to group members 138 (i.e. two or more hosts in possession of a shared symmetric key). 139 This can also be viewed as a way to enforce access control. A 140 typical realization of GS is to encrypt data using a key known only 141 to group members. Essentially, the solution for multicast is the 142 same as the solution for unicast confidentiality. It is important 143 to note, however, that some encryption transforms have special 144 considerations when a key is shared among multiple senders. An MESP 145 encryption or authentication transform SHOULD describe any potential 146 risks of multicast operation and how those risks are averted. 148 b) Group Authentication (GA) 150 The GA functionality enables a group member to verify that 151 the received data originated from someone in the group and was not 152 modified en-route by a non-group member. Note that group 153 authentication by itself does not identify the source of the 154 data. For example, the data might have been forged by any malicious 155 group member. GA can be efficiently realized using standard shared 156 key authentication mechanisms such as Message Authentication Codes 157 (MACs), e.g., CBC-MAC, HMAC, or UMAC. 159 c) Source and Data Authentication (SrA) 161 The SrA functionality enables a group member to verify that 162 the received data originated from the claimed source and was not 163 modified en-route by anyone (including other malicious group 164 members). Unlike Group Authentication, SrA provides the IPsec data- 165 origin authentication function [RFC2401, ESPbis]. Source and Data 166 Authentication provides a much stronger security guarantee than 167 Group Authentication in that a particular group member can be 168 identified as a source of a packet. Group and multicast source 169 authentication requires stronger cryptographic techniques such as 170 digital signatures, stream signatures [GR], flow signatures [WL], 171 hybrid signatures [R], timed MACs, e.g. TESLA [TESLA, 172 Ch,PCTS],asymmetric MACs [CGIMNP], etc. 174 3.1 Composition of the Functionalities 176 A secure multicast solution is likely to utilize all three of the 177 basic functionalities. Due to the diversity of the various 178 application and deployment scenarios for multicast, several issues 179 arise with respect to the composition and ordering of these 180 functionalities. 182 In ESP, encryption precedes authentication when both are applied and 183 a "combined-mode" confidentiality/integrity operation is not used 184 [Section 3.3.2 of ESPBIS]. Combined modes of encryption and 185 authentication are supported in ESP [ESPbis] but are not considered 186 in this version of MESP. Encryption first is an efficient ordering 187 that allows the receiver to apply a message authentication code 188 (MAC) before it runs a more computationally-intensive decryption; 189 fast authentication before decryption offers a better defense 190 against bogus packets from a denial of service attack. In MESP, 191 therefore, the group secrecy (GS) transform MUST precede group 192 authentication (GA) when GS is used. In other words, the sender 193 applies GS prior to GA and the receiver applies GA prior to GS. 194 Krawczyk has shown that it is more secure to authenticate encrypted 195 data rather than encrypt authenticated data [K], but this ordering 196 does not provide non-repudiation. The latter is usually not needed 197 or even desirable for IPsec applications. 199 MESP uses the same ordering for SrA: SrA MUST follow GS. Digital 200 signatures offer the simplest method for multicast source 201 authentication (SrA) but are computationally expensive, greatly 202 expand the packet size and impractical for many, if not most, packet 203 flows. Given the relatively high cost of signature verification, a 204 digital signature leaves the receiver vulnerable to denial of 205 service attack when an attacker succeeds in getting the receiver to 206 perform signature validation of bad packets. 208 MESP partially protects the receiver from denial-of-service attacks 209 from bogus digitally-signed packets by applying a MAC to the packet 210 after signing it. MESP calls this MAC "external authentication" and 211 applies it in an identical fashion to ESP. The digital signature is 212 called "internal authentication," which the sender applies to the 213 packet payload before the MAC. MAC authentication, therefore, is 214 applied first by the receiver. If the attacker is not a member of 215 the group, or otherwise has not obtained the group key, the MAC will 216 fail before the receiver incurs the burden of a signature 217 validation. 219 SrA transforms such as TESLA timed-MAC can be more efficient than 220 digital signatures for many applications. But like a digital 221 signature, it is REQUIRED that TESLA and other SrA transforms use 222 internal authentication in MESP and be protected by an external- 223 authentication MAC. Thus, a digital signature or TESLA MAC MUST be 224 applied prior to GA at the sender and after GA at the receiver. 225 MAC-based GA is an external-authentication transform that MUST be 226 applied last at the sender and first at the receiver. As in ESP, 227 encryption (GS) is applied before any authentication and is 228 optional. 230 3.2 MESP Security Association Database 232 The MESP framework applies up to three transforms to a multicast ESP 233 packet in the order described above: Group Secrecy (GS) is OPTIONAL, 234 Source Authentication (SrA) SHOULD be applied next, and Group 235 Authentication (GA) SHOULD be applied last. The IPsec SAD MUST be 236 extended to store the additional transform information if MESP is to 237 be supported. 239 There are no changes to ESP SA lookup beyond what is specified for 240 multicast SAs in the IPsec specifications [AHbis, ESPbis]. 242 4.0 MESP Packet Format 243 The ESP Packet format is illustrated in Figure 4-1: 245 * Internal Authentication Parameters (variable). The length and 246 contents of this field are defined by the SrA transform. Certain 247 internal authentication transforms have a zero length SrA Transform 248 Parameters fields (Section 5.1). 250 * Internal Authentication Tag (Variable). The length and contents 251 of this field are defined by the internal authentication transform. 252 Certain SrA transforms have a zero length Internal Authentication 253 Tag field. 255 Figure 4-1: MESP Transforms in an ESP Packet 257 0 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Security Parameters Index (SPI) | ^ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 262 | Sequence Number | ^ | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 264 ~ IV (variable & optional) ~ | | 265 +---------------------------------------------------------------+ | | 266 ~ Internal Authentication Parameters (variable & optional) ~ | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 268 ~ Data (variable) ~^ I E 269 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E N X 270 ~ ~ Padding (0-255 bytes) |N T T 271 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C | | 272 | | Pad Length | Next Header |v v | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 274 ~ Internal Authentication Tag (variable) ~ v 275 +---------------------------------------------------------------+ 276 ~ Integrity Check Value (variable) ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Encryption (ENC), when applied, covers the ESP data, padding and 280 next header fields. Internal Authentication (INT) covers the ESP 281 sequence number through the next header field, inclusive. External 282 authentication (EXT) covers the entire ESP packet except for the 283 Integrity Check Value (ICV) field. 285 A sender MAY use an encryption-transform (ENC) as done in any other 286 ESP packet. 288 When INT is applied to the packet, its output (if any) is placed in 289 the Internal Authentication Tag. Section 4.1 identifies the INT 290 transforms, which the sender MUST perform prior to the encryption 291 transform. 293 A sender of an MESP packet SHOULD use an external-authentication 294 transform (EXT). Section 4.1 identifies the EXT transforms, which 295 the sender MUST perform last (and the receiver performs first). 297 The sender MUST perform the MESP transforms in the order of ENC, 298 INT, and EXT while the receiver MUST perform them in the order of 299 EXT, INT and ENC. 301 4.1 MESP Transforms 303 This version of MESP defines a minimal number of transforms. In the 304 future, new transforms MAY be added through the publication of an 305 Internet RFC. The transforms of the MESP framework are listed below 306 and classified according to MESP type. 308 4.1.1 Group Secrecy 310 MESP supports 3DES, AES-CBC, and AES-CTR. 312 4.1.2 Internal Authentication 314 MESP internal authentication is either RSA-SHA1 or TESLA. 316 4.1.3 External Authentication 318 MESP external authentication uses HMAC-SHA1. 320 4.2 MESP Signaling 322 MESP parameters are signaled through a key management protocol or 323 interface such as GDOI, GSAKMP, GKMP, or SDP. 325 4.2.1 GDOI 327 GDOI MUST signal use of the MESP framework using PROTO_ESP_MESP with 328 the TRANSFORM ID set to the MESP transform ID value (see IANA 329 Section below). MESP extends the RFC 2407 attributes ["IPsec 330 Security Association Attributes," IANA] with the three new classes, 331 "ENC_Transform, "INT_Transform," and "EXT_Transform" (see IANA 332 Section below). 334 The ENC Transform MUST be one of the transforms from 4.1.1. 335 Additional ENC transforms MAY be added to this suite through the 336 publication of an Internet RFC. 338 The INT Transform MUST be non-null and MUST be one of the values 339 from 4.1.2. Additional INT transforms MAY be added to this suite 340 through the publication of an Internet RFC. 342 The EXT Transform MUST be one of the transforms from 4.1.3. 343 Additional EXT transforms MAY be added to this suite through the 344 publication of an Internet RFC. 346 The IANA Considerations section of this document describes value 347 assignments for the EXT, INT and ENC attributes. 349 The SA Life Type and Life Duration as defined in RFC 2407 [RFC2407, 350 IANA] apply to all keys used for the session, including the 351 Signature PubKey, which MUST NOT be sent if the INT Transform is not 352 a digital signature algorithm. The length of the encoding is 353 determined by INT. {Editor: Need to define the Signature PubKey 354 format and should make it a GDOI KD payload item instead.} 356 4.2.2 GSAKMP 358 TBD 360 4.2.3 MIKEY 362 TBD 364 5.0 Security Considerations 366 MESP is a framework for IPsec ESP authentication and encryption 367 transforms to support IP multicast delivery. IPsec ESP provides 368 access control, rejection of replayed packets, confidentiality 369 (encryption), limited traffic-flow confidentiality and 370 connectionless integrity. ESP supports a datagram environment where 371 each IP packet is cryptographically independent of other IP packets 372 and can be decrypted, authenticated, and integrity checked when 373 delayed, reordered, or when other packets from the flow are lost. 374 ESP provides rejection of replayed packets for pairwise security 375 associations and for multicast security associations under certain 376 circumstances [ESPbis]. MESP has the same replay mechanism for the 377 single-sender case; the multi-sender case is for further study. ESP 378 provides data origin authentication for pairwise security 379 associations using symmetric message authentication codes, which are 380 not sufficient for group security applications where more than two 381 members share a symmetric key. 383 5.1 MESP Authentication 385 The MESP framework for ESP provides data-origin authentication 386 services to multicast ESP packets. Secure groups, such as secure 387 multicast groups, cannot use a symmetric-key MAC to uniquely 388 identify the sender; any group member that is in possession of the 389 group authentication key is capable of replacing the source address 390 of the packet with that of another group member and applying the 391 symmetric key to authenticate the packet. To uniquely identify a 392 sender among a group of members, digital signature, public key 393 encryption, or specialized source-authentication techniques such as 394 timed MACs are needed. This version of MESP defines a general ESP 395 packet structure for accommodating a digital signature or TESLA 396 timed MAC. 398 5.2 MESP Denial-of-Service Protection 400 As discussed above, a group member cannot authenticate the source of 401 the packet for a multicast group where multiple members share the 402 MAC key. Thus, a rogue member of the group has all the keying 403 material needed to impersonate a sender of the group if that 404 attacker is able to inject packets into the network using that 405 sender's IP address. The MESP framework addresses this problem by 406 augmenting the MAC with an "internal authentication" transform, 407 which MAY be an RSA-SHA1 digital signature or a TESLA timed MAC. 408 Digital signatures leave multicast receivers vulnerable to denial- 409 of-service attack if the receiver is duped into performing 410 computationally-expensive signature validation of bogus packets. An 411 external message authentication SHOULD accompany a digital signature 412 so as to limit the effectiveness of bogus digitally signed packets 413 by non-group members. TESLA is also vulnerable to a denial of 414 service attack if the receiver is duped into storing bogus packets 415 awaiting MAC verification. An external message authentication 416 transform SHOULD accompany a TESLA authentication transform so as to 417 limit the effectiveness of bogus TESLA packets by non-group members. 419 Unfortunately, group members are still capable of sending packets 420 with a valid external-authenticating MAC and invalid digital 421 signature, i.e. a group member can launch a DoS attack on the group 422 using invalid digital signatures. And group members are still 423 capable of sending packets with a valid external-authentication MAC 424 but an invalid TESLA MAC. In both the TESLA and digital-signature 425 cases, the external authentication will succeed only to have the 426 internal authentication fail. MESP includes the ESP sequence number 427 in the internal authentication to protect against a replay attack by 428 a group member. When the RECOMMENDED external authentication code 429 is use, however, the ESP receiver MUST validate both the internal 430 authentication as well as the external authentication before 431 updating the ESP replay window. 433 The value of MESP authentication transforms is to enable the 434 receiver to greatly reduce the effect of an attack by non-group 435 members, to reduce the effects of a denial of service attack by a 436 group member, to detect an attack by a group member, and to support 437 the integration of multicast source-authentication transforms into 438 IPsec ESP for data-origin authentication. 440 5.3 MESP Encryption 442 The value of MESP encryption is to validate individual encryption 443 transforms for multicast operation. It is possible that a 444 particular cipher and mode are suitable for pairwise security 445 associations but not for multicast security associations, such as 446 one where multiple senders share the key. For example, a stream or 447 hybrid stream/block cipher has special risks of keystream reuse when 448 its key is shared by multiple senders. Although IPsec encryption 449 transforms are generally suitable for multicast operation, many have 450 not been evaluated, tested or used in IP multicast environments. 451 This I-D has considered the suitability of several IPsec ESP 452 encryption transforms for inclusion in the MESP framework. It is 453 RECOMMENDED that all future IPsec encryption transforms be analyzed 454 as to their security for multicast and group security as well as for 455 pairwise security. 457 6.0 IANA Considerations 459 This I-D extends the RFC 2407 attributes for IPsec ESP, 460 PROTO_IPSEC_ESP [RFC2407]. Within PROTO_IPSEC_ESP, MESP reserves the 461 transform identifier value 13 [See IANA, "IPSEC ESP Transform 462 Identifiers"]. MESP also adds new type/length/value attributes to 463 RFC 2407. For the MESP transform ID security association 464 attributes, the ENC Transform has type number 11, the INT transform 465 has type number 12, and the EXT transform has type number 13 [see 466 IANA, "Security Association Attributes"]. 468 class value type 469 ----------------------------------------- 470 ENC-Transform 11 B 471 INT-Transform 12 B 472 EXT-Transform 13 B 474 The ENC-Transform has the following values. 475 name value 476 ---- ----- 477 Reserved 0 478 3DES 1 479 AES-CBC 2 480 AES-CTR 3 482 The INT-Transform has the following values. 483 name value 484 ---- ----- 485 Reserved 0 486 RSA-SHA 1 487 TESLA 2 489 The EXT-Transform has the following values. 490 name value 491 ---- ----- 492 Reserved 0 493 HMAC-SHA1 1 495 7.0 Acknowledgements 497 The authors wish to thank Scott Fluhrer, Thomas Hardjono, Steve Kent 498 and Brian Weis for their thoughtful comments and suggestions. 500 8.0 Author's Address 502 Mark Baugher 503 Cisco Systems, Inc. 504 5510 SW Orchid Street 505 Portland, Oregon 506 mbaugher@cisco.com 507 +1-503-245-4543 509 Ran Canetti 510 IBM T.J. Watson Research Center 511 30 Saw Mill River Road 512 Hawthorne, NY 10598, USA 513 canetti@watson.ibm.com 514 Tel: +1-914-784-6692 516 Pau-Chen Cheng 517 IBM T.J. Watson Research Center 518 30 Saw Mill River Road 519 Hawthorne, NY 10598, USA 520 pau@watson.ibm.com 521 Tel: +1-914-784-6692 523 Pankaj Rohatgi 524 IBM T.J. Watson Research Center 525 30 Saw Mill River Road 526 Hawthorne, NY 10598, USA 527 rohatgi@watson.ibm.com 528 Tel: +1-914-784-6692 530 9.0 References 532 9.1 Normative References 534 [AHBIS] S. Kent, IP Authentication Header (AH), IETF, Work in 535 Progress, March 2003, http://www.ietf.org/internet-drafts/draft- 536 ietf-ipsec-rfc2402bis-02.txt 538 [ESPBIS] S. Kent, IP Encapsulated Security Payload (ESP), IETF, Work 539 in Progress, March 2003, http://www.ietf.org/internet-drafts/draft- 540 ietf-ipsec-esp-v3-04.txt. 542 [GDOI] M. Baugher, H. Harjono, H. Harney, B. Weis, The Group Domain 543 of Interpretation, IETF, Work in Progress, October 2002, 544 http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt. 546 [GSAKMP] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light, IETF, 547 Work in Progress, July 2002, http://www.ietf.org/internet- 548 drafts/draft-ietf-msec-gsakmp-light-sec-01.txt 550 [IANA] http://www.iana.org/assignments/isakmp-registry 552 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Normann, 553 MIKEY: Multimedia Internet KEYing, IETF, Work in Progress, September 554 2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- 555 04.txt 557 [PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, 558 ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002. 560 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing 561 for Message Authentication, Internet Request for Comments 2104, 562 IETF, November 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt. 564 [RFC2401] S.Kent, R.Atkinson, Security Architecture for the Internet 565 Protocol, Internet Request for Comments 2401, IETF, November 1998, 566 http://www.ietf.org/rfc/tfc2401.txt. 568 [RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP 569 and AH, Internet Request for Comments 2404, IETF, November 1998, 570 http://www.ietf.org/rfc/rfc2404.txt. 572 [RFC2407] D. Piper, The Internet IP Security Domain of 573 Interpretation for ISAKMP, Internet Request for Comments 2407, IETF, 574 November 1998, http://www.ietf.org/rfc/rfc2407.txt. 576 [RFC2451] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher 577 Algorithms", Internet Request For Comments 2451, IETF, November 578 1998, ftp://ftp.rfc-editor.org/in-notes/rfc2451.txt. 580 [RFC3376] B.Cain, S.Deering, B.Fenner, I. Kouvelas, A. Thyagarajan, 581 Internet Group Management Protocol, Version 3, Internet Request for 582 Comments 3376, IETF, October 2002, 583 http://www.ietf.org/rfc/rfc3376.txt. 585 [SSM]H.Holbrook, B.Cain, Source Specific Multicast for IP, 586 http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work 587 in Progress 589 [TESLA] 591 9.2 Informative References 593 [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B. 594 Pinkas, "Multicast Security: A Taxonomy and Efficient 595 Authentication", INFOCOM '99. 597 [CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security 598 issues",draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998. 600 [Ch] S. Cheung, An Efficient Message Authentication Scheme for 601 Link State Routing, Proceedings of the 13th Annual Computer 602 Security Applications Conference, San Diego, December 8-12, 1997, 603 pp.90-98. 605 [GR] R. Gennaro, P. Rohatgi, "How to Sign Digital Streams", Advances 606 in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, pp. 180-197, 607 1997. 609 [K] H. Krawczyk, The order of encryption and authentication for 610 protecting communications (or: How secure is SSL?). In J. Kilian, 611 editor, CRYPTO 2001. 613 [PCTS] A. Perrig, R. Canetti, D. Tygar, D. Song, Efficient 614 Authentication and Signature of Multicast Streams over Lossy 615 Channels, IEEE Symposium on Security and Privacy, Oakland, CA, May 616 2000. 618 [R] P. Rohatgi, A Compact and Fast Signature Scheme for Multicast 619 Packet Authentication, In 6th ACM Computer and Communications 620 Security Conference (CCS) , Nov 1999. 622 [WL] C. K. Wong and S. S. Lam, Digital Signatures for Flows and 623 Multicasts, IEEE ICNP '98. See also University of Texas at Austin, 624 Computer Science Technical report TR 98-15.