idnits 2.17.1 draft-ietf-rmt-simple-auth-for-alc-norm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (September 30, 2011) is 4586 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Experimental September 30, 2011 5 Expires: April 2, 2012 7 Simple Authentication Schemes for the ALC and NORM Protocols 8 draft-ietf-rmt-simple-auth-for-alc-norm-05 10 Abstract 12 This document introduces four schemes that provide per-packet 13 authentication, integrity and anti-replay services in the context of 14 the ALC and NORM protocols. The first scheme is based on digital 15 signatures. The second scheme relies on the Elliptic Curve Digital 16 Signature Algorithm (ECDSA). The third scheme relies on a group 17 Message Authentication Code (MAC). Finally, the fourth scheme merges 18 the digital signature and group schemes. These schemes have 19 different target use cases and they do not all provide the same 20 service. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 2, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 6 58 1.2. Terminology, Notations and Definitions . . . . . . . . . . 6 59 2. RSA Digital Signature Scheme . . . . . . . . . . . . . . . . . 8 60 2.1. Authentication Header Extension Format . . . . . . . . . . 8 61 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.3.1. Signature Processing . . . . . . . . . . . . . . . . . 10 64 2.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 11 65 2.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 12 66 3. Elliptic Curve Digital Signature Scheme . . . . . . . . . . . 13 67 3.1. Authentication Header Extension Format . . . . . . . . . . 13 68 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 15 70 3.3.1. Signature Processing . . . . . . . . . . . . . . . . . 15 71 3.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 15 72 3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 15 73 4. Group Message Authentication Code (MAC) Scheme . . . . . . . . 17 74 4.1. Authentication Header Extension Format . . . . . . . . . . 17 75 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 18 76 4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 19 77 4.3.1. Signature Processing . . . . . . . . . . . . . . . . . 19 78 4.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 19 79 4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 19 80 5. Combined Use of the RSA/ECC Digital Signatures and Group 81 MAC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.1. Authentication Header Extension Format . . . . . . . . . . 21 83 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 22 85 5.3.1. Signature Processing . . . . . . . . . . . . . . . . . 22 86 5.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 23 87 5.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 23 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 7.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 26 91 7.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 26 92 7.2.1. Impacts of Replay Attacks on the Simple 93 Authentication Schemes . . . . . . . . . . . . . . . . 26 94 7.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 26 95 7.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 27 96 7.3. Dealing With Attacks on the Parameters Sent Out-of-Band . 28 97 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 1. Introduction 105 Many applications using multicast and broadcast communications 106 require that each receiver be able to authenticate the source of any 107 packet it receives to check its integrity. For instance, ALC 108 [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDP) 109 designed to transfer reliably objects (e.g. files) between a 110 session's sender and several receivers. 112 The NORM protocol is based on bidirectional transmissions. With NORM 113 each receiver acknowledges data received or, in case of packet 114 erasures, asks for retransmissions. On the opposite, the ALC 115 protocol defines unidirectional transmissions. With ALC, reliability 116 can be achieved by means of cyclic transmissions of the content 117 within a carousel, or by the use of proactive Forward Error 118 Correction codes (FEC), or by the joint use of these mechanisms. 119 Being purely unidirectional, ALC is massively scalable, while NORM is 120 intrinsically limited in terms of the number of receivers that can be 121 handled in a session. Both protocols have in common the fact that 122 they operate at application level, on top of an erasure channel (e.g. 123 the Internet) where packets can be lost (erased) during the 124 transmission. 126 With these CDP, an attacker might impersonate the ALC or NORM session 127 sender and inject forged packets to the receivers, thereby corrupting 128 the objects reconstructed by the receivers. An attacker might also 129 impersonate a NORM session receiver and inject forged feedback 130 packets to the NORM sender. 132 In case of group communications, several solutions exist to provide 133 the receiver some guaranties on the integrity of the packets it 134 receives and on the identity of the sender of these packets. These 135 solutions have different features that make them more or less suited 136 to a given use case: 138 o digital signatures [RFC4359] (see Section 2 and Section 3): this 139 scheme is well suited to low data rate flows, when a packet sender 140 authentication and packet integrity service is needed. However, 141 digital signatures based on RSA asymmetric cryptography are 142 limited by high computational costs and high transmission 143 overheads. The use of ECC ("Elliptic Curve Cryptography") 144 significantly relaxes these constraints. For instance, the 145 following key lengths provide equivalent security: 1024 bit RSA 146 key versus 160 bit ECC key, or 2048 bit RSA key versus 224 bit ECC 147 key. 149 o group Message Authentication Codes (MAC) (see Section 4): this 150 scheme is well suited to high data rate flows, when transmission 151 overheads must be minimized. However this scheme cannot protect 152 against attacks coming from inside the group, where a group member 153 impersonates the sender and sends forged messages to other 154 receivers. 156 o TESLA (Timed Efficient Stream Loss-tolerant Authentication) 157 [RFC4082][RFC5776]: this scheme is well suited to high data rate 158 flows, when transmission overheads must be minimized, and when a 159 packet sender authentication and packet integrity service is 160 needed. The price to pay is an increased complexity, in 161 particular the need to loosely synchronize the receivers and the 162 sender, as well as the need to wait for the key to be disclosed 163 before being able to authenticate a packet (i.e. the 164 authentication check is delayed) 166 The following table summarizes the pros/cons of each authentication/ 167 integrity scheme used at application/transport level (where "-" means 168 bad, "0" means neutral, and "+" means good): 170 +------------------+-------------+-------------+------------+-------+ 171 | | RSA Digital | ECC Digital | Group MAC | TESLA | 172 | | Signature | Signature | | | 173 +------------------+-------------+-------------+------------+-------+ 174 | Sender auth and | Yes | Yes | No (group | Yes | 175 | packet integrity | | | security) | | 176 | | | | | | 177 | Non delayed | Yes | Yes | Yes | No | 178 | authentication | | | | | 179 | | | | | | 180 | Anti-replay | Opt | Opt | Opt | No | 181 | protection | | | | | 182 | | | | | | 183 | Processing load | - | 0 | + | + | 184 | | | | | | 185 | Transmission | - | 0 | + | + | 186 | overhead | | | | | 187 | | | | | | 188 | Complexity | + | + | + | - | 189 +------------------+-------------+-------------+------------+-------+ 191 Several authentication schemes MAY be used in the same ALC or NORM 192 session, even on the same communication path. Since all the above 193 schemes make use of the same authentication header extension 194 mechanism (Section 2.1, Section 4.1, Section 5.1) and [RFC5776], 195 section 5.1), the same 4-bit "ASID" (Authentication Scheme 196 IDentifier) has been reserved in all the specifications. The 197 association between the "ASID" value and the actual authentication 198 scheme is defined at session startup and communicated to all the 199 group members by an out-of-band mechanism. 201 All the applications build on top of ALC and NORM directly benefit 202 from the source authentication and packet integrity services defined 203 in this document. For instance this is the case of the FLUTE 204 application [RMT-FLUTE] built on top of ALC. 206 The current specification assumes that several parameters (like 207 keying material) are communicated out-of-band, sometimes securely, 208 between the sender and the receivers. This is detailed in 209 Section 2.2 and Section 4.2. 211 1.1. Scope of this Document 213 [RFC5776] explains how to use TESLA in the context of ALC and NORM 214 protocols. 216 The current document specifies the use of the Digital Signature based 217 on RSA asymmetric cryptography, the Elliptic Curve Digital Signature 218 Algorithm (ECDSA) and Group MAC schemes. The current document also 219 specifies the joint use of Digital Signature and Group MAC schemes. 221 Unlike the TESLA scheme, this specification considers the 222 authentication/integrity of the packets generated by the session's 223 sender as well as those generated by the receivers (NORM). 225 1.2. Terminology, Notations and Definitions 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in [RFC2119]. 231 The following notations and definitions are used throughout this 232 document: 234 o MAC is the Message Authentication Code; 236 o HMAC is the Keyed-Hash Message Authentication Code; 238 o sender denotes the sender of a packet that needs the 239 authentication/integrity check service. It can be an ALC or NORM 240 session sender, or a NORM session receiver in case of feedback 241 traffic; 243 o receiver denotes the receiver of a packet that needs the 244 authentication/integrity check service. It can be an ALC or NORM 245 session receiver, or a NORM session sender in case of feedback 246 traffic; 248 Digital signature related definitions: 250 o the public key used by a receiver to check a packet's signature. 251 This key MUST be communicated to all receivers, before starting 252 the session; 254 o the private key used by a sender to generate a packet's signature; 256 o the private key and public key length are expressed in bits. This 257 is also the signature length, since those values are equal with 258 digital signatures; 260 Group MAC related definitions: 262 o the shared group key used by the senders and the receivers. This 263 key MUST be communicated to all group members, confidentially, 264 before starting the session; 266 o the group key length is expressed in bits; 268 o n_m is the length of the truncated output of the MAC [RFC2104]. 269 Only the n_m left-most bits (most significant bits) of the MAC 270 output are kept; 272 2. RSA Digital Signature Scheme 274 2.1. Authentication Header Extension Format 276 The integration of Digital Signatures is similar in ALC and NORM and 277 relies on the header extension mechanism defined in both protocols. 278 More precisely this document details the EXT_AUTH==1 header extension 279 defined in [RFC5651]. 281 Several fields are added in addition to the HET (Header Extension 282 Type) and HEL (Header Extension Length) fields (Figure 1). 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | HET (=1) | HEL | ASID | rsvd|A| | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 289 ~ anti-replay Sequence Number (SN) ~ 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 ~ ~ 293 | Signature | 294 + +-+-+-+-+-+-+-+-+ 295 | | Padding | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 1: Format of the Digital Signature EXT_AUTH header extension. 300 The fields of the Digital Signature EXT_AUTH header extension are: 302 "ASID" (Authentication Scheme Identifier) field (4 bits): 304 The "ASID" identifies the source authentication scheme or protocol 305 in use. The association between the "ASID" value and the actual 306 authentication scheme is defined out-of-band, at session startup. 308 "Reserved" field (3 bits): 310 This is a reserved field that MUST be set to zero in this 311 specification. 313 "A" (Anti-replay) field (1 bit): 315 The "AR" field, when set to 0, indicates that the anti-replay 316 service is not used. When set to 1, it indicates that the anti- 317 replay service is used. 319 "SN" (Sequence Number) field (8 or 40 bits): 321 The "SN" field contains an optional sequence number. When AR=0, 322 this is an 8 bit field that MUST be set to zero. No anti-replay 323 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 324 field and all of the 40 bits MUST be considered by the anti-replay 325 mechanism. 327 "Signature" field (variable size, multiple of 32 bits): 329 The "Signature" field contains a digital signature of the message. 330 If need be, this field is padded (with 0) up to a multiple of 32 331 bits. 333 2.2. Parameters 335 Several parameters MUST be initialized by an out-of-band mechanism. 336 The sender or group controller: 338 o MUST communicate his public key, for each receiver to be able to 339 verify the signature of the packets received. As a side effect, 340 the receivers also know the key length and the signature length, 341 the two parameters being equal; 343 o MAY communicate a certificate (which also means that a PKI has 344 been setup), for each receiver to be able to check the sender's 345 public key; 347 o MUST communicate the Signature Encoding Algorithm. For instance, 348 [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms 349 that are usually used to that purpose; 351 o MUST communicate the Signature Cryptographic Function, for 352 instance SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of 353 security threats on SHA-1, the use of SHA-256 is RECOMMENDED; 355 o MUST associate a value to the "ASID" field (Authentication Scheme 356 Identifier) of the EXT_AUTH header extension (Section 2.1); 358 o MUST communicate whether the anti-replay service is used or not 359 for this session; 361 These parameters MUST be communicated to all receivers before they 362 can authenticate the incoming packets. For instance it can be 363 communicated in the session description, or initialized in a static 364 way on the receivers, or communicated by means of an appropriate 365 protocol. The details of this out-of-band mechanism are out of the 366 scope of this document. 368 2.3. Processing 370 2.3.1. Signature Processing 372 The computation of the digital signature, using the private key, MUST 373 include the ALC or NORM header (with the various header extensions) 374 and the payload when applicable. The UDP/IP/MAC headers MUST NOT be 375 included. During this computation, the "Signature" field MUST be set 376 to 0. 378 Several "Signature Encoding Algorithms" can be used, including 379 RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several 380 "Signature Cryptographic Function" can be used, like SHA-256. 382 First, let us consider a packet sender. More specifically, from 383 [RFC4359]: digital signature generation is performed as described in 384 [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for 385 RSASSA-PSS. The authenticated portion of the packet is used as the 386 message M, which is passed to the signature generation function. The 387 signer's RSA private key is passed as K. In summary (when SHA-256 is 388 used), the signature generation process computes a SHA-256 hash of 389 the authenticated packet bytes, signs the SHA-256 hash using the 390 private key, and encodes the result with the specified RSA encoding 391 type. This process results in a value S, which is the digital 392 signature to be included in the packet. 394 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 395 signature is equal to the "RSA modulus", unless the "RSA modulus" is 396 not a multiple of 8 bits. In that case, the signature MUST be 397 prepended with between 1 and 7 bits set to zero such that the 398 signature is a multiple of 8 bits [RFC4359]. The key length, which 399 in practice is also equal to the "RSA modulus", has major security 400 implications. [RFC4359] explains how to choose this value depending 401 on the maximum expected lifetime of the session. This choice is out 402 of the scope of this document. 404 Now let us consider a receiver. From [RFC4359]: Digital signature 405 verification is performed as described in [RFC3447], Section 8.2.2 406 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon 407 receipt, the digital signature is passed to the verification function 408 as S. The authenticated portion of the packet is used as the message 409 M, and the RSA public key is passed as (n, e). In summary (when SHA- 410 256 is used), the verification function computes a SHA-256 hash of 411 the authenticated packet bytes, decrypts the SHA-256 hash in the 412 packet using the sender's public key, and validates that the 413 appropriate encoding was applied. The two SHA-256 hashes are 414 compared and if they are identical the validation is successful. 416 2.3.2. Anti-Replay Processing 418 Let us assume the anti-replay service is used. The principles are 419 similar to the Sequence Number mechanism described in [RFC4303], with 420 the exception that the present document uses a 40 bit field that 421 contains all the bits of the sequence number counter. 423 At the sender, the mechanism works as follows ([RFC4303], section 424 2.2). The sender's sequence number counter is initialized to 0 at 425 session startup. The sender increments the Sequence Number counter 426 for this session and inserts the value into the SN field. Thus, the 427 first packet sent will contain a SN of 1. The SN value of the 428 Authentication Header Extension MUST be initialized before the 429 signature generation process, in order to enable a receiver to check 430 the SN value during the integrity verification process. 432 The sender SHOULD ensure that the counter does not cycle before 433 inserting the new value in the SN field. Failing to follow this rule 434 would enable an attacker to replay a packet sent during the previous 435 cycle, i.e., it would limit the anti-replay service to a single SN 436 cycle. Since the sequence number is contained in a 40 bit field, it 437 is expected that cycling will never happen in most situations. For 438 instance, on a 10 Gbps network, with small (i.e., 64 byte long) 439 packets, cycling will happen after slightly more than 15 hours. 441 At the receiver, the mechanism works as follows ([RFC4303], sections 442 3.4.3 and A2). For each received packet, the receiver MUST verify 443 that the packet contains a Sequence Number that does not duplicate 444 the Sequence Number of any other packets received during the session. 445 If this preliminary check fails, the packet is discarded, thus 446 avoiding the need for any cryptographic operations by the receiver. 447 If the preliminary check is successful, the receiver cannot yet 448 modify its local counter, because the integrity of the Sequence 449 Number has not been verified at this point. 451 Duplicates are rejected through the use of a sliding receive window. 452 The "right" edge of the window represents the highest, validated 453 Sequence Number value received on this session. Packets that contain 454 sequence numbers lower than the "left" edge of the window are 455 rejected. Packets falling within the window are checked against a 456 list of received packets within the window (how this list is managed 457 is a local, implementation based decision). This window limits how 458 far out of order a packet can be, relative to the packet with the 459 highest sequence number that has been authenticated so far. 461 If the received packet falls within the window and is not a 462 duplicate, or if the packet is to the right of the window, then the 463 receiver proceeds to integrity verification. If the integrity check 464 fails, the receiver MUST discard the received packet as invalid, 465 otherwise the receive window is updated and packet processing 466 continues. 468 2.4. In Practice 470 Each packet sent MUST contain exactly one Digital Signature EXT_AUTH 471 header extension. A receiver MUST drop all the packets that do not 472 contain a Digital Signature EXT_AUTH header extension. 474 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 475 its content, for instance because they do not support digital 476 signatures. In that case the Digital Signature EXT_AUTH header 477 extension is ignored. 479 If the anti-replay mechanism is used, each packet sent MUST contain a 480 valid sequence number. All the packets that fail to contain a valid 481 sequence number MUST be immediately dropped. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | HET (=1) | HEL (=33) | ASID | 0 |0| 0 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 488 | | ^ 1 489 + + | 2 490 | | | 8 491 . . | 492 . Signature (128 bytes) . | b 493 . . | y 494 | | | t 495 + + | e 496 | | v s 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 499 Figure 2: Example: Format of the Digital Signature EXT_AUTH header 500 extension using 1024 bit signatures, without any anti-replay 501 protection. 503 For instance Figure 2 shows the digital signature EXT_AUTH header 504 extension when using 128 byte (1024 bit) key digital signatures 505 (which also means that the signature field is 128 byte long). The 506 Digital Signature EXT_AUTH header extension is then 132 byte long. 508 3. Elliptic Curve Digital Signature Scheme 510 3.1. Authentication Header Extension Format 512 The integration of ECC Digital Signatures is similar in ALC and NORM 513 and relies on the header extension mechanism defined in both 514 protocols. More precisely this document details the EXT_AUTH==1 515 header extension defined in [RFC5651]. 517 Several fields are added in addition to the HET (Header Extension 518 Type) and HEL (Header Extension Length) fields (Figure 1). 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | HET (=1) | HEL | ASID | rsvd|A| | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 525 ~ anti-replay Sequence Number (SN) ~ 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 ~ ~ 529 | Signature | 530 + +-+-+-+-+-+-+-+-+ 531 | | Padding | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 3: Format of the Digital Signature EXT_AUTH header extension. 536 The fields of the Digital Signature EXT_AUTH header extension are: 538 "ASID" (Authentication Scheme Identifier) field (4 bits): 540 The "ASID" identifies the source authentication scheme or protocol 541 in use. The association between the "ASID" value and the actual 542 authentication scheme is defined out-of-band, at session startup. 544 "Reserved" field (3 bits): 546 This is a reserved field that MUST be set to zero in this 547 specification. 549 "A" (Anti-replay) field (1 bit): 551 The "AR" field, when set to 0, indicates that the anti-replay 552 service is not used. When set to 1, it indicates that the anti- 553 replay service is used. 555 "SN" (Sequence Number) field (8 or 40 bits): 557 The "SN" field contains an optional sequence number. When AR=0, 558 this is an 8 bit field that MUST be set to zero. No anti-replay 559 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 560 field and all of the 40 bits MUST be considered by the anti-replay 561 mechanism. 563 "Signature" field (variable size, multiple of 32 bits): 565 The "Signature" field contains a digital signature of the message. 566 If need be, this field is padded (with 0) up to a multiple of 32 567 bits. 569 3.2. Parameters 571 Several parameters MUST be initialized by an out-of-band mechanism. 572 The sender or group controller: 574 o MUST communicate his public key, for each receiver to be able to 575 verify the signature of the packets received. As a side effect, 576 the receivers also know the key length and the signature length, 577 the two parameters being equal; 579 o MAY communicate a certificate (which also means that a PKI has 580 been setup), for each receiver to be able to check the sender's 581 public key; 583 o MUST communicate the Message Digest Algorithm; 585 o MUST communicate the Elliptic Curve; 587 o MUST associate a value to the "ASID" field (Authentication Scheme 588 Identifier) of the EXT_AUTH header extension (Section 2.1); 590 o MUST communicate whether the anti-replay service is used or not 591 for this session; 593 These parameters MUST be communicated to all receivers before they 594 can authenticate the incoming packets. For instance it can be 595 communicated in the session description, or initialized in a static 596 way on the receivers, or communicated by means of an appropriate 597 protocol. The details of this out-of-band mechanism are out of the 598 scope of this document. 600 3.3. Processing 602 3.3.1. Signature Processing 604 The computation of the ECC digital signature, using the private key, 605 MUST include the ALC or NORM header (with the various header 606 extensions) and the payload when applicable. The UDP/IP/MAC headers 607 MUST NOT be included. During this computation, the "Signature" field 608 MUST be set to 0. 610 Several "Elliptic Curves" groups can be used, as well as several 611 "Hash Algorithms". In practice both choices are related and there is 612 a minimum hash algorithm size for any key length. Using a larger 613 hash algorithm and then truncated the output is also feasible, 614 however it consumes more processing power than is necessary. The 615 following table lists the RECOMMENDED choices [RFC4754] [RFC5480]. 617 +---------------------------+--------+------------------+-----------+ 618 | Digital Signature | Key | Message Digest | Elliptic | 619 | Algorithm name [RFC4754] | Size | Algorithm | Curve | 620 +---------------------------+--------+------------------+-----------+ 621 | ECDSA-256 | 256 | SHA-256 | secp256r1 | 622 | | | | | 623 | ECDSA-384 | 384 | SHA-384 | secp384r1 | 624 | | | | | 625 | ECDSA-521 | 512 | SHA-512 | secp521r1 | 626 +---------------------------+--------+------------------+-----------+ 628 The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security 629 comparable with AES-128, AES-192 and AES-256 respectively [RFC4754]. 631 3.3.2. Anti-Replay Processing 633 The anti-replay processing follows the principles described in 634 Section 2.3.2. 636 3.4. In Practice 638 Each packet sent MUST contain exactly one ECC Digital Signature 639 EXT_AUTH header extension. A receiver MUST drop all the packets that 640 do not contain an ECC Digital Signature EXT_AUTH header extension. 642 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 643 its content, for instance because they do not support ECC digital 644 signatures. In that case the Digital Signature EXT_AUTH header 645 extension is ignored. 647 If the anti-replay mechanism is used, each packet sent MUST contain a 648 valid sequence number. All the packets that fail to contain a valid 649 sequence number MUST be immediately dropped. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | HET (=1) | HEL (=9) | ASID | 0 |0| 0 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 656 | | ^ 3 657 + + | 2 658 . . | 659 . Signature (32 bytes) . | b 660 . . | y 661 | | | t 662 + + | e 663 | | v s 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 666 Figure 4: Example: Format of the ECC Digital Signature EXT_AUTH 667 header extension using ECDSA-256 signatures, without any anti-replay 668 protection. 670 For instance Figure 4 shows the digital signature EXT_AUTH header 671 extension when using ECDSA-256 (256 bit) ECC digital signatures. The 672 ECC Digital Signature EXT_AUTH header extension is then 36 byte long. 674 4. Group Message Authentication Code (MAC) Scheme 676 4.1. Authentication Header Extension Format 678 The integration of Group MAC is similar in ALC and NORM and relies on 679 the header extension mechanism defined in both protocols. More 680 precisely this document details the EXT_AUTH==1 header extension 681 defined in [RFC5651]. 683 Several fields are added in addition to the HET (Header Extension 684 Type) and HEL (Header Extension Length) fields (Figure 5). 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | HET (=1) | HEL | ASID | rsvd|A| | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 691 ~ anti-replay Sequence Number (SN) ~ 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | | 694 ~ ~ 695 | Group MAC | 696 + +-+-+-+-+-+-+-+-+ 697 | | Padding | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Figure 5: Format of the Group MAC EXT_AUTH header extension. 702 The fields of the Group MAC EXT_AUTH header extension are: 704 "ASID" (Authentication Scheme Identifier) field (4 bits): 706 The "ASID" identifies the source authentication scheme or protocol 707 in use. The association between the "ASID" value and the actual 708 authentication scheme is defined out-of-band, at session startup. 710 "Reserved" field (3 bits): 712 This is a reserved field that MUST be set to zero in this 713 specification. 715 "A" (Anti-replay) field (1 bit): 717 The "AR" field, when set to 0, indicates that the anti-replay 718 service is not used. When set to 1, it indicates that the anti- 719 replay service is used. 721 "SN" (Sequence Number) field (8 or 40 bits): 723 The "SN" field contains an optional sequence number. When AR=0, 724 this is an 8 bit field that MUST be set to zero. No anti-replay 725 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 726 field and all of the 40 bits MUST be considered by the anti-replay 727 mechanism. 729 "Group MAC" field (variable size, multiple of 32 bits): 731 The "Group MAC" field contains a truncated Group MAC of the 732 message. If need be, this field is padded (with 0) up to a 733 multiple of 32 bits. 735 4.2. Parameters 737 Several parameters MUST be initialized by an out-of-band mechanism. 738 The sender or group controller: 740 o MUST communicate the Cryptographic MAC Function, for instance, 741 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA- 742 512. Because of security threats on SHA-1, the use of HMAC-SHA- 743 256 is RECOMMENDED. As a side effect, the receivers also know the 744 key length and the non truncated MAC output length; 746 o MUST communicate the length of the truncated output of the MAC, 747 n_m, which depends on the Cryptographic MAC Function chosen. Only 748 the n_m left-most bits (most significant bits) of the MAC output 749 are kept. Of course, n_m MUST be lower or equal to the key 750 length; 752 o MUST communicate the group key to the receivers, confidentially, 753 before starting the session. This key might have to be 754 periodically refreshed for improved robustness; 756 o MUST associate a value to the "ASID" field (Authentication Scheme 757 Identifier) of the EXT_AUTH header extension (Section 4.1); 759 o MUST communicate whether the anti-replay service is used or not 760 for this session; 762 These parameters MUST be communicated to all receivers before they 763 can authenticate the incoming packets. For instance it can be 764 communicated in the session description, or initialized in a static 765 way on the receivers, or communicated by means of an appropriate 766 protocol (this will be often the case when periodic re-keying is 767 required). The details of this out-of-band mechanism are out of the 768 scope of this document. 770 4.3. Processing 772 4.3.1. Signature Processing 774 The computation of the Group MAC, using the group key, includes the 775 ALC or NORM header (with the various header extensions) and the 776 payload when applicable. The UDP/IP/MAC headers are not included. 777 During this computation, the Weak Group MAC field MUST be set to 0. 778 Then the sender truncates the MAC output to keep the n_m most 779 significant bits and stores the result in the Group MAC 780 Authentication header. 782 Upon receiving this packet, the receiver computes the Group MAC, 783 using the group key, and compares it to the value carried in the 784 packet. During this computation, the Group MAC field MUST also be 785 set to 0. If the check fails, the packet MUST be immediately 786 dropped. 788 [RFC2104] explains that it is current practice to truncate the MAC 789 output, on condition that the truncated output length, n_m be not 790 less than half the length of the hash and not less than 80 bits. 791 However, this choice is out of the scope of this document. 793 4.3.2. Anti-Replay Processing 795 The anti-replay processing follows the principles described in 796 Section 2.3.2. 798 4.4. In Practice 800 Each packet sent MUST contain exactly one Group MAC EXT_AUTH header 801 extension. A receiver MUST drop packets that do not contain a Group 802 MAC EXT_AUTH header extension. 804 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 805 its content, for instance because they do not support Group MAC. In 806 that case the Group MAC EXT_AUTH extension is ignored. 808 If the anti-replay mechanism is used, each packet sent MUST contain a 809 valid sequence number. All the packets that fail to contain a valid 810 sequence number MUST be immediately dropped. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | HET (=1) | HEL (=4) | ASID | 0 |0| 0 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 + + 819 | Group MAC (10 bytes) | 820 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | | Padding | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Figure 6: Example: Format of the Group MAC EXT_AUTH header extension 825 using HMAC-SHA-1, without any anti-replay protection. 827 For instance Figure 6 shows the Group MAC EXT_AUTH header extension 828 when using HMAC-SHA-1. The Group MAC EXT_AUTH header extension is 829 then 16 byte long. 831 5. Combined Use of the RSA/ECC Digital Signatures and Group MAC Schemes 833 5.1. Authentication Header Extension Format 835 The integration of combined RSA/ECC Digital Signature and Group MAC 836 is similar in ALC and NORM and relies on the header extension 837 mechanism defined in both protocols. More precisely this document 838 details the EXT_AUTH==1 header extension defined in [RFC5651]. 840 Several fields are added in addition to the HET (Header Extension 841 Type) and HEL (Header Extension Length) fields (Figure 7). 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | HET (=1) | HEL | ASID | rsvd|A| | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 848 | anti-replay Sequence Number (SN) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 ~ ~ 852 | Signature | 853 + +-+-+-+-+-+-+-+-+ 854 | | Padding | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Group MAC | 857 ~ ~ 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 7: Format of the Group MAC EXT_AUTH header extension. 862 The fields of the Group MAC EXT_AUTH header extension are: 864 "ASID" (Authentication Scheme Identifier) field (4 bits): 866 The "ASID" identifies the source authentication scheme or protocol 867 in use. The association between the "ASID" value and the actual 868 authentication scheme is defined out-of-band, at session startup. 870 "Reserved" field (3 bits): 872 This is a reserved field that MUST be set to zero in this 873 specification. 875 "A" (Anti-replay) field (1 bit): 877 The "AR" field MUST be set to 1 and it indicates that the anti- 878 replay service is used (see Section 5.3). 880 "SN" (Sequence Number) field (8 or 40 bits): 882 The "SN" field contains a sequence number. Since AR=1, this is a 883 32+8=40 bit field and all of the 40 bits MUST be considered by the 884 anti-replay mechanism. 886 "Signature" field (variable size, multiple of 32 bits): 888 The "Signature" field contains a digital signature of the message. 889 If need be, this field is padded (with 0) up to a multiple of 32 890 bits. 892 "Group MAC" field (variable size, multiple of 32 bits, by default 32 893 bits): 895 The "Group MAC" field contains a truncated Group MAC of the 896 message. 898 5.2. Parameters 900 Several parameters MUST be initialized by an out-of-band mechanism, 901 as defined in Section 2.2, Section 3.2 and Section 4.2. 903 5.3. Processing 905 In some situations, it can be interesting to use both authentication 906 schemes. The goal of the Group MAC is to mitigate DoS attacks coming 907 from attackers that are not group members [RFC4082] by adding a light 908 authentication scheme as a front-end. 910 5.3.1. Signature Processing 912 Before sending a message, the sender sets the Signature field and 913 Group MAC field to zero. Then the sender computes the Signature as 914 detailed in Section 2.3 or in Section 3.3 and stores the value in the 915 Signature field. Then the sender computes the Group MAC as detailed 916 in Section 4.3 and stores the value in the Group MAC field. The (RSA 917 or ECC) digital signature value is therefore protected by the Group 918 MAC, which avoids DoS attacks where the attacker corrupts the digital 919 signature itself. 921 Upon receiving the packet, the receiver first checks the Group MAC, 922 as detailed in Section 4.3. If the check fails, the packet MUST be 923 immediately dropped. Otherwise the receiver checks the Digital 924 Signature, as detailed in Section 2.3. If the check fails, the 925 packet MUST be immediately dropped. 927 This scheme features a few limits: 929 o the Group MAC is of no help if a group member (who knows the group 930 key) impersonates the sender and sends forged messages to other 931 receivers. DoS attacks are still feasible; 933 o it requires an additional MAC computing for each packet, both at 934 the sender and receiver sides; 936 o it increases the size of the authentication headers. In order to 937 limit this problem, the length of the truncated output of the MAC, 938 n_m, SHOULD be kept small (see [RFC3711] section 9.5). In the 939 current specification, n_m MUST be a multiple of 32 bits, and 940 default value is 32 bits. As a side effect, with n_m = 32 bits, 941 the authentication service is significantly weakened since the 942 probability that any packet be successfully forged is one in 2^32. 943 Since the Group MAC check is only a pre-check that is followed by 944 the standard signature authentication check, this is not 945 considered to be an issue. 947 For a given use-case, the benefits brought by the Group MAC must be 948 balanced against these limitations. 950 5.3.2. Anti-Replay Processing 952 The anti-replay processing follows the principles described in 953 Section 2.3.2. Here an anti-replay service MUST be used. Indeed, 954 failing to enable anti-replay protection would facilitate DoS 955 attacks, since all replayed (but otherwise valid) packets would pass 956 the light authentication scheme and oblige a receiver to perform a 957 complex signature verification. 959 5.4. In Practice 961 Each packet sent MUST contain exactly one combined Digital Signature/ 962 Group MAC EXT_AUTH header extension. A receiver MUST drop packets 963 that do not contain a combined Digital Signature/Group MAC EXT_AUTH 964 header extension. 966 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 967 its content, for instance because they do not support combined 968 Digital Signature/Group MAC. In that case the combined Digital 969 Signature/Group MAC EXT_AUTH extension is ignored. 971 Since the anti-replay mechanism MUST be used, each packet sent MUST 972 contain a valid sequence number. All the packets that fail to 973 contain a valid sequence number MUST be immediately dropped. 975 It is RECOMMENDED that the n_m parameter of the group authentication 976 scheme be small, and by default equal to 32 bits (Section 5.3). 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | HET (=1) | HEL (=35) | ASID | 0 |1| | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 983 | anti-replay Sequence Number (SN) | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 985 | | ^ 1 986 + + | 2 987 | | | 8 988 . . | 989 . Signature (128 bytes) . | b 990 . . | y 991 | | | t 992 + + | e 993 | | v s 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 995 | Group MAC (32 bits) | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 998 Figure 8: Example: Format of the combined RSA Digital Signature/Group 999 MAC EXT_AUTH header extension using 1024 bit signatures, with anti- 1000 replay protection. 1002 For instance Figure 8 shows the combined Digital Signature/Group MAC 1003 EXT_AUTH header extension when using 128 byte (1024 bit) key RSA 1004 digital signatures (which also means that the signature field is 128 1005 byte long). The EXT_AUTH header extension is then 140 byte long. 1007 6. IANA Considerations 1009 This document does not require any IANA registration. 1011 7. Security Considerations 1013 7.1. Dealing With DoS Attacks 1015 Let us consider packets secured through the use of a digital 1016 signature scheme first. Because faked packets are easy to create but 1017 checking them requires to compute a costly digital signature, this 1018 scheme introduces new opportunities for an attacker to mount DoS 1019 attacks. More precisely an attacker can easily saturate the 1020 processing capabilities of the receiver. 1022 In order to mitigate these attacks, it is RECOMMENDED to use the 1023 combined Digital Signature/Group MAC scheme (Section 5.3). However, 1024 no mitigation is possible if a group member acts as an attacker. 1025 Additionally, even if checking a Group MAC is significantly faster 1026 than checking a digital signature, there are practical limits on how 1027 many Group MAC can be checked per time unit. Therefore it is 1028 RECOMMENDED to limit the number of authentication checks per time 1029 unit when the number of incoming packets that fail the authentication 1030 check exceeds a given threshold (i.e., in case of a DoS attack). 1032 The RECOMMENDATION to limit the number of checks per time unit under 1033 (presumed) attack situations can be extended to the other 1034 authentication schemes. 1036 7.2. Dealing With Replay Attacks 1038 Replay attacks consist for an attacker to store a valid message and 1039 to replay it later on. It is RECOMMENDED to use the anti-replay 1040 service defined in this document with the signature and group MAC 1041 solutions, and this anti-replay service MUST be used in case of a 1042 combined use of signature and group MAC (see Section 5.3.2). 1044 The following section details some of the potential consequences of 1045 not using the anti-replay protection. 1047 7.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes 1049 Since all the above authentication schemes are stateless, replay 1050 attacks have no impact on these schemes. 1052 7.2.2. Impacts of Replay Attacks on NORM 1054 We review here the potential impacts of a replay attack on the NORM 1055 component. Note that we do not consider here the protocols that 1056 could be used along with NORM, for instance the congestion control 1057 protocols. 1059 First, let us consider replay attacks within a given NORM session. 1060 NORM being a stateful protocol, replaying a packet may have 1061 consequences. 1063 NORM defines a "sequence" field that may be used to protect against 1064 replay attacks [RFC5740] within a given NORM session. This 1065 "sequence" field is a 16-bit value that is set by the message 1066 originator (sender or receiver) as a monotonically increasing number 1067 incremented with each NORM message transmitted. Using this field as 1068 an anti-replay protection would be possible if there is no wrapping 1069 to zero, i.e., would only be possible if at most 65535 packets are 1070 sent. This may be true for some use-cases but not for the general 1071 case. Using this field as an anti-replay protection would also be 1072 possible if the keying material is updated before wrapping to zero 1073 happens. This may be true for some use-cases but not for the general 1074 case. 1076 Now let us consider replay attacks across several NORM sessions. A 1077 host participation in a NORM session is uniquely identified by the 1078 {"source_id"; "instance_id"} tuple. Therefore, when a given host 1079 participates in several NORM sessions, it is RECOMMENDED that the 1080 "instance_id" be changed for each NORM instance. It is also 1081 RECOMMENDED, when the Group MAC authentication/integrity check scheme 1082 is used, that the shared group key be changed across sessions. 1083 Therefore, NORM can be made robust in front of replay attacks across 1084 different sessions. 1086 7.2.3. Impacts of Replay Attacks on ALC 1088 We review here the potential impacts of a replay attack on the ALC 1089 component. Note that we do not consider here the protocols that 1090 could be used along with ALC, for instance the layered or wave based 1091 congestion control protocols. 1093 First, let us consider replay attacks within a given ALC session: 1095 o replayed encoding symbol: a replayed encoding symbol (coming from 1096 a replayed data packet) is detected thanks to the object/block/ 1097 symbol identifiers and is silently discarded. 1099 o replayed control information: more precisely: 1101 * At the end of the session, a "close session" (A flag) packet is 1102 sent. Replaying a packet containing this flag has no impact 1103 since the receivers already left. 1105 * Similarly, replaying a packet containing a "close object" (B 1106 flag) has no impact since this object is probably already 1107 marked as closed by the receiver. 1109 * Timing information sent as part of an LCT EXT_TIME header 1110 extension [RFC5651] may be more sensitive to replay attacks. 1111 For instance replaying a packet containing an ERT (Expected 1112 Residual Time) may mislead a receiver to believe an object 1113 transmission will continue for some time whereas the 1114 transmission of symbols for this object is about to stop. 1115 Replaying a packet containing a SCT (Sender Current Time) is 1116 easily identified if the receiver verifies that time progresses 1117 upon receiving such EXT_TIME header extensions. Replaying a 1118 packet containing a SLC (Session Last Changed) is easily 1119 identified if the receiver verifies the chronology upon 1120 receiving such EXT_TIME header extensions. 1122 This analysis shows that ALC might be, to a limited extent, sensitive 1123 to replay attacks within the same session if timing information is 1124 used. Otherwise ALC is robust in front of replay attacks within the 1125 same session. 1127 Now let us consider replay attacks across several ALC sessions. An 1128 ALC session is uniquely identified by the {sender's IP address; 1129 Transport Session Identifier (TSI)}. Therefore, when a given sender 1130 creates several sessions, the TSI MUST be changed for each ALC 1131 session, so that each TSI is unique among all active sessions of this 1132 sender and for a large period of time preceding and following when 1133 the session is active [RFC5651]. Therefore, ALC can be made robust 1134 in front of replay attacks across different sessions. Of course, 1135 when the Group MAC authentication/integrity check scheme is used, the 1136 shared group key SHOULD be changed across sessions if the set of 1137 receivers changes. 1139 7.3. Dealing With Attacks on the Parameters Sent Out-of-Band 1141 This specification requires several parameters to be communicated to 1142 the receiver(s) via an out-of-band mechanism that is out of the scope 1143 of this document. This is in particular the case for the mapping 1144 between an ASID value and the associated authentication scheme 1145 (Section 1). Since this mapping is critical, this information SHOULD 1146 be carried in a secure way from the sender to the receiver(s). 1148 8. Acknowledgments 1150 The author is grateful to the authors of [RFC4303], [RFC4359], 1151 [RFC4754] and [RFC5480] that inspired several sections of the present 1152 document. The author is also grateful to David Harrington for his 1153 detailed IESG review of this document. 1155 9. References 1157 9.1. Normative References 1159 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1160 Hashing for Message Authentication", RFC 2104, 1161 February 1997. 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", RFC 2119, BCP 14, March 1997. 1166 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1167 Transport (LCT) Building Block", RFC 5651, October 2009. 1169 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1170 "NACK-Oriented Reliable Multicast (NORM) Transport 1171 Protocol", RFC 5740, November 2009. 1173 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1174 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1175 April 2010. 1177 9.2. Informative References 1179 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1180 Standards (PKCS) #1: RSA Cryptography Specifications 1181 Version 2.1", RFC 3447, February 2003. 1183 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1184 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1185 RFC 3711, March 2004. 1187 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1188 Briscoe, "Timed Efficient Stream Loss-Tolerant 1189 Authentication (TESLA): Multicast Source Authentication 1190 Transform Introduction", RFC 4082, June 2005. 1192 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1193 RFC 4303, December 2005. 1195 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 1196 Encapsulating Security Payload (ESP) and Authentication 1197 Header (AH)", RFC 4359, January 2006. 1199 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 1200 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 1201 RFC 4754, January 2007. 1203 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1204 "Elliptic Curve Cryptography Subject Public Key 1205 Information", RFC 5480, March 2009. 1207 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1208 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1209 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1210 Reliable Multicast (NORM) Protocols", RFC 5776, 1211 April 2010. 1213 [RMT-FLUTE] 1214 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1215 "FLUTE - File Delivery over Unidirectional Transport", 1216 Work in Progress, February 2011. 1218 Author's Address 1220 Vincent Roca 1221 INRIA 1222 655, av. de l'Europe 1223 Inovallee; Montbonnot 1224 ST ISMIER cedex 38334 1225 France 1227 Email: vincent.roca@inria.fr 1228 URI: http://planete.inrialpes.fr/people/roca/