idnits 2.17.1 draft-ietf-rmt-simple-auth-for-alc-norm-06.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 (December 9, 2011) is 4515 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 December 9, 2011 5 Expires: June 11, 2012 7 Simple Authentication Schemes for the ALC and NORM Protocols 8 draft-ietf-rmt-simple-auth-for-alc-norm-06 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 RSA digital 15 signatures. The second scheme relies on the Elliptic Curve Digital 16 Signature Algorithm (ECDSA). The third scheme relies on a group- 17 keyed Message Authentication Code (MAC). Finally, the fourth scheme 18 merges 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 June 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 7 58 1.2. Terminology, Notations and Definitions . . . . . . . . . . 7 59 2. Authentication Scheme Identification with the ASID Field . . . 9 60 3. RSA Digital Signature Scheme . . . . . . . . . . . . . . . . . 10 61 3.1. Authentication Header Extension Format . . . . . . . . . . 10 62 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.3.1. Signature Processing . . . . . . . . . . . . . . . . . 12 65 3.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 13 66 3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 14 67 4. Elliptic Curve Digital Signature Scheme . . . . . . . . . . . 15 68 4.1. Authentication Header Extension Format . . . . . . . . . . 15 69 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.3.1. Signature Processing . . . . . . . . . . . . . . . . . 16 72 4.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 17 73 4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 17 74 5. Group-Keyed Message Authentication Code (MAC) Scheme . . . . . 19 75 5.1. Authentication Header Extension Format . . . . . . . . . . 19 76 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 20 77 5.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 21 78 5.3.1. Signature Processing . . . . . . . . . . . . . . . . . 21 79 5.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 21 80 5.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 21 81 6. Combined Use of the RSA/ECC Digital Signatures and 82 group-keyed MAC Schemes . . . . . . . . . . . . . . . . . . . 23 83 6.1. Authentication Header Extension Format . . . . . . . . . . 23 84 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 24 86 6.3.1. Signature Processing . . . . . . . . . . . . . . . . . 24 87 6.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 25 88 6.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 25 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 91 8.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 28 92 8.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 28 93 8.2.1. Impacts of Replay Attacks on the Simple 94 Authentication Schemes . . . . . . . . . . . . . . . . 28 95 8.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 28 96 8.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 29 97 8.3. Dealing With Attacks on the Parameters Sent Out-of-Band . 30 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 1. Introduction 107 Many applications using multicast and broadcast communications 108 require that each receiver be able to authenticate the source of any 109 packet it receives to check its integrity. For instance, ALC 110 [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDP) 111 designed to reliably transfer objects (e.g. files) between a 112 session's sender and several receivers. 114 The NORM protocol is based on bidirectional transmissions. With NORM 115 each receiver acknowledges data received or, in case of packet 116 erasures, asks for retransmissions. On the opposite, the ALC 117 protocol defines unidirectional transmissions. With ALC, reliability 118 can be achieved by means of cyclic transmissions of the content 119 within a carousel, or by the use of proactive Forward Error 120 Correction codes (FEC), or by the joint use of these mechanisms. 121 Being purely unidirectional, ALC is massively scalable, while NORM is 122 intrinsically limited in terms of the number of receivers that can be 123 handled in a session. Both protocols have in common the fact that 124 they operate at application level, on top of an erasure channel (e.g. 125 the Internet) where packets can be lost (erased) during the 126 transmission. 128 With these CDP, an attacker might impersonate the ALC or NORM session 129 sender and inject forged packets to the receivers, thereby corrupting 130 the objects reconstructed by the receivers. An attacker might also 131 impersonate a NORM session receiver and inject forged feedback 132 packets to the NORM sender. 134 In case of group communications, several solutions exist to provide 135 the receiver some guaranties on the integrity of the packets it 136 receives and on the identity of the sender of these packets. These 137 solutions have different features that make them more or less suited 138 to a given use case: 140 o digital signatures [RFC4359] (see Section 3 and Section 4): this 141 scheme is well suited to low data rate flows, when a packet sender 142 authentication and packet integrity service is needed. However, 143 digital signatures based on RSA asymmetric cryptography are 144 limited by high computational costs and high transmission 145 overheads. The use of ECC ("Elliptic Curve Cryptography") 146 [RFC6090] significantly relaxes these constraints. For instance, 147 the following key lengths provide equivalent security: 1024 bit 148 RSA key versus 160 bit ECC key, or 2048 bit RSA key versus 224 bit 149 ECC key. However RSA puts more load on the signer but much much 150 less on the verifier, whereas ECC puts more similar load on both 151 and hence with many verifiers more CPU is consumed overall. 153 o group-keyed Message Authentication Codes (MAC) (see Section 5): 154 this scheme is well suited to high data rate flows, when 155 transmission overheads must be minimized. However this scheme 156 cannot protect against attacks coming from inside the group, where 157 a group member impersonates the sender and sends forged messages 158 to other receivers. 160 o TESLA (Timed Efficient Stream Loss-tolerant Authentication) 161 [RFC4082][RFC5776]: this scheme is well suited to high data rate 162 flows, when transmission overheads must be minimized, and when a 163 packet sender authentication and packet integrity service is 164 needed. The price to pay is an increased complexity, in 165 particular the need to loosely synchronize the receivers and the 166 sender, as well as the need to wait for the key to be disclosed 167 before being able to authenticate a packet (i.e. the 168 authentication check is delayed) 170 The following table summarizes the pros/cons of each authentication/ 171 integrity scheme used at application/transport level (where "-" means 172 bad, "0" means neutral, and "+" means good): 174 +-----------------+-------------+-------------+-------------+-------+ 175 | | RSA Digital | ECC Digital | Group-Keyed | TESLA | 176 | | Signature | Signature | MAC | | 177 +-----------------+-------------+-------------+-------------+-------+ 178 | Sender auth and | Yes | Yes | No (group | Yes | 179 | packet | | | security) | | 180 | integrity | | | | | 181 | | | | | | 182 | Non delayed | Yes | Yes | Yes | No | 183 | authentication | | | | | 184 | | | | | | 185 | Anti-replay | Opt | Opt | Opt | No | 186 | protection | | | | | 187 | | | | | | 188 | Processing load | - | sender: -, | + | + | 189 | | | recv: 0 | | | 190 | | | | | | 191 | Transmission | - | 0 | + | + | 192 | overhead | | | | | 193 | | | | | | 194 | Complexity | + | + | + | - | 195 +-----------------+-------------+-------------+-------------+-------+ 197 Several authentication schemes MAY be used in the same ALC or NORM 198 session, even on the same communication path. This is made possible 199 through a dedicated identifier, "ASID" (Authentication Scheme 200 IDentifier), that is present in each HET=1 (EXT_AUTH) header 201 extension and that tells a receiver how to interpret this HET=1 202 header extension. This is discussed in Section 2. 204 All the applications built on top of ALC and NORM directly benefit 205 from the source authentication and packet integrity services defined 206 in this document. For instance this is the case of the FLUTE 207 application [RMT-FLUTE] built on top of ALC. 209 The current specification assumes that several parameters (like 210 keying material) are communicated out-of-band, sometimes securely, 211 between the sender and the receivers. This is detailed in 212 Section 3.2, Section 4.2, Section 5.2, and Section 6.2. 214 1.1. Scope of this Document 216 [RFC5776] explains how to use TESLA in the context of ALC and NORM 217 protocols. 219 The current document specifies the use of the Digital Signature based 220 on RSA asymmetric cryptography, the Elliptic Curve Digital Signature 221 Algorithm (ECDSA) and group-keyed MAC schemes. The current document 222 also specifies the joint use of Digital Signature and group-keyed MAC 223 schemes. 225 Unlike the TESLA scheme, this specification considers the 226 authentication/integrity of the packets generated by the session's 227 sender as well as those generated by the receivers (NORM). 229 1.2. Terminology, Notations and Definitions 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119]. 235 The following notations and definitions are used throughout this 236 document: 238 o MAC is the Message Authentication Code; 240 o HMAC is the Keyed-Hash Message Authentication Code; 242 o sender denotes the sender of a packet that needs the 243 authentication/integrity check service. It can be an ALC or NORM 244 session sender, or a NORM session receiver in case of feedback 245 traffic; 247 o receiver denotes the receiver of a packet that needs the 248 authentication/integrity check service. It can be an ALC or NORM 249 session receiver, or a NORM session sender in case of feedback 250 traffic; 252 o ASID is the Authentication Scheme IDentifier; 254 Key definitions for Digital signatures: 256 o the public key is used by a receiver to check a packet's 257 signature. This key MUST be communicated to all receivers, before 258 starting the session; 260 o the private key is used by a sender to generate a packet's 261 signature; 263 o the private key and public key length are expressed in bits. For 264 security considerations [RFC5751], when using RSA, RSASSA-PSS, and 265 DSA signatures, key sizes of length strictly inferior to 1024 bits 266 SHOULD NOT be used. Key sizes of length between 1024 and 2048 267 bits, inclusive, SHOULD be used. Key sizes of length strictly 268 superior to 2048 MAY be used. 270 Keys definitions for Group-keyed MAC: 272 o the shared group key is used by the senders and the receivers. 273 This key MUST be communicated to all group members, 274 confidentially, before starting the session; 276 o the group key length is expressed in bits; 278 o n_m is the length of the truncated output of the MAC [RFC2104]. 279 Only the n_m left-most bits (most significant bits) of the MAC 280 output are kept; 282 2. Authentication Scheme Identification with the ASID Field 284 As mentioned in Section 1, several authentication schemes MAY be used 285 in the same ALC or NORM session, even on the same communication path 286 (i.e., from a sender to a receiver, or vice-versa). All the schemes 287 mentioned in Section 1 (some of them being specified in this 288 document) use the same HET=1 (EXT_AUTH) authentication header 289 extension mechanism defined in [RFC5651]. Therefore, the same 4-bit 290 ASID (Authentication Scheme IDentifier) field has been reserved in 291 all the specifications (see Section 3.1, Section 5.1, Section 6.1 and 292 [RFC5776], section 5.1). For a given ALC or NORM session, the ASID 293 value contained in an incoming packet enables a receiver to 294 differentiate the actual use and format of the contents of the HET=1 295 (EXT_AUTH) header extension. 297 The association between the ASID value and the actual authentication 298 scheme of a given ALC or NORM session is defined at session startup 299 and communicated to all the session members by an out-of-band 300 mechanism. This association is per ALC or NORM session, and 301 different sessions MAY reuse the same ASID values for different 302 authentication schemes. 304 With ALC, the ASID value is scoped by the {sender IP address; TSI} 305 tuple [RFC5651] that fully identifies an ALC session. Since 306 [RFC5651] requires that "the TSI MUST be unique among all sessions 307 served by the sender during the period when the session is active, 308 and for a large period of time preceding and following when the 309 session is active", there is no risk of confusion between different 310 sessions. This is in line with Section 8.2.3. 312 With NORM, there is no session identifier within NORM packets. 313 Therefore, depending on whether an Any Source Multicast (ASM) or 314 Source Specific Multicast (SSM) group communication is used, the ASID 315 value is scoped either by the {destination multicast address; 316 destination port number} or {source IP address; destination multicast 317 address; destination port number} tuple that fully identifies a NORM 318 session [RFC5740]. Care should be taken that the above tuples remain 319 unique, within a given scope and for a sufficient period of time 320 preceding, during and following when the session is active, to avoid 321 confusion between different sessions. However, this is a 322 recommendation for NORM sessions, rather than something specific to 323 an authentication scheme. Note also that the ASID value is not 324 scoped by the {"source_id"; "instance_id"} tuple, which uniquely 325 identifies a host participation in a NORM session, rather than the 326 session itself Section 8.2.2. 328 In any case, because this ASID field is 4-bit long, there is a 329 maximum of 16 authentication schemes per ALC or NORM session. 331 3. RSA Digital Signature Scheme 333 3.1. Authentication Header Extension Format 335 The integration of Digital Signatures is similar in ALC and NORM and 336 relies on the header extension mechanism defined in both protocols. 337 More precisely this document details the HET=1 (EXT_AUTH) header 338 extension defined in [RFC5651]. 340 Several fields are added in addition to the HET (Header Extension 341 Type) and HEL (Header Extension Length) fields (Figure 1). 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | HET (=1) | HEL | ASID | rsvd|A| | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 348 ~ anti-replay Sequence Number (SN) ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 ~ ~ 352 | Signature | 353 + +-+-+-+-+-+-+-+-+ 354 | | Padding | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 1: Format of the Digital Signature EXT_AUTH header extension. 359 The fields of the Digital Signature EXT_AUTH header extension are: 361 "ASID" (Authentication Scheme IDentifier) field (4 bits): 363 The "ASID" identifies the source authentication scheme or protocol 364 in use. The association between the "ASID" value and the actual 365 authentication scheme is defined out-of-band, at session startup. 367 "Reserved" field (3 bits): 369 This is a reserved field that MUST be set to zero and ignored by 370 receivers. 372 "A" (Anti-replay) field (1 bit): 374 The "AR" field, when set to 0, indicates that the anti-replay 375 service is not used. When set to 1, it indicates that the anti- 376 replay service is used. 378 "SN" (Sequence Number) field (8 or 40 bits): 380 The "SN" field contains an optional sequence number. When AR=0, 381 this is an 8 bit field that MUST be set to zero. No anti-replay 382 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 383 field and all of the 40 bits MUST be considered by the anti-replay 384 mechanism. 386 "Signature" field (variable size, multiple of 32 bits): 388 The "Signature" field contains a digital signature of the message. 389 If need be, this field is padded (with 0) up to a multiple of 32 390 bits. 392 3.2. Parameters 394 Several parameters MUST be initialized by an out-of-band mechanism. 395 The sender or group controller: 397 o MUST communicate his public key, for each receiver to be able to 398 verify the signature of the packets received. For security 399 reasons [RFC5751], the use of key sizes between 1024 and 2048 400 inclusive is RECOMMENDED. Key sizes inferior to 1024 SHOULD NOT 401 be used. Key sizes above 2048 MAY be used. As a side effect, the 402 receivers also know the key length and the signature length, the 403 two parameters being equal; 405 o MAY communicate a certificate (which also means that a PKI has 406 been setup), for each receiver to be able to check the sender's 407 public key; 409 o MUST communicate the Signature Encoding Algorithm. For instance, 410 [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms 411 that are usually used to that purpose; 413 o MUST communicate the One-way Hash Function, for instance SHA-1, 414 SHA-224, SHA-256, SHA-384, or SHA-512. Because of security 415 threats on SHA-1, the use of SHA-256 is RECOMMENDED [RFC6194]; 417 o MUST associate a value to the "ASID" field (Authentication Scheme 418 IDentifier) of the EXT_AUTH header extension (Section 3.1); 420 o MUST communicate whether the anti-replay service is used or not 421 for this session; 423 These parameters MUST be communicated to all receivers before they 424 can authenticate the incoming packets. For instance it can be 425 communicated in the session description, or initialized in a static 426 way on the receivers, or communicated by means of an appropriate 427 protocol. The details of this out-of-band mechanism are out of the 428 scope of this document. 430 3.3. Processing 432 3.3.1. Signature Processing 434 The computation of the digital signature, using the private key, MUST 435 include the ALC or NORM header (with the various header extensions) 436 and the payload when applicable. The UDP/IP/MAC headers MUST NOT be 437 included. During this computation, the "Signature" field MUST be set 438 to 0. 440 Several "Signature Encoding Algorithms" can be used, including 441 RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several 442 "One-way Hash Function" can be used, like SHA-256. 444 First, let us consider a packet sender. More specifically, from 445 [RFC4359]: digital signature generation is performed as described in 446 [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for 447 RSASSA-PSS. The authenticated portion of the packet is used as the 448 message M, which is passed to the signature generation function. The 449 signer's RSA private key is passed as K. In summary (when SHA-256 is 450 used), the signature generation process computes a SHA-256 hash of 451 the authenticated packet bytes, signs the SHA-256 hash using the 452 private key, and encodes the result with the specified RSA encoding 453 type. This process results in a value S, which is the digital 454 signature to be included in the packet. 456 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 457 signature is equal to the "RSA modulus", unless the "RSA modulus" is 458 not a multiple of 8 bits. In that case, the signature MUST be 459 prepended with between 1 and 7 bits set to zero such that the 460 signature is a multiple of 8 bits [RFC4359]. The key length, which 461 in practice is also equal to the "RSA modulus", has major security 462 implications. [RFC4359] explains how to choose this value depending 463 on the maximum expected lifetime of the session. This choice is out 464 of the scope of this document. 466 Now let us consider a receiver. From [RFC4359]: Digital signature 467 verification is performed as described in [RFC3447], Section 8.2.2 468 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon 469 receipt, the digital signature is passed to the verification function 470 as S. The authenticated portion of the packet is used as the message 471 M, and the RSA public key is passed as (n, e). In summary (when SHA- 472 256 is used), the verification function computes a SHA-256 hash of 473 the authenticated packet bytes, decrypts the SHA-256 hash in the 474 packet using the sender's public key, and validates that the 475 appropriate encoding was applied. The two SHA-256 hashes are 476 compared and if they are identical the validation is successful. 478 3.3.2. Anti-Replay Processing 480 Let us assume the anti-replay service is used. The principles are 481 similar to the Sequence Number mechanism described in [RFC4303], with 482 the exception that the present document uses a 40 bit field that 483 contains all the bits of the sequence number counter. 485 At the sender, the mechanism works as follows ([RFC4303], section 486 2.2). The sender's sequence number counter is initialized to 0 at 487 session startup. The sender increments the Sequence Number counter 488 for this session and inserts the value into the SN field. Thus, the 489 first packet sent will contain a SN of 1. The SN value of the 490 Authentication Header Extension MUST be initialized before the 491 signature generation process, in order to enable a receiver to check 492 the SN value during the integrity verification process. 494 The sender SHOULD ensure that the counter does not cycle before 495 inserting the new value in the SN field. Failing to follow this rule 496 would enable an attacker to replay a packet sent during the previous 497 cycle, i.e., it would limit the anti-replay service to a single SN 498 cycle. Since the sequence number is contained in a 40 bit field, it 499 is expected that cycling will never happen in most situations. For 500 instance, on a 10 Gbps network, with small (i.e., 64 byte long) 501 packets, cycling will happen after slightly more than 15 hours. 503 At the receiver, the mechanism works as follows ([RFC4303], sections 504 3.4.3 and A2). For each received packet, the receiver MUST verify 505 that the packet contains a Sequence Number that does not duplicate 506 the Sequence Number of any other packets received during the session. 507 If this preliminary check fails, the packet is discarded, thus 508 avoiding the need for any cryptographic operations by the receiver. 509 If the preliminary check is successful, the receiver cannot yet 510 modify its local counter, because the integrity of the Sequence 511 Number has not been verified at this point. 513 Duplicates are rejected through the use of a sliding receive window. 514 The "right" edge of the window represents the highest, validated 515 Sequence Number value received on this session. Packets that contain 516 sequence numbers lower than the "left" edge of the window are 517 rejected. Packets falling within the window are checked against a 518 list of received packets within the window (how this list is managed 519 is a local, implementation based decision). This window limits how 520 far out of order a packet can be, relative to the packet with the 521 highest sequence number that has been authenticated so far. 523 If the received packet falls within the window and is not a 524 duplicate, or if the packet is to the right of the window, then the 525 receiver proceeds to integrity verification. If the integrity check 526 fails, the receiver MUST discard the received packet as invalid, 527 otherwise the receive window is updated and packet processing 528 continues. 530 3.4. In Practice 532 Each packet sent MUST contain exactly one Digital Signature EXT_AUTH 533 header extension. A receiver MUST drop all the packets that do not 534 contain a Digital Signature EXT_AUTH header extension. 536 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 537 its content, for instance because they do not support digital 538 signatures. In that case the Digital Signature EXT_AUTH header 539 extension is ignored. 541 If the anti-replay mechanism is used, each packet sent MUST contain a 542 valid sequence number. All the packets that fail to contain a valid 543 sequence number MUST be immediately dropped. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | HET (=1) | HEL (=33) | ASID | 0 |0| 0 | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 550 | | ^ 1 551 + + | 2 552 | | | 8 553 . . | 554 . Signature (128 bytes) . | b 555 . . | y 556 | | | t 557 + + | e 558 | | v s 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 561 Figure 2: Example: Format of the Digital Signature EXT_AUTH header 562 extension using 1024 bit signatures, without any anti-replay 563 protection. 565 For instance Figure 2 shows the digital signature EXT_AUTH header 566 extension when using 128 byte (1024 bit) key digital signatures 567 (which also means that the signature field is 128 byte long). The 568 Digital Signature EXT_AUTH header extension is then 132 byte long. 570 4. Elliptic Curve Digital Signature Scheme 572 This document focuses on the Elliptic Curve Digital Signature 573 Algorithm (ECDSA). However [RFC6090] describes alternative Elliptic 574 Curve techniques, like KT-I Signatures. The use of such alternatives 575 is not considered in this document, but may be added in the future. 577 4.1. Authentication Header Extension Format 579 The integration of ECC Digital Signatures is similar to that of RSA 580 Digital Signatures. Several fields are added in addition to the HET 581 (Header Extension Type) and HEL (Header Extension Length) fields, as 582 illustrated in Figure 1. 584 The fields of the Digital Signature EXT_AUTH header extension are: 586 "ASID" (Authentication Scheme IDentifier) field (4 bits): 588 The "ASID" identifies the source authentication scheme or protocol 589 in use. The association between the "ASID" value and the actual 590 authentication scheme is defined out-of-band, at session startup. 592 "Reserved" field (3 bits): 594 This is a reserved field that MUST be set to zero and ignored by 595 receivers. 597 "A" (Anti-replay) field (1 bit): 599 The "AR" field, when set to 0, indicates that the anti-replay 600 service is not used. When set to 1, it indicates that the anti- 601 replay service is used. 603 "SN" (Sequence Number) field (8 or 40 bits): 605 The "SN" field contains an optional sequence number. When AR=0, 606 this is an 8 bit field that MUST be set to zero. No anti-replay 607 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 608 field and all of the 40 bits MUST be considered by the anti-replay 609 mechanism. 611 "Signature" field (variable size, multiple of 32 bits): 613 The "Signature" field contains a digital signature of the message. 614 If need be, this field is padded (with 0) up to a multiple of 32 615 bits. 617 4.2. Parameters 619 Several parameters MUST be initialized by an out-of-band mechanism. 620 The sender or group controller: 622 o MUST communicate his public key, for each receiver to be able to 623 verify the signature of the packets received. As a side effect, 624 the receivers also know the key length and the signature length, 625 the two parameters being equal; 627 o MAY communicate a certificate (which also means that a PKI has 628 been setup), for each receiver to be able to check the sender's 629 public key; 631 o MUST communicate the Message Digest Algorithm; 633 o MUST communicate the Elliptic Curve; 635 o MUST associate a value to the "ASID" field (Authentication Scheme 636 IDentifier) of the EXT_AUTH header extension (Section 3.1); 638 o MUST communicate whether the anti-replay service is used or not 639 for this session; 641 These parameters MUST be communicated to all receivers before they 642 can authenticate the incoming packets. For instance it can be 643 communicated in the session description, or initialized in a static 644 way on the receivers, or communicated by means of an appropriate 645 protocol. The details of this out-of-band mechanism are out of the 646 scope of this document. 648 4.3. Processing 650 4.3.1. Signature Processing 652 The computation of the ECC digital signature, using the private key, 653 MUST include the ALC or NORM header (with the various header 654 extensions) and the payload when applicable. The UDP/IP/MAC headers 655 MUST NOT be included. During this computation, the "Signature" field 656 MUST be set to 0. 658 Several "Elliptic Curves" groups can be used, as well as several 659 "Hash Algorithms". In practice both choices are related and there is 660 a minimum hash algorithm size for any key length. Using a larger 661 hash algorithm and then truncated the output is also feasible, 662 however it consumes more processing power than is necessary. In 663 order to promote interoperability, [RFC4754] [RFC5480] list several 664 possible choices (see table below). 666 +---------------------------+--------+------------------+-----------+ 667 | Digital Signature | Key | Message Digest | Elliptic | 668 | Algorithm name [RFC4754] | Size | Algorithm | Curve | 669 +---------------------------+--------+------------------+-----------+ 670 | ECDSA-256 (default) | 256 | SHA-256 | secp256r1 | 671 | | | | | 672 | ECDSA-384 | 384 | SHA-384 | secp384r1 | 673 | | | | | 674 | ECDSA-521 | 512 | SHA-512 | secp521r1 | 675 +---------------------------+--------+------------------+-----------+ 677 The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security 678 comparable with AES-128, AES-192 and AES-256 respectively [RFC4754]. 679 Among them, the use of ECDSA-256/secp256r1 is RECOMMENDED. 681 4.3.2. Anti-Replay Processing 683 The anti-replay processing follows the principles described in 684 Section 3.3.2. 686 4.4. In Practice 688 Each packet sent MUST contain exactly one ECC Digital Signature 689 EXT_AUTH header extension. A receiver MUST drop all the packets that 690 do not contain an ECC Digital Signature EXT_AUTH header extension. 692 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 693 its content, for instance because they do not support ECC digital 694 signatures. In that case the Digital Signature EXT_AUTH header 695 extension is ignored. 697 If the anti-replay mechanism is used, each packet sent MUST contain a 698 valid sequence number. All the packets that fail to contain a valid 699 sequence number MUST be immediately dropped. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | HET (=1) | HEL (=9) | ASID | 0 |0| 0 | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 706 | | ^ 3 707 + + | 2 708 . . | 709 . Signature (32 bytes) . | b 710 . . | y 711 | | | t 712 + + | e 713 | | v s 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 716 Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH 717 header extension using ECDSA-256 signatures, without any anti-replay 718 protection. 720 For instance Figure 3 shows the digital signature EXT_AUTH header 721 extension when using ECDSA-256 (256 bit) ECC digital signatures. The 722 ECC Digital Signature EXT_AUTH header extension is then 36 byte long. 724 5. Group-Keyed Message Authentication Code (MAC) Scheme 726 5.1. Authentication Header Extension Format 728 The integration of group-keyed MAC is similar in ALC and NORM and 729 relies on the header extension mechanism defined in both protocols. 730 More precisely this document details the HET=1 (EXT_AUTH) header 731 extension defined in [RFC5651]. 733 Several fields are added in addition to the HET (Header Extension 734 Type) and HEL (Header Extension Length) fields (Figure 4). 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | HET (=1) | HEL | ASID | rsvd|A| | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 741 ~ anti-replay Sequence Number (SN) ~ 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 ~ ~ 745 | Group-keyed MAC | 746 + +-+-+-+-+-+-+-+-+ 747 | | Padding | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Figure 4: Format of the group-keyed MAC EXT_AUTH header extension. 752 The fields of the group-keyed MAC EXT_AUTH header extension are: 754 "ASID" (Authentication Scheme IDentifier) field (4 bits): 756 The "ASID" identifies the source authentication scheme or protocol 757 in use. The association between the "ASID" value and the actual 758 authentication scheme is defined out-of-band, at session startup. 760 "Reserved" field (3 bits): 762 This is a reserved field that MUST be set to zero and ignored by 763 receivers. 765 "A" (Anti-replay) field (1 bit): 767 The "AR" field, when set to 0, indicates that the anti-replay 768 service is not used. When set to 1, it indicates that the anti- 769 replay service is used. 771 "SN" (Sequence Number) field (8 or 40 bits): 773 The "SN" field contains an optional sequence number. When AR=0, 774 this is an 8 bit field that MUST be set to zero. No anti-replay 775 mechanism is used in that case. When AR=1, this is a 32+8=40 bit 776 field and all of the 40 bits MUST be considered by the anti-replay 777 mechanism. 779 "Group-keyed MAC" field (variable size, multiple of 32 bits): 781 The "Group-keyed MAC" field contains a truncated Group-keyed MAC 782 of the message. If need be, this field is padded (with 0) up to a 783 multiple of 32 bits. 785 5.2. Parameters 787 Several parameters MUST be initialized by an out-of-band mechanism. 788 The sender or group controller: 790 o MUST communicate the Cryptographic MAC Function, for instance, 791 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA- 792 512. As a side effect, with these functions, the receivers also 793 know the key length and the non truncated MAC output length. 794 Because of security threats on SHA-1, the use of HMAC-SHA-256 is 795 RECOMMENDED [RFC6194]; 797 o MUST communicate the length of the truncated output of the MAC, 798 n_m, which depends on the Cryptographic MAC Function chosen. Only 799 the n_m left-most bits (most significant bits) of the MAC output 800 are kept. Of course, n_m MUST be lower or equal to the key 801 length; 803 o MUST communicate the group key to the receivers, confidentially, 804 before starting the session. This key might have to be 805 periodically refreshed for improved robustness; 807 o MUST associate a value to the "ASID" field (Authentication Scheme 808 IDentifier) of the EXT_AUTH header extension (Section 5.1); 810 o MUST communicate whether the anti-replay service is used or not 811 for this session; 813 These parameters MUST be communicated to all receivers before they 814 can authenticate the incoming packets. For instance it can be 815 communicated in the session description, or initialized in a static 816 way on the receivers, or communicated by means of an appropriate 817 protocol (this will be often the case when periodic re-keying is 818 required). The details of this out-of-band mechanism are out of the 819 scope of this document. 821 5.3. Processing 823 5.3.1. Signature Processing 825 The computation of the group-keyed MAC, using the group key, includes 826 the ALC or NORM header (with the various header extensions) and the 827 payload when applicable. The UDP/IP/MAC headers are not included. 828 During this computation, the Weak group-keyed MAC field MUST be set 829 to 0. Then the sender truncates the MAC output to keep the n_m most 830 significant bits and stores the result in the group-keyed MAC 831 Authentication header. 833 Upon receiving this packet, the receiver computes the group-keyed 834 MAC, using the group key, and compares it to the value carried in the 835 packet. During this computation, the Group MAC field MUST also be 836 set to 0. If the check fails, the packet MUST be immediately 837 dropped. 839 [RFC2104] explains that it is current practice to truncate the MAC 840 output, on condition that the truncated output length, n_m be not 841 less than half the length of the hash and not less than 80 bits. 842 However, this choice is out of the scope of this document. 844 5.3.2. Anti-Replay Processing 846 The anti-replay processing follows the principles described in 847 Section 3.3.2. 849 5.4. In Practice 851 Each packet sent MUST contain exactly one group-keyed MAC EXT_AUTH 852 header extension. A receiver MUST drop packets that do not contain a 853 group-keyed MAC EXT_AUTH header extension. 855 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 856 its content, for instance because they do not support group-keyed 857 MAC. In that case the group-keyed MAC EXT_AUTH extension is ignored. 859 If the anti-replay mechanism is used, each packet sent MUST contain a 860 valid sequence number. All the packets that fail to contain a valid 861 sequence number MUST be immediately dropped. 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | HET (=1) | HEL (=4) | ASID | 0 |0| 0 | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | 869 + + 870 | group-keyed MAC (16 bytes) | 871 + + 872 | | 873 + + 874 | | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 Figure 5: Example: Format of the group-keyed MAC EXT_AUTH header 878 extension using HMAC-SHA-256, without any anti-replay protection. 880 For instance Figure 5 shows the group-keyed MAC EXT_AUTH header 881 extension when using HMAC-SHA-256. The group-keyed MAC EXT_AUTH 882 header extension is then 16 byte long. 884 6. Combined Use of the RSA/ECC Digital Signatures and group-keyed MAC 885 Schemes 887 6.1. Authentication Header Extension Format 889 The integration of combined RSA/ECC Digital Signature and group-keyed 890 MAC is similar in ALC and NORM and relies on the header extension 891 mechanism defined in both protocols. More precisely this document 892 details the HET=1 (EXT_AUTH) header extension defined in [RFC5651]. 894 Several fields are added in addition to the HET (Header Extension 895 Type) and HEL (Header Extension Length) fields (Figure 6). 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | HET (=1) | HEL | ASID | rsvd|A| | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 902 | anti-replay Sequence Number (SN) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | | 905 ~ ~ 906 | Signature | 907 + +-+-+-+-+-+-+-+-+ 908 | | Padding | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | group-keyed MAC | 911 ~ ~ 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 6: Format of the group-keyed MAC EXT_AUTH header extension. 916 The fields of the group-keyed MAC EXT_AUTH header extension are: 918 "ASID" (Authentication Scheme IDentifier) field (4 bits): 920 The "ASID" identifies the source authentication scheme or protocol 921 in use. The association between the "ASID" value and the actual 922 authentication scheme is defined out-of-band, at session startup. 924 "Reserved" field (3 bits): 926 This is a reserved field that MUST be set to zero and ignored by 927 receivers. 929 "A" (Anti-replay) field (1 bit): 931 The "AR" field MUST be set to 1 and it indicates that the anti- 932 replay service is used (see Section 6.3). 934 "SN" (Sequence Number) field (8 or 40 bits): 936 The "SN" field contains a sequence number. Since AR=1, this is a 937 32+8=40 bit field and all of the 40 bits MUST be considered by the 938 anti-replay mechanism. 940 "Signature" field (variable size, multiple of 32 bits): 942 The "Signature" field contains a digital signature of the message. 943 If need be, this field is padded (with 0) up to a multiple of 32 944 bits. 946 "group-keyed MAC" field (variable size, multiple of 32 bits, by 947 default 32 bits): 949 The "group-keyed MAC" field contains a truncated group-keyed MAC 950 of the message. 952 6.2. Parameters 954 Several parameters MUST be initialized by an out-of-band mechanism, 955 as defined in Section 3.2, Section 4.2 and Section 5.2. 957 6.3. Processing 959 In some situations, it can be interesting to use both authentication 960 schemes. The goal of the group-keyed MAC is to mitigate DoS attacks 961 coming from attackers that are not group members [RFC4082] by adding 962 a light authentication scheme as a front-end. 964 6.3.1. Signature Processing 966 Before sending a message, the sender sets the Signature field and 967 group-keyed MAC field to zero. Then the sender computes the 968 Signature as detailed in Section 3.3 or in Section 4.3 and stores the 969 value in the Signature field. Then the sender computes the group- 970 keyed MAC as detailed in Section 5.3 and stores the value in the 971 group-keyed MAC field. The (RSA or ECC) digital signature value is 972 therefore protected by the group-keyed MAC, which avoids DoS attacks 973 where the attacker corrupts the digital signature itself. 975 Upon receiving the packet, the receiver first checks the group-keyed 976 MAC, as detailed in Section 5.3. If the check fails, the packet MUST 977 be immediately dropped. Otherwise the receiver checks the Digital 978 Signature, as detailed in Section 3.3. If the check fails, the 979 packet MUST be immediately dropped. 981 This scheme features a few limits: 983 o the group-keyed MAC is of no help if a group member (who knows the 984 group key) impersonates the sender and sends forged messages to 985 other receivers. DoS attacks are still feasible; 987 o it requires an additional MAC computing for each packet, both at 988 the sender and receiver sides; 990 o it increases the size of the authentication headers. In order to 991 limit this problem, the length of the truncated output of the MAC, 992 n_m, SHOULD be kept small (see [RFC3711] section 9.5). In the 993 current specification, n_m MUST be a multiple of 32 bits, and 994 default value is 32 bits. As a side effect, with n_m = 32 bits, 995 the authentication service is significantly weakened since the 996 probability that any packet be successfully forged is one in 2^32. 997 Since the group-keyed MAC check is only a pre-check that is 998 followed by the standard signature authentication check, this is 999 not considered to be an issue. 1001 For a given use-case, the benefits brought by the group-keyed MAC 1002 must be balanced against these limitations. 1004 6.3.2. Anti-Replay Processing 1006 The anti-replay processing follows the principles described in 1007 Section 3.3.2. Here an anti-replay service MUST be used. Indeed, 1008 failing to enable anti-replay protection would facilitate DoS 1009 attacks, since all replayed (but otherwise valid) packets would pass 1010 the light authentication scheme and oblige a receiver to perform a 1011 complex signature verification. 1013 6.4. In Practice 1015 Each packet sent MUST contain exactly one combined Digital Signature/ 1016 group-keyed MAC EXT_AUTH header extension. A receiver MUST drop 1017 packets that do not contain a combined Digital Signature/group-keyed 1018 MAC EXT_AUTH header extension. 1020 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 1021 its content, for instance because they do not support combined 1022 Digital Signature/group-keyed MAC. In that case the combined Digital 1023 Signature/group-keyed MAC EXT_AUTH extension is ignored. 1025 Since the anti-replay mechanism MUST be used, each packet sent MUST 1026 contain a valid sequence number. All the packets that fail to 1027 contain a valid sequence number MUST be immediately dropped. 1029 It is RECOMMENDED that the n_m parameter of the group authentication 1030 scheme be small, and by default equal to 32 bits (Section 6.3). 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | HET (=1) | HEL (=35) | ASID | 0 |1| | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1037 | anti-replay Sequence Number (SN) | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1039 | | ^ 1 1040 + + | 2 1041 | | | 8 1042 . . | 1043 . Signature (128 bytes) . | b 1044 . . | y 1045 | | | t 1046 + + | e 1047 | | v s 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1049 | group-keyed MAC (32 bits) | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1052 Figure 7: Example: Format of the combined RSA Digital Signature/ 1053 group-keyed MAC EXT_AUTH header extension using 1024 bit signatures, 1054 with anti-replay protection. 1056 For instance Figure 7 shows the combined Digital Signature/ 1057 group-keyed MAC EXT_AUTH header extension when using 128 byte (1024 1058 bit) key RSA digital signatures (which also means that the signature 1059 field is 128 byte long). The EXT_AUTH header extension is then 140 1060 byte long. 1062 7. IANA Considerations 1064 This document does not require any IANA registration. 1066 8. Security Considerations 1068 8.1. Dealing With DoS Attacks 1070 Let us consider packets secured through the use of a digital 1071 signature scheme first. Because faked packets are easy to create but 1072 checking them requires to compute a costly digital signature, this 1073 scheme introduces new opportunities for an attacker to mount DoS 1074 attacks. More precisely an attacker can easily saturate the 1075 processing capabilities of the receiver. 1077 In order to mitigate these attacks, it is RECOMMENDED to use the 1078 combined Digital Signature/group-keyed MAC scheme (Section 6.3). 1079 However, no mitigation is possible if a group member acts as an 1080 attacker. Additionally, even if checking a group-keyed MAC is 1081 significantly faster than checking a digital signature, there are 1082 practical limits on how many group-keyed MAC can be checked per time 1083 unit. Therefore it is RECOMMENDED to limit the number of 1084 authentication checks per time unit when the number of incoming 1085 packets that fail the authentication check exceeds a given threshold 1086 (i.e., in case of a DoS attack). 1088 The RECOMMENDATION to limit the number of checks per time unit under 1089 (presumed) attack situations can be extended to the other 1090 authentication schemes. 1092 8.2. Dealing With Replay Attacks 1094 Replay attacks consist for an attacker to store a valid message and 1095 to replay it later on. It is RECOMMENDED to use the anti-replay 1096 service defined in this document with the signature and group-keyed 1097 MAC solutions, and this anti-replay service MUST be used in case of a 1098 combined use of signature and group-keyed MAC (see Section 6.3.2). 1100 The following section details some of the potential consequences of 1101 not using the anti-replay protection. 1103 8.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes 1105 Since all the above authentication schemes are stateless, replay 1106 attacks have no impact on these schemes. 1108 8.2.2. Impacts of Replay Attacks on NORM 1110 We review here the potential impacts of a replay attack on the NORM 1111 component. Note that we do not consider here the protocols that 1112 could be used along with NORM, for instance the congestion control 1113 protocols. 1115 First, let us consider replay attacks within a given NORM session. 1116 NORM being a stateful protocol, replaying a packet may have 1117 consequences. 1119 NORM defines a "sequence" field that may be used to protect against 1120 replay attacks [RFC5740] within a given NORM session. This 1121 "sequence" field is a 16-bit value that is set by the message 1122 originator (sender or receiver) as a monotonically increasing number 1123 incremented with each NORM message transmitted. Using this field as 1124 an anti-replay protection would be possible if there is no wrapping 1125 to zero, i.e., would only be possible if at most 65535 packets are 1126 sent. This may be true for some use-cases but not for the general 1127 case. Using this field as an anti-replay protection would also be 1128 possible if the keying material is updated before wrapping to zero 1129 happens. This may be true for some use-cases but not for the general 1130 case. 1132 Now let us consider replay attacks across several NORM sessions. A 1133 host participation in a NORM session is uniquely identified by the 1134 {"source_id"; "instance_id"} tuple. Therefore, when a given host 1135 participates in several NORM sessions, it is RECOMMENDED that the 1136 "instance_id" be changed for each NORM instance. It is also 1137 RECOMMENDED, when the group-keyed MAC authentication/integrity check 1138 scheme is used, that the shared group key be changed across sessions. 1139 Therefore, NORM can be made robust in front of replay attacks across 1140 different sessions. 1142 8.2.3. Impacts of Replay Attacks on ALC 1144 We review here the potential impacts of a replay attack on the ALC 1145 component. Note that we do not consider here the protocols that 1146 could be used along with ALC, for instance the layered or wave based 1147 congestion control protocols. 1149 First, let us consider replay attacks within a given ALC session: 1151 o replayed encoding symbol: a replayed encoding symbol (coming from 1152 a replayed data packet) is detected thanks to the object/block/ 1153 symbol identifiers and is silently discarded. 1155 o replayed control information: more precisely: 1157 * At the end of the session, a "close session" (A flag) packet is 1158 sent. Replaying a packet containing this flag has no impact 1159 since the receivers already left. 1161 * Similarly, replaying a packet containing a "close object" (B 1162 flag) has no impact since this object is probably already 1163 marked as closed by the receiver. 1165 * Timing information sent as part of an LCT EXT_TIME header 1166 extension [RFC5651] may be more sensitive to replay attacks. 1167 For instance replaying a packet containing an ERT (Expected 1168 Residual Time) may mislead a receiver to believe an object 1169 transmission will continue for some time whereas the 1170 transmission of symbols for this object is about to stop. 1171 Replaying a packet containing a SCT (Sender Current Time) is 1172 easily identified if the receiver verifies that time progresses 1173 upon receiving such EXT_TIME header extensions. Replaying a 1174 packet containing a SLC (Session Last Changed) is easily 1175 identified if the receiver verifies the chronology upon 1176 receiving such EXT_TIME header extensions. 1178 This analysis shows that ALC might be, to a limited extent, sensitive 1179 to replay attacks within the same session if timing information is 1180 used. Otherwise ALC is robust in front of replay attacks within the 1181 same session. 1183 Now let us consider replay attacks across several ALC sessions. An 1184 ALC session is uniquely identified by the {sender's IP address; 1185 Transport Session Identifier (TSI)}. Therefore, when a given sender 1186 creates several sessions, the TSI MUST be changed for each ALC 1187 session, so that each TSI is unique among all active sessions of this 1188 sender and for a large period of time preceding and following when 1189 the session is active [RFC5651]. Therefore, ALC can be made robust 1190 in front of replay attacks across different sessions. Of course, 1191 when the group-keyed MAC authentication/integrity check scheme is 1192 used, the shared group key SHOULD be changed across sessions if the 1193 set of receivers changes. 1195 8.3. Dealing With Attacks on the Parameters Sent Out-of-Band 1197 This specification requires several parameters to be communicated to 1198 the receiver(s) via an out-of-band mechanism that is out of the scope 1199 of this document. This is in particular the case for the mapping 1200 between an ASID value and the associated authentication scheme 1201 (Section 1). Since this mapping is critical, this information SHOULD 1202 be carried in a secure way from the sender to the receiver(s). 1204 9. Acknowledgments 1206 The author is grateful to the authors of [RFC4303], [RFC4359], 1207 [RFC4754] and [RFC5480] that inspired several sections of the present 1208 document. The author is also grateful to all the IESG members, and 1209 in particular to David Harrington, Stephen Farrell and Sean Turner 1210 for their very detailed reviews. 1212 10. References 1214 10.1. Normative References 1216 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1217 Hashing for Message Authentication", RFC 2104, 1218 February 1997. 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", RFC 2119, BCP 14, March 1997. 1223 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1224 Transport (LCT) Building Block", RFC 5651, October 2009. 1226 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1227 "NACK-Oriented Reliable Multicast (NORM) Transport 1228 Protocol", RFC 5740, November 2009. 1230 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1231 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1232 April 2010. 1234 10.2. Informative References 1236 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1237 Standards (PKCS) #1: RSA Cryptography Specifications 1238 Version 2.1", RFC 3447, February 2003. 1240 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1241 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1242 RFC 3711, March 2004. 1244 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1245 Briscoe, "Timed Efficient Stream Loss-Tolerant 1246 Authentication (TESLA): Multicast Source Authentication 1247 Transform Introduction", RFC 4082, June 2005. 1249 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1250 RFC 4303, December 2005. 1252 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 1253 Encapsulating Security Payload (ESP) and Authentication 1254 Header (AH)", RFC 4359, January 2006. 1256 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 1257 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 1258 RFC 4754, January 2007. 1260 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1261 "Elliptic Curve Cryptography Subject Public Key 1262 Information", RFC 5480, March 2009. 1264 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1265 Mail Extensions (S/MIME) Version 3.2 Message 1266 Specification", RFC 5751, January 2010. 1268 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1269 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1270 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1271 Reliable Multicast (NORM) Protocols", RFC 5776, 1272 April 2010. 1274 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1275 Curve Cryptography Algorithms", RFC 6090, February 2011. 1277 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1278 Considerations for the SHA-0 and SHA-1 Message-Digest 1279 Algorithms", RFC 6194, March 2011. 1281 [RMT-FLUTE] 1282 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1283 "FLUTE - File Delivery over Unidirectional Transport", 1284 Work in Progress, February 2011. 1286 Author's Address 1288 Vincent Roca 1289 INRIA 1290 655, av. de l'Europe 1291 Inovallee; Montbonnot 1292 ST ISMIER cedex 38334 1293 France 1295 Email: vincent.roca@inria.fr 1296 URI: http://planete.inrialpes.fr/people/roca/