idnits 2.17.1 draft-ietf-rmt-simple-auth-for-alc-norm-00.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 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 904. 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 (October 27, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-msec-tesla-for-alc-norm-06 == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-07 == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-05 == Outdated reference: A later version (-14) exists of draft-ietf-rmt-pi-norm-revised-07 -- 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 (~~), 5 warnings (==), 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 October 27, 2008 5 Expires: April 30, 2009 7 Simple Authentication Schemes for the ALC and NORM Protocols 8 draft-ietf-rmt-simple-auth-for-alc-norm-00.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 April 30, 2009. 35 Abstract 37 This document introduces two schemes that provide a per-packet 38 authentication and integrity service in the context of the ALC and 39 NORM protocols. The first scheme is based on digital signatures. 40 Because it relies on asymmetric cryptography, this scheme generates a 41 high processing load at the sender and to a lesser extent at a 42 receiver, as well as a significant transmission overhead. It is 43 therefore well suited to low data rate sessions. The second scheme 44 relies on a group Message Authentication Code (MAC). Because this 45 scheme relies symmetric cryptography, MAC calculation and 46 verification are fast operations, which makes it suited to high data 47 rate sessions. However it only provides a group authentication and 48 integrity service, which means that it only protects against 49 attackers that are not group members. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 55 1.2. Conventions Used in this Document . . . . . . . . . . . . 6 56 1.3. Terminology and Notations . . . . . . . . . . . . . . . . 6 57 2. RSA-Based Digital Signature Scheme . . . . . . . . . . . . . . 8 58 2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 9 60 2.3. Authentication Header Extension Format . . . . . . . . . . 9 61 2.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 10 62 3. Group Message Authentication Code (MAC) Scheme . . . . . . . . 12 63 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.3. Authentication Header Extension Format . . . . . . . . . . 13 66 3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 14 67 4. Combined Use of the Digital Signatures and Group MAC 68 Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.3. Authentication Header Extension Format . . . . . . . . . . 16 72 4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 17 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 75 6.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 20 76 6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 20 77 6.2.1. Impacts of Replay Attacks on the Simple 78 Authentication Schemes . . . . . . . . . . . . . . . . 20 79 6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 20 80 6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 21 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 Intellectual Property and Copyright Statements . . . . . . . . . . 27 88 1. Introduction 90 Many applications using multicast and broadcast communications 91 require that each receiver be able to authenticate the source of any 92 packet it receives to check check its integrity. For instance, ALC 93 [RMT-PI-ALC] and NORM [RMT-PI-NORM] are two Content Delivery 94 Protocols (CDP) designed to transfer reliably objects (e.g. files) 95 between a session's sender and several receivers. 97 The NORM protocol is based on bidirectional transmissions. Each 98 receiver acknowledges data received or, in case of packet erasures, 99 asks for retransmissions. On the opposite, the ALC protocol defines 100 unidirectional transmissions. Reliability can be achieved by means 101 of cyclic transmissions of the content within a carousel, or by the 102 use of proactive Forward Error Correction codes (FEC), or by the 103 joint use of these mechanisms. Being purely unidirectional, ALC is 104 massively scalable, while NORM is intrinsically limited in terms of 105 the number of receivers that can be handled in a session. Both 106 protocols have in common the fact that they operate at application 107 level, on top of an erasure channel (e.g. the Internet) where packets 108 can be lost (erased) during the transmission. 110 With these CDP, an attacker might impersonate the ALC or NORM session 111 sender and inject forged packets to the receivers, thereby corrupting 112 the objects reconstructed by the receivers. An attacker might also 113 impersonate a NORM session receiver and inject forged feedback 114 packets to the NORM sender. 116 In case of group communications, several solutions exist to provide 117 the receiver some guaranties on the integrity of the packets it 118 receives and on the identity of the sender of these packets. These 119 solutions have different features that make them more or less suited 120 to a given use case: 122 o digital signatures [RFC4359]: this scheme is well suited to low 123 data rate flows, when a true packet sender authentication and 124 packet integrity service is needed. However, digital signatures 125 based on RSA asymmetric cryptography is limited by high 126 computational costs and high transmission overheads. The use of 127 ECC ("Elliptic Curve Cryptography") significantly relaxes these 128 constraints, especially when seeking for higher security levels. 129 For instance, the following key sizes provide equivalent security: 130 1024 bit RSA key versus 160 bit ECC key, or 2048 bit RSA key 131 versus 224 bit ECC key. 133 o group Message Authentication Codes (MAC): this scheme is well 134 suited to high data rate flows, when transmission overheads must 135 be minimized. However this scheme cannot protect against attacks 136 coming from inside the group, where a group member impersonates 137 the sender and sends forged messages to other receivers. 139 o TESLA (Timed Efficient Stream Loss-tolerant Authentication) 140 [RFC4082][MSEC-TESLA]: this scheme is well suited to high data 141 rate flows, when transmission overheads must be minimized, and 142 when a true packet sender authentication and packet integrity 143 service is needed. The price to pay is an increased complexity, 144 in particular the need to loosely synchronize the receivers and 145 the sender, as well as the need to wait for the key to be 146 disclosed before being able to authenticate a packet. 148 The following table summarizes the pros/cons of each authentication/ 149 integrity scheme used at application/transport level (where "-" means 150 bad, "0" means neutral, and "+" means good): 152 +----------------+-------------+--------------+-------------+-------+ 153 | | RSA Digital | ECC Digital | Group MAC | TESLA | 154 | | Signature | Signature | | | 155 +----------------+-------------+--------------+-------------+-------+ 156 | True auth and | Yes | Yes | No (group | Yes | 157 | integrity | | | security) | | 158 | | | | | | 159 | Immediate auth | Yes | Yes | Yes | No | 160 | | | | | | 161 | Processing | - | 0 | + | + | 162 | load | | | | | 163 | | | | | | 164 | Transmission | - | 0 | + | + | 165 | overhead | | | | | 166 | | | | | | 167 | Complexity | + | + | + | - | 168 +----------------+-------------+--------------+-------------+-------+ 170 Several authentication schemes MAY be used in the same ALC or NORM 171 session, even on the same communication path. Since all the above 172 schemes make use of the same authentication header extension 173 mechanism (Section 2.3, Section 3.3, Section 4.3) and [MSEC-TESLA], 174 section 5.1), the same 4-bit "ASID" (Authentication Scheme 175 IDentifier) has been reserved in all the specifications. The 176 association between the "ASID" value and the actual authentication 177 scheme is defined at session startup and communicated to all the 178 group members by an out-of-band mechanism. 180 1.1. Scope of this Document 182 [MSEC-TESLA] explains how to use TESLA in the context of ALC and NORM 183 protocols. 185 The current document specifies the use of the first two schemes, 186 namely the Digital Signature based on RSA asymmetric cryptography and 187 Group MAC schemes. 189 Unlike the TESLA scheme, this specification considers the 190 authentication/integrity of the packets generated by the session's 191 sender as well as those generated by the receivers (NORM). 193 All the applications build on top of ALC and NORM directly benefit 194 from the source authentication and packet integrity services defined 195 in this document. For instance this is the case of the FLUTE 196 application [RFC3926] built on top of ALC. 198 The current specification assumes that several parameters (like 199 keying material) are communicated out-of-band, sometimes securely, 200 between the sender and the receivers. This is detailed in 201 Section 2.2 and Section 3.2. 203 1.2. Conventions Used in this Document 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 1.3. Terminology and Notations 211 The following notations and definitions are used throughout this 212 document: 214 o MAC is the Message Authentication Code; 216 o HMAC is the Keyed-Hash Message Authentication Code; 218 o sender denotes the sender of a packet that needs the 219 authentication/integrity check service. It can be an ALC or NORM 220 session sender, or a NORM session receiver in case of feedback 221 traffic; 223 o receiver denotes the receiver of a packet that needs the 224 authentication/integrity check service. It can be an ALC or NORM 225 session receiver, or a NORM session sender in case of feedback 226 traffic; 228 Digital signature related notations and definitions: 230 o K_pub is the public key used by a receiver to check a packet's 231 signature. This key MUST be communicated to all receivers, before 232 starting the session; 234 o K_priv is the private key used by a sender to generate a packet's 235 signature; 237 o n_k is the private key and public key length, in bits. n_k is also 238 the signature length, since both values are equal with digital 239 signatures; 241 Group MAC related notations and definitions: 243 o K_g is a shared group key used by the senders and the receivers. 244 This key MUST be communicated to all group members, 245 confidentially, before starting the session; 247 o n_k is the group key length, in bits; 249 o n_m is the length of the truncated output of the MAC [RFC2104]. 250 Only the n_m left-most bits (most significant bits) of the MAC 251 output are kept; 253 2. RSA-Based Digital Signature Scheme 255 2.1. Principles 257 The computation of the digital signature, using K_priv, MUST include 258 the ALC or NORM header (with the various header extensions) and the 259 payload when applicable. The UDP/IP/MAC headers MUST NOT be 260 included. During this computation, the "Signature" field MUST be set 261 to 0. 263 Upon receiving this packet, the receiver recomputes the Group MAC, 264 using K_pub, and compares it to the value carried in the packet. 265 During this computation, the Weak Group MAC field MUST also be set to 266 0. If the check fails, the packet MUST be immediately dropped. 268 Several "Signature Encoding Algorithms" can be used, including 269 RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several 270 "Signature Cryptographic Function" can be used, like SHA-256. 272 First, let us consider a packet sender. More specifically, from 273 [RFC4359]: digital signature generation is performed as described in 274 [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for 275 RSASSA-PSS. The authenticated portion of the packet is used as the 276 message M, which is passed to the signature generation function. The 277 signer's RSA private key is passed as K. In summary (when SHA-256 is 278 used), the signature generation process computes a SHA-256 hash of 279 the authenticated packet bytes, signs the SHA-256 hash using the 280 private key, and encodes the result with the specified RSA encoding 281 type. This process results in a value S, which is the digital 282 signature to be included in the packet. 284 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 285 signature is equal to the "RSA modulus", unless the "RSA modulus" is 286 not a multiple of 8 bits. In that case, the signature MUST be 287 prepended with between 1 and 7 bits set to zero such that the 288 signature is a multiple of 8 bits [RFC4359]. The key size, which in 289 practice is also equal to the "RSA modulus", has major security 290 implications. [RFC4359] explains how to choose this value depending 291 on the maximum expected lifetime of the session. This choice is out 292 of the scope of this document. 294 Now let us consider a receiver. From [RFC4359]: Digital signature 295 verification is performed as described in [RFC3447], Section 8.2.2 296 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon 297 receipt, the digital signature is passed to the verification function 298 as S. The authenticated portion of the packet is used as the message 299 M, and the RSA public key is passed as (n, e). In summary (when SHA- 300 256 is used), the verification function computes a SHA-256 hash of 301 the authenticated packet bytes, decrypts the SHA-256 hash in the 302 packet using the sender's public key, and validates that the 303 appropriate encoding was applied. The two SHA-256 hashes are 304 compared and if they are identical the validation is successful. 306 2.2. Parameters 308 Several parameters MUST be initialized by an out-of-band mechanism. 309 The sender or group controller: 311 o MUST communicate his public key, for each receiver to be able to 312 verify the signature of the packets received. As a side effect, 313 the receivers also know the key length, n_k, and the signature 314 length, the two parameters being equal; 316 o MAY communicate a certificate (which also means that a PKI has 317 been setup), for each receiver to be able to check the sender's 318 public key; 320 o MUST communicate the Signature Encoding Algorithm. For instance, 321 [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms 322 that are usually used to that purpose; 324 o MUST communicate the Signature Cryptographic Function, for 325 instance SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of 326 security threats on SHA-1, the use of SHA-256 is RECOMMENDED; 328 o MUST associate a value to the "ASID" field (Authentication Scheme 329 Identifier) of the EXT_AUTH header extension (Section 2.3); 331 These parameters MUST be communicated to all receivers before they 332 can authenticate the incoming packets. For instance it can be 333 communicated in the session description, or initialized in a static 334 way on the receivers, or communicated by means of an appropriate 335 protocol. The details of this out-of-band mechanism are out of the 336 scope of this document. 338 2.3. Authentication Header Extension Format 340 The integration of Digital Signatures is similar in ALC and NORM and 341 relies on the header extension mechanism defined in both protocols. 342 More precisely this document details the EXT_AUTH==1 header extension 343 defined in [RMT-BB-LCT]. 345 Several fields are added in addition to the HET (Header Extension 346 Type) and HEL (Header Extension Length) fields (Figure 1). 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | HET (=1) | HEL | ASID | Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 ~ ~ 355 | Signature | 356 + +-+-+-+-+-+-+-+-+ 357 | | Padding | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 1: Format of the Digital Signature EXT_AUTH header extension. 362 The fields of the Digital Signature EXT_AUTH header extension are: 364 "ASID" (Authentication Scheme Identifier) field (4 bits): 366 The "ASID" identifies the source authentication scheme or protocol 367 in use. The association between the "ASID" value and the actual 368 authentication scheme is defined out-of-band, at session startup. 370 "Reserved" field (12 bits): 372 This is a reserved field that MUST be set to zero in this 373 specification. 375 "Signature" field (variable size, multiple of 32 bits): 377 The "Signature" field contains a digital signature of the message. 378 If need be, this field is padded (with 0) up to a multiple of 32 379 bits. 381 2.4. In Practice 383 Each packet sent MUST contain exactly one Digital Signature EXT_AUTH 384 header extension. A receiver MUST drop all the packets that do not 385 contain a Digital Signature EXT_AUTH header extension. 387 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 388 its content, for instance because they do not support digital 389 signatures. In that case the Digital Signature EXT_AUTH header 390 extension is ignored. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | HET (=1) | HEL (=33) | ASID | 0 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 397 | | ^ 1 398 + + | 2 399 | | | 8 400 . . | 401 . Signature (128 bytes) . | b 402 . . | y 403 | | | t 404 + + | e 405 | | v s 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 408 Figure 2: Example: Format of the Digital Signature EXT_AUTH header 409 extension using 1024 bit signatures. 411 For instance Figure 2 shows the digital signature EXT_AUTH header 412 extension when using 128 byte (1024 bit) key digital signatures 413 (which also means that the signature field is 128 byte long). The 414 Digital Signature EXT_AUTH header extension is then 132 byte long. 416 3. Group Message Authentication Code (MAC) Scheme 418 3.1. Principles 420 The computation of the Group MAC, using K_g, includes the ALC or NORM 421 header (with the various header extensions) and the payload when 422 applicable. The UDP/IP/MAC headers are not included. During this 423 computation, the Weak Group MAC field MUST be set to 0. Then the 424 sender truncates the MAC output to keep the n_m most significant bits 425 and stores the result in the Group MAC Authentication header. 427 Upon receiving this packet, the receiver recomputes the Group MAC, 428 using K_g, and compares it to the value carried in the packet. 429 During this computation, the Group MAC field MUST also be set to 0. 430 If the check fails, the packet MUST be immediately dropped. 432 [RFC2104] explains that it is current practice to truncate the MAC 433 output, on condition that the truncated output length, n_m be not 434 less than half the length of the hash and not less than 80 bits. 435 However, this choice is out of the scope of this document. 437 3.2. Parameters 439 Several parameters MUST be initialized by an out-of-band mechanism. 440 The sender or group controller: 442 o MUST communicate the Cryptographic MAC Function, for instance, 443 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA- 444 512. Because of security threats on SHA-1, the use of HMAC-SHA- 445 256 is RECOMMENDED. As a side effect, the receivers also know the 446 key length, n_k, and the non truncated MAC output length; 448 o MUST communicate the length of the truncated output of the MAC, 449 n_m, which depends on the Cryptographic MAC Function chosen. Only 450 the n_m left-most bits (most significant bits) of the MAC output 451 are kept. Of course, n_m MUST be lower or equal to n_k; 453 o MUST communicate the K_g group key to the receivers, 454 confidentially, before starting the session. This key might have 455 to be periodically refreshed for improved robustness; 457 o MUST associate a value to the "ASID" field (Authentication Scheme 458 Identifier) of the EXT_AUTH header extension (Section 3.3); 460 These parameters MUST be communicated to all receivers before they 461 can authenticate the incoming packets. For instance it can be 462 communicated in the session description, or initialized in a static 463 way on the receivers, or communicated by means of an appropriate 464 protocol (this will be often the case when periodic re-keying is 465 required). The details of this out-of-band mechanism are out of the 466 scope of this document. 468 3.3. Authentication Header Extension Format 470 The integration of Group MAC is similar in ALC and NORM and relies on 471 the header extension mechanism defined in both protocols. More 472 precisely this document details the EXT_AUTH==1 header extension 473 defined in [RMT-BB-LCT]. 475 Several fields are added in addition to the HET (Header Extension 476 Type) and HEL (Header Extension Length) fields (Figure 3). 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | HET (=1) | HEL | ASID | Reserved | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 ~ ~ 485 | Group MAC | 486 + +-+-+-+-+-+-+-+-+ 487 | | Padding | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 3: Format of the Group MAC EXT_AUTH header extension. 492 The fields of the Group MAC EXT_AUTH header extension are: 494 "ASID" (Authentication Scheme Identifier) field (4 bits): 496 The "ASID" identifies the source authentication scheme or protocol 497 in use. The association between the "ASID" value and the actual 498 authentication scheme is defined out-of-band, at session startup. 500 "Reserved" field (12 bits): 502 This is a reserved field that MUST be set to zero in this 503 specification. 505 "Group MAC" field (variable size, multiple of 32 bits): 507 The "Group MAC" field contains a truncated Group MAC of the 508 message. If need be, this field is padded (with 0) up to a 509 multiple of 32 bits. 511 3.4. In Practice 513 Each packet sent MUST contain exactly one Group MAC EXT_AUTH header 514 extension. A receiver MUST drop packets that do not contain a Group 515 MAC EXT_AUTH header extension. 517 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 518 its content, for instance because they do not support Group MAC. In 519 that case the Group MAC EXT_AUTH extension is ignored. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | HET (=1) | HEL (=4) | ASID | 0 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 + + 528 | Group MAC (10 bytes) | 529 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | Padding | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 4: Example: Format of the Group MAC EXT_AUTH header extension 534 using HMAC-SHA-1. 536 For instance Figure 4 shows the Group MAC EXT_AUTH header extension 537 when using HMAC-SHA-1. The Group MAC EXT_AUTH header extension is 538 then 16 byte long. 540 4. Combined Use of the Digital Signatures and Group MAC Schemes 542 4.1. Principles 544 In some situations, it can be interesting to use both authentication 545 schemes. The goal of the Group MAC is to mitigate DoS attacks coming 546 from attackers that are not group members [RFC4082] by adding a light 547 authentication scheme as a front-end. 549 More specifically, before sending a message, the sender sets the 550 Signature field and Group MAC field to zero. Then the sender 551 computes the Signature as detailed in Section 2.1 and stores the 552 value in the Signature field. Then the sender computes the Group MAC 553 as detailed in Section 3.1 and stores the value in the Group MAC 554 field. The digital signature value is therefore protected by the 555 Group MAC, which avoids DoS attacks where the attacker corrupts the 556 digital signature itself. 558 Upon receiving the packet, the receiver first checks the Group MAC, 559 as detailed in Section 3.1. If the check fails, the packet MUST be 560 immediately dropped. Otherwise the receiver checks the Digital 561 Signature, as detailed in Section 2.1. If the check fails, the 562 packet MUST be immediately dropped. 564 This scheme features a few limits: 566 o the Group MAC is of no help if a group member (who knows K_g) 567 impersonates the sender and sends forged messages to other 568 receivers. DoS attacks are still feasible; 570 o it requires an additional MAC computing for each packet, both at 571 the sender and receiver sides; 573 o it increases the size of the authentication headers. In order to 574 limit this problem, the length of the truncated output of the MAC, 575 n_m, SHOULD be kept small (see [RFC3711] section 9.5). In the 576 current specification, n_m MUST be a multiple of 32 bits, and 577 default value is 32 bits. As a side effect, with $n_m = 32$ bits, 578 the authentication service is significantly weakened since the 579 probability that any packet be successfully forged is one in 2^32. 580 Since the Group MAC check is only a pre-check that is followed by 581 the standard signature authentication check, this is not 582 considered to be an issue. 584 For a given use-case, the benefits brought by the Group MAC must be 585 balanced against these limitations. 587 4.2. Parameters 589 Several parameters MUST be initialized by an out-of-band mechanism, 590 as defined in Section 2.2 and Section 3.2. 592 4.3. Authentication Header Extension Format 594 The integration of Combined Digital Signature/Group MAC is similar in 595 ALC and NORM and relies on the header extension mechanism defined in 596 both protocols. More precisely this document details the EXT_AUTH==1 597 header extension defined in [RMT-BB-LCT]. 599 Several fields are added in addition to the HET (Header Extension 600 Type) and HEL (Header Extension Length) fields (Figure 5). 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | HET (=1) | HEL | ASID | Reserved | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 ~ ~ 609 | Signature | 610 + +-+-+-+-+-+-+-+-+ 611 | | Padding | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Group MAC | 614 ~ ~ 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 5: Format of the Group MAC EXT_AUTH header extension. 619 The fields of the Group MAC EXT_AUTH header extension are: 621 "ASID" (Authentication Scheme Identifier) field (4 bits): 623 The "ASID" identifies the source authentication scheme or protocol 624 in use. The association between the "ASID" value and the actual 625 authentication scheme is defined out-of-band, at session startup. 627 "Reserved" field (12 bits): 629 This is a reserved field that MUST be set to zero in this 630 specification. 632 "Signature" field (variable size, multiple of 32 bits): 634 The "Signature" field contains a digital signature of the message. 635 If need be, this field is padded (with 0) up to a multiple of 32 636 bits. 638 "Group MAC" field (variable size, multiple of 32 bits, by default 32 639 bits): 641 The "Group MAC" field contains a truncated Group MAC of the 642 message. 644 4.4. In Practice 646 Each packet sent MUST contain exactly one Combined Digital Signature/ 647 Group MAC EXT_AUTH header extension. A receiver MUST drop packets 648 that do not contain a Combined Digital Signature/Group MAC EXT_AUTH 649 header extension. 651 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 652 its content, for instance because they do not support Combined 653 Digital Signature/Group MAC. In that case the Combined Digital 654 Signature/Group MAC EXT_AUTH extension is ignored. 656 It is RECOMMENDED that the n_m parameter of the group authentication 657 scheme be small, and by default equal to 32 bits (Section 4.1). 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | HET (=1) | HEL (=34) | ASID | 0 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 664 | | ^ 1 665 + + | 2 666 | | | 8 667 . . | 668 . Signature (128 bytes) . | b 669 . . | y 670 | | | t 671 + + | e 672 | | v s 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 674 | Group MAC (32 bits) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 677 Figure 6: Example: Format of the Combined Digital Signature/Group MAC 678 EXT_AUTH header extension using 1024 bit signatures. 680 For instance Figure 6 shows the combined Digital Signature/Group MAC 681 EXT_AUTH header extension when using 128 byte (1024 bit) key digital 682 signatures (which also means that the signature field is 128 byte 683 long). The EXT_AUTH header extension is then 136 byte long. 685 5. IANA Considerations 687 This document does not require any IANA registration. 689 6. Security Considerations 691 6.1. Dealing With DoS Attacks 693 Digital signatures introduces new opportunities for an attacker to 694 mount DoS attacks. For instance an attacker can try to saturate the 695 processing capabilities of the receiver (faked packets are easy to 696 create but checking them requires to compute a costly digital 697 signature). 699 In order to mitigate these attacks, it is RECOMMENDED to use the 700 Combined Digital Signature/Group MAC scheme (Section 4.1). However, 701 no mitigation is possible if a group member acts as an attacker. 703 6.2. Dealing With Replay Attacks 705 Replay attacks, consist for an attacker to store a valid message and 706 to replay it later on. 708 6.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes 710 Since all the above authentication schemes are memoryless, replay 711 attacks have no impact. 713 6.2.2. Impacts of Replay Attacks on NORM 715 We review here the potential impacts of a replay attack on the NORM 716 component. Note that we do not consider here the protocols that 717 could be used along with NORM, for instance the congestion control 718 protocols. 720 First, let us consider replay attacks within a given NORM session. 721 NORM defines a "sequence" field that can be used to protect against 722 replay attacks [RMT-PI-NORM] within a given NORM session. This 723 "sequence" field is a 16-bit value that is set by the message 724 originator (sender or receiver) as a monotonically increasing number 725 incremented with each NORM message transmitted. It is RECOMMENDED 726 that a receiver check this sequence field and drop messages 727 considered as replayed. Similarly, it is RECOMMENDED that a sender 728 check this sequence, for each known receiver, and drop messages 729 considered as replayed. In both cases, checking this sequence field 730 SHOULD be done before authenticating the packet: if the sequence 731 field has not been corrupted, the replay attack will immediately be 732 identified, and otherwise the packet will fail the authentication 733 test. This analysis shows that NORM itself is robust in front of 734 replay attacks within the same session. 736 Now let us consider replay attacks across several NORM sessions. A 737 host participation in a NORM session is uniquely identified by the 738 {"source_id"; "instance_id"} tuple. Therefore, when a given host 739 participates in several NORM sessions, it is RECOMMENDED that the 740 "instance_id" be changed for each NORM instance. It is also 741 RECOMMENDED, when the Group MAC authentication/integrity check scheme 742 is used, that the shared group key, K_g, be changed across sessions. 743 Therefore, NORM can be made robust in front of replay attacks across 744 different sessions. 746 6.2.3. Impacts of Replay Attacks on ALC 748 We review here the potential impacts of a replay attack on the ALC 749 component. Note that we do not consider here the protocols that 750 could be used along with ALC, for instance the layered or wave based 751 congestion control protocols. 753 First, let us consider replay attacks within a given ALC session: 755 o Regular packets containing an authentication tag: a replayed 756 message containing an encoding symbol will be detected once 757 authenticated, thanks to the object/block/symbol identifiers, and 758 will be silently discarded. This kind of replay attack is only 759 penalizing in terms of memory and processing load, but does not 760 compromise the ALC behavior. 762 o Control packets containing an authentication tag: ALC control 763 packets, by definition, do not include any encoding symbol and 764 therefore do not include any object/block/symbol identifier that 765 would enable a receiver to identify duplicates. However, a sender 766 has a very limited number of reasons to send control packets. 767 More precisely: 769 * At the end of the session, a "close session" (A flag) packet is 770 sent. Replaying this packet has no impact since the receivers 771 already left. 773 * Similarly, replaying a packet containing a "close object" (B 774 flag) has no impact since this object is probably already 775 marked as closed by the receiver. 777 This analysis shows that ALC itself is robust in front of replay 778 attacks within the same session. 780 Now let us consider replay attacks across several ALC sessions. An 781 ALC session is uniquely identified by the {sender's IP address; 782 Transport Session Identifier (TSI)} [RMT-BB-LCT]. Therefore, when a 783 given sender creates several sessions, it is RECOMMENDED that the TSI 784 be changed for each ALC instance. It is also RECOMMENDED, when the 785 Group MAC authentication/integrity check scheme is used, that the 786 shared group key, K_g, be changed across sessions. Therefore, ALC 787 can be made robust in front of replay attacks across different 788 sessions. 790 7. Acknowledgments 792 TBD 794 8. References 796 8.1. Normative References 798 [MSEC-TESLA] 799 Adamson, B., Bormann, C., Handley, M., and J. Macker, "Use 800 of TESLA in the ALC and NORM Protocols", 801 draft-ietf-msec-tesla-for-alc-norm-06.txt (work in 802 progress), October 2008. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", RFC 2119, BCP 14, March 1997. 807 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 808 Briscoe, "Timed Efficient Stream Loss-Tolerant 809 Authentication (TESLA): Multicast Source Authentication 810 Transform Introduction", RFC 4082, June 2005. 812 [RMT-BB-LCT] 813 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 814 Transport (LCT) Building Block", 815 draft-ietf-rmt-bb-lct-revised-07.txt (work in progress), 816 July 2008. 818 [RMT-PI-ALC] 819 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 820 Layered Coding (ALC) Protocol Instantiation", 821 draft-ietf-rmt-pi-alc-revised-05.txt (work in progress), 822 November 2007. 824 [RMT-PI-NORM] 825 Adamson, B., Bormann, C., Handley, M., and J. Macker, 826 "Negative-acknowledgment (NACK)-Oriented Reliable 827 Multicast (NORM) Protocol", 828 draft-ietf-rmt-pi-norm-revised-07.txt (work in progress), 829 October 2008. 831 8.2. Informative References 833 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 834 Hashing for Message Authentication", RFC 2104, 835 February 1997. 837 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 838 Standards (PKCS) #1: RSA Cryptography Specifications 839 Version 2.1", RFC 3447, February 2003. 841 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 843 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 844 RFC 3711, March 2004. 846 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 847 "FLUTE - File Delivery over Unidirectional Transport", 848 RFC 3926, October 2004. 850 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 851 Encapsulating Security Payload (ESP) and Authentication 852 Header (AH)", RFC 4359, January 2006. 854 Author's Address 856 Vincent Roca 857 INRIA 858 655, av. de l'Europe 859 Zirst; Montbonnot 860 ST ISMIER cedex 38334 861 France 863 Email: vincent.roca@inria.fr 864 URI: http://planete.inrialpes.fr/~roca/ 866 Full Copyright Statement 868 Copyright (C) The IETF Trust (2008). 870 This document is subject to the rights, licenses and restrictions 871 contained in BCP 78, and except as set forth therein, the authors 872 retain all their rights. 874 This document and the information contained herein are provided on an 875 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 876 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 877 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 878 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 879 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 880 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 882 Intellectual Property 884 The IETF takes no position regarding the validity or scope of any 885 Intellectual Property Rights or other rights that might be claimed to 886 pertain to the implementation or use of the technology described in 887 this document or the extent to which any license under such rights 888 might or might not be available; nor does it represent that it has 889 made any independent effort to identify any such rights. Information 890 on the procedures with respect to rights in RFC documents can be 891 found in BCP 78 and BCP 79. 893 Copies of IPR disclosures made to the IETF Secretariat and any 894 assurances of licenses to be made available, or the result of an 895 attempt made to obtain a general license or permission for the use of 896 such proprietary rights by implementers or users of this 897 specification can be obtained from the IETF on-line IPR repository at 898 http://www.ietf.org/ipr. 900 The IETF invites any interested party to bring to its attention any 901 copyrights, patents or patent applications, or other proprietary 902 rights that may cover technology that may be required to implement 903 this standard. Please address the information to the IETF at 904 ietf-ipr@ietf.org.