idnits 2.17.1 draft-ietf-msec-tesla-for-alc-norm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5268 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-09 == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-11 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) == Outdated reference: A later version (-16) exists of draft-ietf-rmt-flute-revised-07 == Outdated reference: A later version (-06) exists of draft-ietf-rmt-simple-auth-for-alc-norm-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC V. Roca 3 Internet-Draft A. Francillon 4 Intended status: Experimental S. Faurite 5 Expires: April 29, 2010 INRIA 6 October 26, 2009 8 Use of TESLA in the ALC and NORM Protocols 9 draft-ietf-msec-tesla-for-alc-norm-10 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 29, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document details the TESLA packet source authentication and 58 packet integrity verification protocol and its integration within the 59 ALC and NORM content delivery protocols. This document only 60 considers the authentication/integrity verification of the packets 61 generated by the session's sender. The authentication and integrity 62 verification of the packets sent by receivers, if any, is out of the 63 scope of this document. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 6 69 1.2. Conventions Used in this Document . . . . . . . . . . . . 7 70 1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7 71 1.3.1. Notations and Definitions Related to Cryptographic 72 Functions . . . . . . . . . . . . . . . . . . . . . . 7 73 1.3.2. Notations and Definitions Related to Time . . . . . . 8 74 2. Using TESLA with ALC and NORM: General Operations . . . . . . 10 75 2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 10 76 2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 11 77 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 11 78 2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11 79 2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 12 80 2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12 81 2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 13 82 2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 14 83 2.4.1. Delay Bound Calculation in Direct Time 84 Synchronization Mode . . . . . . . . . . . . . . . . . 14 85 2.4.2. Delay Bound Calculation in Indirect time 86 Synchronization Mode . . . . . . . . . . . . . . . . . 15 87 2.5. Cryptographic parameter values . . . . . . . . . . . . . . 16 88 3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 17 89 3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 17 90 3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 17 91 3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 17 92 3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20 93 3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 21 94 3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21 95 3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21 96 3.2.2. Direct Time Synchronization Response . . . . . . . . . 22 97 3.3. TESLA Authentication Information . . . . . . . . . . . . . 23 98 3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23 99 3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23 100 3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24 101 3.4. Format of TESLA Messages and Authentication Tags . . . . . 26 102 3.4.1. Format of a Bootstrap Information Message . . . . . . 26 103 3.4.2. Format of a Direct Time Synchronization Response . . . 32 104 3.4.3. Format of a Standard Authentication Tag . . . . . . . 33 105 3.4.4. Format of an Authentication Tag Without Key 106 Disclosure . . . . . . . . . . . . . . . . . . . . . . 34 107 3.4.5. Format of an Authentication Tag with a ``New Key 108 Chain'' Commitment . . . . . . . . . . . . . . . . . . 35 109 3.4.6. Format of an Authentication Tag with a ``Last Key 110 of Old Chain'' Disclosure . . . . . . . . . . . . . . 36 111 4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 38 112 4.1. Verification of the Authentication Information . . . . . . 38 113 4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 38 114 4.1.2. Processing the Digital Signature . . . . . . . . . . . 38 115 4.1.3. Processing the Authentication Tag . . . . . . . . . . 39 116 4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 39 117 4.2.1. Processing the Bootstrap Information Message . . . . . 39 118 4.2.2. Performing Time Synchronization . . . . . . . . . . . 40 119 4.3. Authentication of Received Packets . . . . . . . . . . . . 42 120 4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 44 121 4.4. Flushing the Non Authenticated Packets of a Previous 122 Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 45 123 5. Integration in the ALC and NORM Protocols . . . . . . . . . . 46 124 5.1. Authentication Header Extension Format . . . . . . . . . . 46 125 5.2. Use of Authentication Header Extensions . . . . . . . . . 47 126 5.2.1. EXT_AUTH Header Extension of Type Bootstrap 127 Information . . . . . . . . . . . . . . . . . . . . . 47 128 5.2.2. EXT_AUTH Header Extension of Type Authentication 129 Tag . . . . . . . . . . . . . . . . . . . . . . . . . 50 130 5.2.3. EXT_AUTH Header Extension of Type Direct Time 131 Synchronization Request . . . . . . . . . . . . . . . 51 132 5.2.4. EXT_AUTH Header Extension of Type Direct Time 133 Synchronization Response . . . . . . . . . . . . . . . 51 134 6. Security Considerations . . . . . . . . . . . . . . . . . . . 53 135 6.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 53 136 6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 54 137 6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 54 138 6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 55 139 6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 55 140 6.3. Security of the Back Channel . . . . . . . . . . . . . . . 56 141 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 142 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 143 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 144 9.1. Normative References . . . . . . . . . . . . . . . . . . . 60 145 9.2. Informative References . . . . . . . . . . . . . . . . . . 60 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 148 1. Introduction 150 Many applications using multicast and broadcast communications 151 require that each receiver be able to authenticate the source of any 152 packet it receives as well as the integrity of these packets. This 153 is the case with ALC [RMT-PI-ALC] and NORM [RMT-PI-NORM], two Content 154 Delivery Protocols (CDP) designed to transfer reliably objects (e.g., 155 files) between a session's sender and several receivers. The NORM 156 protocol is based on bidirectional transmissions. Each receiver 157 acknowledges data received or, in case of packet erasures, asks for 158 retransmissions. On the opposite, the ALC protocol is based on 159 purely unidirectional transmissions. Reliability is achieved by 160 means of the cyclic transmission of the content within a carousel 161 and/or by the use of proactive Forward Error Correction codes (FEC). 162 Both protocols have in common the fact that they operate at 163 application level, on top of an erasure channel (e.g., the Internet) 164 where packets can be lost (erased) during the transmission. 166 The goal of this document is to counter attacks where an attacker 167 impersonates the ALC or NORM session's sender and injects forged 168 packets to the receivers, thereby corrupting the objects 169 reconstructed by the receivers. 171 Preventing this attack is much more complex in case of group 172 communications than it is with unicast communications. Indeed, with 173 unicast communications a simple solution exists: the sender and the 174 receiver share a secret key to compute a Message Authentication Code 175 (MAC) of all messages exchanged. This is no longer feasible in case 176 of multicast and broadcast communications since sharing a group key 177 between the sender and all receivers implies that any group member 178 can impersonate the sender and send forged messages to other 179 receivers. 181 The usual solution to provide the source authentication and message 182 integrity services in case of multicast and broadcast communications 183 consists in relying on asymmetric cryptography and using digital 184 signatures. Yet this solution is limited by high computational costs 185 and high transmission overheads. The Timed Efficient Stream Loss- 186 tolerant Authentication protocol (TESLA) is an alternative solution 187 that provides the two required services, while being compatible with 188 high rate transmissions over lossy channels. 190 This document explains how to integrate the TESLA source 191 authentication and packet integrity protocol to the ALC and NORM CDP. 192 Any application built on top of ALC and NORM will directly benefit 193 from the services offered by TESLA at the transport layer. In 194 particular, this is the case of FLUTE. 196 For more information on the TESLA protocol and its principles, please 197 refer to [RFC4082][Perrig04]. For more information on ALC and NORM, 198 please refer to [RMT-PI-ALC], [RFC5651] and [RMT-PI-NORM] 199 respectively. For more information on FLUTE, please refer to 200 [RMT-FLUTE]. 202 1.1. Scope of this Document 204 This specification only considers the authentication and integrity 205 verification of the packets generated by the session's sender. This 206 specification does not consider the packets that may be sent by 207 receivers, for instance NORM's feedback packets. [RMT-SIMPLE-AUTH] 208 describes several techniques that can be used to that purpose. Since 209 this is usually a low-rate flow (unlike the downstream flow), using 210 computing intensive techniques like digital signatures, possibly 211 combined with a Group MAC scheme, is often acceptable. Finally, the 212 Section 5 explains how to use several authentication schemes in a 213 given session thanks to the ASID (Authentication Scheme IDentifier) 214 field. 216 This specification relies on several external mechanisms, for 217 instance: 219 o to communicate securely the public key or a certificate for the 220 session's sender (Section 2.2.2); 222 o to communicate securely and confidentially the group key, K_g, 223 used by the Group MAC feature, when applicable (Section 3.3.3). 224 In some situations, this group key will have to be periodically 225 refreshed; 227 o to perform secure time synchronization in indirect mode 228 (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the 229 request/response messages with ALC which is purely unidirectional; 231 These mechanisms are required in order to bootstrap TESLA at a sender 232 and at a receiver and must be deployed in parallel to TESLA. 233 Besides, the randomness of the Primary Key of the key chain 234 (Section 3.1.2) is vital to the security of TESLA. Therefore the 235 sender needs an appropriate mechanism to generate this random key. 237 Several technical details of TESLA, like the most appropriate way to 238 alternate between the transmission of a key disclosure and a 239 commitment to a new key chain, or the transmission of a key 240 disclosure and the last key of the previous key chain, or the 241 disclosure of a key and the compact flavor that does not disclose any 242 key, are specific to the target use-case (Section 3.1.2). For 243 instance, it depends on the number of packets sent per time interval, 244 on the desired robustness and the acceptable transmission overhead, 245 which can only be optimized after taking into account the use-case 246 specificities. 248 1.2. Conventions Used in this Document 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in [RFC2119]. 254 1.3. Terminology and Notations 256 The following notations and definitions are used throughout this 257 document. 259 1.3.1. Notations and Definitions Related to Cryptographic Functions 261 Notations and definitions related to cryptographic functions 262 [RFC4082][RFC4383]: 264 o PRF is the Pseudo Random Function; 266 o MAC is the Message Authentication Code; 268 o HMAC is the keyed-Hash Message Authentication Code; 270 o F is the one-way function used to create the key chain 271 (Section 3.1.2.1); 273 o F' is the one-way function used to derive the HMAC keys 274 (Section 3.1.2.1); 276 o n_p is the length, in bits, of the F function's output. This is 277 therefore the length of the keys in the key chain; 279 o n_f is the length, in bits, of the F' function's output. This is 280 therefore the length of the HMAC keys; 282 o n_m is the length, in bits, of the truncated output of the MAC 283 [RFC2104]. Only the n_m most significant bits of the MAC output 284 are kept; 286 o N is the length of a key chain. There are N+1 keys in a key 287 chain: K_0, K_1, .. K_N. When several chains are used, all the 288 chains MUST have the same length and keys are numbered 289 consecutively, following the time interval numbering; 291 o n_c is the number of keys in a key chain. Therefore: n_c = N+1; 293 o n_tx_lastkey is the number of additional intervals during which 294 the last key of the old key chain SHOULD be sent, after switching 295 to a new key chain and after waiting for the disclosure delay d. 296 These extra transmissions take place after the interval during 297 which the last key is normally disclosed. The n_tx_lastkey value 298 is either 0 (no extra disclosure) or larger. This parameter is 299 sender specific and is not communicated to the receiver; 301 o n_tx_newkcc is the number of intervals during which the commitment 302 to a new key chain SHOULD be sent, before switching to the new key 303 chain. The n_tx_newkcc value is either 0 (no commitment sent 304 within authentication tags) or larger. This parameter is sender 305 specific and is not communicated to the receiver; 307 o K_g is a shared group key, communicated to all group members, 308 confidentially, during the TESLA bootstrapping (Section 2.2); 310 o n_w is the length, in bits, of the truncated output of the MAC of 311 the optional group authentication scheme: only the n_w most 312 significant bits of the MAC output are kept. n_w is typically 313 small, multiple of 32 bits (e.g., 32 bits); 315 1.3.2. Notations and Definitions Related to Time 317 Notations and definitions related to time: 319 o i is the time interval index. Interval numbering starts at 0 and 320 increases consecutively. Since the interval index is stored as a 321 32 bit unsigned integer, wrapping to 0 might take place in long 322 sessions. 324 o t_s is the sender local time value at some absolute time (in NTP 325 timestamp format); 327 o t_r is the receiver local time value at the same absolute time (in 328 NTP timestamp format); 330 o T_0 is the start time corresponding to the beginning of the 331 session, i.e., the beginning of time interval 0 (in NTP timestamp 332 format); 334 o T_int is the interval duration (in milliseconds); 336 o d is the key disclosure delay (in number of intervals); 337 o D_t is the upper bound of the lag of the receiver's clock with 338 respect to the clock of the sender; 340 o S_sr is an estimated bound of the clock drift between the sender 341 and a receiver throughout the duration of the session; 343 o D^O_t is the upper bound of the lag of the sender's clock with 344 respect to the time reference in indirect time synchronization 345 mode; 347 o D^R_t is the upper bound of the lag of the receiver's clock with 348 respect to the time reference in indirect time synchronization 349 mode; 351 o D_err is an upper bound of the time error between all the time 352 references, in indirect time synchronization mode; 354 o NTP timestamp format consists in a 64-bit unsigned fixed-point 355 number, in seconds relative to 0h on 1 January 1900. The integer 356 part is in the first 32 bits and the fraction part in the last 32 357 bits [RFC1305]; 359 2. Using TESLA with ALC and NORM: General Operations 361 2.1. ALC and NORM Specificities that Impact TESLA 363 The ALC and NORM protocols have features and requirements that 364 largely impact the way TESLA can be used. 366 In case of ALC: 368 o ALC is massively scalable: nothing in the protocol specification 369 limits the number of receivers that join a session. Therefore an 370 ALC session potentially includes a huge number (e.g., millions or 371 more) of receivers; 373 o ALC can work on top of purely unidirectional transport channels: 374 this is one of the assets of ALC, and examples of unidirectional 375 channels include satellite (even if a back channel might exist in 376 some use cases) and broadcasting networks like DVB-H/SH; 378 o ALC defines an on-demand content delivery model [RMT-PI-ALC] where 379 receivers can arrive at any time, at their own discretion, 380 download the content and leave the session. Other models (e.g., 381 push or streaming) are also defined; 383 o ALC sessions are potentially very long: a session can last several 384 days or months during which the content is continuously 385 transmitted within a carousel. The content can be either static 386 (e.g., a software update) or dynamic (e.g., a web site). 388 Depending on the use case, some of the above features may not apply. 389 For instance ALC can also be used over a bidirectional channel or 390 with a limited number of receivers. 392 In case of NORM: 394 o NORM has been designed for medium size sessions: indeed, NORM 395 relies on feedback messages and the sender may collapse if the 396 feedback message rate is too high; 398 o NORM requires a bidirectional transport channel: the back channel 399 is not necessarily a high data rate channel since the control 400 traffic sent over it by a single receiver is an order of magnitude 401 lower than the downstream traffic. Networks with an asymmetric 402 connectivity (e.g., a high rate satellite downlink and a low-rate 403 RTC based return channel) are appropriate; 405 2.2. Bootstrapping TESLA 407 In order to initialize the TESLA component at a receiver, the sender 408 MUST communicate some key information in a secure way, so that the 409 receiver can check the source of the information and its integrity. 410 Two general methods are possible: 412 o by using an out-of-band mechanism, or 414 o by using an in-band mechanism. 416 The current specification does not recommend any mechanism to 417 bootstrap TESLA. Choosing between an in-band and out-of-band scheme 418 is left to the implementer, depending on the target use-case. 419 However, it is RECOMMENDED that TESLA implementations support the use 420 of the in-band mechanism for interoperability purposes. 422 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism 424 For instance [RFC4442] describes the use of the MIKEY (Multimedia 425 Internet Keying) protocol to bootstrap TESLA. As a side effect, 426 MIKEY also provides a loose time synchronization feature, that TESLA 427 can benefit. Other solutions, for instance based on an extended 428 session description, are possible, on condition these solutions 429 provide the required security level. 431 2.2.2. Bootstrapping TESLA with an In-Band Mechanism 433 This specification describes an in-band mechanism. In some use- 434 cases, it might be desired that bootstrap take place without 435 requiring the use of an additional external mechanism. For instance 436 each device may feature a clock with a known time-drift that is 437 negligible in front of the time accuracy required by TESLA, and each 438 device may embed the public key of the sender. It is also possible 439 that the use-case does not feature a bidirectional channel which 440 prevents the use of out-of-band protocols like MIKEY. For these two 441 examples, the exchange of a bootstrap information message (described 442 in Section 3.4.1) and the knowledge of a few additional parameters 443 (listed below) are sufficient to bootstrap TESLA at a receiver. 445 Some parameters cannot be communicated in-band. In particular: 447 o the sender or group controller MUST either communicate the public 448 key of the sender or a certificate (which also means that a PKI 449 has been setup) to all receivers, so that each receiver be able to 450 verify the signature of the bootstrap message and direct time 451 synchronization response messages (when applicable). 453 o when time synchronization is performed with NTP/SNTP, the sender 454 or group controller MUST communicate the list of valid NTP/SNTP 455 servers to all the session members (sender included), so that they 456 all be able to synchronize themselves on the same NTP/SNTP 457 servers. 459 o when the Group MAC feature is used, the sender or group controller 460 MUST communicate the K_g group key to all the session members 461 (sender included). This group key may be periodically refreshed. 463 The way these parameters are communicated is out of the scope of this 464 document. 466 2.3. Setting Up a Secure Time Synchronization 468 The security offered by TESLA heavily relies on time. Therefore the 469 session's sender and each receiver need to be time synchronized in a 470 secure way. To that purpose, two general methods exist: 472 o direct time synchronization, and 474 o indirect time synchronization. 476 It is also possible that a given session include receivers that use 477 the direct time synchronization mode while others use the indirect 478 time synchronization mode. 480 2.3.1. Direct Time Synchronization 482 When direct time synchronization is used, each receiver asks the 483 sender for a time synchronization. To that purpose, a receiver sends 484 a "Direct Time Synchronization Request" (Section 4.2.2.1). The 485 sender then directly answers to each request with a "Direct Time 486 Synchronization Response" (Section 3.4.2), signing this reply. Upon 487 receiving this response, a receiver first verifies the signature, and 488 then calculates an upper bound of the lag of his clock with respect 489 to the clock of the sender, D_t. The details on how to calculate D_t 490 are given in Section 2.4.1. 492 This synchronization method is both simple and secure. Yet there are 493 two potential issues: 495 o a bidirectional channel must exist between the sender and each 496 receiver, and 498 o the sender may collapse if the incoming request rate is too high. 500 Relying on direct time synchronization is not expected to be an issue 501 with NORM since (1) bidirectional communications already take place, 502 and (2) NORM scalability is anyway limited. Yet it can be required 503 that a mechanism, that is out of the scope of this document, be used 504 to spread the transmission of "Direct time synchronization request" 505 messages over the time if there is a risk that the sender may 506 collapse. 508 But direct time synchronization is potentially incompatible with ALC 509 since (1) there might not be a back channel and (2) there are 510 potentially a huge number of receivers and therefore a risk that the 511 sender collapses. 513 2.3.2. Indirect Time Synchronization 515 When indirect time synchronization is used, the sender and each 516 receiver must synchronize securely via an external time reference. 517 Several possibilities exist: 519 o sender and receivers can synchronize through a NTPv3 (Network Time 520 Protocol version 3) [RFC1305] hierarchy of servers. The 521 authentication mechanism of NTPv3 MUST be used in order to 522 authenticate each NTP message individually. It prevents for 523 instance an attacker to impersonate a NTP server; 525 o they can synchronize through a NTPv4 (Network Time Protocol 526 version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security 527 protocol of NTPv4 MUST be used in order to authenticate each NTP 528 message individually; 530 o they can synchronize through a SNTPv4 (Simple Network Time 531 Protocol version 4) [RFC4330] hierarchy of servers. The 532 authentication features of SNTPv4 must then be used. Note that 533 TESLA only needs a loose (but secure) time synchronization, which 534 is in line with the time synchronization service offered by SNTP; 536 o they can synchronize through a GPS or Galileo (or similar) device 537 that also provides a high precision time reference. Spoofing 538 attacks on the GPS system have recently been reported. Depending 539 on the use case, the security achieved will be or not acceptable; 541 o they can synchronize thanks to a dedicated hardware, embedded on 542 each sender and receiver, that provides a clock with a time-drift 543 that is negligible in front of the TESLA time accuracy 544 requirements. This feature enables a device to synchronize its 545 embedded clock with the official time reference from time to time 546 (in an extreme case once, at manufacturing time), and then to 547 remain autonomous for a duration that depends on the known maximum 548 clock drift. 550 A bidirectional channel is required by the NTP/SNTP schemes. On the 551 opposite, with the GPS/Galileo and high precision clock schemes, no 552 such assumption is made. In situations where ALC is used on purely 553 unidirectional transport channels (Section 2.1), using the NTP/SNTP 554 schemes is not possible. Another aspect is the scalability 555 requirement of ALC, and to a lesser extent of NORM. From this point 556 of view, the above mechanisms usually do not raise any problem, 557 unlike the direct time synchronization schemes. Therefore, using 558 indirect time synchronization can be a good choice. It should be 559 noted that the NTP/SNTP schemes assume that each client trusts the 560 sender and accepts to align its NTP/SNTP configuration to that of the 561 sender. If this assumption does not hold, the sender SHOULD offer an 562 alternative solution. 564 The details on how to calculate an upper bound of the lag of a 565 receiver's clock with respect to the clock of the sender, D_t, are 566 given in Section 2.4.2. 568 2.4. Determining the Delay Bounds 570 Let us assume that a secure time synchronization has been set up. 571 This section explains how to define the various timing parameters 572 that are used during the authentication of received packets. 574 2.4.1. Delay Bound Calculation in Direct Time Synchronization Mode 576 In direct time synchronization mode, synchronization between a 577 receiver and the sender follows the following protocol [RFC4082]: 579 o The receiver sends a "Direct Time Synchronization Request" message 580 to the sender, that includes t_r, the receiver local time at the 581 moment of sending (Section 4.2.2.1). 583 o Upon receipt of this message, the sender records its local time, 584 t_s, and sends to the receiver a "Direct Time Synchronization 585 Response" that includes t_r (taken from the request) and t_s, 586 signing this reply (Section 3.4.2). 588 o Upon receiving this response, the receiver first verifies that he 589 actually sent a request with t_r and then checks the signature. 590 Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an 591 estimated bound of the clock drift between the sender and the 592 receiver throughout the duration of the session. This document 593 does not specify how S_sr is estimated. 595 After this initial synchronization, at any point throughout the 596 session, the receiver knows that: T_s < T_r + D_t, where T_s is the 597 current time at the sender and T_r is the current time at the 598 receiver. 600 2.4.2. Delay Bound Calculation in Indirect time Synchronization Mode 602 In indirect time synchronization, the sender and the receivers must 603 synchronize indirectly using one or several time references. 605 2.4.2.1. Single time reference 607 Let us assume that there is a single time reference. 609 1. The sender calculates D^O_t, the upper bound of the lag of the 610 sender's clock with respect to the time reference. This D^O_t 611 value is then be communicated to the receivers (Section 3.2.1). 613 2. Similarly, a receiver R calculates D^R_t, the upper bound of the 614 lag of the receiver's clock with respect to the time reference. 616 3. Then, for receiver R, the overall upper bound of the lag of the 617 receiver's clock with respect to the clock of the sender, D_t, is 618 the sum: D_t = D^O_t + D^R_t. 620 The D^O_t and D^R_t calculation depends on the time synchronization 621 mechanism used (Section 2.3.2). In some cases, the synchronization 622 scheme specifications provide these values. In other cases, these 623 parameters can be calculated by means of a scheme similar to the one 624 specified in Section 2.4.1, for instance when synchronization is 625 achieved via a group controller [RFC4082]. 627 2.4.2.2. Multiple time references 629 Let us now assume that there are several time references (e.g., 630 several NTP/SNTP servers). The sender and receivers first 631 synchronize with the various time references, independently. It 632 results in D^O_t and D^R_t. Let D_err be an upper bound of the time 633 error between all the time references. Then, the overall value of 634 D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err. 636 In some cases, the D_t value is part of the time synchronization 637 scheme specifications. For instance NTPv3 [RFC1305] defines 638 algorithms that are "capable of accuracies in the order of a 639 millisecond, even after extended periods when synchronization to 640 primary reference sources has been lost". In practice, depending on 641 the NTP server stratum, the accuracy might be a little bit worse. In 642 that case, D_t = security_factor * (1ms + 1ms), where the 643 security_factor is meant to compensate several sources of inaccuracy 644 in NTP. The choice of the security_factor value is left to the 645 implementer, depending on the target use-case. 647 2.5. Cryptographic parameter values 649 The F (resp. F') function output length is given by the n_p (resp. 650 n_f) parameter. The n_p and n_f values depend on the PRF function 651 chosen, as specified below: 653 +------------------------+---------------------+ 654 | PRF name | n_p and n_f | 655 +------------------------+---------------------+ 656 | HMAC-SHA-1 | 160 bits (20 bytes) | 657 | | | 658 | HMAC-SHA-224 | 224 bits (28 bytes) | 659 | | | 660 | HMAC-SHA-256 (default) | 256 bits (32 bytes) | 661 | | | 662 | HMAC-SHA-384 | 384 bits (48 bytes) | 663 | | | 664 | HMAC-SHA-512 | 512 bits (64 bytes) | 665 +------------------------+---------------------+ 667 The computing of regular MAC (resp. Group MAC) makes use of the n_m 668 (resp. n_w) parameter, i.e., the length of the truncated output of 669 the function. The n_m and n_w values depend on the MAC function 670 chosen, as specified below: 672 +------------------------+---------------------+-------------------+ 673 | MAC name | n_m (regular MAC) | n_w (Group MAC) | 674 +------------------------+---------------------+-------------------+ 675 | HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) | 676 | | | | 677 | HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) | 678 | | | | 679 | HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) | 680 | | | | 681 | HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) | 682 | | | | 683 | HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) | 684 +------------------------+---------------------+-------------------+ 686 3. Sender Operations 688 This section describes the TESLA operations at a sender. For more 689 information on the TESLA protocol and its principles, please refer to 690 [RFC4082][Perrig04]. 692 3.1. TESLA Parameters 694 3.1.1. Time Intervals 696 The sender divides the time into uniform intervals of duration T_int. 697 Time interval numbering starts at 0 and is incremented consecutively. 698 The interval index MUST be stored in an unsigned 32 bit integer so 699 that wrapping to 0 takes place only after 2^^32 intervals. For 700 instance, if T_int is equal to 0.5 seconds, then wrapping takes place 701 after approximately 68 years. 703 3.1.2. Key Chains 705 3.1.2.1. Principles 707 The sender computes a one-way key chain of n_c = N+1 keys, and 708 assigns one key from the chain to each interval, consecutively but in 709 reverse order. Key numbering starts at 0 and is incremented 710 consecutively, following the time interval numbering: K_0, K_1 .. 711 K_N. 713 In order to compute this chain, the sender must first select a 714 Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF). The 715 randomness of the Primary Key, K_N, is vital to the security and no 716 one should be able to guess it. 718 The function F is a one-way function that is defined as: F(k) = 719 f_k(0), where f_k(0) is the result of the application of the PRF f to 720 k and 0. When f is a HMAC (Section 7), k is used as the key, and 0 721 as the message, using the algorithm described in [RFC2104]. 722 Similarly, the function F' is a one-way function that is defined as: 723 F'(k) = f_k(1), where f_k(1) is the result of the application of the 724 same PRF f to k and 1. 726 The sender then computes all the keys of the chain, recursively, 727 starting with K_N, using: K_{i-1} = F(K_i). Therefore: K_i = F^{N- 728 i}(K_N), where F^i(x) is the execution of function F with the 729 argument x, i times. The receiver can then compute any value in the 730 key chain from K_N, even if it does not have intermediate values 731 [RFC4082]. The key for MAC calculation can then be derived from the 732 corresponding K_i key by K'_i = F'(K_i). 734 The key chain has a finite length, N, which corresponds to a maximum 735 time duration of (N + 1) * T_int. The content delivery session has a 736 duration T_delivery, which may either be known in advance, or not. A 737 first solution consists in having a single key chain of an 738 appropriate length, so that the content delivery session finishes 739 before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int. 740 But the longer the key chain, the higher the memory and computation 741 required to cope with it. Another solution consists in switching to 742 a new key chain, of the same length, when necessary [Perrig04]. 744 3.1.2.2. Using Multiple Key Chains 746 When several key chains are needed, all of them MUST be of the same 747 length. Switching from the current key chain to the next one 748 requires that a commitment to the new key chain be communicated in a 749 secure way to the receiver. This can be done by using either an out- 750 of-band mechanism, or an in-band mechanism. This document only 751 specifies the in-band mechanism. 753 < -------- old key chain --------- >||< -------- new key chain --... 754 +-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+ 755 0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5 756 || 757 Key disclosures: || 758 N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3 759 | || | | 760 |< -------------- >|| |< ------------- >| 761 Additional key F(K_N+1) || K_N 762 disclosures (commitment to || (last key of the 763 (in parallel): the new chain) || old chain) 765 Figure 1: Switching to the second key chain with the in-band 766 mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3. 768 Figure 1 illustrates the switch to the new key chain, using the in- 769 band mechanism. Let us say that the old key chain stops at K_N and 770 the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two 771 different keys). Then the sender includes the commitment F(K_{N+1}) 772 to the new key chain into packets authenticated with the old key 773 chain (see Section 3.4.5). This commitment SHOULD be sent during 774 n_tx_newkcc time intervals before the end of the old key chain. 775 Since several packets are usually sent during an interval, the sender 776 SHOULD alternate between sending a disclosed key of the old key chain 777 and the commitment to the new key chain. The details of how to 778 alternate between the disclosure and commitment are out of the scope 779 of this document. 781 The receiver will keep the commitment until the key K_{N+1} is 782 disclosed, at interval N+1+d. Then the receiver will be able to test 783 the validity of that key by computing F(K_{N+1}) and comparing it to 784 the commitment. 786 When the key chain is changed, it becomes impossible to recover a 787 previous key from the old key chain. This is a problem if the 788 receiver lost the packets disclosing the last key of the old key 789 chain. A solution consists in re-sending the last key, K_N, of the 790 old key chain (see Section 3.4.6). This SHOULD be done during 791 n_tx_lastkey additional time intervals after the end of the time 792 interval where K_N is disclosed. Since several packets are usually 793 sent during an interval, the sender SHOULD alternate between sending 794 a disclosed key of the new key chain, and the last key of the old key 795 chain. The details of how to alternate between the two disclosures 796 are out of the scope of this document. 798 In some cases a receiver having experienced a very long disconnection 799 might have lost the commitment of the new chain. Therefore this 800 receiver will not be able to authenticate any packet related to the 801 new chain and all the following ones. The only solution for this 802 receiver to catch up consists in receiving an additional bootstrap 803 information message. This can happen by waiting for the next 804 periodic transmission (if sent in-band) or through an external 805 mechanism (Section 3.2.1). 807 3.1.2.3. Values of the n_tx_lastkey and n_tx_newkcc Parameters 809 When several key chains and the in-band commitment mechanism are 810 used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc 811 parameters in such a way that no overlapping occur. In other words, 812 once a sender starts transmitting commitments for a new key chain, he 813 MUST NOT send a disclosure for the last key of the old key chain any 814 more. Therefore, the following property MUST be verified: 816 d + n_tx_lastkey + n_tx_newkcc <= N + 1 818 It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey 819 has been chosen, then: 821 n_tx_newkcc = N + 1 - n_tx_lastkey - d 823 In other words, the sender starts transmitting a commitment to the 824 following key chain immediately after having sent all the disclosures 825 of the last key of the previous key chain. Doing so increases the 826 probability that a receiver gets a commitment for the following key 827 chain. 829 In any case, these two parameters are sender specific and need not be 830 transmitted to the receivers. Of course, as explained above, the 831 sender alternates between the disclosure of a key of the current key 832 chain and the commitment to the new key chain (or the last key of the 833 old key chain). 835 3.1.2.4. The Particular Case of the Session Start 837 Since a key cannot be disclosed before the disclosure delay, d, no 838 key will be disclosed during the first d time intervals (intervals 0 839 and 1 in Figure 1) of the session. To that purpose, the sender uses 840 the Authentication Tag Without Key Disclosure Section 3.4.4. The 841 following key chains, if any, are not concerned since they will 842 disclose the last d keys of the previous chain. 844 3.1.2.5. Managing Silent Periods 846 An ALC or NORM sender may stop transmitting packets for some time. 847 For instance it can be the end of the session and all packets have 848 already been sent, or the use-case may consist in a succession of 849 busy periods (when fresh objects are available) followed by silent 850 periods. In any case, this is an issue since the authentication of 851 the packets sent during the last d intervals requires that the 852 associated keys be disclosed, which will take place during d 853 additional time intervals. 855 To solve this problem, it is recommended that the sender transmit 856 empty packets (i.e., without payload) containing the TESLA EXT_AUTH 857 header extension along with a Standard Authentication Tag during at 858 least d time intervals after the end of the regular ALC or NORM 859 packet transmissions. The number of such packets and the duration 860 during which they are sent must be sufficient for all receivers to 861 receive, with a high probability, at least one packet disclosing the 862 last useful key (i.e., the key used for the last non-empty packet 863 sent). 865 3.1.3. Time Interval Schedule 867 The sender must determine the following parameters: 869 o T_0, the start time corresponding to the beginning of the session, 870 i.e., the beginning of time interval 0 (in NTP timestamp format); 872 o T_int, the interval duration (in milliseconds), usually ranging 873 from 100 milliseconds to 1 second; 875 o d, the key disclosure delay (in number of intervals). It is the 876 time to wait before disclosing a key; 878 o N, the length of a key chain; 880 The correct choice of T_int, d, and N is crucial for the efficiency 881 of the scheme. For instance, a T_int * d product that is too long 882 will cause excessive delay in the authentication process. A T_int * 883 d product that is too short prevents many receivers from verifying 884 packets. A N * T_int product that is too small will cause the sender 885 to switch too often to new key chains. A N that is too long with 886 respect to the expected session duration (if known) will require the 887 sender to compute too many useless keys. [RFC4082] sections 3.2 and 888 3.6 give general guidelines for initializing these parameters. 890 The T_0, T_int, d and N parameters MUST NOT be changed during the 891 lifetime of the session. This restriction is meant to prevent 892 introducing vulnerabilities. For instance if a sender was authorized 893 to change the key disclosure schedule, a receiver that did not 894 receive the change notification would still believe in the old key 895 disclosure schedule, thereby creating vulnerabilities [RFC4082]. 897 3.1.4. Timing Parameters 899 In indirect time synchronization mode, the sender must determine the 900 following parameter: 902 o D^O_t, the upper bound of the lag of the sender's clock with 903 respect to the time reference. 905 The D^O_t parameter MUST NOT be changed during the lifetime of the 906 session. 908 3.2. TESLA Signaling Messages 910 At a sender, TESLA produces two types of signaling information: 912 o The bootstrap information: it can be either sent out-of-band or 913 in-band. In the latter case, a digitally signed packet contains 914 all the information required to bootstrap TESLA at a receiver; 916 o The direct time synchronization response, which enables a receiver 917 to finish a direct time synchronization; 919 3.2.1. Bootstrap Information 921 In order to initialize the TESLA component at a receiver, the sender 922 must communicate some key information in a secure way. This 923 information can be sent in-band or out-of-band, as discussed in 924 Section 2.2. In this section we only consider the in-band scheme. 926 The TESLA bootstrap information message MUST be digitally signed 927 (Section 3.3.2). The goal is to enable a receiver to check the 928 packet source and packet integrity. Then, the bootstrap information 929 can be: 931 o unicast to a receiver during a direct time synchronization 932 request/response exchange; 934 o broadcast to all receivers. This is typically the case in 935 indirect time synchronization mode. It can also be used in direct 936 time synchronization mode, for instance when a large number of 937 clients arrive at the same time, in which case it is more 938 efficient to answer globally. 940 Let us consider situations where the bootstrap information is 941 broadcast. This message should be broadcast at the beginning of the 942 session, before data packets are actually sent. This is particularly 943 important with ALC or NORM sessions in "push" mode, when all clients 944 join the session in advance. For improved reliability, bootstrap 945 information might be sent a certain number of times. 947 A periodic broadcast of the bootstrap information message could also 948 be useful when: 950 o the ALC session uses an "on-demand" mode, clients arriving at 951 their own discretion; 953 o some clients experience an intermittent connectivity. This is 954 particularly important when several key chains are used in an ALC 955 or NORM session, since there is a risk that a receiver loses all 956 the commitments to the new key chain. 958 A balance must be found between the signaling overhead and the 959 maximum initial waiting time at the receiver before starting the 960 delayed authentication process. A period of a few seconds for the 961 transmission of this bootstrap information is often a reasonable 962 value. 964 3.2.2. Direct Time Synchronization Response 966 In Direct Time Synchronization, upon receipt of a synchronization 967 request, the sender records its local time, t_s, and sends a response 968 message that contains both t_r and t_s (Section 2.4.1). This message 969 is unicast to the receiver. This Direct Time Synchronization 970 Response message MUST be digitally signed in order to enable a 971 receiver to check the packet source and packet integrity 972 (Section 3.3.2). The receiver MUST also be able to associate this 973 response and his request, which is the reason why t_r is included in 974 the response message. 976 3.3. TESLA Authentication Information 978 At a sender, TESLA produces three types of security tags: 980 o an authentication tag, in case of data packets, and which contains 981 the MAC of the packet; 983 o a digital signature, in case of one of the two TESLA signaling 984 packets, namely a Bootstrap Information Message or a Direct Time 985 Synchronization Response; and 987 o an optional group authentication tag, that can be added to all the 988 packets to mitigate attacks coming from outside of the group. 990 Because of interdependencies, their computation MUST follow a strict 991 order: 993 o first of all, compute the authentication tag (with data packet) or 994 the digital signature (with signaling packet); 996 o finally compute the Group Mac; 998 3.3.1. Authentication Tags 1000 All the data packets sent MUST have an authentication tag containing: 1002 o the interval index, i, which is also the index of the key used for 1003 computing the MAC of this packet; 1005 o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i); 1007 o either a disclosed key (that belongs to the current key chain or 1008 the previous key chain), or a commitment to a new key chain, or no 1009 key at all; 1011 The computation of MAC(K'_i, M) MUST include the ALC or NORM header 1012 (with the various header extensions) and the payload (when 1013 applicable). The UDP/IP headers MUST NOT be included. During this 1014 computation, the MAC(K'_i, M) field of the authentication tag MUST be 1015 set to 0. 1017 3.3.2. Digital Signatures 1019 The Bootstrap Information message (with the in-band bootstrap scheme) 1020 and Direct Time Synchronization Response message (with the indirect 1021 time synchronization scheme) both need to be signed by the sender. 1023 These two messages contain a "Signature" field to hold the digital 1024 signature. The bootstrap information message also contains the 1025 "Signature Encoding Algorithm", the "Signature Cryptographic 1026 Function", and the "Signature Length" fields that enable a receiver 1027 to process the "Signature" field. Note that there is no such 1028 "Signature Encoding Algorithm", "Signature Cryptographic Function" 1029 and "Signature Length" fields in case of a Direct Time 1030 Synchronization Response message since it is assumed that these 1031 parameters are already known (i.e., the receiver either received a 1032 bootstrap information message before, or these values have been 1033 communicated out-of-band). 1035 Several "Signature Encoding Algorithms" can be used, including 1036 RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With 1037 these encodings, SHA-256 is the default "Signature Cryptographic 1038 Function". 1040 The computation of the signature MUST include the ALC or NORM header 1041 (with the various header extensions) and the payload when applicable. 1042 The UDP/IP headers MUST NOT be included. During this computation, 1043 the "Signature" field MUST be set to 0 as well as the optional Group 1044 MAC, when present, since this Group MAC is calculated later on. 1046 More specifically, from [RFC4359]: digital signature generation is 1047 performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1- 1048 v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of 1049 the packet is used as the message M, which is passed to the signature 1050 generation function. The signer's RSA private key is passed as K. In 1051 summary (when SHA-256 is used), the signature generation process 1052 computes a SHA-256 hash of the authenticated packet bytes, signs the 1053 SHA-256 hash using the private key, and encodes the result with the 1054 specified RSA encoding type. This process results in a value S, 1055 which is the digital signature to be included in the packet. 1057 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 1058 signature is equal to the "RSA modulus", unless the "RSA modulus" is 1059 not a multiple of 8 bits. In that case, the signature MUST be 1060 prepended with between 1 and 7 bits set to zero such that the 1061 signature is a multiple of 8 bits [RFC4359]. The key size, which in 1062 practice is also equal to the "RSA modulus", has major security 1063 implications. [RFC4359] explains how to choose this value depending 1064 on the maximum expected lifetime of the session. This choice is out 1065 of the scope of this document. 1067 3.3.3. Group MAC Tags 1069 An optional Group MAC can be used to mitigate DoS attacks coming from 1070 attackers that are not group members [RFC4082]. This feature assumes 1071 that a group key, K_g, is shared by the sender and all receivers. 1072 When the attacker is not a group member, the benefits of adding a 1073 group MAC to every packet sent are threefold: 1075 o a receiver can immediately drop faked packets, without having to 1076 wait for the disclosure delay, d; 1078 o a sender can immediately drop faked direct time synchronization 1079 requests, and avoid to check the digital signature, a computation 1080 intensive task; 1082 o a receiver can immediately drop faked direct time synchronization 1083 response and bootstrap messages, without having to verify the 1084 digital signature, a computation intensive task; 1086 The computation of the group MAC, MAC(K_g, M), MUST include the ALC 1087 or NORM header (with the various header extensions) and the payload 1088 when applicable. The UDP/IP headers MUST NOT be included. During 1089 this computation, the Group MAC field MUST be set to 0. However the 1090 digital signature (e.g., of a bootstrap message) and the MAC fields 1091 (e.g., of an authentication tag), when present, MUST have been 1092 calculated since they are included in the Group MAC calculation 1093 itself. Then the sender truncates the MAC output to keep the n_w 1094 most significant bits and stores the result in the Group MAC field. 1096 This scheme features a few limits: 1098 o it is of no help if a group member (who knows K_g) impersonates 1099 the sender and sends forged messages to other receivers; 1101 o it requires an additional MAC computing for each packet, both at 1102 the sender and receiver sides; 1104 o it increases the size of the TESLA authentication headers. In 1105 order to limit this problem, the length of the truncated output of 1106 the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711] 1107 section 9.5). As a side effect, the authentication service is 1108 significantly weakened: the probability that any forged packet be 1109 successfully authenticated becomes one in 2^32. Since the group 1110 MAC check is only a pre-check that must be followed by the 1111 standard TESLA authentication check, this is not considered to be 1112 an issue. 1114 For a given use-case, the benefits brought by the group MAC must be 1115 balanced against these limitations. 1117 Note that the Group MAC function can be different from the TESLA MAC 1118 function (e.g., it can use a weaker but faster MAC function). Note 1119 also that the mechanism by which the group key, K_g, is communicated 1120 to all group members, and perhaps periodically updated, is out of the 1121 scope of this document. 1123 3.4. Format of TESLA Messages and Authentication Tags 1125 This section specifies the format of the various kinds of TESLA 1126 messages and authentication tags sent by the session's sender. 1127 Because these TESLA messages are carried as EXT_AUTH header 1128 extensions of the ALC or NORM packets (Section 5), the following 1129 formats do not start on 32 bit word boundaries. 1131 3.4.1. Format of a Bootstrap Information Message 1133 When bootstrap information is sent in-band, the following message is 1134 used: 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+ --- 1139 | V |resvd|S|G|A| ^ 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1141 | d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i 1143 | SigEncAlgo | SigCryptoFunc | Signature Length | | x 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e 1145 | Reserved | T_int | | d 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1147 | | | l 1148 + T_0 (NTP timestamp format) + | e 1149 | | | n 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g 1151 | N (Key Chain Length) | | t 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h 1153 | Current Interval Index i | v 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1155 | | 1156 ~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+ 1157 | | Padding | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | | 1160 + + 1161 ~ Signature ~ 1162 + +-+-+-+-+-+-+-+-+ 1163 | | Padding | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 |P| | 1166 +-+ D^O_t Extension (optional, present if A==1) + 1167 | (NTP timestamp diff, positive if P==1, negative if P==0) | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 ~ Group MAC (optional) ~ 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 Figure 2: Bootstrap information format. 1174 The format of the bootstrap information is depicted in Figure 2. The 1175 fields are: 1177 "V" (Version) field (2 bits): 1179 The "V" field contains the version number of the protocol. For 1180 this specification, the value of 0 MUST be used. 1182 "Reserved" field (3 bits): 1184 This is a reserved field that MUST be set to zero in this 1185 specification. 1187 "S" (Single Key Chain) flag (1 bits): 1189 The "S" flag indicates whether this TESLA session is restricted to 1190 a single key chain (S==1) or relies on one or multiple key chains 1191 (S==0). 1193 "G" (Group MAC Present) flag (1 bits): 1195 The "G" flag indicates whether the Group MAC feature is used 1196 (G==1) or not (G==0). When it is used, a "Group MAC" field is 1197 added to all the packets containing a TESLA EXT_AUTH Header 1198 Extension (including this bootstrap message). 1200 "A" flag (1 bit): 1202 The "A" flag indicates whether the P flag and D^O_t fields are 1203 present (A==1) or not (A==0). In indirect time synchronization 1204 mode, A MUST be equal to 1 since these fields are needed. 1206 "d" field (8 bits): 1208 d is an unsigned integer that defines the key disclosure delay (in 1209 number of intervals). d MUST be greater or equal to 2. 1211 "PRF Type" field (8 bits): 1213 The "PRF Type" is the reference number of the f function used to 1214 derive the F (for key chain) and F' (for MAC keys) functions 1215 (Section 7). 1217 "MAC Function Type" field (8 bits): 1219 The "MAC Function Type" is the reference number of the function 1220 used to compute the MAC of the packets (Section 7). 1222 "Group MAC Function Type" field (8 bits): 1224 When G==1, this field contains the reference number of the 1225 cryptographic MAC function used to compute the group MAC 1226 (Section 7). When G==0, this field MUST be set to zero. 1228 "Signature Encoding Algorithm" field (8 bits): 1230 The "Signature Encoding Algorithm" is the reference number 1231 (Section 7) of the digital signature used to authenticate this 1232 bootstrap information and included in the "Signature" field. 1234 "Signature Cryptographic Function" field (8 bits): 1236 The "Signature Cryptographic Function" is the reference number 1237 (Section 7) of the cryptographic function used within the digital 1238 signature. 1240 "Signature Length" field (16 bits): 1242 The "Signature Length" is an unsigned integer that indicates the 1243 signature field size in bytes in the "Signature Extension" field. 1244 This is also the signature key length, since both parameters are 1245 equal. 1247 "Reserved" fields (16 bits): 1249 This is a reserved field that MUST be set to zero in this 1250 specification. 1252 "T_int" field (16 bits): 1254 T_int is an unsigned 16 bit integer that defines the interval 1255 duration (in milliseconds). 1257 "T_0" field (64 bits): 1259 "T_0" is a timestamp in NTP timestamp format that indicates the 1260 beginning of the session, i.e., the beginning of time interval 0. 1262 "N" field (32 bits): 1264 "N" is an unsigned integer that indicates the key chain length. 1265 There are N + 1 keys per chain. 1267 "i" (Interval Index of K_i) field (32 bits): 1269 "i" is an unsigned integer that indicates the current interval 1270 index when this bootstrap information message is sent. 1272 "Current Key Chain Commitment" field (variable size, padded if 1273 necessary for 32 bit word alignment): 1275 "Key Chain Commitment" is the commitment to the current key chain, 1276 i.e., the key chain corresponding to interval i. For instance, 1277 with the first key chain, this commitment is equal to F(K_0), with 1278 the second key chain, this commitment is equal to F(K_{N+1}), 1279 etc.). If need be, this field is padded (with 0) up to a multiple 1280 of 32 bits. 1282 "Signature" field (variable size, padded if necessary for 32 bit word 1283 alignment): 1285 The "Signature" field is mandatory. It contains a digital 1286 signature of this message, as specified by the encoding algorithm, 1287 cryptographic function and key length parameters. If the 1288 signature length is not multiple of 32 bits, this field is padded 1289 with 0. 1291 "P" flag (optional, 1 bit if present): 1293 The "P" flag is optional and only present if the A flag is equal 1294 to 1.. It is only used in indirect time synchronization mode. 1295 This flag indicates whether the D^O_t NTP timestamp difference is 1296 positive (P==1) or negative (P==0). 1298 "D^O_t" field (optional, 63 bits if present): 1300 The "D^O_t" field is optional and only present if the A flag is 1301 equal to 1. It is only used in indirect time synchronization 1302 mode. It is the upper bound of the lag of the sender's clock with 1303 respect to the time reference. When several time references are 1304 specified (e.g., several NTP servers), then D^O_t is the maximum 1305 upper bound of the lag with each time reference. D^O_t is 1306 composed of two unsigned integers, as with NTP timestamps: the 1307 first 31 bits give the time difference in seconds and the 1308 remaining 32 bits give the sub-second time difference. 1310 "Group MAC" field (optional, variable length, multiple of 32 bits): 1312 This field contains the group MAC, calculated with the group key, 1313 K_g, shared by all group members. The field length, in bits, is 1314 given by n_w which is known once the group MAC function type is 1315 known (Section 7). 1317 Note that the first byte and the following seven 32-bit words are 1318 mandatory fixed length fields. The Current Key Chain Commitment and 1319 Signature fields are mandatory but variable length fields. The 1320 remaining D^O_t and Group MAC fields are optional. 1322 In order to prevent attacks, some parameters MUST NOT be changed 1323 during the lifetime of the session (Section 3.1.3, Section 3.1.4). 1324 The following table summarizes the parameters status: 1326 +--------------------------+----------------------------------------+ 1327 | Parameter | Status | 1328 +--------------------------+----------------------------------------+ 1329 | V | set to 0 in this specification | 1330 | | | 1331 | S | static (during whole session) | 1332 | | | 1333 | G | static (during whole session) | 1334 | | | 1335 | A | static (during whole session) | 1336 | | | 1337 | T_O | static (during whole session) | 1338 | | | 1339 | T_int | static (during whole session) | 1340 | | | 1341 | d | static (during whole session) | 1342 | | | 1343 | N | static (during whole session) | 1344 | | | 1345 | D^O_t (if present) | static (during whole session) | 1346 | | | 1347 | PRF Type | static (during whole session) | 1348 | | | 1349 | MAC Function Type | static (during whole session) | 1350 | | | 1351 | Signature Encoding | static (during whole session) | 1352 | Algorithm | | 1353 | | | 1354 | Signature Crypto. | static (during whole session) | 1355 | Function | | 1356 | | | 1357 | Signature Length | static (during whole session) | 1358 | | | 1359 | Group MAC Func. Type | static (during whole session) | 1360 | | | 1361 | i | dynamic (related to current key chain) | 1362 | | | 1363 | K_i | dynamic (related to current key chain) | 1364 | | | 1365 | signature | dynamic, packet dependent | 1366 | | | 1367 | Group MAC (if present) | dynamic, packet dependent | 1368 +--------------------------+----------------------------------------+ 1370 3.4.2. Format of a Direct Time Synchronization Response 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+ 1375 | Reserved | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | | 1378 + t_s (NTP timestamp) + 1379 | | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | | 1382 + t_r (NTP timestamp) + 1383 | | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | | 1386 + + 1387 ~ Signature ~ 1388 + +-+-+-+-+-+-+-+-+ 1389 | | Padding | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 ~ Group MAC (optional) ~ 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Figure 3: Format of a Direct Time Synchronization Response 1396 The response to a direct time synchronization request contains the 1397 following information: 1399 "Reserved" fields (8 bits): 1401 This is a reserved field that MUST be set to zero in this 1402 specification. 1404 "t_s" (NTP timestamp, 64 bits): 1406 t_s is a timestamp in NTP timestamp format that corresponds to the 1407 sender local time value when receiving the direct time 1408 synchronization request message. 1410 "t_r" (NTP timestamp, 64 bits): 1412 t_r is a timestamp in NTP timestamp format that contains the 1413 receiver local time value received in the direct time 1414 synchronization request message. 1416 "Signature" field (variable size, padded if necessary for 32 bit word 1417 alignment): 1419 The "Signature" field is mandatory. It contains a digital 1420 signature of this message, as specified by the encoding algorithm, 1421 cryptographic function and key length parameters communicated in 1422 the bootstrap information message (if applicable) or out-of-band. 1423 If the signature length is not multiple of 32 bits, this field is 1424 padded with 0. 1426 "Group MAC" field (optional, variable length, multiple of 32 bits): 1428 This field contains the Group MAC, calculated with the group key, 1429 K_g, shared by all group members. The field length, in bits, is 1430 given by n_w, which is known once the group MAC function type is 1431 known (Section 7). 1433 3.4.3. Format of a Standard Authentication Tag 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+ 1438 | Reserved | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | i (Interval Index of K'_i) | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | | 1443 ~ Disclosed Key K_{i-d} ~ 1444 | | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | | 1447 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1448 | | Padding | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 ~ Group MAC (optional) ~ 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Figure 4: Format of the Standard Authentication Tag 1455 Figure 4 shows the format of the Standard Authentication Tag: 1457 "Reserved" field (8 bits): 1459 The "Reserved" field is not used in the current specification and 1460 MUST be set to zero by the sender. 1462 "i" (Interval Index) field (32 bits): 1464 i is the interval index associated to the key (K'_i) used to 1465 compute the MAC of this packet. 1467 "Disclosed Key" (variable size, non padded): 1469 The "Disclosed Key" is the key used for interval i-d: K_{i-d}. 1470 There is no padding between the "Disclosed Key" and "MAC(K'_i, M)" 1471 fields, and the latter MAY not start on a 32 bit boundary, 1472 depending on the n_p parameter. 1474 "MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word 1475 alignment): 1477 MAC(K'_i, M) is the truncated message authentication code of the 1478 current packet. Only the n_m most significant bits of the MAC 1479 output are kept [RFC2104]. 1481 "Group MAC" field (optional, variable length, multiple of 32 bits): 1483 This field contains the Group MAC, calculated with a group key, 1484 K_g, shared by all group members. The field length is given by 1485 n_w, in bits. 1487 Note that because a key cannot be disclosed before the disclosure 1488 delay, d, the sender MUST NOT use this tag during the first d 1489 intervals of the session: {0 .. d-1} (inclusive). Instead the sender 1490 MUST use an Authentication Tag Without Key Disclosure. 1492 3.4.4. Format of an Authentication Tag Without Key Disclosure 1494 The authentication tag without key disclosure is meant to be used in 1495 situations where a high number of packets are sent in a given time 1496 interval. In such a case, it can be advantageous to disclose the 1497 K_{i-d} key only in a subset of the packets sent, using a Standard 1498 Authentication Tag, and use the shortened version that does not 1499 disclose the K_{i-d} key in the remaining packets. It is left to the 1500 implementer to decide how many packets should disclose the K_{i-d} 1501 key. This Authentication Tag Without Key Disclosure MUST also be 1502 used during the first d intervals: {0 .. d-1} (inclusive). 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+ 1507 | Reserved | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | i (Interval Index of K'_i) | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | | 1512 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1513 | | Padding | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 ~ Group MAC (optional) ~ 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 Figure 5: Format of the Authentication Tag Without Key Disclosure 1520 3.4.5. Format of an Authentication Tag with a ``New Key Chain'' 1521 Commitment 1523 During the last n_tx_newkcc intervals of the current key chain, the 1524 sender SHOULD send commitments to the next key chain. This is done 1525 by replacing the disclosed key of the authentication tag with the new 1526 key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch 1527 between the second and third key chains, etc.). Figure 6 shows the 1528 corresponding format. 1530 Note that since there is no padding between the "F(K_{N+1})" and 1531 "MAC(K'_i, M)" fields, this latter MAY not start on a 32 bit 1532 boundary, depending on the n_p parameter. 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+ 1537 | Reserved | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | i (Interval Index of K'_i) | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | | 1542 ~ New Key Commitment F(K_{N+1}) ~ 1543 | | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | | 1546 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1547 | | Padding | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 ~ Group MAC (optional) ~ 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Figure 6: Format of the Authentication Tag with a New Key Chain 1553 Commitment 1555 3.4.6. Format of an Authentication Tag with a ``Last Key of Old Chain'' 1556 Disclosure 1558 During the first n_tx_lastkey intervals of the new key chain after 1559 the disclosing interval, d, the sender SHOULD disclose the last key 1560 of the old key chain. This is done by replacing the disclosed key of 1561 the authentication tag with the last key of the old chain, K_N (or 1562 K_{2N+1} in case of a switch between the second and third key chains, 1563 etc.). Figure 7 shows the corresponding format. 1565 Note that since there is no padding between the "K_N" and "MAC(K'_i, 1566 M)" fields, this latter MAY not start on a 32 bit boundary, depending 1567 on the n_p parameter. 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+ 1572 | Reserved | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | i (Interval Index of K'_i) | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | | 1577 ~ Last Key of Old Chain, K_N ~ 1578 | | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | | 1581 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1582 | | Padding | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 ~ Group MAC (optional) ~ 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 Figure 7: Format of the authentication tag with an old chain last key 1588 disclosure 1590 4. Receiver Operations 1592 This section describes the TESLA operations at a receiver. 1594 4.1. Verification of the Authentication Information 1596 This section details the computation steps required to verify each of 1597 the three possible authentication information of an incoming packet. 1598 The verification MUST follow a strict order: 1600 o first of all, if the Group MAC is present and if the session uses 1601 this feature (e.g., if the G bit is set in the bootstrap 1602 information message), then verify the Group MAC. A packet that 1603 does not contain a Group MAC tag whereas the session uses this 1604 feature MUST be immediately dropped. On the opposite, if a packet 1605 contains a Group MAC tag whereas the session does not use this 1606 feature, this tag MUST be ignored; 1608 o then verify the digital signature (with TESLA signaling packets) 1609 or enter the TESLA authentication process (with data packets) 1611 4.1.1. Processing the Group MAC Tag 1613 Upon receiving a packet containing a Group MAC Tag, the receiver 1614 recomputes the Group MAC and compares it to the value carried in the 1615 packet. If the check fails, the packet MUST be immediately dropped. 1617 More specifically, recomputing the Group MAC requires to save the 1618 value of the Group MAC field, to set this field to 0, and to do the 1619 same computation as a sender does (see Section 3.3.3). 1621 4.1.2. Processing the Digital Signature 1623 Upon receiving a packet containing a digital signature, the receiver 1624 verifies the signature as follows. 1626 The computation of the signature MUST include the ALC or NORM header 1627 (with the various header extensions) and the payload when applicable. 1628 The UDP/IP headers MUST NOT be included. During this computation, 1629 the "Signature" field MUST be set to 0 as well as the optional Group 1630 MAC, when present. 1632 From [RFC4359]: Digital signature verification is performed as 1633 described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and 1634 [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital 1635 signature is passed to the verification function as S. The 1636 authenticated portion of the packet is used as the message M, and the 1637 RSA public key is passed as (n, e). In summary (when SHA-256 is 1638 used), the verification function computes a SHA-256 hash of the 1639 authenticated packet bytes, decrypts the SHA-256 hash in the packet, 1640 and validates that the appropriate encoding was applied. The two 1641 SHA-256 hashes are compared, and if they are identical the validation 1642 is successful. 1644 It is assumed that the receivers have the possibility to retrieve the 1645 sender's public key required to check this digital signature 1646 (Section 2.2). This document does not specify how the public key of 1647 the sender is communicated reliably and in a secure way to all 1648 possible receivers. 1650 4.1.3. Processing the Authentication Tag 1652 When a receiver wants to authenticate a packet using an 1653 Authentication Tag and when he has the key for the associated time 1654 interval (i.e., after the disclosing delay, d), the receiver 1655 recomputes the MAC and compares it to the value carried in the 1656 packet. If the check fails, the packet MUST be immediately dropped. 1658 More specifically, recomputing the MAC requires to save the value of 1659 the MAC field, to set this field to 0, and to do the same computation 1660 as a sender does (see Section 3.3.1). 1662 4.2. Initialization of a Receiver 1664 A receiver MUST be initialized before being able to authenticate the 1665 source of incoming packets. This can be done by an out-of-band 1666 mechanism or an in-band mechanism (Section 2.2). Let us focus on the 1667 in-band mechanism. Two actions must be performed: 1669 o receive and process a bootstrap information message, and 1671 o calculate an upper bound of the sender's local time. To that 1672 purpose, the receiver must perform time synchronization. 1674 4.2.1. Processing the Bootstrap Information Message 1676 A receiver must first receive a packet containing the bootstrap 1677 information, digitally signed by the sender. Once the bootstrap 1678 information has been authenticated (sec Section 4.1), the receiver 1679 can initialize its TESLA component. The receiver MUST then ignore 1680 the following bootstrap information messages, if any. There is an 1681 exception though: when a new key chain is used and if a receiver 1682 missed all the commitments for this new key chain, then this receiver 1683 MUST process one of the future Bootstrap information messages (if 1684 any) in order to be able to authenticate the incoming packets 1685 associated to this new key chain. 1687 Before TESLA has been initialized, a receiver MUST discard incoming 1688 packets other than the bootstrap information message and direct time 1689 synchronization response. 1691 4.2.2. Performing Time Synchronization 1693 First of all, the receiver must know whether the ALC or NORM session 1694 relies on direct or indirect time synchronization. This information 1695 is communicated by an out-of-band mechanism (for instance when 1696 describing the various parameters of an ALC or NORM session. In some 1697 cases, both mechanisms might be available and the receiver can choose 1698 the preferred technique. 1700 4.2.2.1. Direct Time Synchronization 1702 In case of a direct time synchronization, a receiver MUST synchronize 1703 with the sender. To that purpose, the receiver sends a direct time 1704 synchronization request message. This message includes the local 1705 time (in NTP timestamp format) at the receiver when sending the 1706 message. This timestamp will be copied in the sender's response for 1707 the receiver to associate the response to the request. 1709 The direct time synchronization request message format is the 1710 following: 1712 0 1 2 3 1713 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 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | | 1716 + t_r (NTP timestamp) + 1717 | | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 ~ Group MAC (optional) ~ 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 Figure 8: Format of a Direct Time Synchronization Request 1724 The direct time synchronization request (Figure 8) contains the 1725 following information: 1727 "t_r" (NTP timestamp, 64 bits): 1729 t_r is a timestamp in NTP timestamp format that contains the 1730 receiver local time value when sending this direct time 1731 synchronization request message; 1733 "Group MAC" field (optional, variable length, multiple of 32 bits): 1735 This field contains the Group MAC, calculated with the group key, 1736 K_g, shared by all group members. The field length, in bits, is 1737 given by n_w, which is known once the Group MAC function type is 1738 known (Section 7). 1740 The receiver then awaits a response message (Section 3.4.2). Upon 1741 receiving this message, the receiver: 1743 checks that this response relates to the request, by comparing the 1744 t_r fields; 1746 checks the Group MAC if present; 1748 checks the signature; 1750 retrieves the t_s value and calculates D_t (Section 2.4.1); 1752 Note that in an ALC session, the direct time synchronization request 1753 message is sent to the sender by an out-of-band mechanism that is not 1754 specified by the current document. 1756 4.2.2.2. Indirect Time Synchronization 1758 With the indirect time synchronization method, the sender MAY provide 1759 out-of-band the URL or IP address of the NTP server(s) he trusts 1760 along with an OPTIONAL certificate for each NTP server. When several 1761 NTP servers are specified, a receiver MUST choose one of them. This 1762 document does not specify how the choice is made, but for the sake of 1763 scalability, the clients SHOULD NOT use the same server if several 1764 possibilities are offered. The NTP synchronization between the NTP 1765 server and the receiver MUST be authenticated, either using the 1766 certificate provided by the server, or another certificate the client 1767 may obtain for this NTP server. 1769 Then the receiver computes the time offset between itself and the NTP 1770 server chosen. Note that the receiver does not need to update the 1771 local time, (which often requires root privileges), computing the 1772 time offset is sufficient. 1774 Since the offset between the server and the time reference, D^O_t, is 1775 indicated in the bootstrap information message (or communicated out- 1776 of-band), the receiver can now calculate an upper bound of the 1777 sender's local time (Section 2.4.2). 1779 Note that this scenario assumes that each client trusts the sender 1780 and accepts to align its NTP configuration to that of the sender, 1781 using one of the NTP server(s) suggested. If this assumption does 1782 not hold, the client MUST NOT use the NTP indirect time 1783 synchronization method (Section 2.3.2). 1785 4.3. Authentication of Received Packets 1787 The receiver can now authenticate incoming packets (other than 1788 bootstrap information and direct time synchronization response 1789 packets). To that purpose, he MUST follow different steps (see 1790 [RFC4082] section 3.5): 1792 1. The receiver parses the different packet headers. If none of the 1793 four TESLA authentication tags is present, the receiver MUST 1794 discard the packet. If the session is in "Single Key Chain" mode 1795 (e.g., when the "S" flag is set in the bootstrap information 1796 message), then the receiver MUST discard any packet containing an 1797 Authentication Tag With a New Key Chain Commitment or an 1798 Authentication Tag With a Last Key of Old Chain Disclosure. 1800 2. Safe packet test: When the receiver receives packet P_j, it first 1801 records the local time T at which the packet arrived. The 1802 receiver then computes an upper bound t_j on the sender's clock 1803 at the time when the packet arrived: t_j = T + D_t. The receiver 1804 then computes the highest interval the sender could possibly be 1805 in: highest_i = floor((t_j - T_0) / T_int). He also retrieves 1806 the "i" interval index from the authentication tag. The receiver 1807 can now proceed with the "safe packet" test. If highest_i < i + 1808 d, then the sender is not yet in the interval during which it 1809 discloses the key K_i. The packet is safe (but not necessarily 1810 authentic). If the test fails, the packet is unsafe, and the 1811 receiver MUST discard the packet. 1813 3. Group MAC test: if the optional Group MAC tag is present and if 1814 the session uses this feature, then verify the Group MAC 1815 (Section 4.1.1). If the verification fails, the packet MUST be 1816 immediately dropped. A packet that does not contain a Group MAC 1817 tag whereas the session uses this feature MUST be immediately 1818 dropped. On the opposite, if a packet contains a Group MAC tag 1819 whereas the session does not use this feature, this tag MUST be 1820 ignored. 1822 4. Disclosed Key processing: When the packet discloses a key (i.e., 1823 with a Standard Authentication Tag, or with an Authentication Tag 1824 with a ``Last Key of Old Chain'' Disclosure), the following tests 1825 are performed: 1827 * New key index test: the receiver checks whether a legitimate 1828 key already exists with the same index (i.e., i-d). If such a 1829 legitimate key exists, the receiver compares its value with 1830 the current disclosed key and if they are identical, skips the 1831 "Unverifiable key test" and "Key verification test". If such 1832 a legitimate key exists but the values differ, the receiver 1833 MUST discard the packet. 1835 * Unverifiable key test: when the disclosed key index is new, it 1836 is possible that no earlier disclosed and legitimate key 1837 exists for this key chain, thereby preventing the verification 1838 of the disclosed key. This happens when the disclosed key 1839 belongs to the old key chain and no commitment to this old key 1840 chain has ever been received (e.g., because the first 1841 bootstrap packet received by a latecomer is for the current 1842 key chain, and therefore includes a commitment to the current 1843 key chain, not the previous one). When this happens, the 1844 receiver MUST ignore the disclosed key (anyway useless) and 1845 skip the "Key verification test". 1847 * Key verification test: If the disclosed key index is new and 1848 the key can be verified, the receiver checks the legitimacy of 1849 K_{i-d} by verifying, for some earlier disclosed and 1850 legitimate key K_v (with v < i-d), that K_v and F^{i-d- 1851 v}(K_{i-d}) are identical. In other words, the receiver 1852 checks the disclosed key by computing the necessary number of 1853 PRF functions to obtain a previously disclosed and legitimate 1854 (i.e., verified) key. If the key verification fails, the 1855 receiver MUST discard the packet. If the key verification 1856 succeeds, this key is said legitimate and is stored by the 1857 receiver, as well as all the keys between indexes v and i-d. 1859 5. When applicable, the receiver performs any congestion control 1860 related action (i.e., the ALC or NORM headers are used by the 1861 associated congestion control building block, if any), even if 1862 the packet has not yet been authenticated [RFC5651]. If this 1863 feature leads to a potential DoS attack (the attacker can send a 1864 faked packet with a wrong sequence number to simulate packet 1865 losses), it does not compromise the security features offered by 1866 TESLA and enables a rapid reaction in front of actual congestion 1867 problems. 1869 6. The receiver then buffers the packet for a later authentication, 1870 once the corresponding key will be disclosed (after d time 1871 intervals) or deduced from another key (if all packets disclosing 1872 this key are lost). In some situations, this packet might also 1873 be discarded later on, if it turns out that the receiver will 1874 never be able to deduce the associated key. 1876 7. Authentication test: Let v be the smallest index of the 1877 legitimate keys known by the receiver so far. For all the new 1878 keys K_w, with v < w <= i-d, that have been either disclosed by 1879 this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in 1880 interval {v+1,.. i-d-1}), the receiver verifies the authenticity 1881 of the safe packets buffered for the corresponding interval w. 1882 To authenticate one of the buffered packets P_h containing 1883 message M_h protected with a MAC that used key index w, the 1884 receiver will compute K'_w = F'(K_w) from which it can compute 1885 MAC( K'_w, M_h). If this MAC does not equal the MAC stored in 1886 the packet, the receiver MUST discard the packet. If the two MAC 1887 are equal, the packet is successfully authenticated and the 1888 receiver continues processing it. 1890 8. Authenticated new key chain commitment processing: If the 1891 authenticated packet contains a new key chain commitment and if 1892 no verified commitment already exists, then the receiver stores 1893 the commitment to the new key chain. Then, if there are non 1894 authenticated packets for a previous chain (i.e., the key chain 1895 before the current one), all these packets can be discarded 1896 (Section 4.4). 1898 9. The receiver continues the ALC or NORM processing of all the 1899 packets authenticated during the authentication test. 1901 In this specification, a receiver using TESLA MUST immediately drop 1902 unsafe packets. But the receiver MAY also decide, at any time, to 1903 continue an ALC or NORM session in unsafe (insecure) mode, ignoring 1904 TESLA extensions. There SHOULD be an explicit user action to that 1905 purpose. 1907 4.3.1. Discarding Unnecessary Packets Earlier 1909 Following strictly the above steps can lead to excessive processing 1910 overhead in certain situations. This is the case when a receiver 1911 receives packets for an unwanted object with the ALC or NORM 1912 protocols, i.e., an object for which the application (or the end 1913 user) explicitly mentioned it is not interested in. This is also the 1914 case when a receiver receives packets for an already decoded object, 1915 or when this object has been partitioned in several blocks, for an 1916 already decoded block. When such a packet is received, which is 1917 easily identified by looking at the receiver's status for the 1918 incoming ALC or NORM packet, the receiver MUST also check that the 1919 packet is a pure data packet that does not contain any signaling 1920 information of importance for the session. 1922 With ALC, a packet containing a "A" flag ("Close Session") or a "B" 1923 flag ("Close Object") MUST NOT be discarded before having been 1924 authenticated and processed normally. Otherwise, the receiver can 1925 safely discard the incoming packet for instance just after step 1 of 1926 Section 4.3. This optimization can dramatically reduce the 1927 processing overhead, by avoiding many useless authentication checks. 1929 4.4. Flushing the Non Authenticated Packets of a Previous Key Chain 1931 In some cases a receiver having experienced a very long disconnection 1932 might have lost all the disclosures of the last key(s) of a previous 1933 key chain. Let j be the index of this key chain for which there 1934 remains non authenticated packets. This receiver can flush all the 1935 packets of the key chain j if he determines that: 1937 o he has just switched to a chain of index j+2 (inclusive) or 1938 higher; 1940 o the sender has sent a commitment to the new key chain of index j+2 1941 (Section 3.1.2.3). This situation requires that the receiver has 1942 received a packet containing such a commitment and that he has 1943 been able to check its integrity. In some cases it might require 1944 to receive a bootstrap information message for the current key 1945 chain. 1947 If one of the above two tests succeeds, the sender can discard all 1948 the awaiting packets since there is no way to authenticate them. 1950 5. Integration in the ALC and NORM Protocols 1952 5.1. Authentication Header Extension Format 1954 The integration of TESLA in ALC or NORM is similar and relies on the 1955 header extension mechanism defined in both protocols. More precisely 1956 this document details the EXT_AUTH==1 header extension defined in 1957 [RFC5651]. 1959 Several fields are added in addition to the HET (Header Extension 1960 Type) and HEL (Header Extension Length) fields (Figure 9). 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | HET (=1) | HEL | ASID | Type | | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1967 | | 1968 ~ ~ 1969 | Content | 1970 ~ ~ 1971 | | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 Figure 9: Format of the TESLA EXT_AUTH header extension. 1976 The fields of the TESLA EXT_AUTH header extension are: 1978 "ASID" (Authentication Scheme IDentifier) field (4 bits): 1980 The "ASID" identifies the source authentication scheme or protocol 1981 in use. The association between the "ASID" value and the actual 1982 authentication scheme is defined out-of-band, at session startup. 1984 "Type" field (4 bits): 1986 The "Type" field identifies the type of TESLA information carried 1987 in this header extension. This specification defines the 1988 following types: 1990 * 0: Bootstrap Information, sent by the sender periodically or 1991 after a direct time synchronization request; 1993 * 1: Standard Authentication Tag for the on-going key chain, sent 1994 by the sender along with a packet; 1996 * 2: Authentication Tag Without Key Disclosure, sent by the 1997 sender along with a packet; 1999 * 3: Authentication Tag with a New Key Chain Commitment, sent by 2000 the sender when approaching the end of a key chain; 2002 * 4: Authentication Tag with a Last Key of Old Chain Disclosure, 2003 sent by the sender some time after moving to a new key chain; 2005 * 5: Direct Time Synchronization Request, sent by a NORM 2006 receiver. This type of message is invalid in case of an ALC 2007 session since ALC is restricted to unidirectional 2008 transmissions. Yet an external mechanism may provide the 2009 direct time synchronization functionality; 2011 * 6: Direct Time Synchronization Response, sent by a NORM sender. 2012 This type of message is invalid in case of an ALC session since 2013 ALC is restricted to unidirectional transmissions. Yet an 2014 external mechanism may provide the direct time synchronization 2015 functionality; 2017 "Content" field (variable length): 2019 This is the TESLA information carried in the header extension, 2020 whose type is given by the "Type" field. 2022 5.2. Use of Authentication Header Extensions 2024 Each packet sent by the session's sender MUST contain exactly one 2025 TESLA EXT_AUTH header extension. 2027 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 2028 its content, for instance because they do not support TESLA. In that 2029 case these receivers MUST ignore the TESLA EXT_AUTH extensions. In 2030 case of NORM, the packets sent by receivers MAY contain a direct 2031 synchronization request but MUST NOT contain any of the other five 2032 TESLA EXT_AUTH header extensions. 2034 5.2.1. EXT_AUTH Header Extension of Type Bootstrap Information 2036 The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in 2037 a stand-alone control packet, rather than in a packet containing 2038 application data. The reason for that is the large size of this 2039 bootstrap information. By using stand-alone packets, the maximum 2040 payload size of data packets is only affected by the (mandatory) 2041 authentication information header extension. 2043 With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in 2044 a control packet, i.e., containing no encoding symbol. 2046 With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in 2047 a NORM_CMD(APPLICATION) message. 2049 0 1 2 3 2050 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 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2052 | HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^ 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2054 | d | 2 | 2 | 2 | | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2056 | 1 | 3 | 128 | | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2058 | 0 (reserved) | T_int | | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2060 | | | 2061 + T_0 (NTP timestamp format) + | 5 2062 | | | 2 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2064 | N (Key Chain Length) | | b 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y 2066 | Current Interval Index i | | t 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e 2068 | | | s 2069 + + | 2070 | | | 2071 + Current Key Chain Commitment + | 2072 | (20 bytes) | | 2073 + + | 2074 | | | 2075 + + | 2076 | | v 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2078 | | ^ 1 2079 + + | 2 2080 | | | 8 2081 . . | 2082 . Signature . | b 2083 . (128 bytes) . | y 2084 | | | t 2085 + + | e 2086 | | v s 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2088 | Group MAC | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 Figure 10: Example: Format of the bootstrap information message (Type 2092 0), using SHA-256/1024 bit signatures, the default HMAC-SHA-256 and a 2093 Group MAC. 2095 For instance Figure 10 shows the bootstrap information message when 2096 using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC 2097 functions, along with SHA-256/128 byte (1024 bit) key digital 2098 signatures (which also means that the signature field is 128 byte 2099 long). The TESLA EXT_AUTH header extension is then 184 byte long 2100 (i.e., 46 words of 32 bits). 2102 5.2.2. EXT_AUTH Header Extension of Type Authentication Tag 2104 The four "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, and 4) 2105 MUST be attached to the ALC or NORM packet (data or control packet) 2106 that they protect. 2108 0 1 2 3 2109 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 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | HET (=1) | HEL (=10) | ASID | 1 | Reserved | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | i (Interval Index of K'_i) | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | | 2116 + + 2117 | | 2118 + Disclosed Key K_{i-d} + 2119 | (20 bytes) | 2120 + + 2121 | | 2122 + + 2123 | | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | | 2126 + + 2127 | MAC(K'_i, M) | 2128 + (16 bytes) + 2129 | | 2130 + + 2131 | | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Figure 11: Example: Format of the Standard Authentication Tag (Type 2135 1), using the default HMAC-SHA-256. 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | HET (=1) | HEL (=5) | ASID | 2 | Reserved | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | i (Interval Index of K'_i) | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | | 2145 + + 2146 | MAC(K'_i, M) | 2147 + (16 bytes) + 2148 | | 2149 + + 2150 | | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 Figure 12: Example: Format of the Authentication Tag Without Key 2154 Disclosure (Type 2), using the default HMAC-SHA-256. 2156 For instance, Figure 11 and Figure 12 show the format of the 2157 authentication tags, respectively with and without the K_{i-d} key 2158 disclosure, when using the (default) HMAC-SHA-256 transform for the 2159 PRF and MAC functions. In this example, the Group MAC feature is not 2160 used. 2162 5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization 2163 Request 2165 With NORM, the "direct time synchronization request" TESLA EXT_AUTH 2166 (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM 2167 packet. 2169 With ALC, the "direct time synchronization request" TESLA EXT_AUTH 2170 cannot be included in an ALC packet, since ALC is restricted to 2171 unidirectional transmissions, from the session's sender to the 2172 receivers. An external mechanism must be used with ALC for carrying 2173 direct time synchronization requests to the session's sender. 2175 In case of direct time synchronization, it is RECOMMENDED that the 2176 receivers spread the transmission of direct time synchronization 2177 requests over the time (Section 2.3.1). 2179 5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization 2180 Response 2182 With NORM, the "direct time synchronization response" TESLA EXT_AUTH 2183 (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION) 2184 message. 2186 With ALC, the "direct time synchronization response" TESLA EXT_AUTH 2187 can be sent in an ALC control packet (i.e., containing no encoding 2188 symbol) or through the external mechanism use to carry the direct 2189 time synchronization request. 2191 6. Security Considerations 2193 [RFC4082] discusses the security of TESLA in general. These 2194 considerations apply to the present specification, namely: 2196 o great care must be taken to the timing aspects. In particular the 2197 D_t parameter is critical and must be correctly initialized; 2199 o if the sender realizes that the key disclosure schedule is not 2200 appropriate, then the current session MUST be closed and a new one 2201 created. Indeed Section 3.1.3 requires that these parameters be 2202 fixed during the whole session. 2204 o when the verifier that authenticates the incoming packets and the 2205 application that uses the data are two different components, there 2206 is a risk that an attacker located between these components inject 2207 faked data. Similarly, when the verifier and the secure timing 2208 system are two different components, there is a risk that an 2209 attacker located between these components inject faked timing 2210 information. For instance, when the verifier reads the local time 2211 by means of a dedicated system call (e.g., gettimeofday()), if an 2212 attacker controls the host, he may catch the system call and 2213 return a faked time information. 2215 The current specification discusses additional aspects with more 2216 details. 2218 6.1. Dealing With DoS Attacks 2220 TESLA introduces new opportunities for an attacker to mount DoS 2221 attacks. For instance an attacker can try to saturate the processing 2222 capabilities of the receiver (faked packets are easy to create but 2223 checking them requires to compute a MAC over the packet or sometimes 2224 check a digital signature as with the bootstrap and direct time 2225 synchronization response messages). An attacker can also try to 2226 saturate the receiver's memory (since authentication is delayed and 2227 non-authenticated packets will accumulate), or to make the receiver 2228 believe that a congestion has happened (since congestion control MUST 2229 be performed before authenticating incoming packets, Section 4.3). 2231 In order to mitigate these attacks, it is RECOMMENDED to use the 2232 Group MAC scheme (Section 3.3.3). No mitigation is possible if a 2233 group member acts as an attacker with Group MAC. 2235 Generally, it is RECOMMENDED that the amount of memory used to store 2236 incoming packets waiting to be authenticated be limited to a 2237 reasonable value. 2239 6.2. Dealing With Replay Attacks 2241 Replay attacks, whereby an attacker stores a valid message and 2242 replays it later on, can have significant impacts, depending on the 2243 message type. Two levels of impacts must be distinguished: 2245 o within the TESLA protocol, and 2247 o within the ALC or NORM protocol. 2249 6.2.1. Impacts of Replay Attacks on TESLA 2251 Replay attacks can impact the TESLA component itself. We review here 2252 the potential impacts of such an attack depending on the TESLA 2253 message type: 2255 o bootstrap information: since most parameters contained in a 2256 bootstrap information message are static, replay attacks have no 2257 consequences. The fact that the "i" and "K_i" fields can be 2258 updated in subsequent bootstrap information messages does not 2259 create a problem either, since all "i" and "K_i" fields sent 2260 remain valid. Finally, a receiver that successfully initialized 2261 its TESLA component MUST ignore the following messages (see 2262 Section 4.2.1 for an exception to this rule), which voids replay 2263 attacks, unless he missed all the commitments to a new key chain 2264 (e.g., after a long disconnection) (Section 3.2.1). 2266 o direct time synchronization request: If the Group MAC scheme is 2267 used, an attacker that is not a member of the group can replay a 2268 packet and oblige the sender to respond, which requires to 2269 digitally sign the response, a time-consuming process. If the 2270 Group MAC scheme is not used, an attacker can anyway easily forge 2271 a request. In both cases, the attack will not compromise the 2272 TESLA component, but might create a DoS. If this is a concern, it 2273 is RECOMMENDED, when the Group MAC scheme is used, that the sender 2274 verify the "t_r" NTP timestamp contained in the request and 2275 respond only if this value is strictly larger than the previous 2276 one received from this receiver. When the Group MAC scheme is not 2277 used, this attack can be mitigated by limiting the number of 2278 requests per second that will be processed. 2280 o direct time synchronization response: Upon receiving a response, a 2281 receiver who has no pending request MUST immediately drop the 2282 packet. If this receiver has previously issued a request, he 2283 first checks the Group MAC (if applicable), then the "t_r" field, 2284 to be sure it is a response to his request, and finally the 2285 digital signature. A replayed packet will be dropped during these 2286 verifications, without compromising the TESLA component. 2288 o other messages, containing an authentication tag: Replaying a 2289 packet containing a TESLA authentication tag will never compromise 2290 the TESLA component itself (but perhaps the underlying ALC or NORM 2291 component, see below). 2293 To conclude, TESLA itself is robust in front of replay attacks. 2295 6.2.2. Impacts of Replay Attacks on NORM 2297 We review here the potential impacts of a replay attack on the NORM 2298 component. Note that we do not consider here the protocols that 2299 could be used along with NORM, for instance the congestion control 2300 protocols. 2302 First, let us consider replay attacks within a given NORM session. 2303 NORM defines a "sequence" field that can be used to protect against 2304 replay attacks [RMT-PI-NORM] within a given NORM session. This 2305 "sequence" field is a 16-bit value that is set by the message 2306 originator (sender or receiver) as a monotonically increasing number 2307 incremented with each NORM message transmitted. It is RECOMMENDED 2308 that a receiver check this sequence field and drop messages 2309 considered as replayed. Similarly, it is RECOMMENDED that a sender 2310 check this sequence, for each known receiver, and drop messages 2311 considered as replayed. In both cases, checking this sequence field 2312 SHOULD be done before TESLA processing of the packet: if the sequence 2313 field has not been corrupted, the replay attack will immediately be 2314 identified, and otherwise the packet will fail the TESLA 2315 authentication test. This analysis shows that NORM itself is robust 2316 in front of replay attacks within the same session. 2318 Now let us consider replay attacks across several NORM sessions. 2319 Since the key chain used in each session MUST differ, a packet 2320 replayed in a subsequent session will be identified as unauthentic. 2321 Therefore NORM is robust in front of replay attacks across different 2322 sessions. 2324 6.2.3. Impacts of Replay Attacks on ALC 2326 We review here the potential impacts of a replay attack on the ALC 2327 component. Note that we do not consider here the protocols that 2328 could be used along with ALC, for instance the layered or wave based 2329 congestion control protocols. 2331 First, let us consider replay attacks within a given ALC session: 2333 o Regular packets containing an authentication tag: a replayed 2334 message containing an encoding symbol will be detected once 2335 authenticated, thanks to the object/block/symbol identifiers, and 2336 will be silently discarded. This kind of replay attack is only 2337 penalizing in terms of memory and processing load, but does not 2338 compromise the ALC behavior. 2340 o Control packets containing an authentication tag: ALC control 2341 packets, by definition, do not include any encoding symbol and 2342 therefore do not include any object/block/symbol identifier that 2343 would enable a receiver to identify duplicates. However, a sender 2344 has a very limited number of reasons to send control packets. 2345 More precisely: 2347 * At the end of the session, a "close session" (A flag) packet is 2348 sent. Replaying this packet has no impact since the receivers 2349 already left. 2351 * Similarly, replaying a packet containing a "close object" (B 2352 flag) has no impact since this object is probably already 2353 marked as closed by the receiver. 2355 This analysis shows that ALC itself is robust in front of replay 2356 attacks within the same session. 2358 Now let us consider replay attacks across several ALC sessions. 2359 Since the key chain used in each session MUST differ, a packet 2360 replayed in a subsequent session will be identified as unauthentic. 2361 Therefore ALC is robust in front of replay attacks across different 2362 sessions. 2364 6.3. Security of the Back Channel 2366 As specified in Section 1.1, this specification does not consider the 2367 packets that may be sent by receivers, for instance NORM's feedback 2368 packets. When a back channel is used, its security is critical to 2369 the global security, and an appropriate security mechanism MUST be 2370 used. [RMT-SIMPLE-AUTH] describes several techniques that can be 2371 used to that purpose. However, the authentication and integrity 2372 verification of the packets sent by receivers on the back channel, if 2373 any, is out of the scope of this document. 2375 7. IANA Considerations 2377 This document requires a IANA registration for the following 2378 attributes. The registries are provided by [RFC4442] under the 2379 "Timed Efficient Stream Loss-tolerant Authentication (TESLA) 2380 Parameters" registry [TESLA-REG]. Following the policies outlined in 2381 [RFC4442], the values in the range up to 240 (including 240) for the 2382 following attributes are assigned after expert review by the MSEC 2383 working group or its designated successor. The values in the range 2384 from 241 to 255 are reserved for private use. 2386 Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations 2387 MUST support HMAC-SHA-256 (default). 2389 +------------------------+-------+ 2390 | PRF name | Value | 2391 +------------------------+-------+ 2392 | HMAC-SHA-1 | 0 | 2393 | | | 2394 | HMAC-SHA-224 | 1 | 2395 | | | 2396 | HMAC-SHA-256 (default) | 2 | 2397 | | | 2398 | HMAC-SHA-384 | 3 | 2399 | | | 2400 | HMAC-SHA-512 | 4 | 2401 +------------------------+-------+ 2403 Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC: 2404 All implementations MUST support HMAC-SHA-256 (default). These MAC 2405 schemes are used both for the computing of regular MAC and the Group 2406 MAC (if applicable). 2408 +------------------------+-------+ 2409 | MAC name | Value | 2410 +------------------------+-------+ 2411 | HMAC-SHA-1 | 0 | 2412 | | | 2413 | HMAC-SHA-224 | 1 | 2414 | | | 2415 | HMAC-SHA-256 (default) | 2 | 2416 | | | 2417 | HMAC-SHA-384 | 3 | 2418 | | | 2419 | HMAC-SHA-512 | 4 | 2420 +------------------------+-------+ 2422 Furthermore, this document requires IANA to create two new 2423 registries. Here also, the values in the range up to 240 (including 2424 240) for the following attributes are assigned after expert review by 2425 the MSEC working group or its designated successor. The values in 2426 the range from 241 to 255 are reserved for private use. 2428 Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations 2429 MUST support RSASSA-PKCS1-v1_5 (default). 2431 +-----------------------------+-------+ 2432 | Signature Algorithm Name | Value | 2433 +-----------------------------+-------+ 2434 | INVALID | 0 | 2435 | | | 2436 | RSASSA-PKCS1-v1_5 (default) | 1 | 2437 | | | 2438 | RSASSA-PSS | 2 | 2439 +-----------------------------+-------+ 2441 Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All 2442 implementations MUST support SHA-256 (default). 2444 +-----------------------------+-------+ 2445 | Cryptographic Function Name | Value | 2446 +-----------------------------+-------+ 2447 | INVALID | 0 | 2448 | | | 2449 | SHA-1 | 1 | 2450 | | | 2451 | SHA-224 | 2 | 2452 | | | 2453 | SHA-256 (default) | 3 | 2454 | | | 2455 | SHA-384 | 4 | 2456 | | | 2457 | SHA-512 | 5 | 2458 +-----------------------------+-------+ 2460 8. Acknowledgments 2462 The authors are grateful to Yaron Sheffer, Brian Weis, Ramu 2463 Panayappan, Ran Canetti, David L. Mills, Brian Adamson and Lionel 2464 Giraud for their valuable comments while preparing this document. 2465 The authors are also grateful to Brian Weis for the digital signature 2466 details. 2468 9. References 2470 9.1. Normative References 2472 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2473 Specification, Implementation", RFC 1305, March 1992. 2475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2476 Requirement Levels", RFC 2119, BCP 14, March 1997. 2478 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 2479 Briscoe, "Timed Efficient Stream Loss-Tolerant 2480 Authentication (TESLA): Multicast Source Authentication 2481 Transform Introduction", RFC 4082, June 2005. 2483 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 2484 Transport (LCT) Building Block", RFC 5651, October 2009. 2486 [RMT-PI-ALC] 2487 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2488 Layered Coding (ALC) Protocol Instantiation", 2489 draft-ietf-rmt-pi-alc-revised-09.txt (work in progress), 2490 October 2009. 2492 [RMT-PI-NORM] 2493 Adamson, B., Bormann, C., Handley, M., and J. Macker, 2494 "Negative-acknowledgment (NACK)-Oriented Reliable 2495 Multicast (NORM) Protocol", 2496 draft-ietf-rmt-pi-norm-revised-14.txt (work in progress), 2497 September 2009. 2499 [TESLA-REG] 2500 "TESLA Parameters IANA Registry", 2501 http://www.iana.org/assignments/tesla-parameters/. 2503 9.2. Informative References 2505 [NTP-NTPv4] 2506 Burbank, J., Kasch, W., Martin, J., and D. Mills, "The 2507 Network Time Protocol Version 4 Protocol Specification", 2508 draft-ietf-ntp-ntpv4-proto-11.txt (work in progress), 2509 September 2008. 2511 [Perrig04] 2512 Perrig, A. and J. Tygar, "Secure Broadcast Communication 2513 in Wired and Wireless Networks", Kluwer Academic 2514 Publishers ISBN 0-7923-7650-1, 2004. 2516 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2517 Hashing for Message Authentication", RFC 2104, 2518 February 1997. 2520 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2521 Standards (PKCS) #1: RSA Cryptography Specifications 2522 Version 2.1", RFC 3447, February 2003. 2524 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2525 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2526 RFC 3711, March 2004. 2528 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 2529 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 2531 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 2532 Encapsulating Security Payload (ESP) and Authentication 2533 Header (AH)", RFC 4359, January 2006. 2535 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 2536 Stream Loss-Tolerant Authentication (TESLA) in the Secure 2537 Real-time Transport Protocol (SRTP)", RFC 4383, 2538 February 2006. 2540 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed 2541 Efficient Stream Loss-Tolerant Authentication (TESLA)", 2542 RFC 4442, March 2006. 2544 [RMT-FLUTE] 2545 Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, 2546 "FLUTE - File Delivery over Unidirectional Transport", 2547 draft-ietf-rmt-flute-revised-07.txt (work in progress), 2548 August 2009. 2550 [RMT-SIMPLE-AUTH] 2551 Roca, V., "Simple Authentication Schemes for the ALC and 2552 NORM Protocols", 2553 draft-ietf-rmt-simple-auth-for-alc-norm-02.txt (work in 2554 progress), October 2009. 2556 Authors' Addresses 2558 Vincent Roca 2559 INRIA 2560 655, av. de l'Europe 2561 Inovallee; Montbonnot 2562 ST ISMIER cedex 38334 2563 France 2565 Email: vincent.roca@inria.fr 2566 URI: http://planete.inrialpes.fr/~roca/ 2568 Aurelien Francillon 2569 INRIA 2570 655, av. de l'Europe 2571 Inovallee; Montbonnot 2572 ST ISMIER cedex 38334 2573 France 2575 Email: aurelien.francillon@inria.fr 2576 URI: http://planete.inrialpes.fr/~francill/ 2578 Sebastien Faurite 2579 INRIA 2580 655, av. de l'Europe 2581 Inovallee; Montbonnot 2582 ST ISMIER cedex 38334 2583 France 2585 Email: faurite@lcpc.fr