idnits 2.17.1 draft-ietf-rmt-simple-auth-for-alc-norm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5294 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) == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-09 == Outdated reference: A later version (-10) exists of draft-ietf-msec-tesla-for-alc-norm-09 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-16) exists of draft-ietf-rmt-flute-revised-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: Standards Track October 26, 2009 5 Expires: April 29, 2010 7 Simple Authentication Schemes for the ALC and NORM Protocols 8 draft-ietf-rmt-simple-auth-for-alc-norm-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 29, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document introduces four schemes that provide a per-packet 57 authentication and integrity service in the context of the ALC and 58 NORM protocols. The first scheme is based on digital signatures. 59 Because it relies on asymmetric cryptography, this scheme generates a 60 high processing load at the sender and to a lesser extent at a 61 receiver, as well as a significant transmission overhead. It is 62 therefore well suited to low data rate sessions. The second scheme 63 relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). If 64 this approach also relies an asymmetric cryptography, the processing 65 load and the transmission overhead are significantly reduced compared 66 to traditional digital signature schemes. It is therefore well 67 suited to medium data rate sessions. The third scheme relies on a 68 group Message Authentication Code (MAC). Because this scheme relies 69 on symmetric cryptography, MAC calculation and verification are fast 70 operations, which makes it suited to high data rate sessions. 71 However it only provides a group authentication and integrity 72 service, which means that it only protects against attackers that are 73 not group members. Finally, the fourth scheme merges the digital 74 signature and group group schemes, and is useful to mitigate DoS 75 attacks coming from attackers that are not group members. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 6 81 1.2. Conventions Used in this Document . . . . . . . . . . . . 7 82 1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7 83 2. RSA Digital Signature Scheme . . . . . . . . . . . . . . . . . 9 84 2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 9 85 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10 86 2.3. Authentication Header Extension Format . . . . . . . . . . 10 87 2.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 11 88 3. Elliptic Curve Digital Signature Scheme . . . . . . . . . . . 13 89 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 13 90 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 13 91 3.3. Authentication Header Extension Format . . . . . . . . . . 14 92 3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 15 93 4. Group Message Authentication Code (MAC) Scheme . . . . . . . . 16 94 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 16 95 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 16 96 4.3. Authentication Header Extension Format . . . . . . . . . . 17 97 4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 18 98 5. Combined Use of the RSA/ECC Digital Signatures and Group 99 MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 19 101 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 20 102 5.3. Authentication Header Extension Format . . . . . . . . . . 20 103 5.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 21 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 106 7.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 24 107 7.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 24 108 7.2.1. Impacts of Replay Attacks on the Simple 109 Authentication Schemes . . . . . . . . . . . . . . . . 24 110 7.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 24 111 7.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 25 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 116 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 118 1. Introduction 120 Many applications using multicast and broadcast communications 121 require that each receiver be able to authenticate the source of any 122 packet it receives to check check its integrity. For instance, ALC 123 [RMT-PI-ALC] and NORM [RMT-PI-NORM] are two Content Delivery 124 Protocols (CDP) designed to transfer reliably objects (e.g. files) 125 between a session's sender and several receivers. 127 The NORM protocol is based on bidirectional transmissions. Each 128 receiver acknowledges data received or, in case of packet erasures, 129 asks for retransmissions. On the opposite, the ALC protocol defines 130 unidirectional transmissions. Reliability can be achieved by means 131 of cyclic transmissions of the content within a carousel, or by the 132 use of proactive Forward Error Correction codes (FEC), or by the 133 joint use of these mechanisms. Being purely unidirectional, ALC is 134 massively scalable, while NORM is intrinsically limited in terms of 135 the number of receivers that can be handled in a session. Both 136 protocols have in common the fact that they operate at application 137 level, on top of an erasure channel (e.g. the Internet) where packets 138 can be lost (erased) during the transmission. 140 With these CDP, an attacker might impersonate the ALC or NORM session 141 sender and inject forged packets to the receivers, thereby corrupting 142 the objects reconstructed by the receivers. An attacker might also 143 impersonate a NORM session receiver and inject forged feedback 144 packets to the NORM sender. 146 In case of group communications, several solutions exist to provide 147 the receiver some guaranties on the integrity of the packets it 148 receives and on the identity of the sender of these packets. These 149 solutions have different features that make them more or less suited 150 to a given use case: 152 o digital signatures [RFC4359]: this scheme is well suited to low 153 data rate flows, when a true packet sender authentication and 154 packet integrity service is needed. However, digital signatures 155 based on RSA asymmetric cryptography is limited by high 156 computational costs and high transmission overheads. The use of 157 ECC ("Elliptic Curve Cryptography") significantly relaxes these 158 constraints, especially when seeking for higher security levels. 159 For instance, the following key sizes provide equivalent security: 160 1024 bit RSA key versus 160 bit ECC key, or 2048 bit RSA key 161 versus 224 bit ECC key. 163 o group Message Authentication Codes (MAC): this scheme is well 164 suited to high data rate flows, when transmission overheads must 165 be minimized. However this scheme cannot protect against attacks 166 coming from inside the group, where a group member impersonates 167 the sender and sends forged messages to other receivers. 169 o TESLA (Timed Efficient Stream Loss-tolerant Authentication) 170 [RFC4082][MSEC-TESLA]: this scheme is well suited to high data 171 rate flows, when transmission overheads must be minimized, and 172 when a true packet sender authentication and packet integrity 173 service is needed. The price to pay is an increased complexity, 174 in particular the need to loosely synchronize the receivers and 175 the sender, as well as the need to wait for the key to be 176 disclosed before being able to authenticate a packet. 178 The following table summarizes the pros/cons of each authentication/ 179 integrity scheme used at application/transport level (where "-" means 180 bad, "0" means neutral, and "+" means good): 182 +----------------+-------------+--------------+-------------+-------+ 183 | | RSA Digital | ECC Digital | Group MAC | TESLA | 184 | | Signature | Signature | | | 185 +----------------+-------------+--------------+-------------+-------+ 186 | True auth and | Yes | Yes | No (group | Yes | 187 | integrity | | | security) | | 188 | | | | | | 189 | Immediate auth | Yes | Yes | Yes | No | 190 | | | | | | 191 | Processing | - | 0 | + | + | 192 | load | | | | | 193 | | | | | | 194 | Transmission | - | 0 | + | + | 195 | overhead | | | | | 196 | | | | | | 197 | Complexity | + | + | + | - | 198 +----------------+-------------+--------------+-------------+-------+ 200 Several authentication schemes MAY be used in the same ALC or NORM 201 session, even on the same communication path. Since all the above 202 schemes make use of the same authentication header extension 203 mechanism (Section 2.3, Section 4.3, Section 5.3) and [MSEC-TESLA], 204 section 5.1), the same 4-bit "ASID" (Authentication Scheme 205 IDentifier) has been reserved in all the specifications. The 206 association between the "ASID" value and the actual authentication 207 scheme is defined at session startup and communicated to all the 208 group members by an out-of-band mechanism. 210 1.1. Scope of this Document 212 [MSEC-TESLA] explains how to use TESLA in the context of ALC and NORM 213 protocols. 215 The current document specifies the use of the Digital Signature based 216 on RSA asymmetric cryptography, the Elliptic Curve Digital Signature 217 Algorithm (ECDSA) and Group MAC schemes. The current document also 218 specifies the joint use of Digital Signature and Group MAC schemes 219 which is useful to mitigate DoS attacks coming from attackers that 220 are not group members. 222 Unlike the TESLA scheme, this specification considers the 223 authentication/integrity of the packets generated by the session's 224 sender as well as those generated by the receivers (NORM). 226 All the applications build on top of ALC and NORM directly benefit 227 from the source authentication and packet integrity services defined 228 in this document. For instance this is the case of the FLUTE 229 application [RMT-FLUTE] built on top of ALC. 231 The current specification assumes that several parameters (like 232 keying material) are communicated out-of-band, sometimes securely, 233 between the sender and the receivers. This is detailed in 234 Section 2.2 and Section 4.2. 236 1.2. Conventions Used in this Document 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 240 document are to be interpreted as described in [RFC2119]. 242 1.3. Terminology and Notations 244 The following notations and definitions are used throughout this 245 document: 247 o MAC is the Message Authentication Code; 249 o HMAC is the Keyed-Hash Message Authentication Code; 251 o sender denotes the sender of a packet that needs the 252 authentication/integrity check service. It can be an ALC or NORM 253 session sender, or a NORM session receiver in case of feedback 254 traffic; 256 o receiver denotes the receiver of a packet that needs the 257 authentication/integrity check service. It can be an ALC or NORM 258 session receiver, or a NORM session sender in case of feedback 259 traffic; 261 Digital signature related notations and definitions: 263 o K_pub is the public key used by a receiver to check a packet's 264 signature. This key MUST be communicated to all receivers, before 265 starting the session; 267 o K_priv is the private key used by a sender to generate a packet's 268 signature; 270 o n_k is the private key and public key length, in bits. n_k is also 271 the signature length, since both values are equal with digital 272 signatures; 274 Group MAC related notations and definitions: 276 o K_g is a shared group key used by the senders and the receivers. 277 This key MUST be communicated to all group members, 278 confidentially, before starting the session; 280 o n_k is the group key length, in bits; 282 o n_m is the length of the truncated output of the MAC [RFC2104]. 283 Only the n_m left-most bits (most significant bits) of the MAC 284 output are kept; 286 2. RSA Digital Signature Scheme 288 2.1. Principles 290 The computation of the digital signature, using K_priv, MUST include 291 the ALC or NORM header (with the various header extensions) and the 292 payload when applicable. The UDP/IP/MAC headers MUST NOT be 293 included. During this computation, the "Signature" field MUST be set 294 to 0. 296 Upon receiving this packet, the receiver recomputes the Group MAC, 297 using K_pub, and compares it to the value carried in the packet. 298 During this computation, the Weak Group MAC field MUST also be set to 299 0. If the check fails, the packet MUST be immediately dropped. 301 Several "Signature Encoding Algorithms" can be used, including 302 RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several 303 "Signature Cryptographic Function" can be used, like SHA-256. 305 First, let us consider a packet sender. More specifically, from 306 [RFC4359]: digital signature generation is performed as described in 307 [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for 308 RSASSA-PSS. The authenticated portion of the packet is used as the 309 message M, which is passed to the signature generation function. The 310 signer's RSA private key is passed as K. In summary (when SHA-256 is 311 used), the signature generation process computes a SHA-256 hash of 312 the authenticated packet bytes, signs the SHA-256 hash using the 313 private key, and encodes the result with the specified RSA encoding 314 type. This process results in a value S, which is the digital 315 signature to be included in the packet. 317 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 318 signature is equal to the "RSA modulus", unless the "RSA modulus" is 319 not a multiple of 8 bits. In that case, the signature MUST be 320 prepended with between 1 and 7 bits set to zero such that the 321 signature is a multiple of 8 bits [RFC4359]. The key size, which in 322 practice is also equal to the "RSA modulus", has major security 323 implications. [RFC4359] explains how to choose this value depending 324 on the maximum expected lifetime of the session. This choice is out 325 of the scope of this document. 327 Now let us consider a receiver. From [RFC4359]: Digital signature 328 verification is performed as described in [RFC3447], Section 8.2.2 329 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon 330 receipt, the digital signature is passed to the verification function 331 as S. The authenticated portion of the packet is used as the message 332 M, and the RSA public key is passed as (n, e). In summary (when SHA- 333 256 is used), the verification function computes a SHA-256 hash of 334 the authenticated packet bytes, decrypts the SHA-256 hash in the 335 packet using the sender's public key, and validates that the 336 appropriate encoding was applied. The two SHA-256 hashes are 337 compared and if they are identical the validation is successful. 339 2.2. Parameters 341 Several parameters MUST be initialized by an out-of-band mechanism. 342 The sender or group controller: 344 o MUST communicate his public key, for each receiver to be able to 345 verify the signature of the packets received. As a side effect, 346 the receivers also know the key length, n_k, and the signature 347 length, the two parameters being equal; 349 o MAY communicate a certificate (which also means that a PKI has 350 been setup), for each receiver to be able to check the sender's 351 public key; 353 o MUST communicate the Signature Encoding Algorithm. For instance, 354 [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms 355 that are usually used to that purpose; 357 o MUST communicate the Signature Cryptographic Function, for 358 instance SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of 359 security threats on SHA-1, the use of SHA-256 is RECOMMENDED; 361 o MUST associate a value to the "ASID" field (Authentication Scheme 362 Identifier) of the EXT_AUTH header extension (Section 2.3); 364 These parameters MUST be communicated to all receivers before they 365 can authenticate the incoming packets. For instance it can be 366 communicated in the session description, or initialized in a static 367 way on the receivers, or communicated by means of an appropriate 368 protocol. The details of this out-of-band mechanism are out of the 369 scope of this document. 371 2.3. Authentication Header Extension Format 373 The integration of Digital Signatures is similar in ALC and NORM and 374 relies on the header extension mechanism defined in both protocols. 375 More precisely this document details the EXT_AUTH==1 header extension 376 defined in [RFC5651]. 378 Several fields are added in addition to the HET (Header Extension 379 Type) and HEL (Header Extension Length) fields (Figure 1). 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | HET (=1) | HEL | ASID | Reserved | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 ~ ~ 388 | Signature | 389 + +-+-+-+-+-+-+-+-+ 390 | | Padding | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 1: Format of the Digital Signature EXT_AUTH header extension. 395 The fields of the Digital Signature EXT_AUTH header extension are: 397 "ASID" (Authentication Scheme Identifier) field (4 bits): 399 The "ASID" identifies the source authentication scheme or protocol 400 in use. The association between the "ASID" value and the actual 401 authentication scheme is defined out-of-band, at session startup. 403 "Reserved" field (12 bits): 405 This is a reserved field that MUST be set to zero in this 406 specification. 408 "Signature" field (variable size, multiple of 32 bits): 410 The "Signature" field contains a digital signature of the message. 411 If need be, this field is padded (with 0) up to a multiple of 32 412 bits. 414 2.4. In Practice 416 Each packet sent MUST contain exactly one Digital Signature EXT_AUTH 417 header extension. A receiver MUST drop all the packets that do not 418 contain a Digital Signature EXT_AUTH header extension. 420 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 421 its content, for instance because they do not support digital 422 signatures. In that case the Digital Signature EXT_AUTH header 423 extension is ignored. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | HET (=1) | HEL (=33) | ASID | 0 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 430 | | ^ 1 431 + + | 2 432 | | | 8 433 . . | 434 . Signature (128 bytes) . | b 435 . . | y 436 | | | t 437 + + | e 438 | | v s 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 441 Figure 2: Example: Format of the Digital Signature EXT_AUTH header 442 extension using 1024 bit signatures. 444 For instance Figure 2 shows the digital signature EXT_AUTH header 445 extension when using 128 byte (1024 bit) key digital signatures 446 (which also means that the signature field is 128 byte long). The 447 Digital Signature EXT_AUTH header extension is then 132 byte long. 449 3. Elliptic Curve Digital Signature Scheme 451 3.1. Principles 453 The computation of the ECC digital signature, using K_priv, MUST 454 include the ALC or NORM header (with the various header extensions) 455 and the payload when applicable. The UDP/IP/MAC headers MUST NOT be 456 included. During this computation, the "Signature" field MUST be set 457 to 0. 459 Upon receiving this packet, the receiver recomputes the Group MAC, 460 using K_pub, and compares it to the value carried in the packet. 461 During this computation, the Weak Group MAC field MUST also be set to 462 0. If the check fails, the packet MUST be immediately dropped. 464 Several "Elliptic Curves" groups can be used, as well as several 465 "Hash Algorithms". In practice both choices are related and there is 466 a minimum hash algorithm size for any key size. Using a larger hash 467 algorithm and then truncated the output is also feasible, however it 468 consumes more processing power than is necessary. The following 469 table lists the RECOMMENDED choices [RFC4754] [RFC5480]. 471 +-------------------------+-----------+-----------------+-----------+ 472 | Digital Signature | Key Size | Message Digest | Elliptic | 473 | Algorithm name | (n_k) | Algorithm | Curve | 474 | [RFC4754] | | | | 475 +-------------------------+-----------+-----------------+-----------+ 476 | ECDSA-256 | 256 | SHA-256 | secp256r1 | 477 | | | | | 478 | ECDSA-384 | 384 | SHA-384 | secp384r1 | 479 | | | | | 480 | ECDSA-521 | 512 | SHA-512 | secp521r1 | 481 +-------------------------+-----------+-----------------+-----------+ 483 The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security 484 comparable with AES-128, AES-192 and AES-256 respectively [RFC4754]. 486 3.2. Parameters 488 Several parameters MUST be initialized by an out-of-band mechanism. 489 The sender or group controller: 491 o MUST communicate his public key, for each receiver to be able to 492 verify the signature of the packets received. As a side effect, 493 the receivers also know the key length, n_k, and the signature 494 length, the two parameters being equal; 496 o MAY communicate a certificate (which also means that a PKI has 497 been setup), for each receiver to be able to check the sender's 498 public key; 500 o MUST communicate the Message Digest Algorithm; 502 o MUST communicate the Elliptic Curve; 504 o MUST associate a value to the "ASID" field (Authentication Scheme 505 Identifier) of the EXT_AUTH header extension (Section 2.3); 507 These parameters MUST be communicated to all receivers before they 508 can authenticate the incoming packets. For instance it can be 509 communicated in the session description, or initialized in a static 510 way on the receivers, or communicated by means of an appropriate 511 protocol. The details of this out-of-band mechanism are out of the 512 scope of this document. 514 3.3. Authentication Header Extension Format 516 The integration of ECC Digital Signatures is similar in ALC and NORM 517 and relies on the header extension mechanism defined in both 518 protocols. More precisely this document details the EXT_AUTH==1 519 header extension defined in [RFC5651]. 521 Several fields are added in addition to the HET (Header Extension 522 Type) and HEL (Header Extension Length) fields (Figure 1). 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | HET (=1) | HEL | ASID | Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 ~ ~ 531 | Signature | 532 + +-+-+-+-+-+-+-+-+ 533 | | Padding | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Figure 3: Format of the Digital Signature EXT_AUTH header extension. 538 The fields of the Digital Signature EXT_AUTH header extension are: 540 "ASID" (Authentication Scheme Identifier) field (4 bits): 542 The "ASID" identifies the source authentication scheme or protocol 543 in use. The association between the "ASID" value and the actual 544 authentication scheme is defined out-of-band, at session startup. 546 "Reserved" field (12 bits): 548 This is a reserved field that MUST be set to zero in this 549 specification. 551 "Signature" field (variable size, multiple of 32 bits): 553 The "Signature" field contains a digital signature of the message. 554 If need be, this field is padded (with 0) up to a multiple of 32 555 bits. 557 3.4. In Practice 559 Each packet sent MUST contain exactly one ECC Digital Signature 560 EXT_AUTH header extension. A receiver MUST drop all the packets that 561 do not contain an ECC Digital Signature EXT_AUTH header extension. 563 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 564 its content, for instance because they do not support ECC digital 565 signatures. In that case the Digital Signature EXT_AUTH header 566 extension is ignored. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | HET (=1) | HEL (=9) | ASID | 0 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 573 | | ^ 3 574 + + | 2 575 . . | 576 . Signature (32 bytes) . | b 577 . . | y 578 | | | t 579 + + | e 580 | | v s 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 583 Figure 4: Example: Format of the ECC Digital Signature EXT_AUTH 584 header extension using ECDSA-256 signatures. 586 For instance Figure 4 shows the digital signature EXT_AUTH header 587 extension when using ECDSA-256 (256 bit) ECC digital signatures. The 588 ECC Digital Signature EXT_AUTH header extension is then 36 byte long. 590 4. Group Message Authentication Code (MAC) Scheme 592 4.1. Principles 594 The computation of the Group MAC, using K_g, includes the ALC or NORM 595 header (with the various header extensions) and the payload when 596 applicable. The UDP/IP/MAC headers are not included. During this 597 computation, the Weak Group MAC field MUST be set to 0. Then the 598 sender truncates the MAC output to keep the n_m most significant bits 599 and stores the result in the Group MAC Authentication header. 601 Upon receiving this packet, the receiver recomputes the Group MAC, 602 using K_g, and compares it to the value carried in the packet. 603 During this computation, the Group MAC field MUST also be set to 0. 604 If the check fails, the packet MUST be immediately dropped. 606 [RFC2104] explains that it is current practice to truncate the MAC 607 output, on condition that the truncated output length, n_m be not 608 less than half the length of the hash and not less than 80 bits. 609 However, this choice is out of the scope of this document. 611 4.2. Parameters 613 Several parameters MUST be initialized by an out-of-band mechanism. 614 The sender or group controller: 616 o MUST communicate the Cryptographic MAC Function, for instance, 617 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA- 618 512. Because of security threats on SHA-1, the use of HMAC-SHA- 619 256 is RECOMMENDED. As a side effect, the receivers also know the 620 key length, n_k, and the non truncated MAC output length; 622 o MUST communicate the length of the truncated output of the MAC, 623 n_m, which depends on the Cryptographic MAC Function chosen. Only 624 the n_m left-most bits (most significant bits) of the MAC output 625 are kept. Of course, n_m MUST be lower or equal to n_k; 627 o MUST communicate the K_g group key to the receivers, 628 confidentially, before starting the session. This key might have 629 to be periodically refreshed for improved robustness; 631 o MUST associate a value to the "ASID" field (Authentication Scheme 632 Identifier) of the EXT_AUTH header extension (Section 4.3); 634 These parameters MUST be communicated to all receivers before they 635 can authenticate the incoming packets. For instance it can be 636 communicated in the session description, or initialized in a static 637 way on the receivers, or communicated by means of an appropriate 638 protocol (this will be often the case when periodic re-keying is 639 required). The details of this out-of-band mechanism are out of the 640 scope of this document. 642 4.3. Authentication Header Extension Format 644 The integration of Group MAC is similar in ALC and NORM and relies on 645 the header extension mechanism defined in both protocols. More 646 precisely this document details the EXT_AUTH==1 header extension 647 defined in [RFC5651]. 649 Several fields are added in addition to the HET (Header Extension 650 Type) and HEL (Header Extension Length) fields (Figure 5). 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | HET (=1) | HEL | ASID | Reserved | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 ~ ~ 659 | Group MAC | 660 + +-+-+-+-+-+-+-+-+ 661 | | Padding | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 5: Format of the Group MAC EXT_AUTH header extension. 666 The fields of the Group MAC EXT_AUTH header extension are: 668 "ASID" (Authentication Scheme Identifier) field (4 bits): 670 The "ASID" identifies the source authentication scheme or protocol 671 in use. The association between the "ASID" value and the actual 672 authentication scheme is defined out-of-band, at session startup. 674 "Reserved" field (12 bits): 676 This is a reserved field that MUST be set to zero in this 677 specification. 679 "Group MAC" field (variable size, multiple of 32 bits): 681 The "Group MAC" field contains a truncated Group MAC of the 682 message. If need be, this field is padded (with 0) up to a 683 multiple of 32 bits. 685 4.4. In Practice 687 Each packet sent MUST contain exactly one Group MAC EXT_AUTH header 688 extension. A receiver MUST drop packets that do not contain a Group 689 MAC EXT_AUTH header extension. 691 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 692 its content, for instance because they do not support Group MAC. In 693 that case the Group MAC EXT_AUTH extension is ignored. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | HET (=1) | HEL (=4) | ASID | 0 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | | 701 + + 702 | Group MAC (10 bytes) | 703 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | Padding | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 6: Example: Format of the Group MAC EXT_AUTH header extension 708 using HMAC-SHA-1. 710 For instance Figure 6 shows the Group MAC EXT_AUTH header extension 711 when using HMAC-SHA-1. The Group MAC EXT_AUTH header extension is 712 then 16 byte long. 714 5. Combined Use of the RSA/ECC Digital Signatures and Group MAC Schemes 716 5.1. Principles 718 In some situations, it can be interesting to use both authentication 719 schemes. The goal of the Group MAC is to mitigate DoS attacks coming 720 from attackers that are not group members [RFC4082] by adding a light 721 authentication scheme as a front-end. 723 More specifically, before sending a message, the sender sets the 724 Signature field and Group MAC field to zero. Then the sender 725 computes the Signature as detailed in Section 2.1 or in Section 3.1 726 and stores the value in the Signature field. Then the sender 727 computes the Group MAC as detailed in Section 4.1 and stores the 728 value in the Group MAC field. The (RSA or ECC) digital signature 729 value is therefore protected by the Group MAC, which avoids DoS 730 attacks where the attacker corrupts the digital signature itself. 732 Upon receiving the packet, the receiver first checks the Group MAC, 733 as detailed in Section 4.1. If the check fails, the packet MUST be 734 immediately dropped. Otherwise the receiver checks the Digital 735 Signature, as detailed in Section 2.1. If the check fails, the 736 packet MUST be immediately dropped. 738 This scheme features a few limits: 740 o the Group MAC is of no help if a group member (who knows K_g) 741 impersonates the sender and sends forged messages to other 742 receivers. DoS attacks are still feasible; 744 o it requires an additional MAC computing for each packet, both at 745 the sender and receiver sides; 747 o it increases the size of the authentication headers. In order to 748 limit this problem, the length of the truncated output of the MAC, 749 n_m, SHOULD be kept small (see [RFC3711] section 9.5). In the 750 current specification, n_m MUST be a multiple of 32 bits, and 751 default value is 32 bits. As a side effect, with $n_m = 32$ bits, 752 the authentication service is significantly weakened since the 753 probability that any packet be successfully forged is one in 2^32. 754 Since the Group MAC check is only a pre-check that is followed by 755 the standard signature authentication check, this is not 756 considered to be an issue. 758 For a given use-case, the benefits brought by the Group MAC must be 759 balanced against these limitations. 761 5.2. Parameters 763 Several parameters MUST be initialized by an out-of-band mechanism, 764 as defined in Section 2.2, Section 3.2 and Section 4.2. 766 5.3. Authentication Header Extension Format 768 The integration of combined RSA/ECC Digital Signature and Group MAC 769 is similar in ALC and NORM and relies on the header extension 770 mechanism defined in both protocols. More precisely this document 771 details the EXT_AUTH==1 header extension defined in [RFC5651]. 773 Several fields are added in addition to the HET (Header Extension 774 Type) and HEL (Header Extension Length) fields (Figure 7). 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | HET (=1) | HEL | ASID | Reserved | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 ~ ~ 783 | Signature | 784 + +-+-+-+-+-+-+-+-+ 785 | | Padding | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Group MAC | 788 ~ ~ 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 7: Format of the Group MAC EXT_AUTH header extension. 793 The fields of the Group MAC EXT_AUTH header extension are: 795 "ASID" (Authentication Scheme Identifier) field (4 bits): 797 The "ASID" identifies the source authentication scheme or protocol 798 in use. The association between the "ASID" value and the actual 799 authentication scheme is defined out-of-band, at session startup. 801 "Reserved" field (12 bits): 803 This is a reserved field that MUST be set to zero in this 804 specification. 806 "Signature" field (variable size, multiple of 32 bits): 808 The "Signature" field contains a digital signature of the message. 809 If need be, this field is padded (with 0) up to a multiple of 32 810 bits. 812 "Group MAC" field (variable size, multiple of 32 bits, by default 32 813 bits): 815 The "Group MAC" field contains a truncated Group MAC of the 816 message. 818 5.4. In Practice 820 Each packet sent MUST contain exactly one combined Digital Signature/ 821 Group MAC EXT_AUTH header extension. A receiver MUST drop packets 822 that do not contain a combined Digital Signature/Group MAC EXT_AUTH 823 header extension. 825 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 826 its content, for instance because they do not support combined 827 Digital Signature/Group MAC. In that case the combined Digital 828 Signature/Group MAC EXT_AUTH extension is ignored. 830 It is RECOMMENDED that the n_m parameter of the group authentication 831 scheme be small, and by default equal to 32 bits (Section 5.1). 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | HET (=1) | HEL (=34) | ASID | 0 | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 838 | | ^ 1 839 + + | 2 840 | | | 8 841 . . | 842 . Signature (128 bytes) . | b 843 . . | y 844 | | | t 845 + + | e 846 | | v s 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 848 | Group MAC (32 bits) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 851 Figure 8: Example: Format of the combined RSA Digital Signature/Group 852 MAC EXT_AUTH header extension using 1024 bit signatures. 854 For instance Figure 8 shows the combined Digital Signature/Group MAC 855 EXT_AUTH header extension when using 128 byte (1024 bit) key RSA 856 digital signatures (which also means that the signature field is 128 857 byte long). The EXT_AUTH header extension is then 136 byte long. 859 6. IANA Considerations 861 This document does not require any IANA registration. 863 7. Security Considerations 865 7.1. Dealing With DoS Attacks 867 Digital signatures introduces new opportunities for an attacker to 868 mount DoS attacks. For instance an attacker can try to saturate the 869 processing capabilities of the receiver (faked packets are easy to 870 create but checking them requires to compute a costly digital 871 signature). 873 In order to mitigate these attacks, it is RECOMMENDED to use the 874 combined Digital Signature/Group MAC scheme (Section 5.1). However, 875 no mitigation is possible if a group member acts as an attacker. 877 7.2. Dealing With Replay Attacks 879 Replay attacks consist for an attacker to store a valid message and 880 to replay it later on. 882 7.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes 884 Since all the above authentication schemes are memoryless, replay 885 attacks have no impact on these schemes. 887 7.2.2. Impacts of Replay Attacks on NORM 889 We review here the potential impacts of a replay attack on the NORM 890 component. Note that we do not consider here the protocols that 891 could be used along with NORM, for instance the congestion control 892 protocols. 894 First, let us consider replay attacks within a given NORM session. 895 NORM defines a "sequence" field that can be used to protect against 896 replay attacks [RMT-PI-NORM] within a given NORM session. This 897 "sequence" field is a 16-bit value that is set by the message 898 originator (sender or receiver) as a monotonically increasing number 899 incremented with each NORM message transmitted. It is RECOMMENDED 900 that a receiver check this sequence field and drop messages 901 considered as replayed. Similarly, it is RECOMMENDED that a sender 902 check this sequence, for each known receiver, and drop messages 903 considered as replayed. In both cases, checking this sequence field 904 SHOULD be done before authenticating the packet: if the sequence 905 field has not been corrupted, the replay attack will immediately be 906 identified, and otherwise the packet will fail the authentication 907 test. This analysis shows that NORM itself is robust in front of 908 replay attacks within the same session. 910 Now let us consider replay attacks across several NORM sessions. A 911 host participation in a NORM session is uniquely identified by the 912 {"source_id"; "instance_id"} tuple. Therefore, when a given host 913 participates in several NORM sessions, it is RECOMMENDED that the 914 "instance_id" be changed for each NORM instance. It is also 915 RECOMMENDED, when the Group MAC authentication/integrity check scheme 916 is used, that the shared group key, K_g, be changed across sessions. 917 Therefore, NORM can be made robust in front of replay attacks across 918 different sessions. 920 7.2.3. Impacts of Replay Attacks on ALC 922 We review here the potential impacts of a replay attack on the ALC 923 component. Note that we do not consider here the protocols that 924 could be used along with ALC, for instance the layered or wave based 925 congestion control protocols. 927 First, let us consider replay attacks within a given ALC session: 929 o Regular packets containing an authentication tag: a replayed 930 message containing an encoding symbol will be detected once 931 authenticated, thanks to the object/block/symbol identifiers, and 932 will be silently discarded. This kind of replay attack is only 933 penalizing in terms of memory and processing load, but does not 934 compromise the ALC behavior. 936 o Control packets containing an authentication tag: ALC control 937 packets, by definition, do not include any encoding symbol and 938 therefore do not include any object/block/symbol identifier that 939 would enable a receiver to identify duplicates. However, a sender 940 has a very limited number of reasons to send control packets. 941 More precisely: 943 * At the end of the session, a "close session" (A flag) packet is 944 sent. Replaying this packet has no impact since the receivers 945 already left. 947 * Similarly, replaying a packet containing a "close object" (B 948 flag) has no impact since this object is probably already 949 marked as closed by the receiver. 951 This analysis shows that ALC itself is robust in front of replay 952 attacks within the same session. 954 Now let us consider replay attacks across several ALC sessions. An 955 ALC session is uniquely identified by the {sender's IP address; 956 Transport Session Identifier (TSI)} [RFC5651]. Therefore, when a 957 given sender creates several sessions, it is RECOMMENDED that the TSI 958 be changed for each ALC instance. It is also RECOMMENDED, when the 959 Group MAC authentication/integrity check scheme is used, that the 960 shared group key, K_g, be changed across sessions. Therefore, ALC 961 can be made robust in front of replay attacks across different 962 sessions. 964 8. Acknowledgments 966 The author is grateful to the authors of [RFC4359], [RFC4754] and 967 [RFC5480] that inspired several sections of the present document. 969 9. References 971 9.1. Normative References 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", RFC 2119, BCP 14, March 1997. 976 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 977 Transport (LCT) Building Block", RFC 5651, October 2009. 979 [RMT-PI-ALC] 980 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 981 Layered Coding (ALC) Protocol Instantiation", 982 draft-ietf-rmt-pi-alc-revised-09.txt (work in progress), 983 October 2009. 985 [RMT-PI-NORM] 986 Adamson, B., Bormann, C., Handley, M., and J. Macker, 987 "Negative-acknowledgment (NACK)-Oriented Reliable 988 Multicast (NORM) Protocol", 989 draft-ietf-rmt-pi-norm-revised-14.txt (work in progress), 990 September 2009. 992 9.2. Informative References 994 [MSEC-TESLA] 995 Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in 996 the ALC and NORM Protocols", 997 draft-ietf-msec-tesla-for-alc-norm-09.txt (work in 998 progress), October 2009. 1000 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1001 Hashing for Message Authentication", RFC 2104, 1002 February 1997. 1004 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1005 Standards (PKCS) #1: RSA Cryptography Specifications 1006 Version 2.1", RFC 3447, February 2003. 1008 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1009 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1010 RFC 3711, March 2004. 1012 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1013 Briscoe, "Timed Efficient Stream Loss-Tolerant 1014 Authentication (TESLA): Multicast Source Authentication 1015 Transform Introduction", RFC 4082, June 2005. 1017 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 1018 Encapsulating Security Payload (ESP) and Authentication 1019 Header (AH)", RFC 4359, January 2006. 1021 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 1022 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 1023 RFC 4754, January 2007. 1025 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1026 "Elliptic Curve Cryptography Subject Public Key 1027 Information", RFC 5480, March 2009. 1029 [RMT-FLUTE] 1030 Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, 1031 "FLUTE - File Delivery over Unidirectional Transport", 1032 draft-ietf-rmt-flute-revised-07 (work in progress), 1033 August 2009. 1035 Author's Address 1037 Vincent Roca 1038 INRIA 1039 655, av. de l'Europe 1040 Zirst; Montbonnot 1041 ST ISMIER cedex 38334 1042 France 1044 Email: vincent.roca@inria.fr 1045 URI: http://planete.inrialpes.fr/people/roca/