idnits 2.17.1 draft-roca-rmt-simple-auth-for-alc-norm-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 648. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 19, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 3926 (Obsoleted by RFC 6726) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT V. Roca 3 Internet-Draft INRIA 4 Intended status: Experimental November 19, 2007 5 Expires: May 22, 2008 7 Simple Authentication Schemes for the ALC and NORM Protocols 8 draft-roca-rmt-simple-auth-for-alc-norm-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 22, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document introduces two schemes that provide a per-packet 42 authentication and integrity service in the context of the ALC and 43 NORM protocols. The first scheme is based on digital signatures. 44 Because it relies on asymmetric cryptography, this scheme generates a 45 high processing load at the sender and to a lesser extent at a 46 receiver, as well as a significant transmission overhead. It is 47 therefore well suited to low data rate sessions. The second scheme 48 relies on a group Message Authentication Code (MAC). Because this 49 scheme relies symmetric cryptography, MAC calculation and 50 verification are fast operations, which makes it suited to high data 51 rate sessions. However it only provides a group authentication and 52 integrity service, which means that it only protects against 53 attackers that are not group members. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in this Document . . . . . . . . . . . . 4 59 1.2. Terminology and Notations . . . . . . . . . . . . . . . . 4 60 2. Digital Signature Scheme . . . . . . . . . . . . . . . . . . . 6 61 2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Parameters that Need to Be Initialized Out-of-Band . . . . 6 63 2.3. Authentication Header Extension Format . . . . . . . . . . 7 64 2.4. Use of Authentication Header Extensions . . . . . . . . . 8 65 3. Group MAC Scheme . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Parameters that Need to Be Initialized Out-of-Band . . . . 9 68 3.3. Authentication Header Extension Format . . . . . . . . . . 10 69 3.4. Use of Authentication Header Extensions . . . . . . . . . 11 70 4. Combined Use of the Digital Signatures and Group MAC 71 Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.2. Combined Use of both Authentication Header Extensions . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 20 83 1. Introduction 85 Many applications using multicast and broadcast communications 86 require that each receiver be able to authenticate the source of any 87 packet it receives as well as its integrity. For instance, ALC 88 [draft-ietf-rmt-pi-alc-revised] and NORM 89 [draft-ietf-rmt-pi-norm-revised] are two Content Delivery Protocols 90 (CDP) designed to transfer reliably objects (e.g. files) between a 91 session's sender and several receivers. 93 The NORM protocol is based on bidirectional transmissions. Each 94 receiver acknowledges data received or, in case of packet erasures, 95 asks for retransmissions. The ALC protocol defines unidirectional 96 transmissions. Reliability can be achieved by means of cyclic 97 transmissions of the content within a carousel, or by the use of 98 proactive Forward Error Correction codes (FEC), or by the joint use 99 of these mechanisms. Being purely unidirectional, ALC is massively 100 scalable, while NORM is intrinsically limited in terms of the number 101 of receivers that can be handled in a session. Both protocols have 102 in common the fact that they operate at application level, on top of 103 an erasure channel (e.g. the Internet) where packets can be lost 104 (erased) during the transmission. With some use case, an attacker 105 might impersonate the ALC or NORM session's sender and inject forged 106 packets to the receivers, thereby corrupting the objects 107 reconstructed by the receivers. 109 In case of group communications, several solutions exist to provide 110 the receiver some guaranties on the integrity of the packets it 111 receives and on the identity of the sender of these packets. These 112 solutions have different features that make them more or less suited 113 to a given use case: 115 o digital signatures [RFC4359]: this scheme is well suited to low 116 data rate flows, when a true packet sender authentication and 117 packet integrity service is needed. However this solution is 118 limited by high computational costs and high transmission 119 overheads. 121 o group Message Authentication Codes (MAC): this scheme is well 122 suited to high data rate flows, when transmission overheads must 123 be minimized. However this scheme cannot protect against attacks 124 coming from inside the group, where a group member impersonates 125 the sender and sends forged messages to other receivers. 127 o TESLA (Timed Efficient Stream Loss-tolerant Authentication) 128 [RFC4082]: this scheme is well suited to high data rate flows, 129 when transmission overheads must be minimized, and when a true 130 packet sender authentication and packet integrity service is 131 needed. The price to pay is an increased complexity, in 132 particular the need to loosely synchronize the receivers and the 133 sender, as well as the need to wait for the key to be disclosed 134 before being able to authenticate a packet. 136 The following table summarizes the pros/cons of each scheme: 138 +----------------------------+--------------+---------------+-------+ 139 | | Digital | Group MAC | TESLA | 140 | | Signature | | | 141 +----------------------------+--------------+---------------+-------+ 142 | True authentication and | Yes | No (group | Yes | 143 | integrity service | | security) | | 144 | | | | | 145 | Immediate authentication | Yes | Yes | No | 146 | | | | | 147 | Processing load | -- | ++ | + | 148 | | | | | 149 | Transmission overhead | -- | ++ | + | 150 | | | | | 151 | Protocol complexity | ++ | ++ | -- | 152 +----------------------------+--------------+---------------+-------+ 154 [draft-ietf-msec-tesla-for-alc-norm] explains how to use TESLA in the 155 context of ALC and NORM protocols. The current document specifies 156 the use of the first two schemes, namely the Digital Signature and 157 Group MAC schemes, in the ALC and NORM content delivery protocols. 158 Since the FLUTE application [RFC3926] is built on top of ALC, it will 159 directly benefit from the services offered by TESLA at the transport 160 layer. Unlike the TESLA scheme, this specification considers the 161 authentication/integrity of the packets generated by the session's 162 sender as well as those generated by the receivers (NORM). 164 1.1. Conventions Used in this Document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 1.2. Terminology and Notations 172 The following notations and definitions are used throughout this 173 document: 175 o MAC is the Message Authentication Code; 177 o HMAC is the Keyed-Hash Message Authentication Code; 178 Digital signature related notations and definitions: 180 o K_pub is the public key used by a receiver to check a packet's 181 signature. This key must be communicated to all receivers, before 182 starting the session; 184 o K_priv is the private key used by a sender to generate a packet's 185 signature; 187 o n_k is the (private and public) key length, in bits. n_k is also 188 the signature length, since both values must be equal with digital 189 signatures; 191 Group MAC related notations and definitions: 193 o K_g is a shared group key, communicated to all group members, 194 confidentially, before starting the session. The mechanism by 195 which this group key is shared by the group members is out of the 196 scope of this document; 198 o n_k is the key length, in bits; 200 o n_m is the length of the truncated output of the MAC [RFC2104]. 201 Only the n_m left-most bits (most significant bits) of the MAC 202 output are kept; 204 2. Digital Signature Scheme 206 2.1. Principles 208 The computation of the digital signature, using K_priv, includes the 209 ALC or NORM header (with the various header extensions) and the 210 payload when applicable. The UDP/IP/MAC headers are not included. 211 During this computation, the "Signature" field MUST be set to 0. 213 Upon receiving this packet, the receiver recomputes the Group MAC, 214 using K_pub, and compares it to the value carried in the packet. 215 During this computation, the Weak Group MAC field MUST also be set to 216 0. If the check fails, the packet MUST be immediately dropped. 218 With RSASSA-PKCS1-v1_5 (default) and RSASSA-PSS signatures 219 (Section 5), the size of the signature is equal to the "RSA modulus", 220 unless the "RSA modulus" is not a multiple of 8 bits. In that case, 221 the signature MUST be prepended with between 1 and 7 bits set to zero 222 such that the signature is a multiple of 8 bits [RFC4359]. The key 223 size, which in practice is also equal to the "RSA modulus", has major 224 security implications. [RFC4359] explains how to choose this value 225 depending on the maximum expected lifetime of the session. This 226 choice is out of the scope of this document. 228 2.2. Parameters that Need to Be Initialized Out-of-Band 230 Several parameters MUST be initialized by an out-of-band mechanism 231 The sender or group controller: 233 o MUST communicate his public key, for each receiver to be able to 234 verify the signature of the bootstrap (and direct time 235 synchronization response messages when applicable). As a side 236 effect, the receivers also know the key length, n_k, and the 237 signature length, the two parameters being equal. 239 o MAY communicate a certificate (which also means that a PKI has 240 been setup), for each receiver to be able to check the sender's 241 public key. 243 o MUST communicate the Signature Encoding Algorithm. For instance, 244 [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms 245 that are usually used to that purpose. 247 o MUST associate a value to the "ASID" field (Authentication Scheme 248 Identifier) of the EXT_AUTH header extension (Section 2.3). 250 These parameters MUST be communicated to all receivers before they 251 can authenticate the incoming packets. For instance it can be 252 communicated in the session description, or initialized in a static 253 way on the receivers, or communicated by means of an appropriate 254 initialization protocol. The details of this out-of-band mechanism 255 are out of the scope of this document. 257 2.3. Authentication Header Extension Format 259 The integration of Digital Signatures in ALC or NORM is similar and 260 relies on the header extension mechanism defined in both protocols. 261 More precisely this document details the EXT_AUTH==1 header extension 262 defined in [draft-ietf-rmt-bb-lct-revised]. 264 ----- Editor's note: All authentication schemes using the EXT_AUTH 265 header extension MUST reserve the same 4 bit "ASID" field after 266 the HET/HEL fields. This way, several authentication schemes can 267 be used in the same ALC or NORM session, even on the same 268 communication path. ----- 270 Several fields are added in addition to the HET (Header Extension 271 Type) and HEL (Header Extension Length) fields (Figure 1). 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | HET (=1) | HEL | ASID | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 ~ ~ 280 | Signature | 281 + +-+-+-+-+-+-+-+-+ 282 | | Padding | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: Format of the Digital Signature EXT_AUTH header extension. 287 The fields of the Digital Signature EXT_AUTH header extension are: 289 "ASID" (Authentication Scheme Identifier) field (4 bits): 291 The "ASID" identifies the source authentication scheme or protocol 292 in use. The association between the "ASID" value and the actual 293 authentication scheme is defined out-of-band, at session startup. 295 "Reserved" field (12 bits): 297 This is a reserved field that MUST be set to zero in this 298 specification. 300 "Signature" field (variable size, multiple of 32 bits): 302 The "Signature" field contains a digital signature of the message. 303 If need be, this field is padded (with 0) up to a multiple of 32 304 bits. 306 2.4. Use of Authentication Header Extensions 308 Each packet sent by the session's sender MUST contain exactly one 309 Digital Signature EXT_AUTH header extension. A receiver MUST drop 310 packets that do not contain a Digital Signature EXT_AUTH header 311 extension. 313 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 314 its content, for instance because they do not support digital 315 signatures. In that case these receivers MUST ignore the Digital 316 Signature EXT_AUTH header extensions. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | HET (=1) | HEL (=33) | ASID | 0 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 323 | | ^ 1 324 + + | 2 325 | | | 8 326 . . | 327 . Signature (128 bytes) . | b 328 . . | y 329 | | | t 330 + + | e 331 | | v s 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 334 Figure 2: Example: Format of the Digital Signature EXT_AUTH header 335 extension using 1024 bit signatures. 337 For instance Figure 2 shows the digital signature EXT_AUTH header 338 extension when using 128 byte (1024 bit) key digital signatures 339 (which also means that the signature field is 128 byte long). The 340 Digital Signature EXT_AUTH header extension is then 132 byte long. 342 3. Group MAC Scheme 344 3.1. Principles 346 The computation of the Group MAC, using K_g, includes the ALC or NORM 347 header (with the various header extensions) and the payload when 348 applicable. The UDP/IP/MAC headers are not included. During this 349 computation, the Weak Group MAC field MUST be set to 0. Then the 350 sender truncates the MAC output to keep the n_w most significant bits 351 and stores the result in the Group MAC Authentication header. 353 Upon receiving this packet, the receiver recomputes the Group MAC, 354 using K_g, and compares it to the value carried in the packet. 355 During this computation, the Group MAC field MUST also be set to 0. 356 If the check fails, the packet MUST be immediately dropped. 358 [RFC2104] explains that it is current practice to truncate the MAC 359 output, on condition that the truncated output length, n_m be not 360 less than half the length of the hash and not less than 80 bits. 361 However, this choice is out of the scope of this document. 363 3.2. Parameters that Need to Be Initialized Out-of-Band 365 Several parameters MUST be initialized by an out-of-band mechanism 366 The sender or group controller: 368 o MUST communicate the cryptographic Message Authentication Code 369 (MAC). For instance, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, 370 HMAC-SHA-384, or HMAC-SHA-512. As a side effect, the receivers 371 also know the key length, n_k, and the (non truncated) MAC output 372 length. 374 o MUST communicate the length of the truncated output of the MAC, 375 n_m. 377 o MUST communicate the K_g group key to the receivers, 378 confidentially, before starting the session. This key might have 379 to be periodically refreshed. 381 o MUST associate a value to the "ASID" field (Authentication Scheme 382 Identifier) of the EXT_AUTH header extension (Section 3.3). 384 These parameters MUST be communicated to all receivers before they 385 can authenticate the incoming packets. For instance it can be 386 communicated in the session description, or initialized in a static 387 way on the receivers, or communicated by means of an appropriate 388 initialization protocol. The details of this out-of-band mechanism 389 are out of the scope of this document. 391 3.3. Authentication Header Extension Format 393 The integration of Group MAC in ALC or NORM is similar and relies on 394 the header extension mechanism defined in both protocols. More 395 precisely this document details the EXT_AUTH==1 header extension 396 defined in [draft-ietf-rmt-bb-lct-revised]. 398 ----- Editor's note: All authentication schemes using the EXT_AUTH 399 header extension MUST reserve the same 4 bit "ASID" field after 400 the HET/HEL fields. This way, several authentication schemes can 401 be used in the same ALC or NORM session, even on the same 402 communication path. ----- 404 Several fields are added in addition to the HET (Header Extension 405 Type) and HEL (Header Extension Length) fields (Figure 3). 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | HET (=1) | HEL | ASID | Reserved | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 ~ ~ 414 | Group MAC | 415 + +-+-+-+-+-+-+-+-+ 416 | | Padding | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 3: Format of the Group MAC EXT_AUTH header extension. 421 The fields of the Group MAC EXT_AUTH header extension are: 423 "ASID" (Authentication Scheme Identifier) field (4 bits): 425 The "ASID" identifies the source authentication scheme or protocol 426 in use. The association between the "ASID" value and the actual 427 authentication scheme is defined out-of-band, at session startup. 429 "Reserved" field (12 bits): 431 This is a reserved field that MUST be set to zero in this 432 specification. 434 "Group MAC" field (variable size, multiple of 32 bits): 436 The "Group MAC" field contains a Group MAC of the message. If 437 need be, this field is padded (with 0) up to a multiple of 32 438 bits. 440 3.4. Use of Authentication Header Extensions 442 Each packet sent by the session's sender MUST contain exactly one 443 Group MAC EXT_AUTH header extension. A receiver MUST drop packets 444 that do not contain a Group MAC EXT_AUTH header extension. 446 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 447 its content, for instance because they do not support Group MAC. In 448 that case these receivers MUST ignore the Group MAC EXT_AUTH 449 extensions. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | HET (=1) | HEL (=4) | ASID | 0 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 + + 458 | Group MAC (10 bytes) | 459 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | Padding | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: Example: Format of the Group MAC EXT_AUTH header extension 464 using HMAC-SHA-1. 466 For instance Figure 4 shows the Group MAC EXT_AUTH header extension 467 when using HMAC-SHA-1. The Group MAC EXT_AUTH header extension is 468 then 16 byte long. 470 4. Combined Use of the Digital Signatures and Group MAC Schemes 472 4.1. Principles 474 In some situations, it can be interesting to use both authentication 475 schemes. The goal of the Group MAC is to mitigate DoS attacks coming 476 from attackers that are not group member [RFC4082] by adding a light 477 authentication scheme as a front-end. 479 More specifically, before sending a message, the sender computes the 480 Group MAC MAC(K_g, M), which includes the ALC or NORM header (with 481 the various header extensions), plus the payload when applicable. 482 During this computation, the Weak Group MAC field MUST be set to 0. 483 However the digital signature MUST have been calculated and is 484 included in the Group MAC calculation itself. Then the sender 485 truncates the MAC output to keep the n_w most significant bits and 486 stores the result in the Group MAC authentication header. Upon 487 receiving this packet, the receiver recomputes the Group MAC and 488 compares it to the value carried in the packet. If the check fails, 489 the packet MUST be immediately dropped. 491 This scheme features a few limits: 493 o it is of no help if a group member (who knows K_g) impersonates 494 the sender and sends forged messages to other receivers; 496 o it requires an additional MAC computing for each packet, both at 497 the sender and receiver sides; 499 o it increases the size of the authentication headers. In order to 500 limit this problem, the length of the truncated output of the MAC, 501 n_m, SHOULD be kept small (e.g. 32 bits) (see [RFC3711] section 502 9.5). As a side effect, the authentication service is 503 significantly weakened (the probability that any packet be 504 successfully forged is one in 2^32). Since the Group MAC check is 505 only a pre-check that will be followed by the standard signature 506 authentication check, this is not considered to be an issue. 508 For a given use-case, the benefits brought by the Group MAC must be 509 balanced against these limitations. 511 4.2. Combined Use of both Authentication Header Extensions 513 In order to use both authentication schemes, the packet sender 514 calculates and includes two EXT_AUTH header extensions, in any order, 515 one for each authentication scheme. It is RECOMMENDED that the n_m 516 parameter of the group authentication scheme be small, for instance 517 equal to 32 bits (Section 4.1). 519 When it is decided that both schemes should be combined, then all the 520 packets MUST include both header extensions. A receiver receiving a 521 packet with only one of the two schemes MUST reject it. This 522 requirement is meant to prevent DoS attacks where the attacker would 523 inject forged packets containing only the Digital Signature EXT_AUTH 524 header extension, to force the receiver to check it. 526 5. IANA Considerations 528 This document does not require any IANA registration. 530 6. Security Considerations 532 TBD 534 7. Acknowledgments 536 TBD 538 8. References 540 8.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", RFC 2119, BCP 14, March 1997. 545 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 546 Briscoe, "Timed Efficient Stream Loss-Tolerant 547 Authentication (TESLA): Multicast Source Authentication 548 Transform Introduction", RFC 4082, June 2005. 550 [draft-ietf-msec-tesla-for-alc-norm] 551 Adamson, B., Bormann, C., Handley, M., and J. Macker, "Use 552 of TESLA in the ALC and NORM Protocols", 553 draft-ietf-msec-tesla-for-alc-norm-03.txt (work in 554 progress), November 2007. 556 [draft-ietf-rmt-bb-lct-revised] 557 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 558 Transport (LCT) Building Block", 559 draft-ietf-rmt-bb-lct-revised-06.txt (work in progress), 560 November 2007. 562 [draft-ietf-rmt-pi-alc-revised] 563 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 564 Layered Coding (ALC) Protocol Instantiation", 565 draft-ietf-rmt-pi-alc-revised-05.txt (work in progress), 566 November 2007. 568 [draft-ietf-rmt-pi-norm-revised] 569 Adamson, B., Bormann, C., Handley, M., and J. Macker, 570 "Negative-acknowledgment (NACK)-Oriented Reliable 571 Multicast (NORM) Protocol", 572 draft-ietf-rmt-pi-norm-revised-05.txt (work in progress), 573 March 2007. 575 8.2. Informative References 577 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 578 Hashing for Message Authentication", RFC 2104, 579 February 1997. 581 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 582 Standards (PKCS) #1: RSA Cryptography Specifications 583 Version 2.1", RFC 3447, February 2003. 585 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 587 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 588 RFC 3711, March 2004. 590 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 591 "FLUTE - File Delivery over Unidirectional Transport", 592 RFC 3926, October 2004. 594 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 595 Encapsulating Security Payload (ESP) and Authentication 596 Header (AH)", RFC 4359, January 2006. 598 Author's Address 600 Vincent Roca 601 INRIA 602 655, av. de l'Europe 603 Zirst; Montbonnot 604 ST ISMIER cedex 38334 605 France 607 Email: vincent.roca@inrialpes.fr 608 URI: http://planete.inrialpes.fr/~roca/ 610 Full Copyright Statement 612 Copyright (C) The IETF Trust (2007). 614 This document is subject to the rights, licenses and restrictions 615 contained in BCP 78, and except as set forth therein, the authors 616 retain all their rights. 618 This document and the information contained herein are provided on an 619 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 620 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 621 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 622 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 623 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Intellectual Property 628 The IETF takes no position regarding the validity or scope of any 629 Intellectual Property Rights or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; nor does it represent that it has 633 made any independent effort to identify any such rights. Information 634 on the procedures with respect to rights in RFC documents can be 635 found in BCP 78 and BCP 79. 637 Copies of IPR disclosures made to the IETF Secretariat and any 638 assurances of licenses to be made available, or the result of an 639 attempt made to obtain a general license or permission for the use of 640 such proprietary rights by implementers or users of this 641 specification can be obtained from the IETF on-line IPR repository at 642 http://www.ietf.org/ipr. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 this standard. Please address the information to the IETF at 648 ietf-ipr@ietf.org. 650 Acknowledgment 652 Funding for the RFC Editor function is provided by the IETF 653 Administrative Support Activity (IASA).