idnits 2.17.1 draft-ietf-msec-tesla-for-alc-norm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2579. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2008) is 5742 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-07 == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-05 == Outdated reference: A later version (-14) exists of draft-ietf-rmt-pi-norm-revised-06 == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-09 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- 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-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 10 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: January 31, 2009 INRIA 6 July 30, 2008 8 Use of TESLA in the ALC and NORM Protocols 9 draft-ietf-msec-tesla-for-alc-norm-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 31, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document details the TESLA packet source authentication and 43 packet integrity verification protocol and its integration within the 44 ALC and NORM content delivery protocols. This document only 45 considers the authentication/integrity verification of the packets 46 generated by the session's sender. The authentication and integrity 47 verification of the packets sent by receivers, if any, is out of the 48 scope of this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Conventions Used in this Document . . . . . . . . . . . . 5 54 1.2. Terminology and Notations . . . . . . . . . . . . . . . . 5 55 1.2.1. Notations and Definitions Related to Cryptographic 56 Functions . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2.2. Notations and Definitions Related to Time . . . . . . 6 58 2. Using TESLA with ALC and NORM: General Operations . . . . . . 8 59 2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 8 60 2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 9 61 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 9 62 2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 9 63 2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 10 64 2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 10 65 2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 11 66 2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 12 67 2.4.1. Delay Bound Calculation in Direct Time 68 Synchronization Mode . . . . . . . . . . . . . . . . . 12 69 2.4.2. Delay Bound Calculation in Indirect time 70 Synchronization Mode . . . . . . . . . . . . . . . . . 13 71 3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 14 72 3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 14 73 3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 14 74 3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 14 75 3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 17 76 3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 18 77 3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 18 78 3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 18 79 3.2.2. Direct Time Synchronization Response . . . . . . . . . 19 80 3.3. TESLA Authentication Information . . . . . . . . . . . . . 20 81 3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 20 82 3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 21 83 3.3.3. Weak Group MAC Tags . . . . . . . . . . . . . . . . . 22 84 3.4. Format of TESLA Messages and Authentication Tags . . . . . 23 85 3.4.1. Format of a Bootstrap Information Message . . . . . . 23 86 3.4.2. Format of a Direct Time Synchronization Response . . . 29 87 3.4.3. Format of a Standard Authentication Tag . . . . . . . 30 88 3.4.4. Format of a Standard Authentication Tag Without 89 Key Disclosure . . . . . . . . . . . . . . . . . . . . 31 90 3.4.5. Format of an Authentication Tag with a ``New Key 91 Chain'' Commitment . . . . . . . . . . . . . . . . . . 32 92 3.4.6. Format of an Authentication Tag with a ``Last Key 93 of Old Chain'' Disclosure . . . . . . . . . . . . . . 33 94 3.4.7. Format of the Compact Authentication Tags . . . . . . 34 95 4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 38 96 4.1. Verification of the Authentication Information . . . . . . 38 97 4.1.1. Processing the Weak Group MAC Tag . . . . . . . . . . 38 98 4.1.2. Processing the Digital Signature . . . . . . . . . . . 38 99 4.1.3. Processing the Authentication Tag . . . . . . . . . . 39 100 4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 39 101 4.2.1. Processing the Bootstrap Information Message . . . . . 39 102 4.2.2. Performing Time Synchronization . . . . . . . . . . . 40 103 4.3. Authentication of Received Packets . . . . . . . . . . . . 41 104 4.4. Flushing the Non Authenticated Packets of a Previous 105 Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 44 106 5. Integration in the ALC and NORM Protocols . . . . . . . . . . 46 107 5.1. Authentication Header Extension Format . . . . . . . . . . 46 108 5.2. Use of Authentication Header Extensions . . . . . . . . . 48 109 5.2.1. EXT_AUTH Header Extension of Type Bootstrap 110 Information . . . . . . . . . . . . . . . . . . . . . 48 111 5.2.2. EXT_AUTH Header Extension of Type Authentication 112 Tag . . . . . . . . . . . . . . . . . . . . . . . . . 50 113 5.2.3. EXT_AUTH Header Extension of Type Direct Time 114 Synchronization Request . . . . . . . . . . . . . . . 51 115 5.2.4. EXT_AUTH Header Extension of Type Direct Time 116 Synchronization Response . . . . . . . . . . . . . . . 51 117 6. Security Considerations . . . . . . . . . . . . . . . . . . . 53 118 6.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 53 119 6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 54 120 6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 54 121 6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 55 122 6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 55 123 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 124 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 125 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 126 9.1. Normative References . . . . . . . . . . . . . . . . . . . 60 127 9.2. Informative References . . . . . . . . . . . . . . . . . . 60 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 129 Intellectual Property and Copyright Statements . . . . . . . . . . 63 131 1. Introduction 133 Many applications using multicast and broadcast communications 134 require that each receiver be able to authenticate the source of any 135 packet it receives as well as the integrity of these packets. This 136 is the case with ALC [RMT-PI-ALC] and NORM [RMT-PI-NORM], two Content 137 Delivery Protocols (CDP) designed to transfer reliably objects (e.g., 138 files) between a session's sender and several receivers. The NORM 139 protocol is based on bidirectional transmissions. Each receiver 140 acknowledges data received or, in case of packet erasures, asks for 141 retransmissions. On the opposite, the ALC protocol is based on 142 purely unidirectional transmissions. Reliability is achieved by 143 means of the cyclic transmission of the content within a carousel 144 and/or by the use of proactive Forward Error Correction codes (FEC). 145 Both protocols have in common the fact that they operate at 146 application level, on top of an erasure channel (e.g., the Internet) 147 where packets can be lost (erased) during the transmission. 149 The goal of this document is to counter attacks where an attacker 150 impersonates the ALC or NORM session's sender and injects forged 151 packets to the receivers, thereby corrupting the objects 152 reconstructed by the receivers. 154 Preventing this attack is much more complex in case of group 155 communications than it is with unicast communications. Indeed, with 156 unicast communications a simple solution exists: the sender and the 157 receiver share a secret key to compute a Message Authentication Code 158 (MAC) of all messages exchanged. This is no longer feasible in case 159 of multicast and broadcast communications since sharing a group key 160 between the sender and all receivers implies that any group member 161 can impersonate the sender and send forged messages to other 162 receivers. 164 The usual solution to provide the source authentication and message 165 integrity services in case of multicast and broadcast communications 166 consists in relying on asymmetric cryptography and using digital 167 signatures. Yet this solution is limited by high computational costs 168 and high transmission overheads. The Timed Efficient Stream Loss- 169 tolerant Authentication protocol (TESLA) is an alternative solution 170 that provides the two required services, while being compatible with 171 high rate transmissions over lossy channels. 173 This document explains how to integrate the TESLA source 174 authentication and packet integrity protocol to the ALC and NORM CDP. 175 Any application built on top of ALC and NORM will directly benefit 176 from the services offered by TESLA at the transport layer. In 177 particular, this is the case of FLUTE [RMT-FLUTE]. 179 This specification only considers the authentication/integrity of the 180 packets generated by the session's sender. This specification does 181 not consider the packets that may be sent by receivers, for instance 182 NORM's feedback packets. Adding authentication/integrity to the 183 packets sent by receivers is out of the scope of this document. 185 For more information on the TESLA protocol and its principles, please 186 refer to [RFC4082][Perrig04]. For more information on ALC and NORM, 187 please refer to [RMT-PI-ALC], [RMT-BB-LCT] and [RMT-PI-NORM] 188 respectively. 190 1.1. Conventions Used in this Document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 1.2. Terminology and Notations 198 The following notations and definitions are used throughout this 199 document. 201 1.2.1. Notations and Definitions Related to Cryptographic Functions 203 Notations and definitions related to cryptographic functions 204 [RFC4082][RFC4383]: 206 o PRF is the Pseudo Random Function; 208 o MAC is the Message Authentication Code; 210 o HMAC is the Keyed-Hash Message Authentication Code; 212 o F is the one-way function used to create the key chain; 214 o F' is the one-way function used to derive the HMAC keys; 216 o n_p is the length, in bits, of the F function's output. This is 217 therefore the length of the keys in the key chain; 219 o n_f is the length, in bits, of the F' function's output. This is 220 therefore the length of the HMAC keys; 222 o n_m is the length, in bits, of the truncated output of the MAC 223 [RFC2104]. Only the n_m most significant bits of the MAC output 224 are kept; 226 o N is the length of a key chain. There are N+1 keys in a key 227 chain: K_0, K_1, .. K_N. When several chains are used, all the 228 chains MUST have the same length and keys are numbered 229 consecutively, following the time interval numbering; 231 o n_c is the number of keys in a key chain. Therefore: n_c = N+1; 233 o n_tx_lastkey is the number of additional intervals during which 234 the last key of the old key chain SHOULD be sent, after switching 235 to a new key chain and after waiting for the disclosure delay d. 236 These extra transmissions take place after the interval during 237 which the last key is normally disclosed. The n_tx_lastkey value 238 is either 0 (no extra disclosure) or larger. This parameter is 239 sender specific and is not communicated to the receiver; 241 o n_tx_newkcc is the number of intervals during which the commitment 242 to a new key chain SHOULD be sent, before switching to the new key 243 chain. The n_tx_newkcc value is either 0 (no commitment sent 244 within authentication tags) or larger. This parameter is sender 245 specific and is not communicated to the receiver; 247 o K_g is a shared group key, communicated to all group members, 248 confidentially, before starting the session. The mechanism by 249 which this group key is shared by the group members is out of the 250 scope of this document; 252 o n_w is the length, in bits, of the truncated output of the MAC of 253 the optional weak group authentication scheme: only the n_w most 254 significant bits of the MAC output are kept. n_w is typically 255 small, multiple of 32 bits (e.g., 32 bits); 257 1.2.2. Notations and Definitions Related to Time 259 Notations and definitions related to time: 261 o i is the time interval index. Interval numbering starts at 0 and 262 increases consecutively. Since the interval index is stored as a 263 32 bit unsigned integer, wrapping to 0 might take place in long 264 sessions. 266 o t_s is the sender local time value at some absolute time (NTP 267 timestamp); 269 o t_r is the receiver local time value at the same absolute time 270 (NTP timestamp); 272 o T_0 is the start time corresponding to the beginning of the 273 session (NTP timestamp); 275 o T_int is the interval duration (in milliseconds); 277 o d is the key disclosure delay (in number of intervals); 279 o D_t is the upper bound of the lag of the receiver's clock with 280 respect to the clock of the sender; 282 o S_sr is an estimated bound of the clock drift between the sender 283 and a receiver throughout the duration of the session; 285 o D^O_t is the upper bound of the lag of the sender's clock with 286 respect to the time reference in indirect time synchronization 287 mode; 289 o D^R_t is the upper bound of the lag of the receiver's clock with 290 respect to the time reference in indirect time synchronization 291 mode; 293 o D_err is an upper bound of the time error between all the time 294 references, in indirect time synchronization mode; 296 2. Using TESLA with ALC and NORM: General Operations 298 2.1. ALC and NORM Specificities that Impact TESLA 300 The ALC and NORM protocols have features and requirements that 301 largely impact the way TESLA can be used. 303 In case of ALC: 305 o ALC is massively scalable: nothing in the protocol specification 306 limits the number of receivers that join a session. Therefore an 307 ALC session potentially includes a huge number (e.g., millions or 308 more) of receivers; 310 o ALC can work on top of purely unidirectional transport channels: 311 this is one of the assets of ALC, and examples of unidirectional 312 channels include satellite (even if a back channel might exist in 313 some use cases) and broadcasting networks like DVB-H/SH; 315 o ALC defines an on-demand content delivery model [RMT-PI-ALC] where 316 receivers can arrive at any time, at their own discretion, 317 download the content and leave the session. Other models (e.g., 318 push or streaming) are also defined; 320 o ALC sessions are potentially very long: a session can last several 321 days or months during which the content is continuously 322 transmitted within a carousel. The content can be either static 323 (e.g., a software update) or dynamic (e.g., a web site). 325 Depending on the use case, some of the above features may not apply. 326 For instance ALC can also be used over a bidirectional channel or 327 with a limited number of receivers. 329 In case of NORM: 331 o NORM has been designed for medium size sessions: indeed, NORM 332 relies on feedback messages and the sender may collapse if the 333 feedback message rate is too high; 335 o NORM requires a bidirectional transport channel: the back channel 336 is not necessarily a high data rate channel since the control 337 traffic sent over it by a single receiver is an order of magnitude 338 lower than the downstream traffic. Networks with an asymmetric 339 connectivity (e.g., a high rate satellite downlink and a low-rate 340 RTC based return channel) are appropriate; 342 2.2. Bootstrapping TESLA 344 In order to initialize the TESLA component at a receiver, the sender 345 MUST communicate some key information in a secure way, so that the 346 receiver can check the source of the information and its integrity. 347 Two general methods are possible: 349 o by using an out-of-band mechanism, or 351 o by using an in-band mechanism. 353 The current specification does not recommend any mechanism to 354 bootstrap TESLA. Choosing between an in-band and out-of-band scheme 355 is left to the implementer, depending on the target use-case. 357 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism 359 For instance [RFC4442] describes the use of the MIKEY (Multimedia 360 Internet Keying) protocol to bootstrap TESLA. As a side effect, 361 MIKEY also provides a loose time synchronization feature, that TESLA 362 can benefit. Other solutions, for instance based on an extended 363 session description, are possible, on condition these solutions 364 provide the required security level. 366 2.2.2. Bootstrapping TESLA with an In-Band Mechanism 368 This specification describes an in-band mechanism. In some use- 369 cases, it might be desired that bootstrap take place without 370 requiring the use of an additional external mechanism. For instance 371 each device may feature a clock with a known time-drift that is 372 negligible in front of the time accuracy required by TESLA, and each 373 device may embed the public key of the sender. It is also possible 374 that the use-case does not feature a bidirectional channel which 375 prevents the use of out-of-band protocols like MIKEY. For these two 376 examples, the exchange of a bootstrap information message (described 377 in Section 3.4.1) and the knowledge of a few additional parameters 378 (listed below) are sufficient to bootstrap TESLA at a receiver. 380 Some parameters cannot be communicated in-band. In particular: 382 o the sender or group controller MUST either communicate the public 383 key of the sender or a certificate (which also means that a PKI 384 has been setup) to all receivers, so that each receiver be able to 385 verify the signature of the bootstrap message and direct time 386 synchronization response messages (when applicable). 388 o when time synchronization is performed with (S)NTP, the sender or 389 group controller MUST communicate the list of valid (S)NTP servers 390 to all the session members (sender included), so that they all be 391 able to synchronize themselves on the same (S)NTP servers. 393 o when the Weak Group MAC feature is used, the sender or group 394 controller MUST communicate the K_g group key to all the session 395 members (sender included). This group key may be periodically 396 refreshed. 398 The way these parameters are communicated is out of the scope of this 399 document. 401 2.3. Setting Up a Secure Time Synchronization 403 The security offered by TESLA heavily relies on time. Therefore the 404 session's sender and each receiver need to be time synchronized in a 405 secure way. To that purpose, two general methods exist: 407 o direct time synchronization, and 409 o indirect time synchronization. 411 It is also possible that a given session include receivers that use 412 the direct time synchronization mode while others use the indirect 413 time synchronization mode. 415 2.3.1. Direct Time Synchronization 417 When direct time synchronization is used, each receiver asks the 418 sender for a time synchronization. To that purpose, a receiver sends 419 a "Direct Time Synchronization Request" (Section 4.2.2.1). The 420 sender then directly answers to each request with a "Direct Time 421 Synchronization Response" (Section 3.4.2), signing this reply. Upon 422 receiving this response, a receiver first verifies the signature, and 423 then calculates an upper bound of the lag of his clock with respect 424 to the clock of the sender, D_t. The details on how to calculate D_t 425 are given in Section 2.4.1. 427 This synchronization method is both simple and secure. Yet there are 428 two potential issues: 430 o a bidirectional channel must exist between the sender and each 431 receiver, and 433 o the sender may collapse if the incoming request rate is too high. 435 Relying on direct time synchronization is not expected to be an issue 436 with NORM since (1) bidirectional communications already take place, 437 and (2) NORM scalability is anyway limited. Yet it can be required 438 that a mechanism, that is out of the scope of this document, be used 439 to spread the transmission of "Direct time synchronization request" 440 messages over the time if there is a risk that the sender may 441 collapse. 443 But direct time synchronization is potentially incompatible with ALC 444 since (1) there might not be a back channel and (2) there are 445 potentially a huge number of receivers and therefore a risk that the 446 sender collapses. 448 2.3.2. Indirect Time Synchronization 450 When indirect time synchronization is used, the sender and each 451 receiver must synchronize securely via an external time reference. 452 Several possibilities exist: 454 o sender and receivers can synchronize through a NTPv3 (Network Time 455 Protocol version 3) [RFC1305] hierarchy of servers. The 456 authentication mechanism of NTPv3 MUST be used in order to 457 authenticate each NTP message individually. It prevents for 458 instance an attacker to impersonate a NTP server; 460 o they can synchronize through a NTPv4 (Network Time Protocol 461 version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security 462 protocol of NTPv4 MUST be used in order to authenticate each NTP 463 message individually; 465 o they can synchronize through a SNTPv4 (Simple Network Time 466 Protocol version 4) [RFC4330] hierarchy of servers. The 467 authentication features of SNTPv4 must then be used. Note that 468 TESLA only needs a loose (but secure) time synchronization, which 469 is in line with the time synchronization service offered by SNTP; 471 o they can synchronize through a GPS or Galileo (or similar) device 472 that also provides a high precision time reference. This time 473 reference is in general trusted, yet depending on the use case, 474 the security achieved will be or not acceptable; 476 o they can synchronize thanks to a dedicated hardware, embedded on 477 each sender and receiver, that provides a clock with a time-drift 478 that is negligible in front of the TESLA time accuracy 479 requirements. This feature enables a device to synchronize its 480 embedded clock with the official time reference from time to time 481 (in an extreme case once, at manufacturing time), and then to 482 remain autonomous for a duration that depends on the known maximum 483 clock drift. 485 A bidirectional channel is required by the NTP/SNTP schemes. On the 486 opposite, with the GPS/Galileo and high precision clock schemes, no 487 such assumption is made. In situations where ALC is used on purely 488 unidirectional transport channels (Section 2.1), using the NTP/SNTP 489 schemes is not possible. Another aspect is the scalability 490 requirement of ALC, and to a lesser extent of NORM. From this point 491 of view, the above mechanisms usually do not raise any problem, 492 unlike the direct time synchronization schemes. Therefore, using 493 indirect time synchronization can be a good choice. 495 The details on how to calculate an upper bound of the lag of a 496 receiver's clock with respect to the clock of the sender, D_t, are 497 given in Section 2.4.2. 499 2.4. Determining the Delay Bounds 501 Let us assume that a secure time synchronization has been set up. 502 This section explains how to define the various timing parameters 503 that are used during the authentication of received packets. 505 2.4.1. Delay Bound Calculation in Direct Time Synchronization Mode 507 In direct time synchronization mode, synchronization between a 508 receiver and the sender follows the following protocol [RFC4082]: 510 o The receiver sends a "Direct Time Synchronization Request" message 511 to the sender, that includes t_r, the receiver local time at the 512 moment of sending (Section 4.2.2.1). 514 o Upon receipt of this message, the sender records its local time, 515 t_s, and sends to the receiver a "Direct Time Synchronization 516 Response" that includes t_r (taken from the request) and t_s 517 (Section 3.4.2), signing this reply. 519 o Upon receiving this response, the receiver first verifies that he 520 actually sent a request with t_r and then checks the signature. 521 Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an 522 estimated bound of the clock drift between the sender and the 523 receiver throughout the duration of the session. This document 524 does not specify how S_sr is estimated. 526 After this initial synchronization, at any point throughout the 527 session, the receiver knows that: T_s < T_r + D_t, where T_s is the 528 current time at the sender and T_r is the current time at the 529 receiver. 531 2.4.2. Delay Bound Calculation in Indirect time Synchronization Mode 533 In indirect time synchronization, the sender and the receivers must 534 synchronize indirectly with one or several time references. 536 2.4.2.1. Single time reference 538 Let us assume that there is a single time reference. 540 1. The sender calculates D^O_t, the upper bound of the lag of the 541 sender's clock with respect to the time reference. This D^O_t 542 value is then be communicated to the receivers (Section 3.2.1). 544 2. Similarly, a receiver R calculates D^R_t, the upper bound of the 545 lag of the receiver's clock with respect to the time reference. 547 3. Then, for receiver R, the overall upper bound of the lag of the 548 receiver's clock with respect to the clock of the sender, D_t, is 549 the sum: D_t = D^O_t + D^R_t. 551 The D^O_t and D^R_t calculation depends on the time synchronization 552 mechanism used (Section 2.3.2). In some cases, the synchronization 553 scheme specifications provide these values. In other cases, these 554 parameters can be calculated by means of a scheme similar to the one 555 specified in Section 2.4.1, for instance when synchronization is 556 achieved via a group controller [RFC4082]. 558 2.4.2.2. Multiple time references 560 Let us now assume that there are several time references (e.g., 561 several (S)NTP servers). The sender and receivers use the direct 562 time synchronization scheme to synchronize with the various time 563 references. It results in D^O_t and D^R_t. Let D_err be an upper 564 bound of the time error between all the time references. Then, the 565 overall value of D_t within receiver R is set to the sum: D_t = D^O_t 566 + D^R_t + D_err. 568 In some cases, the D_t value is part of the time synchronization 569 scheme specifications. For instance NTPv3 [RFC1305] defines 570 algorithms that are "capable of accuracies in the order of a 571 millisecond, even after extended periods when synchronization to 572 primary reference sources has been lost". In practice, depending on 573 the NTP server stratum, the accuracy might be a little bit worse. In 574 that case, D_t = security_factor * (1ms + 1ms), where the 575 security_factor is meant to compensate several sources of inaccuracy 576 in NTP. The choice of the security_factor value is left to the 577 implementer, depending on the target use-case. 579 3. Sender Operations 581 This section describes the TESLA operations at a sender. 583 3.1. TESLA Parameters 585 3.1.1. Time Intervals 587 The sender divides the time into uniform intervals of duration T_int. 588 Time interval numbering starts at 0 and is incremented consecutively. 589 The interval index MUST be stored in an unsigned 32 bit integer so 590 that wrapping to 0 takes place only after 2^^32 intervals. For 591 instance, if T_int is equal to 0.5 seconds, then wrapping takes place 592 after approximately 68 years. 594 3.1.2. Key Chains 596 3.1.2.1. Principles 598 The sender computes a one-way key chain of n_c = N+1 keys, and 599 assigns one key from the chain to each interval, consecutively but in 600 reverse order. Key numbering starts at 0 and is incremented 601 consecutively, following the time interval numbering: K_0, K_1 .. 602 K_N. 604 In order to compute this chain, the sender must first select a 605 Primary Key, K_N, and a PRF function, f. The functions F and F' are 606 two one-way functions that are defined as: F(k)=f_k(0) and 607 F'(k)=f_k(1). The sender computes all the keys of the chain, 608 starting with K_N, using: K_{i-1} = F(K_i). The key for MAC 609 calculation can then be derived from the corresponding K_i key by 610 K'_i=F'(K_i). The randomness of the Primary Key, K_N, is vital to 611 the security and no one should be able to guess it. 613 The key chain has a finite length, N, which corresponds to a maximum 614 time duration of (N + 1) * T_int. The content delivery session has a 615 duration T_delivery, which may either be known in advance, or not. A 616 first solution consists in having a single key chain of an 617 appropriate length, so that the content delivery session finishes 618 before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int. 619 But the longer the key chain, the higher the memory and computation 620 required to cope with it. Another solution consists in switching to 621 a new key chain, of the same length, when necessary (see Figure 1) 622 [Perrig04]. 624 3.1.2.2. Using Multiple Key Chains 626 When several key chains are needed, all of them MUST be of the same 627 length. Switching from the current key chain to the next one 628 requires that a commitment to the new key chain be communicated in a 629 secure way to the receiver. This can be done by using either an out- 630 of-band mechanism, or an in-band mechanism. This document only 631 specifies the in-band mechanism. 633 < -------- old key chain --------- >||< -------- new key chain --... 634 +-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+ 635 0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5 636 || 637 Key disclosures: || 638 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 639 | || | | 640 |< -------------- >|| |< ------------- >| 641 Additional key F(K_N+1) || K_N 642 disclosures (commitment to || (last key of the 643 (in parallel): the new chain) || old chain) 645 Figure 1: Switching to the second key chain with the in-band 646 mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3. 648 Figure 1 illustrates the switch to the new key chain, using the in- 649 band mechanism. Let us say that the old key chain stops at K_N and 650 the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two 651 different keys). Then the sender includes the commitment F(K_{N+1}) 652 to the new key chain to packets authenticated with the old key chain 653 (see Section 3.4.5). This commitment SHOULD be sent during 654 n_tx_newkcc time intervals before the end of the old key chain. 655 Since several packets are usually sent during an interval, the sender 656 SHOULD alternate between sending a disclosed key of the old key chain 657 and the commitment to the new key chain. The details of how to 658 alternate between the disclosure and commitment are out of the scope 659 of this document. 661 The receiver will keep the commitment until the key K_{N+1} is 662 disclosed, at interval N+1+d. Then the receiver will be able to test 663 the validity of that key by computing F(K_{N+1}) and comparing it to 664 the commitment. 666 When the key chain is changed, it becomes impossible to recover a 667 previous key from the old key chain. This is a problem if the 668 receiver lost the packets disclosing the last key of the old key 669 chain. A solution consists in re-sending the last key, K_N, of the 670 old key chain (see Section 3.4.6). This SHOULD be done during 671 n_tx_lastkey additional time intervals after the end of the time 672 interval where K_N is disclosed. Since several packets are usually 673 sent during an interval, the sender SHOULD alternate between sending 674 a disclosed key of the new key chain, and the last key of the old key 675 chain. The details of how to alternate between the two disclosures 676 are out of the scope of this document. 678 In some cases a receiver having experienced a very long disconnection 679 might have lost the commitment of the new chain. Therefore this 680 receiver will not be able to authenticate any packet related to the 681 new chain and all the following ones. The only solution for this 682 receiver to catch up consists in receiving an additional bootstrap 683 information message. This can happen by waiting for the next 684 periodic transmission (in indirect time synchronization mode), by 685 requesting it (in direct time synchronization mode), or through an 686 external mechanism (Section 3.2.1). 688 3.1.2.3. Values of the n_tx_lastkey and n_tx_newkcc Parameters 690 When several key chains and the in-band commitment mechanism are 691 used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc 692 parameters in such a way that no overlapping occur. In other words, 693 once a sender starts transmitting commitments for a new key chain, he 694 MUST NOT send a disclosure for the last key of the old key chain any 695 more. Therefore, the following property MUST be verified: 697 d + n_tx_lastkey + n_tx_newkcc <= N + 1 699 It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey 700 has been chosen, then: 702 n_tx_newkcc = N + 1 - n_tx_lastkey - d 704 In other words, the sender starts transmitting a commitment to the 705 following key chain immediately after having sent all the disclosures 706 of the last key of the previous key chain. Doing so increases the 707 probability that a receiver gets a commitment for the following key 708 chain. 710 In any case, these two parameters are sender specific and need not be 711 transmitted to the receivers. Of course, as explained above, the 712 sender alternates between the disclosure of a key of the current key 713 chain and the commitment to the new key chain (or the last key of the 714 old key chain). 716 3.1.2.4. The Particular Case of the Session Start 718 Since a key cannot be disclosed before the disclosure delay, d, no 719 key will be disclosed during the first d time intervals (intervals 0 720 and 1 in Figure 1) of the session. To that purpose, the sender uses 721 the standard authentication tag without key disclosure Section 3.4.4 722 or its compact flavor. The following key chains, if any, are not 723 concerned since they will disclose the last d keys of the previous 724 chain. 726 3.1.2.5. Managing Silent Periods 728 An ALC or NORM sender may stop transmitting packets for some time. 729 For instance it can be the end of the session and all packets have 730 already been sent, or the use-case may consist in a succession of 731 busy periods (when fresh objects are available) followed by silent 732 periods. In any case, this is an issue since the authentication of 733 the packets sent during the last d intervals requires that the 734 associated keys be disclosed, which will take place during d 735 additional time intervals. 737 To solve this problem, it is recommended that the sender transmit 738 empty packets (i.e., without payload) containing the TESLA EXT_AUTH 739 header extension along with a standard authentication tag (or its 740 compact flavor) during at least d time intervals after the end of the 741 regular ALC or NORM packet transmissions. The number of such packets 742 and the duration during which they are sent must be sufficient for 743 all receivers to receive, with a high probability, at least one 744 packet disclosing the last useful key (i.e., the key used for the 745 last non-empty packet sent). 747 3.1.3. Time Interval Schedule 749 The sender must determine the following parameters: 751 o T_0, the start time corresponding to the beginning of the session; 753 o T_int, the interval duration, usually ranging from 100 754 milliseconds to 1 second; 756 o d, the key disclosure delay (in number of intervals). It is the 757 time to wait before disclosing a key; 759 o N, the length of a key chain; 761 The correct choice of T_int, d, and N is crucial for the efficiency 762 of the scheme. For instance, a T_int * d product that is too long 763 will cause excessive delay in the authentication process. A T_int * 764 d product that is too short prevents many receivers from verifying 765 packets. A N * T_int product that is too small will cause the sender 766 to switch too often to new key chains. A N that is too long with 767 respect to the expected session duration (if known) will require the 768 sender to compute too many useless keys. [RFC4082] sections 3.2 and 769 3.6 give general guidelines for initializing these parameters. 771 The T_0, T_int, d and N parameters MUST NOT be changed during the 772 lifetime of the session. This restriction is meant to prevent 773 introducing vulnerabilities. For instance if a sender was authorized 774 to change the key disclosure schedule, a receiver that did not 775 receive the change notification would still believe in the old key 776 disclosure schedule, thereby creating vulnerabilities [RFC4082]. 778 3.1.4. Timing Parameters 780 In indirect time synchronization mode, the sender must determine the 781 following parameter: 783 o D^O_t, the upper bound of the lag of the sender's clock with 784 respect to the time reference. 786 The D^O_t parameter MUST NOT be changed during the lifetime of the 787 session. 789 3.2. TESLA Signaling Messages 791 At a sender, TESLA produces two types of signaling information: 793 o The bootstrap information: it can be either sent out-of-band or 794 in-band. In the latter case, a digitally signed packet contains 795 all the information required to bootstrap TESLA at a receiver; 797 o The direct time synchronization response, which enables a receiver 798 to finish a direct time synchronization; 800 3.2.1. Bootstrap Information 802 In order to initialize the TESLA component at a receiver, the sender 803 must communicate some key information in a secure way. This 804 information can be sent in-band or out-of-band, as discussed in 805 Section 2.2. In this section we only consider the in-band scheme. 807 The TESLA bootstrap information message MUST be digitally signed 808 (Section 3.3.2). The goal is to enable a receiver to check the 809 packet source and packet integrity. Then, the bootstrap information 810 can be: 812 o unicast to a receiver during a direct time synchronization 813 request/response exchange; 815 o broadcast to all receivers. This is typically the case in 816 indirect time synchronization mode. It can also be used in direct 817 time synchronization mode, for instance when a large number of 818 clients arrive at the same time, in which case it is more 819 efficient to answer globally. 821 Let us consider situations where the bootstrap information is 822 broadcast. This message should be broadcast at the beginning of the 823 session, before data packets are actually sent. This is particularly 824 important with ALC or NORM sessions in ``push'' mode, when all 825 clients join the session in advance. For improved reliability, 826 bootstrap information might be sent a certain number of times. 828 A periodic broadcast of the bootstrap information message could also 829 be useful when: 831 o the ALC session uses an ``on-demand'' mode, clients arriving at 832 their own discretion; 834 o some clients experience an intermittent connectivity. This is 835 particularly important when several key chains are used in an ALC 836 or NORM session, since there is a risk that a receiver loses all 837 the commitments to the new key chain. 839 A balance must be found between the signaling overhead and the 840 maximum initial waiting time at the receiver before starting the 841 delayed authentication process. A period of a few seconds for the 842 transmission of this bootstrap information is often a reasonable 843 value. 845 3.2.2. Direct Time Synchronization Response 847 In Direct Time Synchronization, upon receipt of a synchronization 848 request, the sender records its local time, t_s, and sends a response 849 message that contains both t_r and t_s (Section 2.4.1). This message 850 is unicast to the receiver. This Direct Time Synchronization 851 Response message MUST be digitally signed in order to enable a 852 receiver to check the packet source and packet integrity 853 (Section 3.3.2). The receiver MUST also be able to associate this 854 response and his request, which is the reason why t_r is included in 855 the response message. 857 3.3. TESLA Authentication Information 859 At a sender, TESLA produces three types of security tags: 861 o an authentication tag, in case of a data packets, and which 862 contains the MAC of the packet; 864 o a digital signatures, in case of one of the two TESLA signaling 865 packets, namely a Bootstrap Information Message or a Direct Time 866 Synchronization Response; and 868 o an optional weak group authentication tag, that can be added to 869 all the packets to mitigate attacks coming from outside of the 870 group. 872 Because of interdependencies, their computation MUST follow a strict 873 order: 875 o first of all, compute the authentication tag (with data packet) or 876 the digital signature (with signaling packet); 878 o finally compute the Weak Group Mac; 880 3.3.1. Authentication Tags 882 All the data packets sent MUST have an authentication tag containing: 884 o the interval index, i, which is also the index of the key used for 885 computing the MAC of this packet. With the compact authentication 886 tags, a subset of i will be communicated. In that case, a 887 receiver must guess the original i value from the few bits carried 888 in the packet (Section 4.3); 890 o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i); 892 o either a disclosed key (that belongs to the current key chain or 893 the previous key chain), or a commitment to a new key chain, or no 894 key at all; 896 The computation of MAC(K'_i, M) MUST include the ALC or NORM header 897 (with the various header extensions) and the payload (when 898 applicable). The UDP/IP headers MUST NOT be included. During this 899 computation, the MAC(K'_i, M) field of the authentication tag MUST be 900 set to 0. 902 3.3.2. Digital Signatures 904 The Bootstrap Information message (with the in-band bootstrap scheme) 905 and Direct Time Synchronization Response message (with the indirect 906 time synchronization scheme) both need to be signed by the sender. 907 These two messages contain a "Signature" field to hold the digital 908 signature. The bootstrap information message also contains the 909 "Signature Encoding Algorithm", the "Signature Cryptographic 910 Function", and the "Signature Length" fields that enable a receiver 911 to process the "Signature" field. Note that there is no such 912 "Signature Encoding Algorithm", "Signature Cryptographic Function" 913 and "Signature Length" fields in case of a Direct Time 914 Synchronization Response message since it is assumed that these 915 parameters are already known (i.e., the receiver either received a 916 bootstrap information message before, or these values have been 917 communicated out-of-band). 919 Several "Signature Encoding Algorithms" can be used, including 920 RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With 921 these encodings, SHA-1 is the default "Signature Cryptographic 922 Function". 924 The computation of the signature MUST include the ALC or NORM header 925 (with the various header extensions) and the payload when applicable. 926 The UDP/IP headers MUST NOT be included. During this computation, 927 the "Signature" field MUST be set to 0 as well as the optional Weak 928 Group MAC, when present, since this Weak Group MAC is calculated 929 later on. 931 More specifically, from [RFC4359]: digital signature generation is 932 performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1- 933 v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of 934 the packet is used as the message M, which is passed to the signature 935 generation function. The signer's RSA private key is passed as K. In 936 summary (when SHA-1 is used), the signature generation process 937 computes a SHA-1 hash of the authenticated packet bytes, signs the 938 SHA-1 hash using the private key, and encodes the result with the 939 specified RSA encoding type. This process results in a value S, 940 which is the digital signature to be included in the packet. 942 With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the 943 signature is equal to the "RSA modulus", unless the "RSA modulus" is 944 not a multiple of 8 bits. In that case, the signature MUST be 945 prepended with between 1 and 7 bits set to zero such that the 946 signature is a multiple of 8 bits [RFC4359]. The key size, which in 947 practice is also equal to the "RSA modulus", has major security 948 implications. [RFC4359] explains how to choose this value depending 949 on the maximum expected lifetime of the session. This choice is out 950 of the scope of this document. 952 3.3.3. Weak Group MAC Tags 954 An optional Weak Group MAC can be used to mitigate DoS attacks coming 955 from attackers that are not group member [RFC4082]. This feature 956 assumes that a group key, K_g, is shared by the sender and all 957 receivers. When the attacker is not a group member, the benefits of 958 adding a group MAC to every packet sent are threefold: 960 o a receiver can immediately drop faked packets, without having to 961 wait for the disclosure delay, d; 963 o a sender can immediately drop faked direct time synchronization 964 requests, and avoid to check the digital signature, a computation 965 intensive task; 967 o a receiver can immediately drop faked direct time synchronization 968 response and bootstrap messages, without having to verify the 969 digital signature, a computation intensive task; 971 The computation of the group MAC, MAC(K_g, M), MUST include the ALC 972 or NORM header (with the various header extensions) and the payload 973 when applicable. The UDP/IP headers MUST NOT be included. During 974 this computation, the Weak Group MAC field MUST be set to 0. However 975 the digital signature (e.g., of a bootstrap message) and the MAC 976 fields (e.g., of an authentication tag), when present, MUST have been 977 calculated since they are included in the Weak Group MAC calculation 978 itself. Then the sender truncates the MAC output to keep the n_w 979 most significant bits and stores the result in the Weak Group MAC 980 field. 982 This scheme features a few limits: 984 o it is of no help if a group member (who knows K_g) impersonates 985 the sender and sends forged messages to other receivers; 987 o it requires an additional MAC computing for each packet, both at 988 the sender and receiver sides; 990 o it increases the size of the TESLA authentication headers. In 991 order to limit this problem, the length of the truncated output of 992 the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711] 993 section 9.5). As a side effect, the authentication service is 994 significantly weakened: the probability that any forged packet be 995 successfully authenticated becomes one in 2^32. Since the weak 996 group MAC check is only a pre-check that must be followed by the 997 standard TESLA authentication check, this is not considered to be 998 an issue. 1000 For a given use-case, the benefits brought by the group MAC must be 1001 balanced against these limitations. 1003 Note that the Weak Group MAC function can be different from the TESLA 1004 MAC function (e.g., it can use a weaker but faster MAC function). 1005 Note also that the mechanism by which the group key, K_g, is 1006 communicated to all group members, and perhaps periodically updated, 1007 is out of the scope of this document. 1009 3.4. Format of TESLA Messages and Authentication Tags 1011 This section specifies the format of the various kinds of TESLA 1012 messages and authentication tags sent by the session's sender. 1013 Because these TESLA messages are carried as EXT_AUTH header 1014 extensions of the ALC or NORM packets (Section 5), the following 1015 formats do not start on 32 bit word boundaries. 1017 3.4.1. Format of a Bootstrap Information Message 1019 When bootstrap information is sent in-band, the following message is 1020 used: 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+ --- 1025 | V |resvd|S|W|A| ^ 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1027 | d | PRF Type | MAC Func Type |WG MAC Fun Type| | f 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i 1029 | SigEncAlgo | SigCryptoFunc | Signature Key Length | | x 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e 1031 | Reserved | T_int | | d 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1033 | | | l 1034 + T_0 (NTP timestamp) + | e 1035 | | | n 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g 1037 | N (Key Chain Length) | | t 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h 1039 | Current Interval Index i | v 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1041 | | 1042 ~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+ 1043 | | Padding | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | | 1046 + + 1047 ~ Signature ~ 1048 + +-+-+-+-+-+-+-+-+ 1049 | | Padding | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |P| | 1052 +-+ D^O_t Extension (optional, present if A==1) + 1053 | (NTP timestamp diff, positive if P==1, negative if P==0) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 ~ Weak Group MAC (optional) ~ 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Figure 2: Bootstrap information format. 1060 The format of the bootstrap information is depicted in Figure 2. The 1061 fields are: 1063 "V" (Version) field (2 bits): 1065 The "V" field contains the version number of the protocol. For 1066 this specification, the value of 0 MUST be used. 1068 "Reserved" field (3 bits): 1070 This is a reserved field that MUST be set to zero in this 1071 specification. 1073 "S" (Single Key Chain) flag (1 bits): 1075 The "S" flag indicates whether this TESLA session is restricted to 1076 a single key chain (S==1) or relies on one or multiple key chains 1077 (S==0). 1079 "W" (Weak Group MAC Present) flag (1 bits): 1081 The "W" flag indicates whether the Weak Group MAC feature is used 1082 (W==1) or not (W==0). When it is used, a "Weak Group MAC" field 1083 is added to all the packets containing a TESLA EXT_AUTH Header 1084 Extension (including this bootstrap message). 1086 "A" flag (1 bit): 1088 The "A" flag indicates whether the P flag and D^O_t fields are 1089 present (A==1) or not (A==0). In indirect time synchronization 1090 mode, A MUST be equal to 1 since these fields are needed. 1092 "d" field (8 bits): 1094 d is an unsigned integer that defines the key disclosure delay (in 1095 number of intervals). d MUST be greater or equal to 2. 1097 "PRF Type" field (8 bits): 1099 The "PRF Type" is the reference number of the f function used to 1100 derive the F (for key chain) and F' (for MAC keys) functions 1101 (Section 7). 1103 "MAC Function Type" field (8 bits): 1105 The "MAC Function Type" is the reference number of the function 1106 used to compute the MAC of the packets (Section 7). 1108 "Weak Group MAC Function Type" field (8 bits): 1110 When W==1, this field contains the reference number of the 1111 cryptographic MAC function used to compute the weak group MAC 1112 (Section 7). When W==0, this field MUST be set to zero. 1114 "Signature Encoding Algorithm" field (8 bits): 1116 The "Signature Encoding Algorithm" is the reference number 1117 (Section 7) of the digital signature used to authenticate this 1118 bootstrap information and included in the "Signature" field. 1120 "Signature Cryptographic Function" field (8 bits): 1122 The "Signature Cryptographic Function" is the reference number 1123 (Section 7) of the cryptographic function used within the digital 1124 signature. 1126 "Signature Key Length" field (12 bits): 1128 The "Signature Length" is an unsigned integer that indicates the 1129 signature field size in bytes in the "Signature Extension" field. 1131 "Reserved" fields (16 bits): 1133 This is a reserved field that MUST be set to zero in this 1134 specification. 1136 "T_int" field (16 bits): 1138 T_int is an unsigned 16 bit integer that defines the interval 1139 duration (in milliseconds). 1141 "T_0" field (64 bits): 1143 "T_0" is an NTP timestamp that indicates the time when this 1144 session began. 1146 "N" field (32 bits): 1148 "N" is an unsigned integer that indicates the key chain length. 1149 There are N + 1 keys per chain. 1151 "i" (Interval Index of K_i) field (32 bits): 1153 "i" is an unsigned integer that indicates the current interval 1154 index when this bootstrap information message is sent. 1156 "Current Key Chain Commitment" field (variable size, padded if 1157 necessary for 32 bit word alignment): 1159 "Key Chain Commitment" is the commitment to the current key chain, 1160 i.e., the key chain corresponding to interval i. For instance, 1161 with the first key chain, this commitment is equal to F(K_0), with 1162 the second key chain, this commitment is equal to F(K_{N+1}), 1163 etc.). If need be, this field is padded (with 0) up to a multiple 1164 of 32 bits. 1166 "Signature" field (variable size, padded if necessary for 32 bit word 1167 alignment): 1169 The "Signature" field is mandatory. It contains a digital 1170 signature of this message, as specified by the encoding algorithm, 1171 cryptographic function and key length parameters. If the 1172 signature length is not multiple of 32 bits, this field is padded 1173 with 0. 1175 "P" flag (optional, 1 bit if present): 1177 The "P" flag is optional and only present if the A flag is equal 1178 to 1.. It is only used in indirect time synchronization mode. 1179 This flag indicates whether the D^O_t NTP timestamp difference is 1180 positive (P==1) or negative (P==0). 1182 "D^O_t" field (optional, 63 bits if present): 1184 The "D^O_t" field is optional and only present if the A flag is 1185 equal to 1. It is only used in indirect time synchronization 1186 mode. It is the upper bound of the lag of the sender's clock with 1187 respect to the time reference. When several time references are 1188 specified (e.g., several NTP servers), then D^O_t is the maximum 1189 upper bound of the lag with each time reference. D^O_t is 1190 composed of two unsigned integers, as with NTP timestamps: the 1191 first 31 bits give the time difference in seconds and the 1192 remaining 32 bits give the sub-second time difference. 1194 "Weak Group MAC" field (optional, variable length, multiple of 32 1195 bits): 1197 This field contains the weak group MAC, calculated with the group 1198 key, K_g, shared by all group members. The field length, in bits, 1199 is given by n_w which is known once weak group MAC function type 1200 is known (Section 7). 1202 Note that the first byte and the following seven 32-bit words are 1203 mandatory fixed length fields. The Current Key Chain Commitment and 1204 Signature fields are mandatory but variable length fields. The 1205 remaining D^O_t and Weak Group MAC fields are optional. 1207 In order to prevent attacks, some parameters MUST NOT be changed 1208 during the lifetime of the session (Section 3.1.3, Section 3.1.4). 1209 The following table summarizes the parameters status: 1211 +--------------------------+----------------------------------------+ 1212 | Parameter | Status | 1213 +--------------------------+----------------------------------------+ 1214 | V | set to 0 in this specification | 1215 | | | 1216 | S | static (during whole session) | 1217 | | | 1218 | W | static (during whole session) | 1219 | | | 1220 | A | static (during whole session) | 1221 | | | 1222 | T_O | static (during whole session) | 1223 | | | 1224 | T_int | static (during whole session) | 1225 | | | 1226 | d | static (during whole session) | 1227 | | | 1228 | N | static (during whole session) | 1229 | | | 1230 | D^O_t (if present) | static (during whole session) | 1231 | | | 1232 | PRF Type | static (during whole session) | 1233 | | | 1234 | MAC Function Type | static (during whole session) | 1235 | | | 1236 | Signature Encoding | static (during whole session) | 1237 | Algorithm | | 1238 | | | 1239 | Signature Crypto. | static (during whole session) | 1240 | Function | | 1241 | | | 1242 | Signature Length | static (during whole session) | 1243 | | | 1244 | Weak Group MAC Func. | static (during whole session) | 1245 | Type | | 1246 | | | 1247 | i | dynamic (related to current key chain) | 1248 | | | 1249 | K_i | dynamic (related to current key chain) | 1250 | | | 1251 | signature | dynamic, packet dependent | 1252 | | | 1253 | Weak Group MAC (if | dynamic, packet dependent | 1254 | present) | | 1255 +--------------------------+----------------------------------------+ 1257 3.4.2. Format of a Direct Time Synchronization Response 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+ 1262 | Reserved | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | | 1265 + t_s (NTP timestamp) + 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | | 1269 + t_r (NTP timestamp) + 1270 | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | | 1273 + + 1274 ~ Signature ~ 1275 + +-+-+-+-+-+-+-+-+ 1276 | | Padding | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 ~ Weak Group MAC (optional) ~ 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 Figure 3: Format of a Direct Time Synchronization Response 1283 The response to a direct time synchronization request contains the 1284 following information: 1286 "Reserved" fields (8 bits): 1288 This is a reserved field that MUST be set to zero in this 1289 specification. 1291 "t_s" (NTP timestamp, 64 bits): 1293 t_s is an NTP timestamp that corresponds to the sender local time 1294 value when receiving the direct time synchronization request 1295 message. 1297 "t_r" (NTP timestamp, 64 bits): 1299 t_r is an NTP timestamp that contains the receiver local time 1300 value received in the direct time synchronization request message. 1302 "Signature" field (variable size, padded if necessary for 32 bit word 1303 alignment): 1305 The "Signature" field is mandatory. It contains a digital 1306 signature of this message, as specified by the encoding algorithm, 1307 cryptographic function and key length parameters communicated in 1308 the bootstrap information message (if applicable) or out-of-band. 1309 If the signature length is not multiple of 32 bits, this field is 1310 padded with 0. 1312 "Weak Group MAC" field (optional, variable length, multiple of 32 1313 bits): 1315 This field contains the weak group MAC, calculated with the group 1316 key, K_g, shared by all group members. The field length, in bits, 1317 is given by n_w which is known once weak group MAC function type 1318 is known (Section 7). 1320 3.4.3. Format of a Standard Authentication Tag 1322 0 1 2 3 1323 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 1324 +-+-+-+-+-+-+-+-+ 1325 | Reserved | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | i (Interval Index of K'_i) | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | | 1330 ~ Disclosed Key K_{i-d} ~ 1331 | | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | | 1334 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1335 | | Padding | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 ~ Weak Group MAC (optional) ~ 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Figure 4: Format of the authentication tag 1342 Figure 4 shows the format of the authentication tag: 1344 "Reserved" field (8 bits): 1346 The "Reserved" field is not used in the current specification and 1347 MUST be set to zero by the sender. 1349 "i" (Interval Index) field (32 bits): 1351 i is the interval index associated to the key (K'_i) used to 1352 compute the MAC of this packet. 1354 "Disclosed Key" (variable size, non padded): 1356 The "Disclosed Key" is the key used for interval i-d: K_{i-d}; 1357 Note that during the first d time intervals of a session, this 1358 field must be initialized to "0" since no key can be disclosed 1359 yet. There is no padding between the "Disclosed Key" and 1360 "MAC(K'_i, M)" fields, and this latter MAY not start on a 32 bit 1361 boundary, depending on the n_p parameter. 1363 "MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word 1364 alignment): 1366 MAC(K'_i, M) is the message authentication code of the current 1367 packet. 1369 "Weak Group MAC" field (optional, variable length, multiple of 32 1370 bits): 1372 This field contains the weak group MAC, calculated with a group 1373 key, K_g, shared by all group members. The field length is given 1374 by n_w, in bits. 1376 Note that because a key cannot be disclosed before the disclosure 1377 delay, d, the sender MUST NOT use this tag during the first d 1378 intervals of the session: {0 .. d-1} (inclusive). Instead the sender 1379 MUST use a Standard or a Compact Authentication Tag Without Key 1380 Disclosure. 1382 3.4.4. Format of a Standard Authentication Tag Without Key Disclosure 1384 The authentication tag without key disclosure is meant to be used in 1385 situations where a high number of packets are sent in a given time 1386 interval. In such a case, it can be advantageous to disclose the 1387 K_{i-d} key only in a subset of the packets sent, using a standard 1388 authentication tag, and use the shortened version that does not 1389 disclose the K_{i-d} key in the remaining packets. It is left to the 1390 implementer to decide how many packets should disclose the K_{i-d} 1391 key. This authentication tag or its compact flavor MUST also be used 1392 during the first d intervals: {0 .. d-1} (inclusive). 1394 0 1 2 3 1395 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 1396 +-+-+-+-+-+-+-+-+ 1397 | Reserved | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | i (Interval Index of K'_i) | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | | 1402 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1403 | | Padding | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 ~ Weak Group MAC (optional) ~ 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 Figure 5: Format of the authentication tag without key disclosure 1410 3.4.5. Format of an Authentication Tag with a ``New Key Chain'' 1411 Commitment 1413 During the last n_tx_newkcc intervals of the current key chain, the 1414 sender SHOULD send commitments to the next key chain. This is done 1415 by replacing the disclosed key of the authentication tag with the new 1416 key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch 1417 between the second and third key chains, etc.). Figure 6 shows the 1418 corresponding format. 1420 Note that since there is no padding between the "F(K_{N+1})" and 1421 "MAC(K'_i, M)" fields, this latter MAY not start on a 32 bit 1422 boundary, depending on the n_p parameter. 1424 0 1 2 3 1425 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 1426 +-+-+-+-+-+-+-+-+ 1427 | Reserved | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | i (Interval Index of K'_i) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | | 1432 ~ New Key Commitment F(K_{N+1}) ~ 1433 | | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | | 1436 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1437 | | Padding | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 ~ Weak Group MAC (optional) ~ 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 Figure 6: Format of the authentication tag with a new key chain 1443 commitment 1445 3.4.6. Format of an Authentication Tag with a ``Last Key of Old Chain'' 1446 Disclosure 1448 During the first n_tx_lastkey intervals of the new key chain after 1449 the disclosing interval, d, the sender SHOULD disclose the last key 1450 of the old key chain. This is done by replacing the disclosed key of 1451 the authentication tag with the last key of the old chain, K_N (or 1452 K_{2N+1} in case of a switch between the second and third key chains, 1453 etc.). Figure 7 shows the corresponding format. 1455 Note that since there is no padding between the "K_N" and "MAC(K'_i, 1456 M)" fields, this latter MAY not start on a 32 bit boundary, depending 1457 on the n_p parameter. 1459 0 1 2 3 1460 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 1461 +-+-+-+-+-+-+-+-+ 1462 | Reserved | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | i (Interval Index of K'_i) | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | | 1467 ~ Last Key of Old Chain, K_N ~ 1468 | | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | | 1471 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1472 | | Padding | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 ~ Weak Group MAC (optional) ~ 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 Figure 7: Format of the authentication tag with an old chain last key 1478 disclosure 1480 3.4.7. Format of the Compact Authentication Tags 1482 The four compact flavors of the Authentication tags follow. 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+ 1487 | i_LSB | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | | 1490 ~ Disclosed Key K_{i-d} ~ 1491 | | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | | 1494 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1495 | | i_NSB (opt) | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 ~ Weak Group MAC (optional) ~ 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Figure 8: Format of the compact authentication tag 1502 0 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+ 1505 | i_LSB | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | | 1508 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1509 | | i_NSB (opt) | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 ~ Weak Group MAC (optional) ~ 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 Figure 9: Format of the compact authentication tag without key 1515 disclosure 1517 0 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+ 1520 | i_LSB | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | 1523 ~ New Key Commitment F(K_{N+1}) ~ 1524 | | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | | 1527 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1528 | | i_NSB (opt) | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 ~ Weak Group MAC (optional) ~ 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 Figure 10: Format of the compact authentication tag with a new key 1534 chain commitment 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+ 1539 | i_LSB | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | | 1542 ~ Last Key of Old Chain, K_N ~ 1543 | | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | | 1546 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1547 | | i_NSB (opt) | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 ~ Weak Group MAC (optional) ~ 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Figure 11: Format of the compact authentication tag with a last key 1553 of old chain disclosure 1555 where: 1557 "i_LSB" (Interval Index Least Significant Byte) field (8 bits): 1559 the i_LSB field contains the least significant byte of the 1560 interval index associated to the key (K'_i) used to compute the 1561 MAC of this packet. 1563 "i_NSB" (Interval Index Next Significant Bytes) field (variable 1564 length, depending on the MAC type): 1566 the i_NSB field contains the next significant bytes (after i_LSB) 1567 of the interval index. This field replaces the "Padding" field 1568 when the MAC(K'_i, M) field length is not a multiple of 32 bits. 1570 The compact version does not include the "i" interval index but the 1571 "i_LSB" field and sometimes, depending on the MAC type, the "i_NSB" 1572 field. Upon receiving such an authentication tag, a receiver infers 1573 the associated "i" value, by estimating the current interval where 1574 the sender is supposed to be, assuming that this packet has not been 1575 significantly delayed by the network. The remaining of the 1576 processing does not change. 1578 For instance, with HMAC-SHA-1, the MAC(K'_i, M) field is 10 byte 1579 long. In that case the i_NSB field contains the middle two bytes of 1580 "i". Together with the i_LSB byte, the three least significant bytes 1581 of "i" are carried in the compact tag authentication header 1582 extensions. If T_int is 0.5s, then the {i_NSB; i_LSB} counter is 1583 sufficient (i.e. contains as much information as the 32 bit "i" 1584 field) for sessions that last at most 2330 hours. 1586 4. Receiver Operations 1588 This section describes the TESLA operations at a receiver. 1590 4.1. Verification of the Authentication Information 1592 This section details the computation steps required to verify each of 1593 the three possible authentication information of an incoming packet. 1594 The verification MUST follow a strict order: 1596 o first of all, verify the Weak Group Mac if present; 1598 o then verify the digital signature (with TESLA signaling packets) 1599 or enter the TESLA authentication process (with data packets) 1601 4.1.1. Processing the Weak Group MAC Tag 1603 Upon receiving a packet containing a Weak Group MAC Tag, the receiver 1604 recomputes the Weak Group MAC and compares it to the value carried in 1605 the packet. If the check fails, the packet MUST be immediately 1606 dropped. 1608 More specifically, recomputing the Weak Group MAC requires to save 1609 the value of the Weak Group MAC field, to set this field to 0, and to 1610 do the same computation as a sender does (see Section 3.3.3). 1612 4.1.2. Processing the Digital Signature 1614 Upon receiving a packet containing a digital signature, the receiver 1615 verifies the signature as follows. 1617 The computation of the signature MUST include the ALC or NORM header 1618 (with the various header extensions) and the payload when applicable. 1619 The UDP/IP headers MUST NOT be included. During this computation, 1620 the "Signature" field MUST be set to 0 as well as the optional Weak 1621 Group MAC, when present. 1623 From [RFC4359]: Digital signature verification is performed as 1624 described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and 1625 [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital 1626 signature is passed to the verification function as S. The 1627 authenticated portion of the packet is used as the message M, and the 1628 RSA public key is passed as (n, e). In summary (when SHA-1 is used), 1629 the verification function computes a SHA-1 hash of the authenticated 1630 packet bytes, decrypts the SHA-1 hash in the packet, and validates 1631 that the appropriate encoding was applied. The two SHA-1 hashes are 1632 compared, and if they are identical the validation is successful. 1634 It is assumed that the receivers have the possibility to retrieve the 1635 sender's public key required to check this digital signature 1636 (Section 2.2). This document does not specify how the public key of 1637 the sender is communicated reliably and in a secure way to all 1638 possible receivers. 1640 4.1.3. Processing the Authentication Tag 1642 When a receiver wants to authenticate a packet using an 1643 Authentication Tag and when he has the key for the associated time 1644 interval (i.e., after the disclosing delay, d), the receiver 1645 recomputes the MAC and compares it to the value carried in the 1646 packet. If the check fails, the packet MUST be immediately dropped. 1648 More specifically, recomputing the MAC requires to save the value of 1649 the MAC field, to set this field to 0, and to do the same computation 1650 as a sender does (see Section 3.3.1). 1652 4.2. Initialization of a Receiver 1654 A receiver must be initialized before being able to authenticate the 1655 source of incoming packets. This can be done by an out-of-band 1656 mechanism, out of the scope of the present document, or an in-band 1657 mechanism (Section 2.2). Let us focus on the in-band mechanism. Two 1658 actions must be performed: 1660 o receive and process a bootstrap information message, and 1662 o calculate an upper bound of the sender's local time. To that 1663 purpose, the receiver must perform time synchronization. 1665 4.2.1. Processing the Bootstrap Information Message 1667 A receiver must first receive a packet containing the bootstrap 1668 information, digitally signed by the sender. Once the bootstrap 1669 information has been authenticated (sec Section 4.1), the receiver 1670 can initialize its TESLA component. The receiver MUST then ignore 1671 the following bootstrap information messages, if any. There is an 1672 exception though: when a new key chain is used and if a receiver 1673 missed all the commitments for this new key chain, then this receiver 1674 MUST process one of the future Bootstrap information messages (if 1675 any) in order to be able to authenticate the incoming packets 1676 associated to this new key chain. 1678 Before TESLA has been initialized, a receiver MUST NOT process 1679 incoming packets other than the bootstrap information message and 1680 direct time synchronization response. 1682 4.2.2. Performing Time Synchronization 1684 First of all, the receiver must know whether the ALC or NORM session 1685 relies on direct or indirect time synchronization. This information 1686 is communicated by an out-of-band mechanism (for instance when 1687 describing the various parameters of an ALC or NORM session. In some 1688 cases, both mechanisms might be available and the receiver can choose 1689 the preferred technique. 1691 4.2.2.1. Direct Time Synchronization 1693 In case of a direct time synchronization, a receiver MUST synchronize 1694 with the sender. To that purpose, the receiver sends a direct time 1695 synchronization request message. This message includes the local 1696 time (NTP timestamp) at the receiver when sending the message. This 1697 timestamp will be copied in the sender's response for the receiver to 1698 associate the response to the request. 1700 The direct time synchronization request message format is the 1701 following: 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | | 1707 + t_r (NTP timestamp) + 1708 | | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 ~ Weak Group MAC (optional) ~ 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Figure 12: Format of a Direct Time Synchronization Request 1715 The direct time synchronization request (Figure 12) contains the 1716 following information: 1718 "t_r" (NTP timestamp, 64 bits): 1720 t_r is an NTP timestamp that contains the receiver local time 1721 value when sending this direct time synchronization request 1722 message; 1724 "Weak Group MAC" field (optional, variable length, multiple of 32 1725 bits): 1727 This field contains the weak group MAC, calculated with the group 1728 key, K_g, shared by all group members. The field length, in bits, 1729 is given by n_w which is known once the weak group MAC function 1730 type is known (Section 7). 1732 The receiver then awaits a response message (Section 3.4.2). Upon 1733 receiving this message, the receiver: 1735 checks that this response relates to the request, by comparing the 1736 t_r fields; 1738 checks the Weak Group MAC if present; 1740 checks the signature; 1742 retrieves the t_s value and calculates D_t (Section 2.4.1); 1744 Note that in an ALC session, the direct time synchronization request 1745 message is sent to the sender by an out-of-band mechanism that is not 1746 specified by the current document. 1748 4.2.2.2. Indirect Time Synchronization 1750 With the indirect time synchronization method, the sender MAY provide 1751 out-of-band the URL or IP address of the NTP server(s) he trusts 1752 along with an OPTIONAL certificate for each NTP server. When several 1753 NTP servers are specified, a receiver MUST choose one of them. This 1754 document does not specify how the choice is made, but for the sake of 1755 scalability, the clients SHOULD NOT use the same server if several 1756 possibilities are offered. The NTP synchronization between the NTP 1757 server and the receiver MUST be authenticated, either using the 1758 certificate provided by the server, or another certificate the client 1759 may obtain for this NTP server. 1761 Then the receiver computes the time offset between itself and the NTP 1762 server chosen. Note that the receiver does not need to update the 1763 local time, (which often requires root privileges), computing the 1764 time offset is sufficient. 1766 Since the offset between the server and the time reference, D^O_t, is 1767 indicated in the bootstrap information message (or communicated out- 1768 of-band), the receiver can now calculate an upper bound of the 1769 sender's local time (Section 2.4.2). 1771 4.3. Authentication of Received Packets 1773 The receiver can now authenticate incoming packets (other than 1774 bootstrap information and direct time synchronization response 1775 packets). To that purpose, he MUST follow different steps (see 1776 [RFC4082] section 3.5): 1778 1. The receiver parses the different packet headers. If none of the 1779 eight TESLA authentication tags is present, the receiver MUST 1780 discard the packet. If the session is in "Single Key Chain" mode 1781 (e.g., when the "S" flag is set in the bootstrap information 1782 message), then the receiver MUST discard any packet containing an 1783 authentication tag with a new key chain commitment or an 1784 authentication tag with a last key of old chain disclosure. 1786 2. Safe packet test: When the receiver receives packet P_j, it first 1787 records the local time T at which the packet arrived. The 1788 receiver then computes an upper bound t_j on the sender's clock 1789 at the time when the packet arrived: t_j = T + D_t. The receiver 1790 then computes the highest interval the sender could possibly be 1791 in: highest_i = floor((t_j - T_0) / T_int). Two possibilities 1792 arise then: 1794 * with a non compact authentication tag, the "i" interval index 1795 is available. Get it from the header. 1797 * When a compact authentication tag is used, the receiver must 1798 compute the corresponding "i" interval index from the "i_LSB" 1799 and perhaps "i_NSB" fields. The following algorithm is used: 1801 if (MAC(K'_i, M) is not padded) { 1802 // with HMAC-SHA-256 and higher, the i_LSB field is the only 1803 // field available to guess i. 1804 i_mask = 0xFFFFFF00; 1805 i_low = i_LSB; // lower bits of "i" 1806 } else { 1807 // with a two byte padding (i.e., HMAC-SHA-1 and HMAC-SHA-224), 1808 // the 2 byte i_NSB field is available in addition to i_LSB. 1809 i_mask = 0xFF000000; 1810 i_low = i_LSB + i_NSB; // lower bits of "i" 1811 } 1812 i_high = highest_i & i_mask; // (guessed) higher bits of "i", using 1813 // the highest interval the sender can 1814 // possibly be in. 1815 i = i_high + i_low; // raw guessed "i" 1816 if (i > highest_i) { 1817 // cycling took place. Since "i" cannot be larger than "highest_i", 1818 // decrement it. 1819 i_cycle = (~i_mask) + 1; // length of a cycle 1820 i = i - i_cycle; 1821 } 1822 The receiver can now proceed with the "safe packet" test. If 1823 highest_i < i + d, then the sender is not yet in the interval 1824 during which it discloses the key K_i. The packet is safe (but 1825 not necessarily authentic). If the test fails, the packet is 1826 unsafe, and the receiver MUST discard the packet. 1828 3. Weak Group MAC test: The receiver checks the optional Weak Group 1829 Tag, if present. To that purpose, the receiver recomputes the 1830 group MAC and compares it to the value stored in the "Weak Group 1831 MAC" field. If the check fails, the packet is immediately 1832 dropped. 1834 4. Disclosed Key processing: When the packet discloses a key (i.e., 1835 with a standard or compact authentication tag, or with a standard 1836 or compact authentication tag with a last key of old chain 1837 disclosure), the following tests are performed: 1839 * New key index test: the receiver checks whether a legitimate 1840 key already exists with the same index (i.e., i-d), or with an 1841 index strictly superior (i.e., with an index > i-d). If such 1842 a legitimate key exists, the receiver ignores the current 1843 disclosed key and skips the "Key verification test". 1845 * Key verification test: If the disclosed key index is new, the 1846 receiver checks the legitimacy of K_{i-d} by verifying, for 1847 some earlier disclosed and legitimate key K_v (with v < i-d), 1848 that K_v = F^{i-d-v}(K_{i-d}). In other words, the receiver 1849 checks the disclosed key by computing the necessary number of 1850 PRF functions to obtain a previously disclosed and legitimate 1851 (i.e., verified) key. If the key verification fails, the 1852 receiver MUST discard the packet. If the key verification 1853 succeeds, this key is said legitimate and is stored by the 1854 receiver. 1856 5. When applicable, the receiver performs congestion control, even 1857 if the packet has not yet been authenticated [RMT-BB-LCT]. If 1858 this feature leads to a potential DoS attack (the attacker can 1859 send a high data rate stream of faked packets), it does not 1860 compromise the security features offered by TESLA and enables a 1861 rapid reaction in front of actual congestion problems. 1863 6. The receiver then buffers the packet for a later authentication, 1864 once the corresponding key will be disclosed (after d time 1865 intervals) or deduced from another key (if all packets disclosing 1866 this key are lost). In some situations, this packet might also 1867 be discarded later on, if it turns out that the receiver will 1868 never be able to deduce the associated key. 1870 7. Authentication test: Let v be the smallest index of the 1871 legitimate keys known by the receiver so far. For all the new 1872 keys K_w, with v < w < = i-d, that have been either disclosed by 1873 this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in 1874 interval {v+1,.. i-d-1}), the receiver verifies the authenticity 1875 of the safe packets buffered for the corresponding interval w. 1876 To authenticate one of the buffered packets P_h containing 1877 message M_h protected with a MAC that used key index w, the 1878 receiver will compute K'_w = F'(K_w) from which it can compute 1879 MAC( K'_w, M_h). If this MAC does not equal the MAC stored in 1880 the packet, the receiver MUST discard the packet. If the two MAC 1881 are equal, the packet is successfully authenticated and the 1882 receiver continues processing it. 1884 8. Authenticated new key chain commitment processing: If the 1885 authenticated packet contains a new key chain commitment and if 1886 no verified commitment already exists, then the receiver stores 1887 the commitment to the new key chain. Then, if there are non 1888 authenticated packets for a previous chain (i.e., the key chain 1889 before the current one), all these packets can be discarded 1890 (Section 4.4). 1892 9. The receiver continues the ALC or NORM processing of all the 1893 packets authenticated during the authentication test. 1895 In this specification, a receiver using TESLA MUST immediately drop 1896 unsafe packets. But the receiver MAY also decide, at any time, to 1897 continue an ALC or NORM session in unsafe mode, ignoring TESLA 1898 extensions. 1900 4.4. Flushing the Non Authenticated Packets of a Previous Key Chain 1902 In some cases a receiver having experienced a very long disconnection 1903 might have lost all the disclosures of the last key(s) of a previous 1904 key chain. Let j be the index of this key chain for which there 1905 remains non authenticated packets. This receiver can flush all the 1906 packets of the key chain j if he determines that: 1908 o he has just switched to a chain of index j+2 (inclusive) or 1909 higher; 1911 o the sender has sent a commitment to the new key chain of index j+2 1912 (Section 3.1.2.3). This situation requires that the receiver has 1913 received a packet containing such a commitment and that he has 1914 been able to check its integrity. In some cases it might require 1915 to receive a bootstrap information message for the current key 1916 chain. 1918 If one of the above two tests succeeds, the sender can discard all 1919 the awaiting packets since there is no way to authenticate them. 1921 5. Integration in the ALC and NORM Protocols 1923 5.1. Authentication Header Extension Format 1925 The integration of TESLA in ALC or NORM is similar and relies on the 1926 header extension mechanism defined in both protocols. More precisely 1927 this document details the EXT_AUTH==1 header extension defined in 1928 [RMT-BB-LCT]. 1930 Editor's note: All authentication schemes using the EXT_AUTH 1931 header extension MUST reserve the same 4 bit "ASID" field after 1932 the HET/HEL fields. This way, several authentication schemes can 1933 be used in the same ALC or NORM session, even on the same 1934 communication path. 1936 Several fields are added in addition to the HET (Header Extension 1937 Type) and HEL (Header Extension Length) fields (Figure 14). 1939 0 1 2 3 1940 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 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | HET (=1) | HEL | ASID | Type | | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1944 | | 1945 ~ ~ 1946 | Content | 1947 ~ ~ 1948 | | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 Figure 14: Format of the TESLA EXT_AUTH header extension. 1953 The fields of the TESLA EXT_AUTH header extension are: 1955 "ASID" (Authentication Scheme Identifier) field (4 bits): 1957 The "ASID" identifies the source authentication scheme or protocol 1958 in use. The association between the "ASID" value and the actual 1959 authentication scheme is defined out-of-band, at session startup. 1961 "Type" field (4 bits): 1963 The "Type" field identifies the type of TESLA information carried 1964 in this header extension. This specification defines the 1965 following types: 1967 * 0: bootstrap information, sent by the sender periodically or 1968 after a direct time synchronization request; 1970 * 1: standard authentication tag for the on-going key chain, sent 1971 by the sender along with a packet; 1973 * 2: authentication tag without key disclosure, sent by the 1974 sender along with a packet; 1976 * 3: authentication tag with a new key chain commitment, sent by 1977 the sender when approaching the end of a key chain; 1979 * 4: authentication tag with a last key of old chain disclosure, 1980 sent by the sender some time after moving to a new key chain; 1982 * 5: compact (i.e., that contains the last byte of the interval 1983 index) authentication tag for the on-going key chain, sent by 1984 the sender along with a packet; 1986 * 6: compact (i.e., that contains the last byte of the interval 1987 index) authentication tag without any key disclosure, sent by 1988 the sender along with a packet; 1990 * 7: compact (i.e., that contains the last byte of the interval 1991 index) authentication tag with a new key chain commitment, sent 1992 by the sender when approaching the end of a key chain; 1994 * 8: compact (i.e., that contains the last byte of the interval 1995 index) authentication tag with a last key of old chain 1996 disclosure, sent by the sender some time after moving to a new 1997 key chain; 1999 * 9: direct time synchronization request, sent by a NORM 2000 receiver. This type of message is invalid in case of an ALC 2001 session since ALC is restricted to unidirectional 2002 transmissions. Yet an external mechanism may provide the 2003 direct time synchronization functionality. How this is done is 2004 out of the scope of this document; 2006 * 10: direct time synchronization response, sent by a NORM 2007 sender. This type of message is invalid in case of an ALC 2008 session since ALC is restricted to unidirectional 2009 transmissions. Yet an external mechanism may provide the 2010 direct time synchronization functionality. How this is done is 2011 out of the scope of this document; 2013 "Content" field (variable length): 2015 This is the TESLA information carried in the header extension, 2016 whose type is given by the "Type" field. 2018 5.2. Use of Authentication Header Extensions 2020 Each packet sent by the session's sender MUST contain exactly one 2021 TESLA EXT_AUTH header extension. 2023 All receivers MUST recognize EXT_AUTH but MAY not be able to parse 2024 its content, for instance because they do not support TESLA. In that 2025 case these receivers MUST ignore the TESLA EXT_AUTH extensions. In 2026 case of NORM, the packets sent by receivers MAY contain a direct 2027 synchronization request but MUST NOT contain any of the other five 2028 TESLA EXT_AUTH header extensions. 2030 5.2.1. EXT_AUTH Header Extension of Type Bootstrap Information 2032 The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in 2033 a stand-alone control packet, rather than in a packet containing 2034 application data. The reason for that is the large size of this 2035 bootstrap information. By using stand-alone packets, the maximum 2036 payload size of data packets is only affected by the (mandatory) 2037 authentication information header extension. 2039 With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in 2040 a control packet, i.e., containing no encoding symbol. 2042 With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in 2043 a NORM_CMD(APPLICATION) message. 2045 0 1 2 3 2046 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 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2048 | HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^ 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2050 | d | 1 | 1 | 1 | | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2052 | 1 | 1 | 128 | | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2054 | 0 (reserved) | T_int | | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2056 | | | 2057 + T_0 (NTP timestamp) + | 5 2058 | | | 2 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2060 | N (Key Chain Length) | | b 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y 2062 | Current Interval Index i | | t 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e 2064 | | | s 2065 + + | 2066 | | | 2067 + Current Key Chain Commitment + | 2068 | (20 bytes) | | 2069 + + | 2070 | | | 2071 + + | 2072 | | v 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2074 | | ^ 1 2075 + + | 2 2076 | | | 8 2077 . . | 2078 . Signature . | b 2079 . (128 bytes) . | y 2080 | | | t 2081 + + | e 2082 | | v s 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2084 | Weak Group MAC | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 Figure 15: Example: Format of the bootstrap information message (Type 2088 0), using SHA-1/1024 bit signatures, the default HMAC-SHA-1 and a 2089 Weak Group MAC. 2091 For instance Figure 15 shows the bootstrap information message when 2092 using the HMAC-SHA-1 transform for the PRF, MAC, and Weak Group MAC 2093 functions, along with SHA-1/128 byte (1024 bit) key digital 2094 signatures (which also means that the signature field is 128 byte 2095 long). The TESLA EXT_AUTH header extension is then 184 byte long 2096 (i.e., 46 words of 32 bits). 2098 5.2.2. EXT_AUTH Header Extension of Type Authentication Tag 2100 The eight "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, 4, 5, 6, 2101 7 and 8) MUST be attached to the ALC or NORM packet (data or control 2102 packet) that they protect. 2104 0 1 2 3 2105 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 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | HET (=1) | HEL (=9) | ASID | 5 | i_LSB | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | | 2110 + + 2111 | | 2112 + Disclosed Key K_{i-d} + 2113 | (20 bytes) | 2114 + + 2115 | | 2116 + + 2117 | | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | | 2120 + MAC(K'_i, M) + 2121 | (10 bytes) | 2122 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | | i_NSB | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 Figure 16: Example: Format of the standard authentication tag (Type 2127 5), using the default HMAC-SHA-1. 2129 0 1 2 3 2130 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 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | HET (=1) | HEL (=4) | ASID | 6 | i_LSB | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | | 2135 + MAC(K'_i, M) + 2136 | (10 bytes) | 2137 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | | i_NSB | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 Figure 17: Example: Format of the compact authentication tag without 2142 key disclosure (Type 6), using the default HMAC-SHA-1. 2144 For instance, Figure 16 and Figure 17 show the format of the compact 2145 authentication tags, respectively with and without the K_{i-d} key 2146 disclosure, when using the (default) HMAC-SHA-1 transform for the PRF 2147 and MAC functions. In this example, the Weak Group MAC feature is 2148 not used. 2150 5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization 2151 Request 2153 With NORM, the "direct time synchronization request" TESLA EXT_AUTH 2154 (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM 2155 packet. 2157 With ALC, the "direct time synchronization request" TESLA EXT_AUTH 2158 cannot be included in an ALC packet, since ALC is restricted to 2159 unidirectional transmissions, from the session's sender to the 2160 receivers. An external mechanism, out of the scope of this document, 2161 must be used with ALC for carrying direct time synchronization 2162 requests to the session's sender. 2164 In case of direct time synchronization, it is RECOMMENDED that the 2165 receivers spread the transmission of direct time synchronization 2166 requests over the time (Section 2.3.1). 2168 5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization 2169 Response 2171 With NORM, the "direct time synchronization response" TESLA EXT_AUTH 2172 (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION) 2173 message. 2175 With ALC, the "direct time synchronization response" TESLA EXT_AUTH 2176 can be sent in an ALC control packet (i.e., containing no encoding 2177 symbol) or through the external mechanism use to carry the direct 2178 time synchronization request. 2180 6. Security Considerations 2182 [RFC4082] discusses the security of TESLA in general. These 2183 considerations apply to the present specification, namely: 2185 o great care must be taken to the timing aspects. In particular the 2186 D_t parameter is critical and must be correctly initialized; 2188 o if the sender realizes that the key disclosure schedule are not 2189 appropriate, then the current session MUST be closed and a new one 2190 created. Indeed Section 3.1.3 requires that these parameters be 2191 fixed during the whole session. 2193 o when the verifier that authenticates the incoming packets and the 2194 application that uses the data are two different components, there 2195 is a risk that an attacker located between these components inject 2196 faked data. Similarly, when the verifier and the secure timing 2197 system are two different components, there is a risk that an 2198 attacker located between these components inject faked timing 2199 information. For instance, when the verifier reads the local time 2200 by means of a dedicated system call (e.g., gettimeofday()), if an 2201 attacker controls the host, he may catch the system call and 2202 return a faked time information. 2204 The current specification discusses additional aspects with more 2205 details. 2207 6.1. Dealing With DoS Attacks 2209 TESLA introduces new opportunities for an attacker to mount DoS 2210 attacks: for instance by saturating the processing capabilities of 2211 the receiver (faked packets are easy to create but checking them 2212 requires to compute a MAC over the packet or sometimes check a 2213 digital signature), or by saturating its memory (since authentication 2214 is delayed), or by making the receiver believe that a congestion has 2215 happened (since congestion control MUST be performed before 2216 authenticating incoming packets, Section 4.3). 2218 In order to mitigate these attacks, when it is believed that 2219 attackers do not belong to the group, it is RECOMMENDED to use the 2220 Weak Group MAC scheme (Section 3.3.3). 2222 Generally, it is RECOMMENDED that the amount of memory used to store 2223 incoming packets waiting to be authenticated be limited to a 2224 reasonable value. 2226 6.2. Dealing With Replay Attacks 2228 Replay attacks, whereby an attacker stores a valid message and 2229 replays it later on, can have significant impacts, depending on the 2230 message type. Two levels of impacts must be distinguished: 2232 o within the TESLA protocol, and 2234 o within the ALC or NORM protocol. 2236 6.2.1. Impacts of Replay Attacks on TESLA 2238 Replay attacks can impact the TESLA component itself. We review here 2239 the potential impacts of such an attack depending on the TESLA 2240 message type: 2242 o bootstrap information: since most parameters contained in a 2243 bootstrap information message are static, replay attacks have no 2244 consequences. The fact that the "i" and "K_i" fields can be 2245 updated in subsequent bootstrap information messages does not 2246 create a problem either, since all "i" and "K_i" fields sent 2247 remain valid. Finally, a receiver that successfully initialized 2248 its TESLA component should ignore the following messages 2249 (Section 4.2.1), which voids replay attacks, unless he missed all 2250 the commitments to a new key chain (e.g., after a long 2251 disconnection) (Section 3.2.1). 2253 o direct time synchronization request: If the Weak Group MAC scheme 2254 is used, an attacker that is not member of the group can replay a 2255 packet and oblige the sender to respond, which requires to 2256 digitally sign the response, a time-consuming process. If the 2257 Weak Group MAC scheme is not used, an attacker can anyway easily 2258 forge a request. In both cases, the attack will not compromise 2259 the TESLA component, but might create a DoS. If this is a 2260 concern, it is RECOMMENDED, when the Weak Group MAC scheme is 2261 used, that the sender verify the "t_r" NTP timestamp contained in 2262 the request and respond only if this value is strictly larger than 2263 the previous one received from this receiver. When the Weak Group 2264 MAC scheme is not used, this attack can be mitigated by limiting 2265 the number of requests per second that will be processed. 2267 o direct time synchronization response: Upon receiving a response, a 2268 receiver who has no pending request MUST immediately drop the 2269 packet. If this receiver has previously issued a request, he 2270 first checks the Weak Group MAC (if applicable), then the "t_r" 2271 field, to be sure it is a response to his request, and finally the 2272 digital signature. A replayed packet will be dropped during these 2273 verifications, without compromising the TESLA component. 2275 o other messages, containing an authentication tag: Replaying a 2276 packet containing a TESLA authentication tag will never compromise 2277 the TESLA component itself (but perhaps the underlying ALC or NORM 2278 component, see below). 2280 To conclude, TESLA itself is robust in front of replay attacks. 2282 6.2.2. Impacts of Replay Attacks on NORM 2284 We review here the potential impacts of a replay attack on the NORM 2285 component. Note that we do not consider here the protocols that 2286 could be used along with NORM, for instance the congestion control 2287 protocols. 2289 First, let us consider replay attacks within a given NORM session. 2290 NORM defines a "sequence" field that can be used to protect against 2291 replay attacks [RMT-PI-NORM] within a given NORM session. This 2292 "sequence" field is a 16-bit value that is set by the message 2293 originator (sender or receiver) as a monotonically increasing number 2294 incremented with each NORM message transmitted. It is RECOMMENDED 2295 that a receiver check this sequence field and drop messages 2296 considered as replayed. Similarly, it is RECOMMENDED that a sender 2297 check this sequence, for each known receiver, and drop messages 2298 considered as replayed. This analysis shows that NORM itself is 2299 robust in front of replay attacks within the same session. 2301 Now let us consider replay attacks across several NORM sessions. 2302 Since the key chain used in each session MUST differ, a packet 2303 replayed in a subsequent session will be identified as unauthentic. 2304 Therefore NORM is robust in front of replay attacks across different 2305 sessions. 2307 6.2.3. Impacts of Replay Attacks on ALC 2309 We review here the potential impacts of a replay attack on the ALC 2310 component. Note that we do not consider here the protocols that 2311 could be used along with ALC, for instance the layered or wave based 2312 congestion control protocols. 2314 First, let us consider replay attacks within a given ALC session: 2316 o Regular packets containing an authentication tag: a replayed 2317 message containing an encoding symbol will be detected once 2318 authenticated, thanks to the object/block/symbol identifiers, and 2319 will be silently discarded. This kind of replay attack is only 2320 penalizing in terms of memory and processing load, but does not 2321 compromise the ALC behavior. 2323 o Control packets containing an authentication tag: ALC control 2324 packets, by definition, do not include any encoding symbol and 2325 therefore do not include any object/block/symbol identifier that 2326 would enable a receiver to identify duplicates. However, a sender 2327 has a very limited number of reasons to send control packets. 2328 More precisely: 2330 * At the end of the session, a "close session" (A flag) packet is 2331 sent. Replaying this packet has no impact since the receivers 2332 already left. 2334 * Similarly, replaying a packet containing a "close object" (B 2335 flag) has no impact since this object is probably already 2336 marked as closed by the receiver. 2338 This analysis shows that ALC itself is robust in front of replay 2339 attacks within the same session. 2341 Now let us consider replay attacks across several ALC sessions. 2342 Since the key chain used in each session MUST differ, a packet 2343 replayed in a subsequent session will be identified as unauthentic. 2344 Therefore ALC is robust in front of replay attacks across different 2345 sessions. 2347 7. IANA Considerations 2349 This document requires a IANA registration for the following 2350 attributes: 2352 Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations 2353 MUST support HMAC-SHA-1 (default). 2355 +----------------------+-------+---------------------+ 2356 | PRF name | Value | n_p and n_f | 2357 +----------------------+-------+---------------------+ 2358 | INVALID | 0 | N/A | 2359 | | | | 2360 | HMAC-SHA-1 (default) | 1 | 160 bits (20 bytes) | 2361 | | | | 2362 | HMAC-SHA-224 | 2 | 224 bits (28 bytes) | 2363 | | | | 2364 | HMAC-SHA-256 | 3 | 256 bits (32 bytes) | 2365 | | | | 2366 | HMAC-SHA-384 | 4 | 384 bits (48 bytes) | 2367 | | | | 2368 | HMAC-SHA-512 | 5 | 512 bits (64 bytes) | 2369 +----------------------+-------+---------------------+ 2371 Cryptographic Message Authentication Code (MAC): All implementations 2372 MUST support HMAC-SHA-1 (default). These MAC schemes are used both 2373 for the computing of regular MAC and the Weak Group MAC (if 2374 applicable). 2376 +--------------------+-------+------------------+-------------------+ 2377 | MAC name | Value | n_m (regular | n_w (Weak Group | 2378 | | | MAC) | MAC) | 2379 +--------------------+-------+------------------+-------------------+ 2380 | INVALID | 0 | N/A | N/A | 2381 | | | | | 2382 | HMAC-SHA-1 | 1 | 80 bits (10 | 32 bits (4 bytes) | 2383 | (default) | | bytes) | | 2384 | | | | | 2385 | HMAC-SHA-224 | 2 | 112 bits (14 | 32 bits (4 bytes) | 2386 | | | bytes) | | 2387 | | | | | 2388 | HMAC-SHA-256 | 3 | 128 bits (16 | 32 bits (4 bytes) | 2389 | | | bytes) | | 2390 | | | | | 2391 | HMAC-SHA-384 | 4 | 192 bits (24 | 32 bits (4 bytes) | 2392 | | | bytes) | | 2393 | | | | | 2394 | HMAC-SHA-512 | 5 | 256 bits (32 | 32 bits (4 bytes) | 2395 | | | bytes) | | 2396 +--------------------+-------+------------------+-------------------+ 2398 Signature Encoding Algorithm: All implementations MUST support 2399 RSASSA-PKCS1-v1_5 (default). 2401 +-----------------------------+-------+ 2402 | Signature Algorithm Name | Value | 2403 +-----------------------------+-------+ 2404 | INVALID | 0 | 2405 | | | 2406 | RSASSA-PKCS1-v1_5 (default) | 1 | 2407 | | | 2408 | RSASSA-PSS | 2 | 2409 +-----------------------------+-------+ 2411 Signature Cryptographic Function: All implementations MUST support 2412 SHA-1 (default). 2414 +-----------------------------+-------+ 2415 | Cryptographic Function Name | Value | 2416 +-----------------------------+-------+ 2417 | INVALID | 0 | 2418 | | | 2419 | SHA-1 (default) | 1 | 2420 +-----------------------------+-------+ 2422 8. Acknowledgments 2424 The authors are grateful to Ran Canetti, David L. Mills and Lionel 2425 Giraud for their valuable comments while preparing this document. 2426 The authors are grateful to Brian Weis for the digital signature 2427 details. 2429 9. References 2431 9.1. Normative References 2433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2434 Requirement Levels", RFC 2119, BCP 14, March 1997. 2436 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 2437 Briscoe, "Timed Efficient Stream Loss-Tolerant 2438 Authentication (TESLA): Multicast Source Authentication 2439 Transform Introduction", RFC 4082, June 2005. 2441 [RMT-BB-LCT] 2442 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 2443 Transport (LCT) Building Block", 2444 draft-ietf-rmt-bb-lct-revised-07.txt (work in progress), 2445 July 2008. 2447 [RMT-PI-ALC] 2448 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2449 Layered Coding (ALC) Protocol Instantiation", 2450 draft-ietf-rmt-pi-alc-revised-05.txt (work in progress), 2451 November 2007. 2453 [RMT-PI-NORM] 2454 Adamson, B., Bormann, C., Handley, M., and J. Macker, 2455 "Negative-acknowledgment (NACK)-Oriented Reliable 2456 Multicast (NORM) Protocol", 2457 draft-ietf-rmt-pi-norm-revised-06.txt (work in progress), 2458 January 2008. 2460 9.2. Informative References 2462 [NTP-NTPv4] 2463 Burbank, J., Kasch, W., Martin, J., and D. Mills, "The 2464 Network Time Protocol Version 4 Protocol Specification", 2465 draft-ietf-ntp-ntpv4-proto-09.txt (work in progress), 2466 February 2008. 2468 [Perrig04] 2469 Perrig, A. and J. Tygar, "Secure Broadcast Communication 2470 in Wired and Wireless Networks", Kluwer Academic 2471 Publishers ISBN 0-7923-7650-1, 2004. 2473 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2474 Specification, Implementation", RFC 1305, March 1992. 2476 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2477 Hashing for Message Authentication", RFC 2104, 2478 February 1997. 2480 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2481 Standards (PKCS) #1: RSA Cryptography Specifications 2482 Version 2.1", RFC 3447, February 2003. 2484 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2485 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2486 RFC 3711, March 2004. 2488 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 2489 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 2491 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 2492 Encapsulating Security Payload (ESP) and Authentication 2493 Header (AH)", RFC 4359, January 2006. 2495 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 2496 Stream Loss-Tolerant Authentication (TESLA) in the Secure 2497 Real-time Transport Protocol (SRTP)", RFC 4383, 2498 February 2006. 2500 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed 2501 Efficient Stream Loss-Tolerant Authentication (TESLA)", 2502 RFC 4442, March 2006. 2504 [RMT-FLUTE] 2505 Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, 2506 "FLUTE - File Delivery over Unidirectional Transport", 2507 draft-ietf-rmt-flute-revised-05.txt (work in progress), 2508 October 2007. 2510 Authors' Addresses 2512 Vincent Roca 2513 INRIA 2514 655, av. de l'Europe 2515 Inovallee; Montbonnot 2516 ST ISMIER cedex 38334 2517 France 2519 Email: vincent.roca@inria.fr 2520 URI: http://planete.inrialpes.fr/~roca/ 2522 Aurelien Francillon 2523 INRIA 2524 655, av. de l'Europe 2525 Inovallee; Montbonnot 2526 ST ISMIER cedex 38334 2527 France 2529 Email: aurelien.francillon@inria.fr 2530 URI: http://planete.inrialpes.fr/~francill/ 2532 Sebastien Faurite 2533 INRIA 2534 655, av. de l'Europe 2535 Inovallee; Montbonnot 2536 ST ISMIER cedex 38334 2537 France 2539 Email: faurite@lcpc.fr 2541 Full Copyright Statement 2543 Copyright (C) The IETF Trust (2008). 2545 This document is subject to the rights, licenses and restrictions 2546 contained in BCP 78, and except as set forth therein, the authors 2547 retain all their rights. 2549 This document and the information contained herein are provided on an 2550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2557 Intellectual Property 2559 The IETF takes no position regarding the validity or scope of any 2560 Intellectual Property Rights or other rights that might be claimed to 2561 pertain to the implementation or use of the technology described in 2562 this document or the extent to which any license under such rights 2563 might or might not be available; nor does it represent that it has 2564 made any independent effort to identify any such rights. Information 2565 on the procedures with respect to rights in RFC documents can be 2566 found in BCP 78 and BCP 79. 2568 Copies of IPR disclosures made to the IETF Secretariat and any 2569 assurances of licenses to be made available, or the result of an 2570 attempt made to obtain a general license or permission for the use of 2571 such proprietary rights by implementers or users of this 2572 specification can be obtained from the IETF on-line IPR repository at 2573 http://www.ietf.org/ipr. 2575 The IETF invites any interested party to bring to its attention any 2576 copyrights, patents or patent applications, or other proprietary 2577 rights that may cover technology that may be required to implement 2578 this standard. Please address the information to the IETF at 2579 ietf-ipr@ietf.org. 2581 Acknowledgment 2583 Funding for the RFC Editor function is provided by the IETF 2584 Administrative Support Activity (IASA).